[PD] How's Pd limited?

[david medine]

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 at lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160224/67069ef4/attachment.html>