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

[Julian Rohrhuber <julian.rohrhuber@xxxxxxxxxxxxxxxxxx>]

> 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.



 







_______________________________________________
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/