[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 20:22, Julian Rohrhuber <julian.rohrhuber@xxxxxxxxxxxxxxxxxx> wrote:

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

Actually it would have been nice, but it never worked that way. The ugen just failed and didn't try again ...


>> I hadn't thought that there are NRT files that are
>> separately kept - is that so? But then, still 0 would
>> be the default.
> 
> It's any existing binary ugen graphs, so either as
> scsyndef files or as d_recv messages in NRT files.
> 
> The graph stores the number of inputs for each ugen,
> and if it's not the same as the actual ugen at the
> server things can go wrong, or at least they have in
> the past...
> 
> I've got NRT and scsyndef files on disk.  Is it very
> eccentric?  NRT files can be much smaller than sound
> files, and can live in git etc.
> 

Nice idea, I just never saw it. It is a slightly unstable format if argument numbers can't change, unfortunately. It may be better in terms of sustainability to use a human readable score. I wonder what would have to be done to make it sustainable.


> I still really don't know if the MODE input's worth the
> trouble.

Yes, let's see.

(btw. now your mails end up even in a completely different mailbox ...)
_______________________________________________
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/