Re: [sc-dev] [jit] BusPlug:ar/kr return array if no numChannels specified

[Till Bovermann <lfsaw@xxxxxxxx>]

> On 17. Dec 2015, at 18:42, Julian Rohrhuber <julian.rohrhuber@xxxxxxxxxxxxxxxxxx> wrote:
> 
> 
>> On 17.12.2015, at 14:25, James Harkins <jamshark70@xxxxxx> wrote:
>> 
>>         // always return an array if no channel size is specified
>>        ^if(numChannels.isNil) { output.asArray } { output }
>> 
>> I'm sorry... I'm sure this was carefully considered, but it's rather annoying in one case which I would suppose to be quite common.
>> 
>> ~freq = 100;
>> 
>> ~mod.addSpec(\index, #[0.01, 50, \exp], \ratio, SnapControlSpec(1, 8, \lin, 0.5).snap_(0.05));
>> ~mod = { |index = 1, ratio = 1|
>>    SinOsc.ar(~freq.kr(1) * ratio, 0, index)
>> };
>> 
>> ~car = { |amp = 0.1|
>>    SinOsc.ar(~freq.kr * (1 + ~mod.ar(1)), 0, amp).dup
>> };
>> 
>> Only because I forgot the '(1)' after '~freq.kr', I get:
>> 
>> WARNING: Synth output should be a flat array.
>> [ [ a BinaryOpUGen ], [ a BinaryOpUGen ] ]
>> 
>> The synth appears to have the right structure, so this is a superfluous warning in the case of 'kr' or 'ar' on a mono NodeProxy. (As JITLib is meant for live coding, I'd assume it would err on the side of removing fussy requirements from user input. Here... nope.)
>> 
>> hjh
> 
> 
> Makes sense.
> 
> There are two ways of solving this, both involve trade offs.
> 
> 1) relax the test for right shape 
> 1.1) post only a warning if subarrays are > 1, 
> 1.2) or don’t post one at all
> 
> 2) unbubble the result of proxy.kr
> 2.1. when no num channels was given in the call to kr, and it happens to return only one
> 2.2. when one channel was given in the call to kr
> 2.2 always unbubble it, i.e. when one channel is returned, it won’t be an array then
> 
> 
> The trade offs:
> 1.1. a bit obscure as a condition
> 1.2. you may end up with something very hard to understand, and then a warning may be better also when live coding
> 
> 2.1. you need to call .asArray always when you want to iterate, and when the number of channels may vary
> 2.2. makes numChannels: 1 structurally different from numChannels: n (so a bit similar to 2.1.)
> 2.3. same as 2.2
> 
> 
> Not sure what is best.
> 


I am with james here... already had several cases where I could not find the problem of my implementation and then it turned out that I get a single-item array for Ndef(\a).kr. It just doesn't go well with channel expansion...

I could live perfectly well with 2.1


cheers
	Till
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/