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