date:20161123

I think it's happening all at once in one block.

It's kind of a baroque way of doing it, however clever; an actual clear
method would be better, and a memset() call is fast and and among the least
controversial ways of zeroing a buffer.

On Wed, Nov 23, 2016 at 9:31 PM, Jonathan Wilkes  wrote:

> > Cyrille is doing it one go by exploiting the "bang" feature of switch~
> with an [until] loop to basically "fast forward" the zeroing process by
> however many blocks long the buffer is. It's really clever, and I don't
> think it screws anything up on the outside. This is a technique I'd never
> thought of, and I can imagine some interesting things coming from this
> (though I'm not sure it's a canonical technique or incidental). There are
> some things to think about, like whether the [inlet~] vector is cleared or
> if it just keeps the last 64 samples for each iteration of the [until] loop.
>
>
>
> I'm just talking in general about the idea of amortizing the cost of the
> operation
> across multiple blocks, which I assume is what's happening in his
> abstraction (or
> at least what's supposed to happen).
>
> Hm...
> In practice, how do you find Pd-l2ork's "clear" method compares to
> Cyrille's abstraction?
>
> -Jonathan
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [delwrite~], or "what Pd operations are/should be realtime?"

please show us (and miller) what it is about :)

2016-11-23 20:48 GMT-02:00 Orm Finnendahl <
orm.finnend...@selma.hfmdk-frankfurt.de>:

> Hi,
>
>  FYI, I patched vanilla pd when I prepared performances of Nono pieces
> by introducing a clear method into the delwrite~ a couple of years ago
> to speed up restarts at rehearsals. I already thought about proposing
> this as a change to the vanilla sources. It's quite trivial and I can
> send the patch if Miller is interested...
>
> --
> Orm
>
>
> Am Mittwoch, den 23. November 2016 um 20:25:48 Uhr (+0100) schrieb
> cyrille henry:
> > on my computer, using this patch, I can clear a 10mn delay with no click
> (using a 50ms audio setting buffer)...
> >
> >
> > Le 23/11/2016 à 20:07, cyrille henry a écrit :
> > > i don't understand the question.
> > > delwrite/delread emulate a tape delay, where the write pointer did not
> move, it's the read pointer (delread) that can move.
> > >
> > > anyway, I did not fully test this patch neither. I just made it
> because I prefer to patch than to complain.
> > >
> > > cheers
> > > c
> > >
> > >
> > > Le 23/11/2016 à 19:47, Matt Barber a écrit :
> > > > Ha ha ha! Great. I'm not sure if that would ever have occurred to
> me. I didn't check rigorously, but does it move the write pointer back to
> where it started?
> > > >
> > > > On Wed, Nov 23, 2016 at 1:40 PM, cyrille henry  > wrote:
> > > >
> > > >
> > > > here is a vanilla way to clear a delay line.
> > > > cheers
> > > > c
> > > >
> > > > Le 23/11/2016 à 18:59, Matt Barber a écrit :
> > > >
> > > > I don't know about average, but I have heard "longest delay
> I use is maybe 30-60 seconds" a few times. The bass piece I presented at
> PdCon has up to 30 seconds of delay for a complex mensuration/transposition
> canon, and it would be very useful to be able to clear it for rehearsal
> purposes.
> > > >
> > > > On Wed, Nov 23, 2016 at 12:35 PM, Jonathan Wilkes <
> jancs...@yahoo.com   >> wrote:
> > > >
> > > > > In this case, I'd probably rather see a hybrid
> approach where a second buffer is already waiting. Then you could give
> "clear 300", and it would switch to the empty buffer immediately while
> guaranteeing that the other one is clear in 300ms. But this is maybe too
> complicated for the user, and uses too much memory?
> > > >
> > > >
> > > >
> > > > Matt,
> > > > In the user reports, what is the average size of the
> buffer?  Are we really talking about buffers greater than, say, 1000ms?
> > > >
> > > > This sounds like premature optimization to me.
> > > >
> > > > -Jonathan
> > > >
> > > >
> > > > On Tue, Nov 22, 2016 at 7:32 AM, Ivica Bukvic <
> i...@vt.edu  >>
> wrote:
> > > >
> > > > For clear, I can imagine having a second empty
> memory buffer being created while delay continues to use the populated one
> until the memory allocation is complete. At that point a simple change in
> the pointer should suffice, after which the old buffer gets trashed. This
> would break determinacy, so perhaps a separate argument could be used to
> enable this option in which case the object could get another outlet that
> sends a bang when the procedure is complete.
> > > > Best,
> > > > --
> > > > Ivica Ico Bukvic, D.M.A.
> > > > Associate Professor
> > > > Computer Music
> > > > ICAT Senior Fellow
> > > > Director -- DISIS, L2Ork
> > > > Virginia Tech
> > > > School of Performing Arts – 0141
> > > > Blacksburg, VA 24061
> > > > (540) 231-6139 
> > > > i...@vt.edu   >
> > > > www.performingarts.vt.edu <
> http://www.performingarts.vt.edu>  http://www.performingarts.vt.edu/>>
> > > > disis.icat.vt.edu  <
> http://disis.icat.vt.edu/>
> > > > l2ork.icat.vt.edu  <
> http://l2ork.icat.vt.edu/>
> > > > ico.bukvic.net  <
> http://ico.bukvic.net/>
> > > >
> > > > On Nov 22, 2016 00:07, "Matt Barber" <
> brbrof...@gmail.com   brbrof...@gmail.com >> wrote:
> > > >
> > > > Hi list; thanks for a wonderful PdCon (to
> Stevens and NYU people especially).
> > > >
> > > > I had a quick chat with Miller after the "future
> of Pd" discussion. I told him there is one feature I've heard Pd users ask
> for many times: a "clear" method for

Re: [PD] [delwrite~], or "what Pd operations are/should be realtime?"

2016-11-23 Thread Orm Finnendahl

Hi,

 FYI, I patched vanilla pd when I prepared performances of Nono pieces
by introducing a clear method into the delwrite~ a couple of years ago
to speed up restarts at rehearsals. I already thought about proposing
this as a change to the vanilla sources. It's quite trivial and I can
send the patch if Miller is interested...

--
Orm


Am Mittwoch, den 23. November 2016 um 20:25:48 Uhr (+0100) schrieb
cyrille henry:
> on my computer, using this patch, I can clear a 10mn delay with no click 
> (using a 50ms audio setting buffer)...
> 
> 
> Le 23/11/2016 à 20:07, cyrille henry a écrit :
> > i don't understand the question.
> > delwrite/delread emulate a tape delay, where the write pointer did not 
> > move, it's the read pointer (delread) that can move.
> > 
> > anyway, I did not fully test this patch neither. I just made it because I 
> > prefer to patch than to complain.
> > 
> > cheers
> > c
> > 
> > 
> > Le 23/11/2016 à 19:47, Matt Barber a écrit :
> > > Ha ha ha! Great. I'm not sure if that would ever have occurred to me. I 
> > > didn't check rigorously, but does it move the write pointer back to where 
> > > it started?
> > > 
> > > On Wed, Nov 23, 2016 at 1:40 PM, cyrille henry  > > > wrote:
> > > 
> > > 
> > > here is a vanilla way to clear a delay line.
> > > cheers
> > > c
> > > 
> > > Le 23/11/2016 à 18:59, Matt Barber a écrit :
> > > 
> > > I don't know about average, but I have heard "longest delay I use 
> > > is maybe 30-60 seconds" a few times. The bass piece I presented at PdCon 
> > > has up to 30 seconds of delay for a complex mensuration/transposition 
> > > canon, and it would be very useful to be able to clear it for rehearsal 
> > > purposes.
> > > 
> > > On Wed, Nov 23, 2016 at 12:35 PM, Jonathan Wilkes 
> > >  
> > > >> wrote:
> > > 
> > > > In this case, I'd probably rather see a hybrid approach 
> > > where a second buffer is already waiting. Then you could give "clear 
> > > 300", and it would switch to the empty buffer immediately while 
> > > guaranteeing that the other one is clear in 300ms. But this is maybe too 
> > > complicated for the user, and uses too much memory?
> > > 
> > > 
> > > 
> > > Matt,
> > > In the user reports, what is the average size of the buffer?  
> > > Are we really talking about buffers greater than, say, 1000ms?
> > > 
> > > This sounds like premature optimization to me.
> > > 
> > > -Jonathan
> > > 
> > > 
> > > On Tue, Nov 22, 2016 at 7:32 AM, Ivica Bukvic  > >  >> wrote:
> > > 
> > > For clear, I can imagine having a second empty memory 
> > > buffer being created while delay continues to use the populated one until 
> > > the memory allocation is complete. At that point a simple change in the 
> > > pointer should suffice, after which the old buffer gets trashed. This 
> > > would break determinacy, so perhaps a separate argument could be used to 
> > > enable this option in which case the object could get another outlet that 
> > > sends a bang when the procedure is complete.
> > > Best,
> > > --
> > > Ivica Ico Bukvic, D.M.A.
> > > Associate Professor
> > > Computer Music
> > > ICAT Senior Fellow
> > > Director -- DISIS, L2Ork
> > > Virginia Tech
> > > School of Performing Arts – 0141
> > > Blacksburg, VA 24061
> > > (540) 231-6139 
> > > i...@vt.edu   > > >
> > > www.performingarts.vt.edu 
> > >   > > >
> > > disis.icat.vt.edu  
> > > 
> > > l2ork.icat.vt.edu  
> > > 
> > > ico.bukvic.net  
> > > 
> > > 
> > > On Nov 22, 2016 00:07, "Matt Barber"  > >   > > >> wrote:
> > > 
> > > Hi list; thanks for a wonderful PdCon (to Stevens and 
> > > NYU people especially).
> > > 
> > > I had a quick chat with Miller after the "future of 
> > > Pd" discussion. I told him there is one feature I've heard Pd users ask 
> > > for many times: a "clear" method for [delwrite~]. A [delwrite~] resize 
> > > method is something I've heard brought up a number of times as well,

Re: [PD] abl_link~ external for windows

2016-11-23 Thread Lucas Cordiviola

Cool,

Loads with no problem and when turning on DSP I get output.

Don`t have another app to do tests but I will try these days.

IOhannes mentions doing the Deken package, he's right, there are versions for 
OSX and Linux, we are missing the w32.

If you already have and account on puredata.info just upload the Zip (in your 
section) with a suitable name for a Deken pkg :

abl_link~-v0.1-(Windows-i386-32)-externals.zip

Thats all, it will be available via Deken.

More on this:
https://github.com/pure-data/deken/blob/master/developer/README.md


Salutti,
Lucarda.



Mensaje telepatico asistido por maquinas.



From: Jean-Yves Gratius 
Sent: Wednesday, November 23, 2016 10:19 AM
To: Jean-Yves Gratius; pd-list@lists.iem.at; Lucas Cordiviola
Subject: Re: [PD] abl_link~ external for windows


Hi

Please check the new binary @  
https://sourceforge.net/projects/jygsdownloads/files/abl_link%7E4windows/


that may resolve all dll dependancies.

Works on virtual XP and Windows 7 machines.

Let me know,

regards

Le 22 novembre 2016 à 23:17, Lucas Cordiviola 
 a écrit :




Hi Jean-Yves

I`m having trouble with [abl_link~ ].
..

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [delwrite~], or "what Pd operations are/should be realtime?"

Cyrille is doing it one go by exploiting the "bang" feature of switch~ with
an [until] loop to basically "fast forward" the zeroing process by however
many blocks long the buffer is. It's really clever, and I don't think it
screws anything up on the outside. This is a technique I'd never thought
of, and I can imagine some interesting things coming from this (though I'm
not sure it's a canonical technique or incidental). There are some things
to think about, like whether the [inlet~] vector is cleared or if it just
keeps the last 64 samples for each iteration of the [until] loop.

On Wed, Nov 23, 2016 at 4:19 PM, Jonathan Wilkes  wrote:

> > Yeah, this is the kind of thing I think about often. The thing is, if
> "clear" is included with [delwrite~], and people are using 30-60 seconds of
> delay, people are going to use "clear" in those circumstances at some point.
>
>
>
> If that turns out to be then it's a matter of revising the algo to "smear"
> the work of zeroing across the affected blocks, like Cyrille is
> doing.  Or am I missing something?
>
> > For the piece, sure – ramping down, switch~ing off, and clearing would
> be great. Sometimes you want to start in the middle, and you'd rather have
> zeroes than detritus from the last pass in the buffer.
>
> Makes sense.
>
> -Jonathan
>
> On Wed, Nov 23, 2016 at 2:12 PM, Jonathan Wilkes 
> wrote:
>
> > I don't know about average, but I have heard "longest delay I use is
> maybe 30-60 seconds" a few times.
>
> In a case where the user wants a "clear" method that works in realtime
> without dropouts?
>
> > The bass piece I presented at PdCon has up to 30 seconds of delay for a
> complex mensuration/transposition canon, and it would be very useful to be
> able to clear it for rehearsal purposes.
>
> When the performer stops, do you want the DSP graph to continue unabated?
> Or could you ramp down and duck out of dsp computation to trigger the
> "clear" method?
>
> -Jonathan
>
>
>
> On Wed, Nov 23, 2016 at 12:35 PM, Jonathan Wilkes 
> wrote:
>
> > In this case, I'd probably rather see a hybrid approach where a second
> buffer is already waiting. Then you could give "clear 300", and it would
> switch to the empty buffer immediately while guaranteeing that the other
> one is clear in 300ms. But this is maybe too complicated for the user, and
> uses too much memory?
>
>
>
> Matt,
> In the user reports, what is the average size of the buffer?  Are we
> really talking about buffers greater than, say, 1000ms?
>
> This sounds like premature optimization to me.
>
> -Jonathan
>
>
> On Tue, Nov 22, 2016 at 7:32 AM, Ivica Bukvic  wrote:
>
> For clear, I can imagine having a second empty memory buffer being created
> while delay continues to use the populated one until the memory allocation
> is complete. At that point a simple change in the pointer should suffice,
> after which the old buffer gets trashed. This would break determinacy, so
> perhaps a separate argument could be used to enable this option in which
> case the object could get another outlet that sends a bang when the
> procedure is complete.
> Best,
> --
> Ivica Ico Bukvic, D.M.A.
> Associate Professor
> Computer Music
> ICAT Senior Fellow
> Director -- DISIS, L2Ork
> Virginia Tech
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> i...@vt.edu
> www.performingarts.vt.edu
> disis.icat.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
>
> On Nov 22, 2016 00:07, "Matt Barber"  wrote:
>
> Hi list; thanks for a wonderful PdCon (to Stevens and NYU people
> especially).
>
> I had a quick chat with Miller after the "future of Pd" discussion. I told
> him there is one feature I've heard Pd users ask for many times: a "clear"
> method for [delwrite~]. A [delwrite~] resize method is something I've heard
> brought up a number of times as well, but I didn't mention it.
>
> Each of these has a runtime cost that could disrupt the realtime dsp
> calculation. Clearing a [delwrite~] is a linear-time operation, and for
> long delay lines it could cause audio dropouts; resizing is more
> problematic because it's not clear what to do with samples already in the
> delay line – probably it would need to be cleared as well, which would take
> even more time (although there is already an indirect resize function when
> sample rate is changed).
>
> On the other hand, Pd arrays can be resized and cleared (const 0) ad
> libitum, which is more or less the same operation. We usually tell users
> 'do this at your own risk when computing audio.'
>
> So what is the main difference? I think it's that [delwrite~] is a tilde
> object that is supposed not to cause dropouts on its own. If clearing it
> could cause a dropout, there are reasons for thinking of that as a bug
> rather than simply a risk.
>
> Is there a compromise procedure? We could add an option to spread the
> clearing out over time. For instance "clear 5000" would

Re: [PD] [delwrite~], or "what Pd operations are/should be realtime?"

2016-11-23 Thread Jonathan Wilkes via Pd-list

> Yeah, this is the kind of thing I think about often. The thing is, if "clear" 
> is included with [delwrite~], and people are using 30-60 seconds of delay, 
> people are going to use "clear" in those circumstances at some point.

If that turns out to be then it's a matter of revising the algo to "smear" the 
work of zeroing across the affected blocks, like Cyrille is 
doing.  Or am I missing something?

> For the piece, sure – ramping down, switch~ing off, and clearing would be 
> great. Sometimes you want to start in the middle, and you'd rather have 
> zeroes than detritus from the last pass in the buffer.
Makes sense.
-Jonathan

On Wed, Nov 23, 2016 at 2:12 PM, Jonathan Wilkes  wrote:

> I don't know about average, but I have heard "longest delay I use is maybe 
> 30-60 seconds" a few times.
In a case where the user wants a "clear" method that works in realtime without 
dropouts?

> The bass piece I presented at PdCon has up to 30 seconds of delay for a 
> complex mensuration/transposition canon, and it would be very useful to be 
> able to clear it for rehearsal purposes.
When the performer stops, do you want the DSP graph to continue unabated?  Or 
could you ramp down and duck out of dsp computation to trigger the "clear" 
method?
-Jonathan

On Wed, Nov 23, 2016 at 12:35 PM, Jonathan Wilkes  wrote:

> In this case, I'd probably rather see a hybrid approach where a second buffer 
> is already waiting. Then you could give "clear 300", and it would switch to 
> the empty buffer immediately while guaranteeing that the other one is clear 
> in 300ms. But this is maybe too complicated for the user, and uses too much 
> memory?

Matt,In the user reports, what is the average size of the buffer?  Are we 
really talking about buffers greater than, say, 1000ms?
This sounds like premature optimization to me.
-Jonathan

On Tue, Nov 22, 2016 at 7:32 AM, Ivica Bukvic  wrote:

For clear, I can imagine having a second empty memory buffer being created 
while delay continues to use the populated one until the memory allocation is 
complete. At that point a simple change in the pointer should suffice, after 
which the old buffer gets trashed. This would break determinacy, so perhaps a 
separate argument could be used to enable this option in which case the object 
could get another outlet that sends a bang when the procedure is 
complete.Best,-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Nov 22, 2016 00:07, "Matt Barber"  wrote:

Hi list; thanks for a wonderful PdCon (to Stevens and NYU people especially).
I had a quick chat with Miller after the "future of Pd" discussion. I told him 
there is one feature I've heard Pd users ask for many times: a "clear" method 
for [delwrite~]. A [delwrite~] resize method is something I've heard brought up 
a number of times as well, but I didn't mention it.
Each of these has a runtime cost that could disrupt the realtime dsp 
calculation. Clearing a [delwrite~] is a linear-time operation, and for long 
delay lines it could cause audio dropouts; resizing is more problematic because 
it's not clear what to do with samples already in the delay line – probably it 
would need to be cleared as well, which would take even more time (although 
there is already an indirect resize function when sample rate is changed).
On the other hand, Pd arrays can be resized and cleared (const 0) ad libitum, 
which is more or less the same operation. We usually tell users 'do this at 
your own risk when computing audio.'
So what is the main difference? I think it's that [delwrite~] is a tilde object 
that is supposed not to cause dropouts on its own. If clearing it could cause a 
dropout, there are reasons for thinking of that as a bug rather than simply a 
risk.
Is there a compromise procedure? We could add an option to spread the clearing 
out over time. For instance "clear 5000" would mean "clear the delay line over 
the next 5000 ms." A second argument would let the user choose whether to 
preferentially preserve the most recent samples or the oldest samples. Given 
only a time argument, default would be to preserve oldest samples (less work 
has to be done overall since the write pointer would also be filling the line 
with zeroes). Without a time argument (i.e. "clear" with no arguments), the 
default would be to clear it immediately with the understanding that there 
could be a possible dropout.
A broader topic for another time would be "what Pd operations are/should be 
realtime, and which are best at load time?"
Thoughts?
Matt
__ _
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/li

[PD] controlling a robot arm

2016-11-23 Thread me.grimm

to the land of collective knowledge:

we are working on controlling a 6-axis industrial robot arm (puma 560) with
pd/arduino(mega). last month i was attempting to write my own arduino code
and successfully moved one of the servo motors with a number box. a couple
questions:

1) has anybody controlled a multi-axis robot arm with pd/arduino before?
tips?
2) onyx mentioned at the pdcon to just use firmata on the arduino and be
done with it. will this suffice?

my arduino knowledge is still quite limited so before i throw too much time
behind pduino/firmata stuff i just want to make sure it will be worthwhile,
save time, etc

also we built our own controller with sabertooth/kangaroo combo with
arduino as the serial interface. the servo motor encoders seem to be
producing quite the noise. what is the advice of filtering this noise? in
hardware (arduino) or software(pd)?

thanks!

m
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [delwrite~], or "what Pd operations are/should be realtime?"

on my computer, using this patch, I can clear a 10mn delay with no click (using
a 50ms audio setting buffer)...

Le 23/11/2016 à 20:07, cyrille henry a écrit :

i don't understand the question.
delwrite/delread emulate a tape delay, where the write pointer did not move,
it's the read pointer (delread) that can move.

anyway, I did not fully test this patch neither. I just made it because I
prefer to patch than to complain.

cheers
c

Le 23/11/2016 à 19:47, Matt Barber a écrit :

Ha ha ha! Great. I'm not sure if that would ever have occurred to me. I
didn't check rigorously, but does it move the write pointer back to where it
started?

On Wed, Nov 23, 2016 at 1:40 PM, cyrille henry > wrote:

here is a vanilla way to clear a delay line.
cheers
c

Le 23/11/2016 à 18:59, Matt Barber a écrit :

I don't know about average, but I have heard "longest delay I use is maybe
30-60 seconds" a few times. The bass piece I presented at PdCon has up to 30 seconds
of delay for a complex mensuration/transposition canon, and it would be very useful to be
able to clear it for rehearsal purposes.

On Wed, Nov 23, 2016 at 12:35 PM, Jonathan Wilkes >> wrote:

> In this case, I'd probably rather see a hybrid approach where a second
buffer is already waiting. Then you could give "clear 300", and it would switch to
the empty buffer immediately while guaranteeing that the other one is clear in 300ms. But
this is maybe too complicated for the user, and uses too much memory?

Matt,
In the user reports, what is the average size of the buffer? Are
we really talking about buffers greater than, say, 1000ms?

This sounds like premature optimization to me.

-Jonathan

On Tue, Nov 22, 2016 at 7:32 AM, Ivica Bukvic
>> wrote:

For clear, I can imagine having a second empty memory buffer
being created while delay continues to use the populated one until the memory
allocation is complete. At that point a simple change in the pointer should
suffice, after which the old buffer gets trashed. This would break determinacy,
so perhaps a separate argument could be used to enable this option in which
case the object could get another outlet that sends a bang when the procedure
is complete.
Best,
--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu >
www.performingarts.vt.edu
>
disis.icat.vt.edu

l2ork.icat.vt.edu

ico.bukvic.net

On Nov 22, 2016 00:07, "Matt Barber" >>
wrote:

Hi list; thanks for a wonderful PdCon (to Stevens and NYU
people especially).

I had a quick chat with Miller after the "future of Pd" discussion. I
told him there is one feature I've heard Pd users ask for many times: a "clear" method
for [delwrite~]. A [delwrite~] resize method is something I've heard brought up a number of times
as well, but I didn't mention it.

Each of these has a runtime cost that could disrupt the
realtime dsp calculation. Clearing a [delwrite~] is a linear-time operation,
and for long delay lines it could cause audio dropouts; resizing is more
problematic because it's not clear what to do with samples already in the delay
line – probably it would need to be cleared as well, which would take even more
time (although there is already an indirect resize function when sample rate is
changed).

On the other hand, Pd arrays can be resized and cleared
(const 0) ad libitum, which is more or less the same operation. We usually tell
users 'do this at your own risk when computing audio.'

So what is the main difference? I think it's that
[delwrite~] is a tilde object that is supposed not to cause dropouts on its
own. If clearing it could cause a dropout, there are reasons for thinking of
that as a bug rather than simply a risk.

Re: [PD] [delwrite~], or "what Pd operations are/should be realtime?"

Yeah, this is the kind of thing I think about often. The thing is, if
"clear" is included with [delwrite~], and people are using 30-60 seconds of
delay, people are going to use "clear" in those circumstances at some point.

For the piece, sure – ramping down, switch~ing off, and clearing would be
great. Sometimes you want to start in the middle, and you'd rather have
zeroes than detritus from the last pass in the buffer.

On Wed, Nov 23, 2016 at 2:12 PM, Jonathan Wilkes  wrote:

> > I don't know about average, but I have heard "longest delay I use is
> maybe 30-60 seconds" a few times.
>
> In a case where the user wants a "clear" method that works in realtime
> without dropouts?
>
> > The bass piece I presented at PdCon has up to 30 seconds of delay for a
> complex mensuration/transposition canon, and it would be very useful to be
> able to clear it for rehearsal purposes.
>
> When the performer stops, do you want the DSP graph to continue unabated?
> Or could you ramp down and duck out of dsp computation to trigger the
> "clear" method?
>
> -Jonathan
>
>
>
> On Wed, Nov 23, 2016 at 12:35 PM, Jonathan Wilkes 
> wrote:
>
> > In this case, I'd probably rather see a hybrid approach where a second
> buffer is already waiting. Then you could give "clear 300", and it would
> switch to the empty buffer immediately while guaranteeing that the other
> one is clear in 300ms. But this is maybe too complicated for the user, and
> uses too much memory?
>
>
>
> Matt,
> In the user reports, what is the average size of the buffer?  Are we
> really talking about buffers greater than, say, 1000ms?
>
> This sounds like premature optimization to me.
>
> -Jonathan
>
>
> On Tue, Nov 22, 2016 at 7:32 AM, Ivica Bukvic  wrote:
>
> For clear, I can imagine having a second empty memory buffer being created
> while delay continues to use the populated one until the memory allocation
> is complete. At that point a simple change in the pointer should suffice,
> after which the old buffer gets trashed. This would break determinacy, so
> perhaps a separate argument could be used to enable this option in which
> case the object could get another outlet that sends a bang when the
> procedure is complete.
> Best,
> --
> Ivica Ico Bukvic, D.M.A.
> Associate Professor
> Computer Music
> ICAT Senior Fellow
> Director -- DISIS, L2Ork
> Virginia Tech
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> i...@vt.edu
> www.performingarts.vt.edu
> disis.icat.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
>
> On Nov 22, 2016 00:07, "Matt Barber"  wrote:
>
> Hi list; thanks for a wonderful PdCon (to Stevens and NYU people
> especially).
>
> I had a quick chat with Miller after the "future of Pd" discussion. I told
> him there is one feature I've heard Pd users ask for many times: a "clear"
> method for [delwrite~]. A [delwrite~] resize method is something I've heard
> brought up a number of times as well, but I didn't mention it.
>
> Each of these has a runtime cost that could disrupt the realtime dsp
> calculation. Clearing a [delwrite~] is a linear-time operation, and for
> long delay lines it could cause audio dropouts; resizing is more
> problematic because it's not clear what to do with samples already in the
> delay line – probably it would need to be cleared as well, which would take
> even more time (although there is already an indirect resize function when
> sample rate is changed).
>
> On the other hand, Pd arrays can be resized and cleared (const 0) ad
> libitum, which is more or less the same operation. We usually tell users
> 'do this at your own risk when computing audio.'
>
> So what is the main difference? I think it's that [delwrite~] is a tilde
> object that is supposed not to cause dropouts on its own. If clearing it
> could cause a dropout, there are reasons for thinking of that as a bug
> rather than simply a risk.
>
> Is there a compromise procedure? We could add an option to spread the
> clearing out over time. For instance "clear 5000" would mean "clear the
> delay line over the next 5000 ms." A second argument would let the user
> choose whether to preferentially preserve the most recent samples or the
> oldest samples. Given only a time argument, default would be to preserve
> oldest samples (less work has to be done overall since the write pointer
> would also be filling the line with zeroes). Without a time argument (i.e.
> "clear" with no arguments), the default would be to clear it immediately
> with the understanding that there could be a possible dropout.
>
> A broader topic for another time would be "what Pd operations are/should
> be realtime, and which are best at load time?"
>
> Thoughts?
>
> Matt
>
> __ _
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
> stinfo/pd-list 
>
>

Re: [PD] [delwrite~], or "what Pd operations are/should be realtime?"

2016-11-23 Thread Jonathan Wilkes via Pd-list

> I don't know about average, but I have heard "longest delay I use is maybe 
> 30-60 seconds" a few times.
In a case where the user wants a "clear" method that works in realtime without 
dropouts?

> The bass piece I presented at PdCon has up to 30 seconds of delay for a 
> complex mensuration/transposition canon, and it would be very useful to be 
> able to clear it for rehearsal purposes.
When the performer stops, do you want the DSP graph to continue unabated?  Or 
could you ramp down and duck out of dsp computation to trigger the "clear" 
method?
-Jonathan

On Wed, Nov 23, 2016 at 12:35 PM, Jonathan Wilkes  wrote:

> In this case, I'd probably rather see a hybrid approach where a second buffer 
> is already waiting. Then you could give "clear 300", and it would switch to 
> the empty buffer immediately while guaranteeing that the other one is clear 
> in 300ms. But this is maybe too complicated for the user, and uses too much 
> memory?

Matt,In the user reports, what is the average size of the buffer?  Are we 
really talking about buffers greater than, say, 1000ms?
This sounds like premature optimization to me.
-Jonathan

On Tue, Nov 22, 2016 at 7:32 AM, Ivica Bukvic  wrote:

For clear, I can imagine having a second empty memory buffer being created 
while delay continues to use the populated one until the memory allocation is 
complete. At that point a simple change in the pointer should suffice, after 
which the old buffer gets trashed. This would break determinacy, so perhaps a 
separate argument could be used to enable this option in which case the object 
could get another outlet that sends a bang when the procedure is 
complete.Best,-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Nov 22, 2016 00:07, "Matt Barber"  wrote:

Hi list; thanks for a wonderful PdCon (to Stevens and NYU people especially).
I had a quick chat with Miller after the "future of Pd" discussion. I told him 
there is one feature I've heard Pd users ask for many times: a "clear" method 
for [delwrite~]. A [delwrite~] resize method is something I've heard brought up 
a number of times as well, but I didn't mention it.
Each of these has a runtime cost that could disrupt the realtime dsp 
calculation. Clearing a [delwrite~] is a linear-time operation, and for long 
delay lines it could cause audio dropouts; resizing is more problematic because 
it's not clear what to do with samples already in the delay line – probably it 
would need to be cleared as well, which would take even more time (although 
there is already an indirect resize function when sample rate is changed).
On the other hand, Pd arrays can be resized and cleared (const 0) ad libitum, 
which is more or less the same operation. We usually tell users 'do this at 
your own risk when computing audio.'
So what is the main difference? I think it's that [delwrite~] is a tilde object 
that is supposed not to cause dropouts on its own. If clearing it could cause a 
dropout, there are reasons for thinking of that as a bug rather than simply a 
risk.
Is there a compromise procedure? We could add an option to spread the clearing 
out over time. For instance "clear 5000" would mean "clear the delay line over 
the next 5000 ms." A second argument would let the user choose whether to 
preferentially preserve the most recent samples or the oldest samples. Given 
only a time argument, default would be to preserve oldest samples (less work 
has to be done overall since the write pointer would also be filling the line 
with zeroes). Without a time argument (i.e. "clear" with no arguments), the 
default would be to clear it immediately with the understanding that there 
could be a possible dropout.
A broader topic for another time would be "what Pd operations are/should be 
realtime, and which are best at load time?"
Thoughts?
Matt
__ _
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/li 
stinfo/pd-list

__ _
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/ 
listinfo/pd-list

   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [delwrite~], or "what Pd operations are/should be realtime?"

i don't understand the question.
delwrite/delread emulate a tape delay, where the write pointer did not move,
it's the read pointer (delread) that can move.

anyway, I did not fully test this patch neither. I just made it because I
prefer to patch than to complain.

cheers
c

Le 23/11/2016 à 19:47, Matt Barber a écrit :

Ha ha ha! Great. I'm not sure if that would ever have occurred to me. I
didn't check rigorously, but does it move the write pointer back to where it
started?

On Wed, Nov 23, 2016 at 1:40 PM, cyrille henry > wrote:

here is a vanilla way to clear a delay line.
cheers
c

Le 23/11/2016 à 18:59, Matt Barber a écrit :

On Wed, Nov 23, 2016 at 12:35 PM, Jonathan Wilkes >> wrote:

Matt,
In the user reports, what is the average size of the buffer? Are
we really talking about buffers greater than, say, 1000ms?

This sounds like premature optimization to me.

-Jonathan

On Tue, Nov 22, 2016 at 7:32 AM, Ivica Bukvic
>> wrote:

l2ork.icat.vt.edu

ico.bukvic.net

On Nov 22, 2016 00:07, "Matt Barber" >>
wrote:

Hi list; thanks for a wonderful PdCon (to Stevens and NYU
people especially).

On the other hand, Pd arrays can be resized and cleared
(const 0) ad libitum, which is more or less the same operation. We usually tell
users 'do this at your own risk when computing audio.'

Is there a compromise procedure? We could add an option to spread the clearing out over
time. For instance "clear 5000" would mean "clear the

Re: [PD] [delwrite~], or "what Pd operations are/should be realtime?"

Ha ha ha! Great. I'm not sure if that would ever have occurred to me. I
didn't check rigorously, but does it move the write pointer back to where
it started?

On Wed, Nov 23, 2016 at 1:40 PM, cyrille henry  wrote:

>
> here is a vanilla way to clear a delay line.
> cheers
> c
>
> Le 23/11/2016 à 18:59, Matt Barber a écrit :
>
>> I don't know about average, but I have heard "longest delay I use is
>> maybe 30-60 seconds" a few times. The bass piece I presented at PdCon has
>> up to 30 seconds of delay for a complex mensuration/transposition canon,
>> and it would be very useful to be able to clear it for rehearsal purposes.
>>
>> On Wed, Nov 23, 2016 at 12:35 PM, Jonathan Wilkes > > wrote:
>>
>> > In this case, I'd probably rather see a hybrid approach where a
>> second buffer is already waiting. Then you could give "clear 300", and it
>> would switch to the empty buffer immediately while guaranteeing that the
>> other one is clear in 300ms. But this is maybe too complicated for the
>> user, and uses too much memory?
>>
>>
>>
>> Matt,
>> In the user reports, what is the average size of the buffer?  Are we
>> really talking about buffers greater than, say, 1000ms?
>>
>> This sounds like premature optimization to me.
>>
>> -Jonathan
>>
>>
>> On Tue, Nov 22, 2016 at 7:32 AM, Ivica Bukvic  i...@vt.edu>> wrote:
>>
>> For clear, I can imagine having a second empty memory buffer
>> being created while delay continues to use the populated one until the
>> memory allocation is complete. At that point a simple change in the pointer
>> should suffice, after which the old buffer gets trashed. This would break
>> determinacy, so perhaps a separate argument could be used to enable this
>> option in which case the object could get another outlet that sends a bang
>> when the procedure is complete.
>> Best,
>> --
>> Ivica Ico Bukvic, D.M.A.
>> Associate Professor
>> Computer Music
>> ICAT Senior Fellow
>> Director -- DISIS, L2Ork
>> Virginia Tech
>> School of Performing Arts – 0141
>> Blacksburg, VA 24061
>> (540) 231-6139
>> i...@vt.edu 
>> www.performingarts.vt.edu 
>> disis.icat.vt.edu 
>> l2ork.icat.vt.edu 
>> ico.bukvic.net 
>>
>> On Nov 22, 2016 00:07, "Matt Barber" > > wrote:
>>
>> Hi list; thanks for a wonderful PdCon (to Stevens and NYU
>> people especially).
>>
>> I had a quick chat with Miller after the "future of Pd"
>> discussion. I told him there is one feature I've heard Pd users ask for
>> many times: a "clear" method for [delwrite~]. A [delwrite~] resize method
>> is something I've heard brought up a number of times as well, but I didn't
>> mention it.
>>
>> Each of these has a runtime cost that could disrupt the
>> realtime dsp calculation. Clearing a [delwrite~] is a linear-time
>> operation, and for long delay lines it could cause audio dropouts; resizing
>> is more problematic because it's not clear what to do with samples already
>> in the delay line – probably it would need to be cleared as well, which
>> would take even more time (although there is already an indirect resize
>> function when sample rate is changed).
>>
>> On the other hand, Pd arrays can be resized and cleared
>> (const 0) ad libitum, which is more or less the same operation. We usually
>> tell users 'do this at your own risk when computing audio.'
>>
>> So what is the main difference? I think it's that [delwrite~]
>> is a tilde object that is supposed not to cause dropouts on its own. If
>> clearing it could cause a dropout, there are reasons for thinking of that
>> as a bug rather than simply a risk.
>>
>> Is there a compromise procedure? We could add an option to
>> spread the clearing out over time. For instance "clear 5000" would mean
>> "clear the delay line over the next 5000 ms." A second argument would let
>> the user choose whether to preferentially preserve the most recent samples
>> or the oldest samples. Given only a time argument, default would be to
>> preserve oldest samples (less work has to be done overall since the write
>> pointer would also be filling the line with zeroes). Without a time
>> argument (i.e. "clear" with no arguments), the default would be to clear it
>> immediately with the understanding that there could be a possible dropout.
>>
>> A broader topic for another time would be "what Pd operations
>> are/should be realtime, and which are best at load time?"
>>
>> Thoughts?
>>
>> Matt
>>
>> __ _
>>

Re: [PD] another cyclone0.3 pre-alpha

>
> *>  the new [play~] and [average~] haven't gone*
>
> *through the thorough Porres-tests yet though.*
>
>
and average~ just failed it :) so really forget that

I'm yet to test [play~] and should have done it but I wanted to release a
latest snapshot for PdCon. Maybe skip a windows version for this one 'til I
organize a better new release (maybe an actual alpha)

2016-11-22 19:47 GMT-02:00 Dan Wilcox :

> Maybe cyclone needs it’s own mailing list :)
>

it's usually just a facebook chat between 3 people ;)

Anyway, thanks for trying this Lucas, we fixed the build issue with play~
but we'll keep working on it ;)

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [delwrite~], or "what Pd operations are/should be realtime?"

here is a vanilla way to clear a delay line.
cheers
c

Le 23/11/2016 à 18:59, Matt Barber a écrit :

I don't know about average, but I have heard "longest delay I use is maybe 30-60
seconds" a few times. The bass piece I presented at PdCon has up to 30 seconds of
delay for a complex mensuration/transposition canon, and it would be very useful to be
able to clear it for rehearsal purposes.

On Wed, Nov 23, 2016 at 12:35 PM, Jonathan Wilkes > wrote:

> In this case, I'd probably rather see a hybrid approach where a second buffer is
already waiting. Then you could give "clear 300", and it would switch to the empty
buffer immediately while guaranteeing that the other one is clear in 300ms. But this is
maybe too complicated for the user, and uses too much memory?

Matt,
In the user reports, what is the average size of the buffer? Are we really
talking about buffers greater than, say, 1000ms?

This sounds like premature optimization to me.

-Jonathan

On Tue, Nov 22, 2016 at 7:32 AM, Ivica Bukvic > wrote:

For clear, I can imagine having a second empty memory buffer being
created while delay continues to use the populated one until the memory
allocation is complete. At that point a simple change in the pointer should
suffice, after which the old buffer gets trashed. This would break determinacy,
so perhaps a separate argument could be used to enable this option in which
case the object could get another outlet that sends a bang when the procedure
is complete.
Best,
--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Nov 22, 2016 00:07, "Matt Barber" > wrote:

Hi list; thanks for a wonderful PdCon (to Stevens and NYU people
especially).

I had a quick chat with Miller after the "future of Pd" discussion. I told
him there is one feature I've heard Pd users ask for many times: a "clear" method for
[delwrite~]. A [delwrite~] resize method is something I've heard brought up a number of times as
well, but I didn't mention it.

Each of these has a runtime cost that could disrupt the realtime
dsp calculation. Clearing a [delwrite~] is a linear-time operation, and for
long delay lines it could cause audio dropouts; resizing is more problematic
because it's not clear what to do with samples already in the delay line –
probably it would need to be cleared as well, which would take even more time
(although there is already an indirect resize function when sample rate is
changed).

On the other hand, Pd arrays can be resized and cleared (const 0)
ad libitum, which is more or less the same operation. We usually tell users 'do
this at your own risk when computing audio.'

So what is the main difference? I think it's that [delwrite~] is a
tilde object that is supposed not to cause dropouts on its own. If clearing it
could cause a dropout, there are reasons for thinking of that as a bug rather
than simply a risk.

Is there a compromise procedure? We could add an option to spread the clearing out over time. For
instance "clear 5000" would mean "clear the delay line over the next 5000 ms." A second
argument would let the user choose whether to preferentially preserve the most recent samples or the oldest
samples. Given only a time argument, default would be to preserve oldest samples (less work has to be done
overall since the write pointer would also be filling the line with zeroes). Without a time argument (i.e.
"clear" with no arguments), the default would be to clear it immediately with the understanding
that there could be a possible dropout.

A broader topic for another time would be "what Pd operations are/should
be realtime, and which are best at load time?"

Thoughts?

Matt

__ _
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
stinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list

Re: [PD] another cyclone0.3 pre-alpha

2016-11-23 Thread Derek Kwan


Haha, we'll be out of the pd-list's hair soon enough. Or perhaps are
better served by directing this talk onto the repo itself. btw nice to
meet you over at the pdcon =).

Derek

On Nov 22, Dan Wilcox wrote:
> Maybe cyclone needs it’s own mailing list :)
> 
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
> > On Nov 22, 2016, at 2:02 PM, pd-list-requ...@lists.iem.at wrote:
> > 
> > From: Lucas Cordiviola  > >
> > Subject: Re: [PD] another cyclone0.3 pre-alpha
> > Date: November 22, 2016 at 2:02:13 PM MST
> > To: Derek Kwan >, 
> > "por...@gmail.com "  > >
> > Cc: "pd-list@lists.iem.at " 
> > >
> > 
> > 
> > Hi Derek,
> > 
> > I used your “Makefile” and all objects compiled successfully on w32.
> > 
> > I put the binaries here:
> > 
> > http://lucarda.com.ar/x/cyclone.0.3prealpha5_Win32.zip 
> > 
> > 
> > I moved all helps and used abs to the same dir as the objects, also moved 
> > there the two 3th party.dlls needed for w32 (libgcc_s_dw2-1.dll and 
> > pthreadGC-3.dll)
> > 
> > Salutti,
> > Lucarda.
> 

-- 
Derek Kwan
www.derekxkwan.com

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [delwrite~], or "what Pd operations are/should be realtime?"

2016-11-23 Thread Derek Kwan

To chime in: 

I've done Stockhausen's Solo Nr. 19 and at least in the form scheme I
interpreted, there were at least 45.6 s delays, and in the other form
schemes there are bound to be longer delays... I suppose Stockhausen
isn't the normal use case though =). 

Derek

On Nov 23, Matt Barber wrote:
> I don't know about average, but I have heard "longest delay I use is maybe
> 30-60 seconds" a few times. The bass piece I presented at PdCon has up to
> 30 seconds of delay for a complex mensuration/transposition canon, and it
> would be very useful to be able to clear it for rehearsal purposes.
> 
> On Wed, Nov 23, 2016 at 12:35 PM, Jonathan Wilkes 
> wrote:
> 
> > > In this case, I'd probably rather see a hybrid approach where a second
> > buffer is already waiting. Then you could give "clear 300", and it would
> > switch to the empty buffer immediately while guaranteeing that the other
> > one is clear in 300ms. But this is maybe too complicated for the user, and
> > uses too much memory?
> >
> >
> >
> > Matt,
> > In the user reports, what is the average size of the buffer?  Are we
> > really talking about buffers greater than, say, 1000ms?
> >
> > This sounds like premature optimization to me.
> >
> > -Jonathan
> >
> >
> > On Tue, Nov 22, 2016 at 7:32 AM, Ivica Bukvic  wrote:
> >
> > For clear, I can imagine having a second empty memory buffer being created
> > while delay continues to use the populated one until the memory allocation
> > is complete. At that point a simple change in the pointer should suffice,
> > after which the old buffer gets trashed. This would break determinacy, so
> > perhaps a separate argument could be used to enable this option in which
> > case the object could get another outlet that sends a bang when the
> > procedure is complete.
> > Best,
> > --
> > Ivica Ico Bukvic, D.M.A.
> > Associate Professor
> > Computer Music
> > ICAT Senior Fellow
> > Director -- DISIS, L2Ork
> > Virginia Tech
> > School of Performing Arts – 0141
> > Blacksburg, VA 24061
> > (540) 231-6139
> > i...@vt.edu
> > www.performingarts.vt.edu
> > disis.icat.vt.edu
> > l2ork.icat.vt.edu
> > ico.bukvic.net
> >
> > On Nov 22, 2016 00:07, "Matt Barber"  wrote:
> >
> > Hi list; thanks for a wonderful PdCon (to Stevens and NYU people
> > especially).
> >
> > I had a quick chat with Miller after the "future of Pd" discussion. I told
> > him there is one feature I've heard Pd users ask for many times: a "clear"
> > method for [delwrite~]. A [delwrite~] resize method is something I've heard
> > brought up a number of times as well, but I didn't mention it.
> >
> > Each of these has a runtime cost that could disrupt the realtime dsp
> > calculation. Clearing a [delwrite~] is a linear-time operation, and for
> > long delay lines it could cause audio dropouts; resizing is more
> > problematic because it's not clear what to do with samples already in the
> > delay line – probably it would need to be cleared as well, which would take
> > even more time (although there is already an indirect resize function when
> > sample rate is changed).
> >
> > On the other hand, Pd arrays can be resized and cleared (const 0) ad
> > libitum, which is more or less the same operation. We usually tell users
> > 'do this at your own risk when computing audio.'
> >
> > So what is the main difference? I think it's that [delwrite~] is a tilde
> > object that is supposed not to cause dropouts on its own. If clearing it
> > could cause a dropout, there are reasons for thinking of that as a bug
> > rather than simply a risk.
> >
> > Is there a compromise procedure? We could add an option to spread the
> > clearing out over time. For instance "clear 5000" would mean "clear the
> > delay line over the next 5000 ms." A second argument would let the user
> > choose whether to preferentially preserve the most recent samples or the
> > oldest samples. Given only a time argument, default would be to preserve
> > oldest samples (less work has to be done overall since the write pointer
> > would also be filling the line with zeroes). Without a time argument (i.e.
> > "clear" with no arguments), the default would be to clear it immediately
> > with the understanding that there could be a possible dropout.
> >
> > A broader topic for another time would be "what Pd operations are/should
> > be realtime, and which are best at load time?"
> >
> > Thoughts?
> >
> > Matt
> >
> > __ _
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
> > stinfo/pd-list 
> >
> >
> >
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> > listinfo/pd-list
> >
> >
> >

-- 
Derek Kwan
www.derekxkwan.com

___
Pd-list@lists.iem.at

Re: [PD] [delwrite~], or "what Pd operations are/should be realtime?"

2016-11-23 Thread katja

On Wed, Nov 23, 2016 at 11:22 AM, Roman Haefeli  wrote:
> On Wed, 2016-11-23 at 10:48 +0100, IOhannes m zmoelnig wrote:
>> On 2016-11-22 17:29, Alexandre Torres Porres wrote:
>> >
>> > there is a clear method for the delay line in pd-l2ork,
>> > undocumented,
>> > but there, not sure how it is done,
>> implementing the "clear" is trivial.
>>
>> however, afaiu this is not the concern that miller has.
>> the concern is, that you are breaking some realtime assumptions
>> (deterministic, bound execution time), with *any* possible
>> implementation.
>
> This concern seems a bit arbitrary. Someone already brought up the
> 'const ' sent to array example, which is probably a similar
> operation and already exists. Also, I once found out that resizing
> arrays that are accessed by tilde objects causes a recalculation of the
> DSP graph and this leads to drop-outs, too (but might be only noticed
> when having a huge set of patches loaded so that the DSP graph is very
> big). Since I found out about this, I try to avoid resizing arrays
> altogether.
>
> Personally, I think a programming language shouldn't second-guess what
> is sensible for a programmer to do and what not. It should be up to the
> programmer whether they want to risk a drop-out or not.
>
> BTW, how can you implement a 'clear' method with abstractions?
>
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>

Not vanilla, but I use a sound-on-sound looper with [cyclone/poke~]
writing into the buffers and [tabread4~] reading.

If [delwrite~] would have a 'const' or 'clear' method I would use that
instead, if only because [cyclone/poke~] doesn't have a
subnormals-eliminator.

By the way I haven't noticed problems when flushing large buffers
(over 1 million samples total) in this looper while other audio is
still running.

Katja

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Next PdCon?

Alexandre Castonguay
Alexandre Porres
Alexandros Drymonitis

What is wrong with people called Alex and their urge to organize PdCons?

2016-11-23 16:20 GMT-02:00 Alexandre Torres Porres :

> every once in a thousand emails I hit a magic shortcut I never know of and
> send an incomplete email out...
>
> continuing...
>
> I never guaranteed any structure, and I can say now that it was quite a
> bluff that I could pull something off, as I had never done that... and...
> well... these days, if we were to do it here, it'd be a lot more modest...
>
> And anyway, we had a pretty nice technical structure, but also no spatial
> system whatsoever...
>
> what I', trying to say is that you shouldn't worry much about being fancy
> and meeting any standard requirements. Well, let me refer to some of your
> text.
>
> 2016-11-23 16:05 GMT-02:00 Alexandre Torres Porres :
>
>>
>>
>> 2016-11-23 9:14 GMT-02:00 Alexandros Drymonitis :
>>
>>> I asked a friend and colleague who works at the American College of
>>> Greece in Athens whether it would be possible to host the next Pd
>>> Convention there. He is very positive about this, without this meaning it's
>>> certain.
>>>
>>
> sounds like a great start :)
>
>
>> What I would like to ask is when do you guys think it would be best to
>>> organize this? 2017 or 2018?
>>>
>>
> I guess anything earlier than 5 years (2021) is a progress :D we never had
> two years in a row, but sure i'd personally love to see PdCons every year.
> But looks like 2018 is more like it...
>
> the college can provide the necessary infrastructure
>>>
>>
> yeah, that all sounds great
>
>
>> Some other stuff (like concerts) can happen in various places in Athens
>>> (...) anything else will probably happen in the center.
>>> I know that PdCon16~ was a bit scattered around NYC, and Athens is much
>>> smaller than that, but transportation is not the best.
>>>
>>
> Well, herd in São Paulo it was all over the place and transportation is
> definitely worse than in NY
>
> What helps a lot with these kind of things is a good organization, that
> you guys provides us all the best information on how to get around, also
> specially made maps with detailed transportation info, etc... just work out
> good logistics with enough time in schedule to get around.
>
> I can say we did offer a good structure, but I can also say that the
> hardest part and what's more important is to offer a well organized event.
>
> I can add more thoughts as this thread progresses ;)
>
> cheers
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Next PdCon?

every once in a thousand emails I hit a magic shortcut I never know of and
send an incomplete email out...

continuing...

I never guaranteed any structure, and I can say now that it was quite a
bluff that I could pull something off, as I had never done that... and...
well... these days, if we were to do it here, it'd be a lot more modest...

And anyway, we had a pretty nice technical structure, but also no spatial
system whatsoever...

what I', trying to say is that you shouldn't worry much about being fancy
and meeting any standard requirements. Well, let me refer to some of your
text.

2016-11-23 16:05 GMT-02:00 Alexandre Torres Porres :

>
>
> 2016-11-23 9:14 GMT-02:00 Alexandros Drymonitis :
>
>> I asked a friend and colleague who works at the American College of
>> Greece in Athens whether it would be possible to host the next Pd
>> Convention there. He is very positive about this, without this meaning it's
>> certain.
>>
>
sounds like a great start :)


> What I would like to ask is when do you guys think it would be best to
>> organize this? 2017 or 2018?
>>
>
I guess anything earlier than 5 years (2021) is a progress :D we never had
two years in a row, but sure i'd personally love to see PdCons every year.
But looks like 2018 is more like it...

the college can provide the necessary infrastructure
>>
>
yeah, that all sounds great


> Some other stuff (like concerts) can happen in various places in Athens
>> (...) anything else will probably happen in the center.
>> I know that PdCon16~ was a bit scattered around NYC, and Athens is much
>> smaller than that, but transportation is not the best.
>>
>
Well, herd in São Paulo it was all over the place and transportation is
definitely worse than in NY

What helps a lot with these kind of things is a good organization, that you
guys provides us all the best information on how to get around, also
specially made maps with detailed transportation info, etc... just work out
good logistics with enough time in schedule to get around.

I can say we did offer a good structure, but I can also say that the
hardest part and what's more important is to offer a well organized event.

I can add more thoughts as this thread progresses ;)

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Next PdCon?

2016-11-23 9:14 GMT-02:00 Alexandros Drymonitis :

> Hi list,
> Since we talked about this at the Convention, I asked a friend and
> colleague who works at the American College of Greece in Athens whether it
> would be possible to host the next Pd Convention there. He is very positive
> about this, without this meaning it's certain.
> What I would like to ask is when do you guys think it would be best to
> organize this? 2017 or 2018?
> I guess both years would work fine for us (my colleague and me), but maybe
> a convention in one year would be a bit of an overkill.
>
> FYI, the college can provide the necessary infrastructure (well, maybe
> there's no room with eight or sixteen speakers, but there's at least a quad
> PA and a studio, and rooms to host paper presentations and workshops - have
> to check in more detail as to what is available there) for the most part.
> Some other stuff (like concerts) can happen in various places in Athens.
> The thing is that the college is in the northern suburbs of Athens, and
> anything else will probably happen in the center.
> I know that PdCon16~ was a bit scattered around NYC, and Athens is much
> smaller than that, but transportation is not the best. Not really sure if
> that's a problem though. I mean, if Athens is the only candidate for the
> next convention, I wouldn't see this as a problem. If there are other
> candidates, it might be something to consider (I'm pretty sure few places
> would beat the weather we've got here though!).
>
> Any advice on organizing a Pd Convention is very welcome. As I already
> wrote, it's not certain that it will happen in Athens, but it's quite
> possible.
>

well, I'll share some thoughts as a previous organizer and someone who's
been to the 4 latest events.

I was even about to write some of this to the list, saying that anyone who
feels like organizing a convention should go for it, because, as miller
says, all it only really requires is that you call it a Pd Convention :)

We had a crazy amount of support when organizing the Pd Convention in
Brazil as we were able to pay for over 20 international flights, provide
hostel acomodation, van transportation, but I had never guaranteed any of
that, and I can say now that it was q when I said I'd do it  I was pretty
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [delwrite~], or "what Pd operations are/should be realtime?"

2016-11-23 Thread Jonathan Wilkes via Pd-list

> In this case, I'd probably rather see a hybrid approach where a second buffer 
> is already waiting. Then you could give "clear 300", and it would switch to 
> the empty buffer immediately while guaranteeing that the other one is clear 
> in 300ms. But this is maybe too complicated for the user, and uses too much 
> memory?

Matt,In the user reports, what is the average size of the buffer?  Are we 
really talking about buffers greater than, say, 1000ms?
This sounds like premature optimization to me.
-Jonathan

On Tue, Nov 22, 2016 at 7:32 AM, Ivica Bukvic  wrote:

For clear, I can imagine having a second empty memory buffer being created 
while delay continues to use the populated one until the memory allocation is 
complete. At that point a simple change in the pointer should suffice, after 
which the old buffer gets trashed. This would break determinacy, so perhaps a 
separate argument could be used to enable this option in which case the object 
could get another outlet that sends a bang when the procedure is 
complete.Best,-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Nov 22, 2016 00:07, "Matt Barber"  wrote:

Hi list; thanks for a wonderful PdCon (to Stevens and NYU people especially).
I had a quick chat with Miller after the "future of Pd" discussion. I told him 
there is one feature I've heard Pd users ask for many times: a "clear" method 
for [delwrite~]. A [delwrite~] resize method is something I've heard brought up 
a number of times as well, but I didn't mention it.
Each of these has a runtime cost that could disrupt the realtime dsp 
calculation. Clearing a [delwrite~] is a linear-time operation, and for long 
delay lines it could cause audio dropouts; resizing is more problematic because 
it's not clear what to do with samples already in the delay line – probably it 
would need to be cleared as well, which would take even more time (although 
there is already an indirect resize function when sample rate is changed).
On the other hand, Pd arrays can be resized and cleared (const 0) ad libitum, 
which is more or less the same operation. We usually tell users 'do this at 
your own risk when computing audio.'
So what is the main difference? I think it's that [delwrite~] is a tilde object 
that is supposed not to cause dropouts on its own. If clearing it could cause a 
dropout, there are reasons for thinking of that as a bug rather than simply a 
risk.
Is there a compromise procedure? We could add an option to spread the clearing 
out over time. For instance "clear 5000" would mean "clear the delay line over 
the next 5000 ms." A second argument would let the user choose whether to 
preferentially preserve the most recent samples or the oldest samples. Given 
only a time argument, default would be to preserve oldest samples (less work 
has to be done overall since the write pointer would also be filling the line 
with zeroes). Without a time argument (i.e. "clear" with no arguments), the 
default would be to clear it immediately with the understanding that there 
could be a possible dropout.
A broader topic for another time would be "what Pd operations are/should be 
realtime, and which are best at load time?"
Thoughts?
Matt
__ _
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/li 
stinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Results from PdCon round-table / workbench

Thanks, Katja and Jamie.. Downloading now so that I can watch later
with mpv which allows to route left channel to both ears.

Roman

On Wed, 2016-11-23 at 13:13 +0100, katja wrote:
> At http://www.nyu-waverlylabs.org/pdcon16/ there's currently one
> video
> with these two subjects.
> 
> Starting at 00:00:30, conclusions from 'round workbench' sessions
> about building Pd and libraries.
> 
> Starting at 00:47:00, round table discussion about the future of Pd.
> 
> Skip the first 30 seconds with 'intermission music', played while
> technical problems were being solved.
> 
> Katja.
> 
> 
> 
> On Wed, Nov 23, 2016 at 11:48 AM, Roman Haefeli 
> wrote:
> > 
> > Hi all
> > 
> > Greetings to all of you who had the pleasure to attend this year's
> > Pd-
> > Con.
> > 
> > I'm interested to know about the outcomes of the following
> > meetings:
> > 
> >  * Workbench: building pd and libraries
> >  * Open Roundtable on Future Pd Developments
> > 
> > Are there any written/recorded remnants of those sessions?
> > 
> > Roman
> > 
> > 
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/l
> > istinfo/pd-list
> > 

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Results from PdCon round-table / workbench

2016-11-23 Thread Jaime Oliver

Indeed, the direct youtube link is this one: 
https://www.youtube.com/watch?v=cAWFk1PPTtk

We still need to download and parse each talk and upload several videos of the 
first day. So more soon!

J


> On Nov 23, 2016, at 7:13 AM, katja  wrote:
> 
> At http://www.nyu-waverlylabs.org/pdcon16/ there's currently one video
> with these two subjects.
> 
> Starting at 00:00:30, conclusions from 'round workbench' sessions
> about building Pd and libraries.
> 
> Starting at 00:47:00, round table discussion about the future of Pd.
> 
> Skip the first 30 seconds with 'intermission music', played while
> technical problems were being solved.
> 
> Katja.
> 
> 
> 
> On Wed, Nov 23, 2016 at 11:48 AM, Roman Haefeli  wrote:
>> Hi all
>> 
>> Greetings to all of you who had the pleasure to attend this year's Pd-
>> Con.
>> 
>> I'm interested to know about the outcomes of the following meetings:
>> 
>> * Workbench: building pd and libraries
>> * Open Roundtable on Future Pd Developments
>> 
>> Are there any written/recorded remnants of those sessions?
>> 
>> Roman
>> 
>> 
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
>> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Results from PdCon round-table / workbench

2016-11-23 Thread katja

At http://www.nyu-waverlylabs.org/pdcon16/ there's currently one video
with these two subjects.

Starting at 00:00:30, conclusions from 'round workbench' sessions
about building Pd and libraries.

Starting at 00:47:00, round table discussion about the future of Pd.

Skip the first 30 seconds with 'intermission music', played while
technical problems were being solved.

Katja.

On Wed, Nov 23, 2016 at 11:48 AM, Roman Haefeli  wrote:
> Hi all
>
> Greetings to all of you who had the pleasure to attend this year's Pd-
> Con.
>
> I'm interested to know about the outcomes of the following meetings:
>
>  * Workbench: building pd and libraries
>  * Open Roundtable on Future Pd Developments
>
> Are there any written/recorded remnants of those sessions?
>
> Roman
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] abl_link~ external for windows

2016-11-23 Thread IOhannes m zmoelnig

On 2016-11-23 11:19, Jean-Yves Gratius wrote:
> Please check the new binary @
> https://sourceforge.net/projects/jygsdownloads/files/abl_link%7E4windows/

would you consider using deken for distributing the package?

fgmasdr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Next PdCon?

2016-11-23 Thread Alexandros Drymonitis

Hi list,
Since we talked about this at the Convention, I asked a friend and
colleague who works at the American College of Greece in Athens whether it
would be possible to host the next Pd Convention there. He is very positive
about this, without this meaning it's certain.
What I would like to ask is when do you guys think it would be best to
organize this? 2017 or 2018?
I guess both years would work fine for us (my colleague and me), but maybe
a convention in one year would be a bit of an overkill.

FYI, the college can provide the necessary infrastructure (well, maybe
there's no room with eight or sixteen speakers, but there's at least a quad
PA and a studio, and rooms to host paper presentations and workshops - have
to check in more detail as to what is available there) for the most part.
Some other stuff (like concerts) can happen in various places in Athens.
The thing is that the college is in the northern suburbs of Athens, and
anything else will probably happen in the center.
I know that PdCon16~ was a bit scattered around NYC, and Athens is much
smaller than that, but transportation is not the best. Not really sure if
that's a problem though. I mean, if Athens is the only candidate for the
next convention, I wouldn't see this as a problem. If there are other
candidates, it might be something to consider (I'm pretty sure few places
would beat the weather we've got here though!).

Any advice on organizing a Pd Convention is very welcome. As I already
wrote, it's not certain that it will happen in Athens, but it's quite
possible.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Results from PdCon round-table / workbench

Hi all

Greetings to all of you who had the pleasure to attend this year's Pd-
Con.

I'm interested to know about the outcomes of the following meetings:

 * Workbench: building pd and libraries
 * Open Roundtable on Future Pd Developments

Are there any written/recorded remnants of those sessions?

Roman



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] convert signal to 16bit stream

On Wed, 2016-11-23 at 11:29 +0100, cyrille henry wrote:
> oh, and to answer about the why do you need a [t b b] to generate
> your table :
> it's because you bang 1st the switch~.
> I would bang it last.
> but since you've got an other switch~ in a subpatch (for the elegant
> upsampling), the correct order is in attachment.

I see, thanks. I had the order exactly the opposite way. I gather that
with nested reblocked subpatches the deepest subpatch needs to be
triggered last.

Roman

> Le 23/11/2016 à 10:59, Roman Haefeli a écrit :
> > 
> > Hey all
> > 
> > Thanks for your submissions, Cyrille and Patrice. I put my 4
> > versions
> > and yours into a single patch to make it easy for comparing. It
> > turns
> > out I'm not clearly in favor of any of them. All work fine and none
> > is
> > perfect. In netpd, I went for table_lookup, however, it later
> > turned
> > out that CPU wise, it's not that significantly faster than the
> > others
> > and may not justify to use 2x4x65536 (which is a half MB!) of
> > memory.
> > 
> > All of them are significantly faster than the message based
> > version,
> > which is not that surprising.
> > 
> > Cyrilly, I think the table_lookup variant is what you described in
> > your
> > mail.
> > 
> > It turns out that the difficult part is to find a way to implement
> > an
> > [int~] with Pd-vanilla objects. Once, you have an [int~], you have
> > a
> > [div~], and when you have [div~], you have a [mod~]. However,
> > making a
> > good [int~] is not that trivial. One can make one with [wrap~], but
> > it
> > exhibits the strange behaviour that it outputs '1' with '0' as
> > input.
> > To work-around that, I add an integer constant to the input of
> > [wrap~]
> > so that its input is always greater than 0. But because we're
> > dealing
> > with floating point numbers, the fractional part of [wrap~] output
> > is
> > less precise than the fractional part of its input (before constant
> > was
> > added), which leads to rounding errors.
> > 
> > uint8_table uses a pre-computed table with values from 0 to 255,
> > which
> > can be used as [int~] for said range.
> > 
> > float_rounding implements an [int~] by adding (and subsequently
> > subtracting) a constant which is high enough so that the fractional
> > part of the floating point number disappears. This approach might
> > be
> > interesting for the purpose of this exercise, but it shoudln't be
> > used.
> > It would break in an environment with a different floating point
> > number
> > format.
> > 
> > Cyrille Henry's approach assumes the receiving side automatically
> > wraps
> > negative numbers around. It turns out to be true for the object
> > classes
> > I'm interested in ([packOSC], [tcpclient], [netsend -b]), so his
> > version is quite clean and because of the lack of implementing
> > another
> > [mod], it uses less arithmetic operations than my 'wrap' approach.
> > It
> > totally lacks divisions. Thumbs up!
> > 
> > Patrice Colet's version uses [expr~] for some parts, which is fine,
> > I
> > think. Somehow, for positive inputs the LSB is always higher by one
> > compared to the others. This leads to even more severe side effect
> > for
> > input 1: 127 0 (should be 127 255).
> > 
> > Please share your opinions. I now think Cyrille's version is the
> > best.
> > 
> > Roman
> > 
> > 
> > 
> > On Tue, 2016-11-08 at 12:06 +0100, cyrille henry wrote:
> > > 
> > > hello,
> > > 
> > > in your patch, the input signal is truncated, so strange things
> > > append near 0.
> > > I think rounding to inferior value will gives better result.
> > > 
> > > 
> > > here is a version done with 2 wrap~.
> > > the result for negative number is a bit different than in your
> > > example for 2 reason :
> > > - it round to inferior value and not truncate the input.
> > > - it return negative int, but in uint8 : 255 and -1 are the same
> > > number anyhow.
> > > 
> > > sometimes rounding error result in 1 being 0.. So i guess
> > > this
> > > patch is useless.
> > > 
> > > The other easy solution I can think of is using 2 tables with 65K
> > > point each, and reading the tables with tabread~.
> > > it is easy to populate the table with the value you want.
> > > 
> > > sorry, i don't have time to provide a patch.
> > > 
> > > cheers
> > > Cyrille
> > > 
> > > 
> > > Le 07/11/2016 à 16:24, Roman Haefeli a écrit :
> > > > 
> > > > 
> > > > Hi all
> > > > 
> > > > In order to store audio data more efficiently in netpd presets
> > > > and
> > > > also
> > > > to transmit live audio through OSC, I'm thinking of ways to
> > > > convert
> > > > an
> > > > signal to a 16-bit stream represented as two signals, one for
> > > > each
> > > > byte, the first for MSB and the second for LSB. I already came
> > > > up
> > > > with
> > > > a few solutions, but I'm not totally happy with any of them
> > > > because
> > > > they are not very efficient or/and have strange edge cases. It
> > > > turns
> > > > out what seems a simple task is a bit more complex and

Re: [PD] convert signal to 16bit stream

On Wed, 2016-11-23 at 11:18 +0100, cyrille henry wrote:
> just few comment :
> - [<~] in patrice patch is not vanilla.

True (didn't notice since I had zexy loaded).

> - the patch with it's 6 different and simultaneous conversions use
> about 1% of my CPU. why do you need to optimise?

I don't need to specifically optimize solely for this case. However,
CPU usage still is a thing with netpd and many small optimizations make
a difference. Turns out that CPUs aren't getting faster significantly
since a few years.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] convert signal to 16bit stream


oh, and to answer about the why do you need a [t b b] to generate your table :
it's because you bang 1st the switch~.
I would bang it last.
but since you've got an other switch~ in a subpatch (for the elegant 
upsampling), the correct order is in attachment.

cheers
c



Le 23/11/2016 à 10:59, Roman Haefeli a écrit :

Hey all

Thanks for your submissions, Cyrille and Patrice. I put my 4 versions
and yours into a single patch to make it easy for comparing. It turns
out I'm not clearly in favor of any of them. All work fine and none is
perfect. In netpd, I went for table_lookup, however, it later turned
out that CPU wise, it's not that significantly faster than the others
and may not justify to use 2x4x65536 (which is a half MB!) of memory.

All of them are significantly faster than the message based version,
which is not that surprising.

Cyrilly, I think the table_lookup variant is what you described in your
mail.

It turns out that the difficult part is to find a way to implement an
[int~] with Pd-vanilla objects. Once, you have an [int~], you have a
[div~], and when you have [div~], you have a [mod~]. However, making a
good [int~] is not that trivial. One can make one with [wrap~], but it
exhibits the strange behaviour that it outputs '1' with '0' as input.
To work-around that, I add an integer constant to the input of [wrap~]
so that its input is always greater than 0. But because we're dealing
with floating point numbers, the fractional part of [wrap~] output is
less precise than the fractional part of its input (before constant was
added), which leads to rounding errors.

uint8_table uses a pre-computed table with values from 0 to 255, which
can be used as [int~] for said range.

float_rounding implements an [int~] by adding (and subsequently
subtracting) a constant which is high enough so that the fractional
part of the floating point number disappears. This approach might be
interesting for the purpose of this exercise, but it shoudln't be used.
It would break in an environment with a different floating point number
format.

Cyrille Henry's approach assumes the receiving side automatically wraps
negative numbers around. It turns out to be true for the object classes
I'm interested in ([packOSC], [tcpclient], [netsend -b]), so his
version is quite clean and because of the lack of implementing another
[mod], it uses less arithmetic operations than my 'wrap' approach. It
totally lacks divisions. Thumbs up!

Patrice Colet's version uses [expr~] for some parts, which is fine, I
think. Somehow, for positive inputs the LSB is always higher by one
compared to the others. This leads to even more severe side effect for
input 1: 127 0 (should be 127 255).

Please share your opinions. I now think Cyrille's version is the best.

Roman



On Tue, 2016-11-08 at 12:06 +0100, cyrille henry wrote:

hello,

in your patch, the input signal is truncated, so strange things
append near 0.
I think rounding to inferior value will gives better result.


here is a version done with 2 wrap~.
the result for negative number is a bit different than in your
example for 2 reason :
- it round to inferior value and not truncate the input.
- it return negative int, but in uint8 : 255 and -1 are the same
number anyhow.

sometimes rounding error result in 1 being 0.. So i guess this
patch is useless.

The other easy solution I can think of is using 2 tables with 65K
point each, and reading the tables with tabread~.
it is easy to populate the table with the value you want.

sorry, i don't have time to provide a patch.

cheers
Cyrille


Le 07/11/2016 à 16:24, Roman Haefeli a écrit :


Hi all

In order to store audio data more efficiently in netpd presets and
also
to transmit live audio through OSC, I'm thinking of ways to convert
an
signal to a 16-bit stream represented as two signals, one for each
byte, the first for MSB and the second for LSB. I already came up
with
a few solutions, but I'm not totally happy with any of them because
they are not very efficient or/and have strange edge cases. It
turns
out what seems a simple task is a bit more complex and probably has
quiet a few totally different solutions.

I would be interested to see with what solutions people come up
with.
Consider it a puzzle, a brain teaser (in case you're done writing
your
paper for pdcon and need some distraction).

Requirements:
 * It must be done in signal domain (I was doing it in message
domain
   yet, but performance is obviously bad)
 * Only vanilla objects are allowed.
 * Input is in the range -1 to 1. Input outside this range should
be
   clipped and not wrapped around.
 * Output is two signals, each consisting of an integer value
between
   0 and 255
 * The two bytes represent a 16-bit _signed_ integer

You can compare your output with the message version in attached
patch.
If this generates interest and makes some people participate, I'll
disclose my solutions after people submitted their solutions.

Re: [PD] [delwrite~], or "what Pd operations are/should be realtime?"

On Wed, 2016-11-23 at 10:48 +0100, IOhannes m zmoelnig wrote:
> On 2016-11-22 17:29, Alexandre Torres Porres wrote:
> > 
> > there is a clear method for the delay line in pd-l2ork,
> > undocumented,
> > but there, not sure how it is done,
> implementing the "clear" is trivial.
> 
> however, afaiu this is not the concern that miller has.
> the concern is, that you are breaking some realtime assumptions
> (deterministic, bound execution time), with *any* possible
> implementation.

This concern seems a bit arbitrary. Someone already brought up the
'const ' sent to array example, which is probably a similar
operation and already exists. Also, I once found out that resizing
arrays that are accessed by tilde objects causes a recalculation of the
DSP graph and this leads to drop-outs, too (but might be only noticed
when having a huge set of patches loaded so that the DSP graph is very
big). Since I found out about this, I try to avoid resizing arrays
altogether. 

Personally, I think a programming language shouldn't second-guess what
is sensible for a programmer to do and what not. It should be up to the
programmer whether they want to risk a drop-out or not. 

BTW, how can you implement a 'clear' method with abstractions?

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] abl_link~ external for windows

2016-11-23 Thread Jean-Yves Gratius


Hi

Please check the new binary @ 
https://sourceforge.net/projects/jygsdownloads/files/abl_link%7E4windows/


that may resolve all dll dependancies.

Works on virtual XP and Windows 7 machines.

Let me know,

regards

Le 22 novembre 2016 à 23:17, Lucas Cordiviola  
a écrit :



Hi Jean-Yves

I`m having trouble with [abl_link~ ].

I downloaded your object and when I first loaded it, it asked me for 
lots of .dlls :


api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-multibyte-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
msvcp140.dll
vcruntime140.dll

Once I found all and put them in the same folder as the object I get 
this error:


--

pd.com -Entry Point Not Found

The procedure entry point_crt_atexit could not be located in the 
dynamic library C:\users\lucarda\appdata\roaming\pd\alpd\abl_link.dll,



Can you upload a new package with all the dlls that where used by your 
compiler?


Btw, I highly appreciate and use your work on PDVST~, any news on that?

Salutti,
Lucarda.



Mensaje telepatico asistido por maquinas.



*From:* Pd-list  on behalf of Jean-Yves 
Gratius 

*Sent:* Monday, November 21, 2016 10:59 PM
*To:* pd-list@lists.iem.at
*Subject:* [PD] abl_link~ external for windows
Hi Peter, hi list,

Today I succedeed in compiling abl_link~ for windows.

Documentation will come later.

I couldn't use makefile, I created a code:blocks project with VC++2015
standalone compiler, with some changes into files.

https://sourceforge.net/projects/jygsdownloads/files/abl_link%7E4windows/


Sync tested with puredata metronome patch and ninjaJamm android app,
seems to work.

cheers,

Jean-Yves Gratius

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list 



Aucun virus trouvé dans ce message.
Analyse effectuée par AVG - www.avg.com 
Version: 2016.0.7924 / Base de données virale: 4664/13454 - Date: 22/11/2016

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] convert signal to 16bit stream


just few comment :
- [<~] in patrice patch is not vanilla.
- yes, the table lookup is what I was describing
- using 2 table of 65K samples use "half a MB" of memory. I don't think this is 
a lot : it's 1/1000 of what a RPi offers...
- the patch with it's 6 different and simultaneous conversions use about 1% of 
my CPU. why do you need to optimise?

cheers
Cyrille

Le 23/11/2016 à 10:59, Roman Haefeli a écrit :

Hey all

Thanks for your submissions, Cyrille and Patrice. I put my 4 versions
and yours into a single patch to make it easy for comparing. It turns
out I'm not clearly in favor of any of them. All work fine and none is
perfect. In netpd, I went for table_lookup, however, it later turned
out that CPU wise, it's not that significantly faster than the others
and may not justify to use 2x4x65536 (which is a half MB!) of memory.

All of them are significantly faster than the message based version,
which is not that surprising.

Cyrilly, I think the table_lookup variant is what you described in your
mail.

It turns out that the difficult part is to find a way to implement an
[int~] with Pd-vanilla objects. Once, you have an [int~], you have a
[div~], and when you have [div~], you have a [mod~]. However, making a
good [int~] is not that trivial. One can make one with [wrap~], but it
exhibits the strange behaviour that it outputs '1' with '0' as input.
To work-around that, I add an integer constant to the input of [wrap~]
so that its input is always greater than 0. But because we're dealing
with floating point numbers, the fractional part of [wrap~] output is
less precise than the fractional part of its input (before constant was
added), which leads to rounding errors.

uint8_table uses a pre-computed table with values from 0 to 255, which
can be used as [int~] for said range.

float_rounding implements an [int~] by adding (and subsequently
subtracting) a constant which is high enough so that the fractional
part of the floating point number disappears. This approach might be
interesting for the purpose of this exercise, but it shoudln't be used.
It would break in an environment with a different floating point number
format.

Cyrille Henry's approach assumes the receiving side automatically wraps
negative numbers around. It turns out to be true for the object classes
I'm interested in ([packOSC], [tcpclient], [netsend -b]), so his
version is quite clean and because of the lack of implementing another
[mod], it uses less arithmetic operations than my 'wrap' approach. It
totally lacks divisions. Thumbs up!

Patrice Colet's version uses [expr~] for some parts, which is fine, I
think. Somehow, for positive inputs the LSB is always higher by one
compared to the others. This leads to even more severe side effect for
input 1: 127 0 (should be 127 255).

Please share your opinions. I now think Cyrille's version is the best.

Roman



On Tue, 2016-11-08 at 12:06 +0100, cyrille henry wrote:

hello,

in your patch, the input signal is truncated, so strange things
append near 0.
I think rounding to inferior value will gives better result.


here is a version done with 2 wrap~.
the result for negative number is a bit different than in your
example for 2 reason :
- it round to inferior value and not truncate the input.
- it return negative int, but in uint8 : 255 and -1 are the same
number anyhow.

sometimes rounding error result in 1 being 0.. So i guess this
patch is useless.

The other easy solution I can think of is using 2 tables with 65K
point each, and reading the tables with tabread~.
it is easy to populate the table with the value you want.

sorry, i don't have time to provide a patch.

cheers
Cyrille


Le 07/11/2016 à 16:24, Roman Haefeli a écrit :


Hi all

In order to store audio data more efficiently in netpd presets and
also
to transmit live audio through OSC, I'm thinking of ways to convert
an
signal to a 16-bit stream represented as two signals, one for each
byte, the first for MSB and the second for LSB. I already came up
with
a few solutions, but I'm not totally happy with any of them because
they are not very efficient or/and have strange edge cases. It
turns
out what seems a simple task is a bit more complex and probably has
quiet a few totally different solutions.

I would be interested to see with what solutions people come up
with.
Consider it a puzzle, a brain teaser (in case you're done writing
your
paper for pdcon and need some distraction).

Requirements:
 * It must be done in signal domain (I was doing it in message
domain
   yet, but performance is obviously bad)
 * Only vanilla objects are allowed.
 * Input is in the range -1 to 1. Input outside this range should
be
   clipped and not wrapped around.
 * Output is two signals, each consisting of an integer value
between
   0 and 255
 * The two bytes represent a 16-bit _signed_ integer

You can compare your output with the message version in attached
patch.
If this generates interest and makes some people participate, I'll
disclose my

Re: [PD] convert signal to 16bit stream