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
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
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.
yes, my idea as well, is the only send message data across, with all the
heavy lifting done in the "signal" patch on the client end.
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:
would this work properly on high speed realtime data? my goal is to create a connection that can handle many streams of real time data, very fast. it may be a moot point later this week as i just ordered an i7 based quadcore laptop which i think will deal with all of this without blinking but I would like to find the most efficient route for elegance sake.
thanks for the feedback. i will investigate those patches thoroughly.
onyx
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
----- Mail original -----
De: "onyx@onyx-ashanti.com" onyxashanti@gmail.com À: "Patrice Colet" colet.patrice@free.fr Cc: Pd-list@iem.at Envoyé: Dimanche 11 Décembre 2011 21:08:37 Objet: Re: [PD] Networking patches to utilize multiple cores
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:
would this work properly on high speed realtime data? my goal is to create a connection that can handle many streams of real time data, very fast.
This would just allow to send sequence events without blowing network all the time
The idea is about using a message system for regenerating data on client instead of directly streaming data, that way it reduces network bandwidth needs, but require a faster cpu. this also certainly need to use NTP (a time server) to sync everything.
it
may be a moot point later this week as i just ordered an i7 based quadcore laptop which i think will deal with all of this without blinking but I would like to find the most efficient route for elegance sake.
You might also be interested at looking into netpd code.
thanks for the feedback. i will investigate those patches thoroughly.
onyx
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
-- www.onyx-ashanti.com
-
onyx＠onyx-ashanti.com -
Patrice Colet