[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] [jit] BusPlug:ar/kr return array if no numChannels specified
> On 23.12.2015, at 08:27, Till Bovermann <lfsaw@xxxxxxxx> wrote:
>
>
>> 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
Could you live with 2.2 also? With 2.1 you may run into errors when working with dynamic multichannel expansion.
_______________________________________________
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/