[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] call-backs, co-routines and inversion of control



On 08.01.2013, at 10:10, iani <zannos@xxxxxxxxx> wrote:

> - A synth is started (scheduled for sending). At that point: 
> - The system checks whether any buffers have been declared for loading, and
> if not, loads them.
> - The system checks whether any synthdefs have been declared for loading,
> and if not, loads them. 
> - [!!!] While the system is loading buffers and synthdefs: 
>   - if a new buffer is declared for loading, it is added to the queue for
> loading
>   - if a new synthdef is declared for loading (sending) it is added to the
> queue
>   - if another synth or routine is added, it is added to the queue of
> synths to be sent / routines to start. 
> - *After* all buffers and synthdefs are loaded in the correct order, synths
> and routines are started. 
> 
> This guarantees that synths will always be started *after* any buffers or
> synthdefs have finished loading. 
> 
> From your code I understand that you do some similar book-keeping at the
> level of organizing the sending of bundles. It seems that your splitBundles
> method does something similar to what I described above, but I am not
> exactly sure. Perhaps the description above may be of help. Might also be
> useful if you could provide a similar description of the what splitBundles
> does, plus a usage example. 

Hi Iannis, I just saw this mail late, so here a tentative reply.

s.bind works on a lower level. In the current implementation, it allows you to put an s.sync call between those calls that need to wait for completion. E.g.

s.bind {
	load a buffer
	send a synthdef
	s.sync;
	play a synth that uses the buffer and the synthdef
}

The main change with the new implementation we have been discussing is that you can leave out the s.sync call. Asynchronous messages are detected implicitly.

As this changes the behaviour, the question is whether to make it common as such.





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