Hello,
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:
http://megalego.free.fr/pd/patko/list-sequence/
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:
http://megalego.free.fr/pd/patko/tablas/
There you have my two cents, good luck in your project.
Colet Patrice
----- Mail original -----
De: "onyx@onyx-ashanti.com" onyxashanti@gmail.com À: Pd-list@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list