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

[Rohan Drape <rohan.drape@xxxxxxxxx>]

> The complementary case, however, isn't possible:
>
>  UGen:[1,2] & Buffer:[1,2,3,4] -> [(1,1),(2,2),(1,3),(2,4)] etc.
>
> Would this be an argument against cycling?

I guess so, it'd be asymmetric, & more problematic still:

UGen:[1,2] & Buffer:[] -> [_,_]

So yes, your rule is clearer.

Still, it'd be good to keep the warning.

Best,
Rohan

Semi-off-topic: The current rule (JMcC) does have a logic.

playBuf nodes wait for the buffer to have the correct
allocation and then begin to sound, if the buffer ceases
being correct the node ceases to sound, if the buffer
resumes being correct... etc. etc.

Could someone be utilising that logic?

If so perhaps a 'channel-mismatch-mode' is worth the trouble?

I really don't know.

MODE 0 - zero (JMcC rule)
MODE 1 - first n-channels then zero as required (JR rule)

/u_cmd isn't as simple to implement, or to use, as an extra
UGen input.

Adding an input breaks some codes, if sclang and scsynth are
on different sides of the edit, and existing NRT files.

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