[PD] Parallel Audio Processing (Was: How's Pd limited?)

[Christof Ressi]

Another possibility for at least some degree of parallel audio processing, I guess, is to use streaming objects + several instances of Pd.  I tried out [udpsend~] and [udpreceive~] (taken from the "net" library in Pd extended) and they seem to work reliably. Of course there is some latency envolved and it's no practical solution for our future 100 core machines :-p.

What are in your experience the best methods for sharing audio via different Pd instances?
And does anyone know the current status of "Audio over OSC"? I found this paper from 2010 http://iem.kug.ac.at/fileadmin/media/iem/projects/2010/jaeger.pdf 
 
Christof



> Gesendet: Mittwoch, 24. Februar 2016 um 11:12 Uhr
> Von: Jack <jack at rybn.org>
> An: pd-list at lists.iem.at
> Betreff: Re: [PD] How's Pd limited?
>
> 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
> > 
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>