Le vendredi 20 août 2010 à 11:58 -0300, Bernardo Barros a écrit :
sorry: 44100 (or 48000 or 96000)
2010/8/20 Bernardo Barros bernardobarros2@gmail.com:
maybe as audio signal through JACK? That is the fastest way I'm aware. That would be 441000 values per second per channel -1.0/+1.0, then you had to rescale again.
Yep, i used to use JACK. But always slow here ;) Thanx anyway. ++
Jack
2010/8/20 Jack jack@rybn.org:
Hello Mathieu,
I have already do that with [packOSC]/[unpackOSC] and [udpsend]/[udpreceive], it is slow too. I need to send 20000 lists of 3 floats (id, pos x, pos y) each frame (50 fps) from one process to other. Thanx. ++
Jack
Le vendredi 20 août 2010 à 10:20 -0400, Mathieu Bouchard a écrit :
On Fri, 20 Aug 2010, Jack wrote:
Is there another method to accelerate this transfert between GEM and MSD using [pd~] and [stdout] ?
Can you try communicating with OSC instead, and see whether it's faster ? It does lesser amounts of encoding and decoding for floats, than what [netsend]/[netreceive]/[stdout]/[pd~] need. How many floats do you need to send from one process to the other, per second ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Maybe that is a limitation of the PD "control rate" cords. You only get "audio rate" messages between audio boxes.
2010/8/20 Jack jack@rybn.org:
Le vendredi 20 août 2010 à 11:58 -0300, Bernardo Barros a écrit :
sorry: 44100 (or 48000 or 96000)
2010/8/20 Bernardo Barros bernardobarros2@gmail.com:
maybe as audio signal through JACK? That is the fastest way I'm aware. That would be 441000 values per second per channel -1.0/+1.0, then you had to rescale again.
Yep, i used to use JACK. But always slow here ;) Thanx anyway. ++
Jack
2010/8/20 Jack jack@rybn.org:
Hello Mathieu,
I have already do that with [packOSC]/[unpackOSC] and [udpsend]/[udpreceive], it is slow too. I need to send 20000 lists of 3 floats (id, pos x, pos y) each frame (50 fps) from one process to other. Thanx. ++
Jack
Le vendredi 20 août 2010 à 10:20 -0400, Mathieu Bouchard a écrit :
On Fri, 20 Aug 2010, Jack wrote:
Is there another method to accelerate this transfert between GEM and MSD using [pd~] and [stdout] ?
Can you try communicating with OSC instead, and see whether it's faster ? It does lesser amounts of encoding and decoding for floats, than what [netsend]/[netreceive]/[stdout]/[pd~] need. How many floats do you need to send from one process to the other, per second ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/20/2010 05:45 PM, Bernardo Barros wrote:
Maybe that is a limitation of the PD "control rate" cords. You only get "audio rate" messages between audio boxes.
it took a while for me to understand what you actually mean...
"control rate" really means "event-based" (asynchronous), and only at certain points in time (at the 64 samples boundary). the 64 samples boundary limits your latency (it will jitter up to 64 samples[1]), but it doesn't say anything about the bandwidth. you can send 100 times more data in a second between 2 [+] objects than between to [+~] objects [2].
mgasdr IOhannes
[1] plus an offset [2] if you don't do block processing.
[2] if you don't do block processing
ah yes, I was thinking as one value per block.
2010/8/20 IOhannes m zmölnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/20/2010 05:45 PM, Bernardo Barros wrote:
Maybe that is a limitation of the PD "control rate" cords. You only get "audio rate" messages between audio boxes.
it took a while for me to understand what you actually mean...
"control rate" really means "event-based" (asynchronous), and only at certain points in time (at the 64 samples boundary). the 64 samples boundary limits your latency (it will jitter up to 64 samples[1]), but it doesn't say anything about the bandwidth. you can send 100 times more data in a second between 2 [+] objects than between to [+~] objects [2].
mgasdr IOhannes
[1] plus an offset [2] if you don't do block processing. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxur00ACgkQkX2Xpv6ydvQG1wCeNExE1sM5ez+6uKIg+dTR+nLY YmwAoM02qkqU1q6JFSphnrN2/Z1UEWpT =R/k8 -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Bernardo Barros -
IOhannes m zmölnig -
Jack