hi all, interesting to have this discussion on this list ... > Since synths run fairly independent of each other, and we have a fairly clear > structure of the graph, as determined by the group tree structure, I think it > should be possible to determine which synths can run independently, and at > which points they need to be mixed together. > It would require an analysis of which synths are writing to which buses, and > which ones are subsequently reading from it. And in the end, you'll need to > mix everything together. > Mind you, this can still be somewhat of an headache to determine. the main problem when thinking about a multithreaded audio signal processing is the implicit dependency tracking. parallelizing a graph with explicit dependencies is quite easy (actually, i did an implementation of that for nova a few years ago). the problems start, when thinking about a implicit dependency tracking, i.e. ordering the access to resources. i would not want to implement a dependency tracking for the resource access in scsynth, since the accessed resources can be changed in a sample-accurate way. it would be a pain and would probably introduce quite a significant overhead. from my view, supercollider's node dependency management is not sufficient enough for formulating an asynchronous dsp graph, since the node graph is essentially a node list. i have been thinking about an extension to the dependency constraints, i.e. constraint lists, basically a list of constraints for node ordering, where a constraint is a pair (node, relation). that way, one could formulate multiple dependencies for one node manually explicitly from the language instead of implementing an automatic dependency tracking. so much about the idea ;) i already have a c++ implementation of a multithreaded dsp graph scheduler using constraint lists, which is completely independent from scsynth. i am not completely sure, how compatible it will be with scsynth (i.e. synthdefs/ugens/osc interface), though ... it is part of my master thesis, so i may be able so spend some time on the project during this year ... of course, i would be interested in some kind of supercollider integration, however it would result in a language extension, which is not backwards compatible. anyway, i would be curious to hear some thoughts on this from the supercollider community best, tim -- tim@xxxxxxxxxx http://tim.klingt.org All we composers really have to work with is time and sound - and sometimes I'm not even sure about sound. Morton Feldman
Attachment:
signature.asc
Description: OpenPGP digital signature