[PD] Networking patches to utilize multiple cores

Patrice Colet colet.patrice at free.fr
Sun Dec 11 15:08:00 CET 2011


 I've once made a project like this, and found out that it's better to not send interpolated data through FUDI,
interpolation can be done on client's end, it saves a lot of bandwidth.

Just an idea,

 for sequencing events there are ways to reduce a lot the dataflow by using protocols different from MIDI sequencing.
MIDI needs a very tight timecode, the amount of data is increasing with bpm and controller values.
I've found one different way that is about sending a packet containing all the pattern informations
that would be triggered with a simple beat clock. There is a backup of this work there:


This might be suited for transmitting sequential events through network,
but I haven't experimented this yet, 
the main idea was about interpreting tabla language:


There you have my two cents, good luck in your project.

Colet Patrice

----- Mail original -----
> De: "onyx at onyx-ashanti.com" <onyxashanti at gmail.com>
> À: Pd-list at iem.at
> Envoyé: Jeudi 8 Décembre 2011 19:19:55
> Objet: [PD] Networking patches to utilize multiple cores
> Greets.
> Is there a proper or preferred method for using any of the networking
> objects in pd-extended to allow for realtime bi-directional
> communication
> between patches on the same computer, so as to utilize 2 or more cpu
> cores?
>  I am currently trying to discover the best way to handle this.
> i started with netsend/netrecieve and used [route] to send
> approximately 40
> or so streams as messages, and it worked, somewhat, but I think i may
> have
> been squeezing too much data through that one netsend as it was a bit
> sluggish (running on a dual core thinkpad 1.83ghz, 3gb ram).  I am
> working
> with 2-5ms latencies so sluggish can screw me up in performance,
> especially
> since i havent even added 60% of the data that will be streaming from
> my
> "messages" patch to my "signals" patch.  I am looking at
> netserver/netclient  and contemplating breaking the streams up into 2
> or
> more clients but i wanted to see if anyone had any advice in this
> regard.
> the goal is to have a "messages" patch that would interpret all the
> incoming sensor and performance data, send it to subpatches for GEM
> visualizations, interpretive synth controls and looping system
> parameters,
> THEN, send that data to a separate patch that would house around 15
> signal
> object based subpatches for synthesis, looping and effects.  any
> status
> feedback i need from the signal objects would need to be sent back to
> the
> messages patch for processing and display, so a realtime,
> bi-directional
> solution is very important.
>  insight?
> Onyx
> --
> www.onyx-ashanti.com
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list

More information about the Pd-list mailing list