[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



I haven't read the patch yet, but from the standpoint if functionality, this seems problematic to me, an probably incurs more overhead in the code.
The problem is that you have the UGen making decisions for you that you have no power to quickly override. If I play a 4 channel ambisonic file and make the mistake if coding in 2 channels, I will then start to wonder why I seem to have no y and z information coming through, and the 'bug' is that PlayBuf decided to go ahead an work with only the first two channels. I would be looking at my decoders, the original files, etc, and probably not at the source if the problem.
With silence, I investigate why my file isn't playing back, and I see a warning in the window.
Many languages return nothing when a function or method with a return is not able to fulfill the return, and that is what PlayBuf is doing. It makes the problem much easier to find and fix, rather then providing a bandaid that might mask problems further down the signal chain.
And like I said, I also imagine the prevention of the read pointers reading off into garbage memory to achieve what you did is more costly CPU wise the. The single check, posting of a warning and the silence return.
Hope that makes sense.
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/