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...
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
