[PD] How's Pd limited?

[Jack]

Hello,

Le 24/02/2016 00:19, Matt Barber a écrit :
> Can anyone explain more why [pd~] doesn't fulfill the desire for
> parallel processing, and maybe provide an example of something outside
> of Pd that does? I don't feel like I have a great handle on the design.
> As Jonathan said, it seems like Pd's determinism constraint is a big
> hurdle to clear, though it's already relaxed a bit with netsend/receive.
> What are the main differences between running an instance of Pd as a
> [pd~] slave to another instance, and running two instances that
> communicate via netsend/receive and jack?

I think, the main difference is :
- with [pd~] your communication is synchronous
- with [netsend]/[netreceive] your communication is asynchronous

So (if i am right), if something is heavy to compute (more than 100% of
your CPU) in your subprocess with [pd~], your parent have to wait the
end of this computation. This is not the case with [netsend]/[netreceive].
++

Jack


> 
> On Tue, Feb 23, 2016 at 5:45 PM, David Medine <dmedine at ucsd.edu
> <mailto:dmedine at ucsd.edu>> 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 <mailto: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 <mailto: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
>