delays and buffers

[Andre Bartetzki]

Hi there,

when working with multitap delay patches I find the Tap pseudo UGen quite
inefficient. Compared to multiple delays, like this:

{  DelayC.ar(Impulse.ar(1), 1, { rrand(0.02, 0.12) } ! 100 ) }.play;


Tap in combination with RecordBuf or BufWr, like this:

r = Buffer.alloc(s, s.sampleRate * 1, 1);
y = { RecordBuf.ar( Impulse.ar(1), r);  Tap.ar(r, 1, { rrand(0.02, 0.12) } !
100 ) }.play;

takes around 170% of the multiple DelayC solution!!
Also, with PlayBuf ("inside" Tap) it is not possible to modulate the
delaytime, because it just sets the startPos.

When I replace Tap by BufRd, even with only one Phasor for everything, I
could modulate the delaytimes. But regarding CPU power this takes still as
much as Tap:

r = Buffer.alloc(s, s.sampleRate * 1, 1)
(
y = { var ph, smps;
ph = Phasor.ar(0,1, 0, BufFrames.ir(r));
smps = SampleRate.ir.neg;
BufWr.ar( Impulse.ar(1), r, ph, 1);
BufRd.ar(1, r, ph + ({ rrand(0.02, 0.12) * smps } ! 100), 1, 4);
}.play
)


In order to save memory one could use shared buffers, like this:

r = Buffer.alloc(s, s.sampleRate * 1, 1)
y = {  BufDelayC.ar(r, Impulse.ar(1), { rrand(0.02, 0.12) } ! 100 ) }.play

which needs almost the same amount of CPU power than DelayC.

So in the end BufDelayC seems to be for now the most efficient solution in
terms of memory usage and CPU power.
But it still needs x buffer write UGens instead of only one.

So I guess there must be be a more efficient way to implement multitap
delays in SC3. What about a pair of UGens like the ones in MaxMSP but using
shared buffers:

BufTapIn.ar(inputArray, bufnum);
BufTapOut.ar(numChannels, bufnum, delaytime, interpolation);

???
Would it be hard to implement that?

Also, I'd like to have non-interpolating Delay UGens which take just samples
instead of delaytimes, like Delay1 and Delay2.
For the construction of reverbs it would be good to also have sample based
versions for Comb and Allpass. Plus a feedback argument instead of
decaytime!

I know, Christmas is still far ....


thanks

Andre


--------------------------------------------------
Andre Bartetzki
http://www.bartetzki.de
mailto:andre@...

Tel   [phone]
VoIP  [phone]
Fax   [phone]

Skype bartetzki
http://www.myspace.com/andrebartetzki
--------------------------------------------------



_______________________________________________
sc-users mailing list


info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[Josh Parmenter]

On Jun 29, 2008, at 4:01 AM, Andre Bartetzki wrote:

> BufTapIn.ar(inputArray, bufnum);
> BufTapOut.ar(numChannels, bufnum, delaytime, interpolation);
> ???
> Would it be hard to implement that?
>
> Also, I'd like to have non-interpolating Delay UGens which take just  
> samples
> instead of delaytimes, like Delay1 and Delay2.
> For the construction of reverbs it would be good to also have sample  
> based
> versions for Comb and Allpass. Plus a feedback argument instead of
> decaytime!

I think all of these are possible, but at the same time, these are  
just variants of things that do already exist. I agree that finding an  
efficient tap would be a good idea (I'll look into it), but converting  
between time and samples is pretty easy math. Making a new UGen for it  
seems like a bit of overkill.

I think the main reason behind using times instead of samples and  
decaytime instead of feedback has to do making code that will easily  
move between sample rates. Samples and feedback would drastically  
change how a delay would react between different sample rates, so it  
is much safer to use the current UGens.

With that in mind, if you really do think that you need a delay with  
samples instead of time, it would be easy to make (actually easier  
then the ones we currently have)... feedback and decaytime as well.

How do others feel?

Josh


******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/


_______________________________________________
sc-users mailing list


info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[Andre Bartetzki]

Es war der 29.06.2008 19:11 Uhr, als Josh Parmenter nicht widerstehen
konnte, folgende Gedanken dem Netz anzuvertrauen:


> I think all of these are possible, but at the same time, these are
> just variants of things that do already exist. I agree that finding an
> efficient tap would be a good idea (I'll look into it), but converting
> between time and samples is pretty easy math. Making a new UGen for it
> seems like a bit of overkill.

Hi Josh,

sure, these would be just variants.
But sometimes one needs to refer to samples, for example for comb filters in
reverb patches one approach is to take higher prime numbers for buffer
sizes. Starting from a delaytime one needs to look for the next prime number
of samples that is close to that delaytime. And then one has to convert this
sample value back to a delaytime - although the delay UGen needs samples
inside anyway ....

Csound has at least these variants for taps:
deltapn (in samples)
deltap  (as delaytime)
deltapi (as delaytime with interpolation)

 
> With that in mind, if you really do think that you need a delay with
> samples instead of time, it would be easy to make (actually easier
> then the ones we currently have)... feedback and decaytime as well.

I guess a delay UGen with a sample argument would be more efficient than the
current one? If so that would be a good reason to have one with a sample
arg.

Although it is very convenient in most cases to have a decaytime argument in
combs and allpasses, it is harder to convert patches from MaxMSP and the
likes as well as from digital filter formulas  where usually a feedback
factor is given.


best

Andre


--------------------------------------------------
Andre Bartetzki
http://www.bartetzki.de
mailto:andre@...

Tel   [phone]
VoIP  [phone]
Fax   [phone]

Skype bartetzki
http://www.myspace.com/andrebartetzki
--------------------------------------------------



_______________________________________________
sc-users mailing list


info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[Dan Stowell]

2008/6/29, Josh Parmenter <josh@...>:

> On Jun 29, 2008, at 4:01 AM, Andre Bartetzki wrote:
>
>
> > BufTapIn.ar(inputArray, bufnum);
> > BufTapOut.ar(numChannels, bufnum, delaytime, interpolation);
> > ???
> > Would it be hard to implement that?
> >
> > Also, I'd like to have non-interpolating Delay UGens which take just
> samples
> > instead of delaytimes, like Delay1 and Delay2.
> > For the construction of reverbs it would be good to also have sample based
> > versions for Comb and Allpass. Plus a feedback argument instead of
> > decaytime!
> >
>
>
>  I think all of these are possible, but at the same time, these are just
> variants of things that do already exist. I agree that finding an efficient
> tap would be a good idea (I'll look into it), but converting between time
> and samples is pretty easy math. Making a new UGen for it seems like a bit
> of overkill.
>
>  I think the main reason behind using times instead of samples and decaytime
> instead of feedback has to do making code that will easily move between
> sample rates. Samples and feedback would drastically change how a delay
> would react between different sample rates, so it is much safer to use the
> current UGens.
>
>  With that in mind, if you really do think that you need a delay with
> samples instead of time, it would be easy to make (actually easier then the
> ones we currently have)... feedback and decaytime as well.
>
>  How do others feel?

I agree that enough units already exist to cater for this. Converting
between seconds and samples is just dividing by the sample-rate, an
incredibly trivial thing for a user to do, so certainly doesn't
justify any new UGens. The conversion from decaytime to feedback level
is not quite so trivial but still fairly easy.

For non-interpolating delays, Andre, are you aware that
non-interpolating delays exist (DelayN instead of DelayC)? Just making
sure, since you didn't mention it. Dividing by the sample-rate, and
there you have your non-interpolating sample-specified delay.

The findings re the efficiency of the different delay options are
interesting. Finding a more efficient approach to Tap would be good -
please do look into that further, IMHO. But I'd be hoping for a
pseudo-UGen solution, rather than more UGen C code to maintain!

Just my 2p

Dan

_______________________________________________
sc-users mailing list


info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[Josh Parmenter]

Maybe:

+ SimpleNumber {
        feedbackToDecaytime {arg deltime = 0.1;
                ^(0.001.log2 * deltime) / this.log2;
                }
        }

0.995.feedbackToDecaytime(0.001)

I'm sure there can be a better way to phrase this... this is for a  
-60db decay... perhaps that should be variable also:

+ SimpleNumber {
        feedbackToDecaytime {arg deltime = 0.1, db = -60;
                ^(db.dbamp.log2 * deltime) / this.log2;
                }
        }

Josh

On Jun 29, 2008, at 10:59 AM, Dan Stowell wrote:

> 2008/6/29, Josh Parmenter <josh@...>:
>> On Jun 29, 2008, at 4:01 AM, Andre Bartetzki wrote:
>>
>>
>>> BufTapIn.ar(inputArray, bufnum);
>>> BufTapOut.ar(numChannels, bufnum, delaytime, interpolation);
>>> ???
>>> Would it be hard to implement that?
>>>
>>> Also, I'd like to have non-interpolating Delay UGens which take just
>> samples
>>> instead of delaytimes, like Delay1 and Delay2.
>>> For the construction of reverbs it would be good to also have  
>>> sample based
>>> versions for Comb and Allpass. Plus a feedback argument instead of
>>> decaytime!
>>>
>>
>>
>> I think all of these are possible, but at the same time, these are  
>> just
>> variants of things that do already exist. I agree that finding an  
>> efficient
>> tap would be a good idea (I'll look into it), but converting  
>> between time
>> and samples is pretty easy math. Making a new UGen for it seems  
>> like a bit
>> of overkill.
>>
>> I think the main reason behind using times instead of samples and  
>> decaytime
>> instead of feedback has to do making code that will easily move  
>> between
>> sample rates. Samples and feedback would drastically change how a  
>> delay
>> would react between different sample rates, so it is much safer to  
>> use the
>> current UGens.
>>
>> With that in mind, if you really do think that you need a delay with
>> samples instead of time, it would be easy to make (actually easier  
>> then the
>> ones we currently have)... feedback and decaytime as well.
>>
>> How do others feel?
>
> I agree that enough units already exist to cater for this. Converting
> between seconds and samples is just dividing by the sample-rate, an
> incredibly trivial thing for a user to do, so certainly doesn't
> justify any new UGens. The conversion from decaytime to feedback level
> is not quite so trivial but still fairly easy.
>
> For non-interpolating delays, Andre, are you aware that
> non-interpolating delays exist (DelayN instead of DelayC)? Just making
> sure, since you didn't mention it. Dividing by the sample-rate, and
> there you have your non-interpolating sample-specified delay.
>
> The findings re the efficiency of the different delay options are
> interesting. Finding a more efficient approach to Tap would be good -
> please do look into that further, IMHO. But I'd be hoping for a
> pseudo-UGen solution, rather than more UGen C code to maintain!
>
> Just my 2p
>
> Dan
>
> _______________________________________________
> sc-users mailing list
>
>
> info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/


_______________________________________________
sc-users mailing list


info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[nescivi]

Hiho,

On Sunday 29 June 2008 07:01:02 Andre Bartetzki wrote:

> {  DelayC.ar(Impulse.ar(1), 1, { rrand(0.02, 0.12) } ! 100 ) }.play;
>
> Tap in combination with RecordBuf or BufWr, like this:
>
> r = Buffer.alloc(s, s.sampleRate * 1, 1);
> y = { RecordBuf.ar( Impulse.ar(1), r);  Tap.ar(r, 1, { rrand(0.02, 0.12) }
> ! 100 ) }.play;
>
> takes around 170% of the multiple DelayC solution!!
> Also, with PlayBuf ("inside" Tap) it is not possible to modulate the
> delaytime, because it just sets the startPos.

Note, there is a difference between the cpu indication of the server, and the
one in activity monitor (or top). The latter is the actual used cpu, the
other is how much of the block processing time is taken up.

The second one is indeed more hungry with regard to the scsynth indication.

> When I replace Tap by BufRd, even with only one Phasor for everything, I
> could modulate the delaytimes. But regarding CPU power this takes still as
> much as Tap:
>
> r = Buffer.alloc(s, s.sampleRate * 1, 1)
> (
> y = { var ph, smps;
> ph = Phasor.ar(0,1, 0, BufFrames.ir(r));
> smps = SampleRate.ir.neg;
> BufWr.ar( Impulse.ar(1), r, ph, 1);
> BufRd.ar(1, r, ph + ({ rrand(0.02, 0.12) * smps } ! 100), 1, 4);
> }.play
> )

cpu takes more, scsynths indication about the same.

> In order to save memory one could use shared buffers, like this:
>
> r = Buffer.alloc(s, s.sampleRate * 1, 1)
> y = {  BufDelayC.ar(r, Impulse.ar(1), { rrand(0.02, 0.12) } ! 100 ) }.play
>
> which needs almost the same amount of CPU power than DelayC.
>
> So in the end BufDelayC seems to be for now the most efficient solution in
> terms of memory usage and CPU power.
> But it still needs x buffer write UGens instead of only one.
>
> So I guess there must be be a more efficient way to implement multitap
> delays in SC3. What about a pair of UGens like the ones in MaxMSP but using
> shared buffers:
>
> BufTapIn.ar(inputArray, bufnum);
> BufTapOut.ar(numChannels, bufnum, delaytime, interpolation);

hmm..
could be interesting...

But... if you are going up to a certain amount of taps in the delay, it will
eventually become more effiicient to do a convolution.
Now, these UGens can be greatly improved still in performance...

> ???
> Would it be hard to implement that?
>
> Also, I'd like to have non-interpolating Delay UGens which take just
> samples instead of delaytimes, like Delay1 and Delay2.
> For the construction of reverbs it would be good to also have sample based
> versions for Comb and Allpass. Plus a feedback argument instead of
> decaytime!

It should be trivial to make pseudo-ugens which make this conversion.

sincerely,
Marije

_______________________________________________
sc-users mailing list


info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[Andre Bartetzki]

Es war der 29.06.2008 20:24 Uhr, als nescivi nicht widerstehen konnte,
folgende Gedanken dem Netz anzuvertrauen:

> Note, there is a difference between the cpu indication of the server, and the
> one in activity monitor (or top). The latter is the actual used cpu, the
> other is how much of the block processing time is taken up.
>
> The second one is indeed more hungry with regard to the scsynth indication.

I meant only the server cpu indication.

> But... if you are going up to a certain amount of taps in the delay, it will
> eventually become more effiicient to do a convolution.

But I want to process the taps separately as well as send them to different
busses.

> It should be trivial to make pseudo-ugens which make this conversion.

yes, but in my opinion it is the wrong way as samples and feedback (instead
of delaytime and decaytime) are the "natural" ingredients for a delay.
Using a pseudo ugen or any conversion method to convert from samples to
delaytime whereas the delay needs internally anyway samples - these
inefficient back and forth calculations wouldn't be necessary if there were
also samples based delays.



best

Andre


--------------------------------------------------
Andre Bartetzki
http://www.bartetzki.de
mailto:andre@...

Tel   [phone]
VoIP  [phone]
Fax   [phone]

Skype bartetzki
http://www.myspace.com/andrebartetzki
--------------------------------------------------



_______________________________________________
sc-users mailing list


info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[Wouter Snoei-2]

>> So I guess there must be be a more efficient way to implement  
>> multitap
>> delays in SC3. What about a pair of UGens like the ones in MaxMSP  
>> but using
>> shared buffers:
>>
>> BufTapIn.ar(inputArray, bufnum);
>> BufTapOut.ar(numChannels, bufnum, delaytime, interpolation);

I would very much like it if those were there. They resemble the -  
very useful - DelayWr and DelayRd UGens from SC2. I really miss those..

cheers,
Wouter



Wouter Snoei

info@...
http://www.woutersnoei.nl


_______________________________________________
sc-users mailing list


info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[Julian Rohrhuber]

>>>So I guess there must be be a more efficient way to implement multitap
>>>delays in SC3. What about a pair of UGens like the ones in MaxMSP but using
>>>shared buffers:
>>>
>>>BufTapIn.ar(inputArray, bufnum);
>>>BufTapOut.ar(numChannels, bufnum, delaytime, interpolation);
>
>I would very much like it if those were there. They resemble the -
>very useful - DelayWr and DelayRd UGens from SC2. I really miss
>those..

wouldn't it already be of great help to make a phasor ugen that takes
such arguments? This could be used in a BufRd / BufWr and elsewhere,
and would not mean that there need to be extra ugens for each
interpolation scheme.
--





.

_______________________________________________
sc-users mailing list


info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/