[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
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/