Hi everyone,
In the process of building some kind of audio oscilloscope in Gem I'm trying to send values from a table/array from one computer's PD to another's through OSC.
At the moment, my chosen solution is to have a counter scan the table, then pack the values (X & Y) and send them through a:
[send /OSC/Whatever/The/Name $1 $2(
Anyway, I do have this feeling that this is not a smart solution.
Anyone has ever done it before (send array values through OSC)/has a cleverer idea ?
Danke,
Jérôme
I've only played with OSC a little, but some things that come to mind:
use blocks of 32 or 64 values rather than sending each one individually. That way your packet overhead is smaller.
but the spec lists them as IEEE32s, check on what you are getting at the receiving end.
you can't be sure of the delivery order (or of delivery at all).
see
http://opensoundcontrol.org/spec-1_0
On Sun, 03 Dec 2006 22:21:17 +0100 Jerome Tuncer columbiatwo@free.fr wrote:
Hi everyone,
In the process of building some kind of audio oscilloscope in Gem I'm trying to send values from a table/array from one computer's PD to another's through OSC.
At the moment, my chosen solution is to have a counter scan the table, then pack the values (X & Y) and send them through a:
[send /OSC/Whatever/The/Name $1 $2(
Anyway, I do have this feeling that this is not a smart solution.
Anyone has ever done it before (send array values through OSC)/has a cleverer idea ?
Danke,
Jérôme
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi padawan12
padawan12 a écrit :
I've only played with OSC a little, but some things that come to mind:
- OSC lets you pack things into "bundles" and it might be better to
use blocks of 32 or 64 values rather than sending each one individually. That way your packet overhead is smaller.
I didn't dig very much much into what OSC bundles were all about but it seems to me that it looks more like something to send messages to multiple destinations at the same time than to send multiple values to only one dest. Somebody correct me if I'm wrong...
- Beware of what happens to floats, I seemed to get some truncation
but the spec lists them as IEEE32s, check on what you are getting at the receiving end.
I'd have to check that yes, anyway my scope is only a kind of scope, it doesn't have to be very very accurate in term of values (-:
- It's a UDP protocol so bear in mind that over a wide area link
you can't be sure of the delivery order (or of delivery at all).
I'll bear that in mind as well.
see
Thanks, worth checking,
Jé
On Sun, 03 Dec 2006 22:21:17 +0100 Jerome Tuncer columbiatwo@free.fr wrote:
Hi everyone,
In the process of building some kind of audio oscilloscope in Gem I'm trying to send values from a table/array from one computer's PD to another's through OSC.
At the moment, my chosen solution is to have a counter scan the table, then pack the values (X & Y) and send them through a:
[send /OSC/Whatever/The/Name $1 $2(
Anyway, I do have this feeling that this is not a smart solution.
Anyone has ever done it before (send array values through OSC)/has a cleverer idea ?
Danke,
Jérôme
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Jerome Tuncer wrote:
Hi padawan12
padawan12 a écrit :
I've only played with OSC a little, but some things that come to mind:
- OSC lets you pack things into "bundles" and it might be better to
use blocks of 32 or 64 values rather than sending each one individually. That way your packet overhead is smaller.
I didn't dig very much much into what OSC bundles were all about but it seems to me that it looks more like something to send messages to multiple destinations at the same time than to send multiple values to only one dest. Somebody correct me if I'm wrong...
i am happy to correct you here. OSC bundles are about logical time: each message in an OSC bundle will be at received at the same logical time (bundles have time stamps, messages don't). it has nothing to do with broadcasting or the like.
however i doubt whether bundles make so much sense here: i would just send "raw" data over the link (a list of floats you want to display; probably 2 lists, if you want an xy-scope), instead of sending x,y-pairs in separate messages (just think of all the OSC-selectors you will have to send with no additional information)
another idea would be to use audio directly via some audio-routing framework (jack)....
mfga.sdr IOhannes
Hallo,
IOhannes m zmoelnig a écrit :
Jerome Tuncer wrote:
Hi padawan12
padawan12 a écrit :
I've only played with OSC a little, but some things that come to mind:
- OSC lets you pack things into "bundles" and it might be better to
use blocks of 32 or 64 values rather than sending each one individually. That way your packet overhead is smaller.
I didn't dig very much much into what OSC bundles were all about but it seems to me that it looks more like something to send messages to multiple destinations at the same time than to send multiple values to only one dest. Somebody correct me if I'm wrong...
i am happy to correct you here. OSC bundles are about logical time: each message in an OSC bundle will be at received at the same logical time (bundles have time stamps, messages don't). it has nothing to do with broadcasting or the like.
That's kind of what I meant. Except that I had not had coffee yet : "multiple destinations" were supposed to mean different OSC receive names but on same machine ! Wasn't I clear ?! I must admit I wasn't at all (-:
however i doubt whether bundles make so much sense here: i would just send "raw" data over the link (a list of floats you want to display; probably 2 lists, if you want an xy-scope), instead of sending x,y-pairs in separate messages (just think of all the OSC-selectors you will have to send with no additional information)
That's precisely the point: sending a list of floats except that OSC messages don't seem to be able to handle lists. To be more precise, they sort of do but I have to convert them to symbol first and they still come out as lists. Check out my example patch (zexy and OSCx libs needed) that illustrates my first idea on how to transmit my list. tabset doesn't seem to work here. I'd say it should, shouldn't it?
Anyway, seeing the patch should make my desire more understable and I'm sure someone has a smartre idea...
another idea would be to use audio directly via some audio-routing framework (jack)....
This would be a good solution for me, I'd have to dig into what I once heard was called netjack.
mfga.sdr IOhannes
#N canvas 324 372 843 454 8; #X obj 336 93 cnv 15 370 140 empty empty empty 5 12 0 16 -233017 -66577 0; #X obj 177 93 cnv 15 150 140 empty empty empty 5 12 0 16 -233017 -66577 0; #X obj 19 93 cnv 15 150 140 empty empty empty 5 12 0 16 -233017 -66577 0; #X obj 498 68 print; #X obj 498 46 l2s; #X obj 19 42 cnv 15 130 50 empty empty 1 5 15 0 18 -195568 -66577 0 ; #X text 52 71 Fill the array:; #X obj 177 42 cnv 15 130 50 empty empty 2 5 15 0 18 -195568 -66577 0; #X text 210 71 Connect UDP :; #X obj 336 42 cnv 15 130 50 empty empty 3 5 15 0 18 -195568 -66577 0; #X text 370 71 Dump & send:; #X text 468 100 <- Outputs content of a table as a list; #X text 365 147 <- Converts to type "symbol"; #X obj 20 292 cnv 15 450 140 empty empty empty 5 12 0 16 -233017 -66577 0; #X obj 20 241 cnv 15 130 50 empty empty 4 5 15 0 18 -195568 -66577 0; #X text 48 251 OSC is received; #X obj 49 266 dumpOSC 9990; #X obj 49 300 OSCroute /Test; #N canvas 0 0 450 300 FillArray 0; #X obj 10 14 inlet; #X msg 10 43 ; SendingArray sinesum 32 0.5 0.5 0.1; #X connect 0 0 1 0; #X restore 23 99 pd FillArray; #X obj 23 118 table SendingArray; #X obj 23 67 bng 22 250 50 0 empty empty empty 17 7 0 10 -260818 -1 -1; #X obj 181 67 bng 22 250 50 0 empty empty empty 17 7 0 10 -260818 -1 -1; #X obj 181 214 sendOSC; #X msg 198 118 disconnect; #X msg 181 99 connect localhost 9990; #X obj 340 67 bng 22 250 50 0 empty empty empty 17 7 0 10 -260818 -1 -1; #X obj 340 99 tabdump SendingArray; #X obj 340 146 l2s; #X obj 340 125 prepend 0; #X text 402 126 <- Prepends a "0" (table filling purpose); #X msg 340 166 send /Test/Symbol $1; #X obj 49 390 tabset ReceivingArray; #X obj 74 367 print SymbolTransfer; #X obj 49 322 OSCroute /Symbol; #X obj 49 367 a2l; #X obj 49 411 table ReceivingArray; #X obj 49 342 t a a; #X text 203 368 <- Prints exactly what I'd like to get!!; #X text 178 411 Check the table; #X text 182 390 <- Doesn't do anything & no error in console; #X msg 498 13 this is a list that that appears to be too long to be converted to a symbol without losing info; #X connect 4 0 3 0; #X connect 16 0 17 0; #X connect 17 0 33 0; #X connect 20 0 18 0; #X connect 21 0 24 0; #X connect 23 0 22 0; #X connect 24 0 22 0; #X connect 25 0 26 0; #X connect 26 0 28 0; #X connect 27 0 30 0; #X connect 28 0 27 0; #X connect 30 0 22 0; #X connect 33 0 36 0; #X connect 34 0 31 0; #X connect 36 0 34 0; #X connect 36 1 32 0; #X connect 40 0 4 0;
Hallo, Jerome Tuncer hat gesagt: // Jerome Tuncer wrote:
That's precisely the point: sending a list of floats except that OSC messages don't seem to be able to handle lists. To be more precise, they sort of do but I have to convert them to symbol first and they still come out as lists. Check out my example patch (zexy and OSCx libs needed) that illustrates my first idea on how to transmit my list. tabset doesn't seem to work here. I'd say it should, shouldn't it?
I made some changes to your example and removed the symbol conversion again. It is working fine here, there as well?
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo Frank,
It does work and that's exactly what I needed... Thanks for helping, hadn't tried bulding the whole 'sendOSC formatted message' directly from a list. [list] is indeed an interesting and clever objet/class. I looked at the help file one hour ago and I was wondering: "What the hell is this 'trim the list selector off' interesting for??" (-:
++
Jé
Frank Barknecht a écrit :
Hallo, Jerome Tuncer hat gesagt: // Jerome Tuncer wrote:
That's precisely the point: sending a list of floats except that OSC messages don't seem to be able to handle lists. To be more precise, they sort of do but I have to convert them to symbol first and they still come out as lists. Check out my example patch (zexy and OSCx libs needed) that illustrates my first idea on how to transmit my list. tabset doesn't seem to work here. I'd say it should, shouldn't it?
I made some changes to your example and removed the symbol conversion again. It is working fine here, there as well?
Ciao
#N canvas 174 258 970 469 8; #X obj 336 93 cnv 15 570 140 empty empty empty 5 12 0 16 -233017 -66577 0; #X obj 177 93 cnv 15 150 140 empty empty empty 5 12 0 16 -233017 -66577 0; #X obj 19 93 cnv 15 150 140 empty empty empty 5 12 0 16 -233017 -66577 0; #X obj 498 68 print; #X obj 498 46 l2s; #X obj 19 42 cnv 15 130 50 empty empty 1 5 15 0 18 -195568 -66577 0 ; #X text 52 71 Fill the array:; #X obj 177 42 cnv 15 130 50 empty empty 2 5 15 0 18 -195568 -66577 0; #X text 210 71 Connect UDP :; #X obj 336 42 cnv 15 130 50 empty empty 3 5 15 0 18 -195568 -66577 0; #X text 370 71 Dump & send:; #X text 468 100 <- Outputs content of a table as a list; #X obj 20 292 cnv 15 450 140 empty empty empty 5 12 0 16 -233017 -66577 0; #X obj 20 241 cnv 15 130 50 empty empty 4 5 15 0 18 -195568 -66577 0; #X text 48 251 OSC is received; #X obj 49 266 dumpOSC 9990; #X obj 49 300 OSCroute /Test; #N canvas 0 0 450 300 FillArray 0; #X obj 10 14 inlet; #X msg 10 43 ; SendingArray sinesum 32 0.5 0.5 0.1; #X connect 0 0 1 0; #X restore 23 99 pd FillArray; #X obj 23 118 table SendingArray; #X obj 23 67 bng 22 250 50 0 empty empty empty 17 7 0 10 -260818 -1 -1; #X obj 181 67 bng 22 250 50 0 empty empty empty 17 7 0 10 -260818 -1 -1; #X obj 181 214 sendOSC; #X msg 198 118 disconnect; #X msg 181 99 connect localhost 9990; #X obj 340 67 bng 22 250 50 0 empty empty empty 17 7 0 10 -260818 -1 -1; #X obj 340 99 tabdump SendingArray; #X obj 49 322 OSCroute /Symbol; #X obj 49 342 t a a; #X text 203 368 <- Prints exactly what I'd like to get!!; #X text 198 411 Check the table; #X text 182 390 <- Doesn't do anything & no error in console; #X msg 498 13 this is a list that that appears to be too long to be converted to a symbol without losing info; #X obj 340 152 list trim; #X text 411 153 <- Converts remove "list" selector from [list]; #X msg 343 176 send /Test/Symbol $1; #X text 486 176 <- not needed anymore; #X obj 340 125 list prepend send /Test/Symbol 0; #X text 548 127 <- Prepends "send ..." etc. and a "0" (table filling purpose); #X obj 49 367 list; #X obj 49 411 table ReceivingArray 35; #X obj 74 367 print FloatTransfer; #X obj 49 390 s ReceivingArray; #X connect 4 0 3 0; #X connect 15 0 16 0; #X connect 16 0 26 0; #X connect 19 0 17 0; #X connect 20 0 23 0; #X connect 22 0 21 0; #X connect 23 0 21 0; #X connect 24 0 25 0; #X connect 25 0 36 0; #X connect 26 0 27 0; #X connect 27 0 38 0; #X connect 27 1 40 0; #X connect 31 0 4 0; #X connect 32 0 21 0; #X connect 36 0 32 0; #X connect 38 0 41 0;
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 4 Dec 2006, Jerome Tuncer wrote:
It does work and that's exactly what I needed... Thanks for helping, hadn't tried bulding the whole 'sendOSC formatted message' directly from a list. [list] is indeed an interesting and clever objet/class. I looked at the help file one hour ago and I was wondering: "What the hell is this 'trim the list selector off' interesting for??" (-:
[list trim] is not interesting: with a list input, it's the same as the left outlet of [route list]; otherwise it's the same as nothing at all (or right outlet of [route list]).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Mon, 4 Dec 2006, Jerome Tuncer wrote:
It does work and that's exactly what I needed... Thanks for helping, hadn't tried bulding the whole 'sendOSC formatted message' directly from a list. [list] is indeed an interesting and clever objet/class. I looked at the help file one hour ago and I was wondering: "What the hell is this 'trim the list selector off' interesting for??" (-:
[list trim] is not interesting: with a list input, it's the same as the left outlet of [route list]; otherwise it's the same as nothing at all (or right outlet of [route list]).
Almost: [list trim] is like both outlets of [route list] fused into the one outlet of [list trim]. This saves a bit of patching. Additionally the name "list trim" gives a better indication of when and why this operation is normally used. It's a better mnemonic than "route list"
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Jerome Tuncer hat gesagt: // Jerome Tuncer wrote:
It does work and that's exactly what I needed... Thanks for helping, hadn't tried bulding the whole 'sendOSC formatted message' directly from a list. [list] is indeed an interesting and clever objet/class. I looked at the help file one hour ago and I was wondering: "What the hell is this 'trim the list selector off' interesting for??" (-:
In addition to list-help.pd also this might be noteworthy: http://www.puredata.info/dev/PdMessages
Lists in Pd come in two major flavours: Those which start with a word other than "list" are "meta-messages", the others are "list-messages"
"send /test/symbol abc" is a meta-message. To convert it to a list message "list send /test/symbol abc" simply use the [list] object.
To convert "list send /test/symbol abc" back to "send /test/symbol abc" as wanted by [sendOSC] you use [list trim].
Frank Barknecht _ ______footils.org_ __goto10.org__
Ive been using netreceive to receive data from flash, but I cannot
send data to flash.
It seems that i need to send the messages with \0 at the end, but in
pure data i cannot write such message....
Has anyone been able to do it?
On Tue, 5 Dec 2006, Miguel Cardoso wrote:
Ive been using netreceive to receive data from flash, but I cannot send data to flash. It seems that i need to send the messages with \0 at the end, but in pure data i cannot write such message.... Has anyone been able to do it?
Try Martin Peach's networking externals. They allow you to send any bytes you want.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Thanks Martin!
do you know where i can find these externals?
On Dec 5, 2006, at 4:45 PM, Mathieu Bouchard wrote:
On Tue, 5 Dec 2006, Miguel Cardoso wrote:
Ive been using netreceive to receive data from flash, but I cannot
send data to flash. It seems that i need to send the messages with
\0 at the end, but in pure data i cannot write such message....
Has anyone been able to do it?Try Martin Peach's networking externals. They allow you to send any
bytes you want._ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Tue, 5 Dec 2006, Miguel Cardoso wrote:
Thanks Martin! do you know where i can find these externals?
In the CVS repository, or hopefully in an upcoming version of pd-extended.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Dec 5, 2006, at 2:34 PM, Mathieu Bouchard wrote:
On Tue, 5 Dec 2006, Miguel Cardoso wrote:
Thanks Martin! do you know where i can find these externals?
In the CVS repository, or hopefully in an upcoming version of pd- extended.
They are in the nightly builds, in the library "mrpeach"
http://autobuild.pure-data.info
.hc
Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith