Yeah, but the problem here (automatic compute resource distribution) isn't just with the actual distribution. Control timing is a huge issue too. If you have multiple voices of the same synth on different threads, good luck playing a chord. It will frequently be an arpeggio. If there are very strict, predictable rules about the order of when each voice computes and when it sleeps in order to wait for new samples and control signals, this problem vanishes, but then you are no longer computing in parallel, and you might as well have everything on one thread anyway.
This is a /really/ interesting problem. If someone can solve it, she deserves the nobel prize in computer music.
On 2/24/16 5:11 AM, martin brinkmann wrote:
maybe this is also a matter of convenience: i'd rather have the dsp-framework automagically divide and distribute my program to the available resources than to care for it myself. while it is for example ok to put each complex voice of a synth in an extra pd~ to make optimum use of the few cores, i'd rather not want to spend much time thinking about grouping functinality into (lots of) pd~ objects for a huge amount of cores.
one possibility would be to generally encapsulate any small part of a patch into its own pd~ object and let the os do the work. but i think this is not very convenient and would create a massive and unnecessary overhead.
i don't know of any (audio-)examples where this problem is handled in an elegant way though: afaik max has the same problem, reaktor is single-threaded too, and most daws do something like "use one thread per track"...
On 23/02/16 23:45, David Medine wrote:
I think we all need to learn more about multi-threading if we want to run real-time, modular, digital signal processing algorithms on multi-core machines. I, for one, can not think of any general, robust way to do this. In that sense, Pd's adherence to single threading is actually a very elegant solution to the problem.
On 2/23/2016 12:25 PM, martin brinkmann wrote:
On 22/02/16 02:49, Matti Viljamaa wrote:
How do you think Pure Data is limited?
for me the only real and important (i can think of at the moment) limitation is the block-based audio processing. to me this seems quite unnatural and inconvenient when dealing with digital audio. it kept me for a couple of years from using pd, though it is only a 'showstopper' in rather few cases, i found out. feedback in large/complex patches for example, since it is not very practical (or possible at all) to re-block everything to 1...
what i tried but couldn't (yet): build a decent piano-roll editor (vanilla).
and i believe too, pd has to 'learn' better multithreading to run adequately on our future machines with hundreds or even thousands of arm-cores...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list