[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] For a more tolerant PlayBuf
On 14.12.2013, at 01:46, Rohan Drape <rohan.drape@xxxxxxxxx> wrote:
>> 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.
OK, I'll to that then. I just have to implement a mechanism that prevents the message from being posted once every cycle.
> 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.
Ok this is true, I hadn't thought about this at all.
> 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)
One could add one argument to the end of the inputs. It is a little bit like a \beginAction, analogous to \doneAction.
> Adding an input breaks some codes, if sclang and scsynth are
> on different sides of the edit, and existing NRT files.
Why should that be so? This would only happen if sclang and plugins were not edited together.
I hadn't thought that there are NRT files that are separately kept - is that so? But then, still 0 would be the default.
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml