[PD] How's Pd limited?

[martin brinkmann]

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