Re: [sc-dev] For a more tolerant PlayBuf

[Josh Parmenter <josh@xxxxxxxxxxxxxxxxx>]

Wow... I need to retread what I type on the phone before hitting send. That first sentence is atrocious.

/*
Josh Parmenter
www.realizedsound.net/josh
*/

> On Dec 12, 2013, at 7:48 AM, Josh Parmenter <josh@xxxxxxxxxxxxxxxxx> wrote:
> 
> One other thing - if you want a 2 channel to play 2 channels of 4 channel file, THAT could be another UGen, and adding a channel offset would make sense as well (give me channels 2 and 3 of this four channel file, for instance). Perhaps take this version if PlayBuf that you have created, give it a new name and add that parameter to the interface and propose that? I would find that UGen very useful and worth the performance hit. Since it would probably mean using less memory in certain situations.
> Best
> Josh
> 
> /*
> Josh Parmenter
> www.realizedsound.net/josh
> */
> 
>> On Dec 12, 2013, at 2:07 AM, Julian Rohrhuber <julian.rohrhuber@xxxxxxxxxxxxxxxxxx> wrote:
>> 
>> Currently, in PlayBuf and BufRd, when the number of channels of a buffer don't match the number of ugen channels, we get a warning and silent failure. This seems overly strict, as we could easily just play back those channels that can be played back with a given configuration and ignore the rest.
>> 
>> Here is a patch that implements this, and I would argue it also makes the warning unnecessary, as it is entirely logical:
>> - playing back a four channel buffer with a stereo ugen, you get the first two channels
>> - playing back a one channel buffer with a stereo ugen, you get the channel and silence in the second
>> 
>> Please have a look if you find this reasonable - I'll also adjust the helpfiles accordingly.
>> BufRd and RecordBuf are other candidates for the future, also we could think of an offset parameter to PlayBuf and BufRd.
>> 
>> There is one glitch I have found, which is in the original implementation, and my change doesn't fix it (it must be in cubicinterp or the way it is used) - this is a separate issue:
>> a = Buffer.sendCollection(s, (1..1024), 1);
>> { PlayBuf.ar(1, a, rate: 0.5, loop:1) }.loadToFloatArray(action: _.postln);
>> FloatArray[ 1, -62.5, 2, 2.5, 3, 3.5, 4, 4.5, ...
>> 
>> Apart from this all the following tests return what they should:
>> 
>> s.reboot;
>> 
>> a = Buffer.sendCollection(s, (1..1024), 1);
>> b = Buffer.sendCollection(s, (1..1024), 3);
>> 
>> (
>> f = { |numChannels, buf|
>>   { PlayBuf.ar(numChannels, buf, loop:1) }.loadToFloatArray(action: _.postln)
>> };
>> );
>> 
>> // OK
>> 
>> f.(1, a);
>> f.(3, b);
>> f.(2, b);
>> f.(2, a);
>> f.(3, a);
>> 
>> 
>> (
>> f = { |numChannels, buf, interp, rate = 1|
>>   { BufRd.ar(numChannels, buf, Phasor.ar(0, BufRateScale.kr(buf) * rate, 0, BufFrames.kr(buf)), loop: 1, interpolation: interp) }.loadToFloatArray(action: _.postln);
>> };
>> )
>> 
>> f.(1, a, 2);
>> f.(3, a, 2);
>> 
>> f.(1, a, 1);
>> f.(3, a, 1);
>> 
>> f.(1, b, 2);
>> f.(3, b, 2);
>> 
>> f.(1, b, 1);
>> f.(2, b, 1);
>> f.(3, b, 1);
>> 
>> f.(1, b, 4);
>> f.(3, b, 4);
>> 
>> // rate:
>> 
>> f.(1, a, 2, 0.5);
>> f.(3, a, 2, 0.5);
>> 
>> f.(1, a, 1, 0.5);
>> f.(3, a, 1, 0.5);
>> 
>> f.(1, b, 2, 0.5);
>> f.(3, b, 2, 0.5);
>> 
>> f.(1, b, 1, 0.5);
>> f.(2, b, 1, 0.5);
>> f.(3, b, 1, 0.5);
>> 
>> f.(1, b, 4, 0.5); // glitch (but same as old implementation)
>> f.(3, b, 4, 0.5); // glitch
>> 
>> <tolerant_playbuf.diff>
> 
> _______________________________________________
> sc-dev mailing list
> 
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: https://listarc.bham.ac.uk/marchives/sc-dev/
> search: https://listarc.bham.ac.uk/lists/sc-dev/search/

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/