« Return to Thread: delays and buffers
Re: delays and buffers
by nescivi
::
Rate this Message:
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/
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/
« Return to Thread: delays and buffers
| Free embeddable forum powered by Nabble | Forum Help |
