I've posted source and dlls for [routeOSC], [packOSC], and [unpackOSC] here: http://puredata.info/Members/martinrp/OSCobjects They work with [udpsend] and [udpreceive] or [tcpsend] and [tcpreceive] which are here: http://puredata.info/Members/martinrp/netobjects They could probably also work to send OSC messages through [comport] if some kind of length was prepended to the list, otherwise comport doesn't know how long the message is. Also MIDI could work if there was a way to pack 8bits into 7bits for system exclusive. routeOSC is settable using messages like [set /path/one /path/two( ...but you can't set more paths than were in the original arguments of the object.
Martin
Hi Martin,
Martin Peach wrote:
I've posted source and dlls for [routeOSC], [packOSC], and [unpackOSC] here: http://puredata.info/Members/martinrp/OSCobjects
Could you shortly explain the differences between [routeOSC] and [OSCroute] from the OSCx package? And is [dumpOSC] comparable with [udpreceive]+[unpackOSC]? I'm little bit confused with all the different OSC externals from different packages...
thanks,
Piotr
Piotr Majdak wrote:
Hi Martin,
Martin Peach wrote:
I've posted source and dlls for [routeOSC], [packOSC], and [unpackOSC] here: http://puredata.info/Members/martinrp/OSCobjects
Could you shortly explain the differences between [routeOSC] and [OSCroute] from the OSCx package? And is [dumpOSC] comparable with [udpreceive]+[unpackOSC]?
Sure...[routeOSC] is based on [OSCroute] but the routes are settable after the object is created. It is also standalone in the sense that you don't need to load lib OSC to use it. It's basically the same code, cleaned up a bit. [unpackOSC] is based on [dumpOSC], again nearly the same thing but cleaned up and made independent of lib OSC. For instance the messages to the user use 'post' instead of printf and OSCerror or whatever it was. [packOSC] is based on [sendOSC] but doesn't do the network part. That can be handled by [udpsend] or [tcpsend] or possibly [comport] and [midiout] with some extra massaging of the lists they output. That makes the OSC objects transport independent as the spec intended (but nearly every implementation is hard-wired to use udp). The net objects can probably also be used to do telnet or email from within pd, without using python or scripts. I used different names for all of them so as not to break existing patches.
I'm little bit confused with all the different OSC externals from different packages...
I based them all on OSCx (the net objects are based on the [netsend] and [netreceive] objects inside pd), I consider them to be an improved version of OSCx but that's my opinion :) The other libraries (e.g. liblo) for OSC seem to be in c++ which is harder to integrate with pd's c code.
Martin
thanks,
Piotr
Hi Martin,
Martin Peach wrote:
Sure...[routeOSC] is based on [OSCroute] but the routes are settable after the object is created. It is also standalone in the sense that you don't need to load lib OSC to use it. It's basically the same code, cleaned up a bit. [unpackOSC] is based on [dumpOSC], again nearly the same thing but cleaned up and made independent of lib OSC. For instance the messages to the user use 'post' instead of printf and OSCerror or whatever it was. [packOSC] is based on [sendOSC] but doesn't do the network part. That can be handled by [udpsend] or [tcpsend] or possibly [comport] and [midiout] with some extra massaging of the lists they output. That makes the OSC objects transport independent as the spec intended (but nearly every implementation is hard-wired to use udp).
That's a nice thing. So, as far as I understand you, [packOSC] outputs something (a stream of messages, one message per byte?) which can be sent to a communication object such as [udpsend] or [comport]?
But, the oposite object to [packOSC], [unpackOSC] is hardcoded to UDP, like [sendOSC], right?
I used different names for all of them so as not to break existing patches.
That's a good idea. Thanks for watching the weird compatibility things :-)
I based them all on OSCx (the net objects are based on the [netsend] and [netreceive] objects inside pd), I consider them to be an improved version of OSCx but that's my opinion :)
I see it as an improvement too :-) Would you like to add your objects to the externals/OSCx directory in CVS? We could keep all the OSC stuff at one place...
br, Piotr
Piotr Majdak wrote:
Hi Martin,
Martin Peach wrote:
Sure...[routeOSC] is based on [OSCroute] but the routes are settable after the object is created. It is also standalone in the sense that you don't need to load lib OSC to use it. It's basically the same code, cleaned up a bit. [unpackOSC] is based on [dumpOSC], again nearly the same thing but cleaned up and made independent of lib OSC. For instance the messages to the user use 'post' instead of printf and OSCerror or whatever it was. [packOSC] is based on [sendOSC] but doesn't do the network part. That can be handled by [udpsend] or [tcpsend] or possibly [comport] and [midiout] with some extra massaging of the lists they output. That makes the OSC objects transport independent as the spec intended (but nearly every implementation is hard-wired to use udp).
That's a nice thing. So, as far as I understand you, [packOSC] outputs something (a stream of messages, one message per byte?) which can be sent to a communication object such as [udpsend] or [comport]?
It outputs a list of pd floats on [0..255], in other words, bytes, for each OSC packet. For example you could send a message like this:
[send /test/one/two 1 2 3 a b c( | [packOSC] | <---list of floats [prepend send] | <- list of 'send' + floats [udpsend]
See the attached patch.
But, the oposite object to [packOSC], [unpackOSC] is hardcoded to UDP, like [sendOSC], right?
No, [unpackOSC] takes a list of floats and converts it into a list whose first element is the OSC address, and subsequent elements are either symbols or floats, depending on what was in the OSC packet. [unpackOSC] can take output from [udpreceive] or [tcpreceive], or any list of floats that represent an OSC packet.
I used different names for all of them so as not to break existing patches.
That's a good idea. Thanks for watching the weird compatibility things :-)
I based them all on OSCx (the net objects are based on the [netsend] and [netreceive] objects inside pd), I consider them to be an improved version of OSCx but that's my opinion :)
I see it as an improvement too :-) Would you like to add your objects to the externals/OSCx directory in CVS? We could keep all the OSC stuff at one place...
Yes, sure, but you don't need OSCx for these objects to work.
br, Piotr
Martin
#N canvas 720 26 484 671 12; #X obj 171 184 udpsend; #X msg 177 158 disconnect; #X msg 171 96 connect 127.0.0.1 9997; #X obj 71 96 packOSC; #X obj 71 128 prepend send; #X obj 54 470 udpreceive 9997; #X obj 169 494 unpack 0 0 0 0; #X floatatom 169 517 3 0 0 0 - - -; #X floatatom 204 517 3 0 0 0 - - -; #X floatatom 240 517 3 0 0 0 - - -; #X floatatom 276 517 3 0 0 0 - - -; #X text 133 516 from; #X text 6 431 right output is sender's ip address as list of floats ; #X obj 171 207 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1; #X text 25 259 (i.e. bytes).; #X text 4 312 The output is 1 when connected , else 0; #X text 4 226 udpsend takes three messages: 1> send followed by one or more floats on [0..255]; #X text 4 274 2> connect followed by an ip address and a port number ; #X text 4 293 3> disconnect; #X text 6 395 udpreceive takes a port number as argument; #X text 6 413 left output is received udp packet as list of floats ; #X obj 54 502 unpackOSC; #X msg 14 18 send /test/one/two/three zz 88 T; #X msg 71 65 send /test 1 2 3; #X obj 52 546 print; #X obj 66 594 routeOSC /test /west; #X obj 66 629 print a; #X obj 143 629 print b; #X obj 221 629 print c; #X msg 90 43 send /west 35; #X msg 199 559 set /left; #X msg 201 41 send /*/left 22; #X msg 296 24 send /?est/ 1; #X msg 246 66 send /left one two; #X msg 290 559 set /left /right; #X msg 339 43 send /right 88; #X connect 0 0 13 0; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 3 0 4 0; #X connect 4 0 0 0; #X connect 5 0 21 0; #X connect 5 1 6 0; #X connect 6 0 7 0; #X connect 6 1 8 0; #X connect 6 2 9 0; #X connect 6 3 10 0; #X connect 21 0 24 0; #X connect 21 0 25 0; #X connect 22 0 3 0; #X connect 23 0 3 0; #X connect 25 0 26 0; #X connect 25 1 27 0; #X connect 25 2 28 0; #X connect 29 0 3 0; #X connect 30 0 25 0; #X connect 31 0 3 0; #X connect 32 0 3 0; #X connect 33 0 3 0; #X connect 34 0 25 0; #X connect 35 0 3 0;
On Apr 26, 2006, at 11:01 PM, Piotr Majdak wrote:
Hi Martin,
Martin Peach wrote:
Sure...[routeOSC] is based on [OSCroute] but the routes are
settable after the object is created. It is also standalone in the
sense that you don't need to load lib OSC to use it. It's
basically the same code, cleaned up a bit. [unpackOSC] is based on [dumpOSC], again nearly the same thing but
cleaned up and made independent of lib OSC. For instance the messages to the user use 'post' instead of printf
and OSCerror or whatever it was. [packOSC] is based on [sendOSC] but doesn't do the network part.
That can be handled by [udpsend] or [tcpsend] or possibly
[comport] and [midiout] with some extra massaging of the lists
they output. That makes the OSC objects transport independent as
the spec intended (but nearly every implementation is hard-wired
to use udp).That's a nice thing. So, as far as I understand you, [packOSC]
outputs something (a stream of messages, one message per byte?)
which can be sent to a communication object such as [udpsend] or
[comport]?But, the oposite object to [packOSC], [unpackOSC] is hardcoded to
UDP, like [sendOSC], right?
These are really great, it should make things much more flexible.
I used different names for all of them so as not to break existing
patches.That's a good idea. Thanks for watching the weird compatibility
things :-)I based them all on OSCx (the net objects are based on the
[netsend] and [netreceive] objects inside pd), I consider them to
be an improved version of OSCx but that's my opinion :)I see it as an improvement too :-) Would you like to add your
objects to the externals/OSCx directory in CVS? We could keep all
the OSC stuff at one place...
I think it might make more sense to make a separate library for these
objects. But if they are based on libOSC, then they could be
integrated. [OSCroute] and [routeOSC] in the same package sounds a
bit odd to me. Perhaps [routeOSC] could be renamed to soemthing like
[set_route].
.hc
"I have the audacity to believe that peoples everywhere can have
three meals a day for their bodies, education and culture for their
minds, and dignity, equality and freedom for their spirits."
- Martin Luther King, Jr.
I think OSCx should be deprecated,
left around only for compatibility with old patches.
Seems to me Martin's OSC stuff does the same and more than the orginal OSCx, so keeping them both around makes little sense.
Especially when it means giving the (hopefully more used) routeOSC a name like set_route.
Actually I think we could do:
net/tcpsend net/tcpreceive net/udpsend net/udpreceive osc/route osc/pack osc/unpack
..b.
Hans-Christoph Steiner wrote:
On Apr 26, 2006, at 11:01 PM, Piotr Majdak wrote:
Hi Martin,
Martin Peach wrote:
Sure...[routeOSC] is based on [OSCroute] but the routes are settable after the object is created. It is also standalone in the sense that you don't need to load lib OSC to use it. It's basically the same code, cleaned up a bit. [unpackOSC] is based on [dumpOSC], again nearly the same thing but cleaned up and made independent of lib OSC. For instance the messages to the user use 'post' instead of printf and OSCerror or whatever it was. [packOSC] is based on [sendOSC] but doesn't do the network part. That can be handled by [udpsend] or [tcpsend] or possibly [comport] and [midiout] with some extra massaging of the lists they output. That makes the OSC objects transport independent as the spec intended (but nearly every implementation is hard-wired to use udp).
That's a nice thing. So, as far as I understand you, [packOSC] outputs something (a stream of messages, one message per byte?) which can be sent to a communication object such as [udpsend] or [comport]?
But, the oposite object to [packOSC], [unpackOSC] is hardcoded to UDP, like [sendOSC], right?
These are really great, it should make things much more flexible.
I used different names for all of them so as not to break existing patches.
That's a good idea. Thanks for watching the weird compatibility things :-)
I based them all on OSCx (the net objects are based on the [netsend] and [netreceive] objects inside pd), I consider them to be an improved version of OSCx but that's my opinion :)
I see it as an improvement too :-) Would you like to add your objects to the externals/OSCx directory in CVS? We could keep all the OSC stuff at one place...
I think it might make more sense to make a separate library for these objects. But if they are based on libOSC, then they could be integrated. [OSCroute] and [routeOSC] in the same package sounds a bit odd to me. Perhaps [routeOSC] could be renamed to soemthing like [set_route].
.hc
"I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits." - Martin Luther King, Jr.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi!
B. Bogart wrote:
I think OSCx should be deprecated,
Are there any disadvantages in Martin's impementation? I'm thinking about many short messages between [udpreceive] and [unpackOSC] compared to the old solution with [dumpOSC]...
Actually I think we could do:
net/tcpsend net/tcpreceive net/udpsend net/udpreceive osc/route osc/pack osc/unpack
I like this idea. This is very transparent and easy to memorise.
br, Piotr
Piotr Majdak wrote:
Hi!
B. Bogart wrote:
I think OSCx should be deprecated,
Are there any disadvantages in Martin's impementation? I'm thinking about many short messages between [udpreceive] and [unpackOSC] compared to the old solution with [dumpOSC]...
Yes, it takes more time to copy the bytes from one buffer into another and then send them to another object. If [dumpOSC] does what you want, you should keep using it. Also [unpackOSC] doesn't handle bundles efficiently (it's copying the same buffer recursively -- and I haven't even tested it :( ). I need to work on that a bit more but then I don't know if anyone actually uses bundles. Also timetags are in the future... And of course if you need the speed it's best to hardcode a program in c or assembler.
Martin
On Apr 27, 2006, at 2:03 AM, B. Bogart wrote:
I think OSCx should be deprecated,
left around only for compatibility with old patches.
Seems to me Martin's OSC stuff does the same and more than the orginal OSCx, so keeping them both around makes little sense.
Especially when it means giving the (hopefully more used) routeOSC a name like set_route.
Actually I think we could do:
net/tcpsend net/tcpreceive net/udpsend net/udpreceive
sound ok to me.
osc/route osc/pack osc/unpack
I think these should be more descriptive. They don't work exactly
the same as the core versions, so they should have different, but
similar, names.
The suffix is fine, but it should be consistent across objects in the
lib, like:
[osc/packOSC] [osc/unpackOSC] [osc/routeOSC]
.hc
..b.
Hans-Christoph Steiner wrote:
On Apr 26, 2006, at 11:01 PM, Piotr Majdak wrote:
Hi Martin,
Martin Peach wrote:
Sure...[routeOSC] is based on [OSCroute] but the routes are
settable after the object is created. It is also standalone in the sense
that you don't need to load lib OSC to use it. It's basically the same code, cleaned up a bit. [unpackOSC] is based on [dumpOSC], again nearly the same thing but cleaned up and made independent of lib OSC. For instance the messages to the user use 'post' instead of printf and OSCerror or whatever it was. [packOSC] is based on [sendOSC] but doesn't do the network part. That can be handled by [udpsend] or [tcpsend] or possibly
[comport] and [midiout] with some extra massaging of the lists they output. That makes the OSC objects transport independent as the spec intended (but nearly every implementation is hard-wired to use
udp).That's a nice thing. So, as far as I understand you, [packOSC] outputs something (a stream of messages, one message per byte?)
which can be sent to a communication object such as [udpsend] or
[comport]?But, the oposite object to [packOSC], [unpackOSC] is hardcoded to UDP, like [sendOSC], right?
These are really great, it should make things much more flexible.
I used different names for all of them so as not to break existing patches.
That's a good idea. Thanks for watching the weird compatibility things :-)
I based them all on OSCx (the net objects are based on the
[netsend] and [netreceive] objects inside pd), I consider them to be an improved version of OSCx but that's my opinion :)I see it as an improvement too :-) Would you like to add your
objects to the externals/OSCx directory in CVS? We could keep all the OSC stuff at one place...I think it might make more sense to make a separate library for these objects. But if they are based on libOSC, then they could be integrated. [OSCroute] and [routeOSC] in the same package sounds
a bit odd to me. Perhaps [routeOSC] could be renamed to soemthing like [set_route]..hc
"I have the audacity to believe that peoples everywhere can have
three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits." - Martin Luther King, Jr.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"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
Hi guys
Martin - these objects look really cool. I think they'll be incredibly useful.
Now for the bit where I feel like a dunce... I have no idea how to compile these things without a makefile. (I'm on OSX but I'll be doing this on Linux too) I've copied m_pd.h from the 0.39-2 source into the directory I'm working in. Tried the following but I have no idea where to go from here. I'm sure it's a simple solution but it escapes me.
butterfly:~/cvs dafydd$ gcc routeOSC.c /usr/bin/ld: Undefined symbols: _main _class_addanything _class_addlist _class_addmethod _class_new _class_sethelpsymbol _gensym _outlet_anything _outlet_bang _outlet_float _outlet_list _outlet_new _pd_new _post _s_list collect2: ld returned 1 exit status
Any advice would be lovely.
cheers dafydd
On 4/27/06, Hans-Christoph Steiner hans@eds.org wrote:
On Apr 27, 2006, at 2:03 AM, B. Bogart wrote:
I think OSCx should be deprecated,
left around only for compatibility with old patches.
Seems to me Martin's OSC stuff does the same and more than the orginal OSCx, so keeping them both around makes little sense.
Especially when it means giving the (hopefully more used) routeOSC a name like set_route.
Actually I think we could do:
net/tcpsend net/tcpreceive net/udpsend net/udpreceive
sound ok to me.
osc/route osc/pack osc/unpack
I think these should be more descriptive. They don't work exactly the same as the core versions, so they should have different, but similar, names.
The suffix is fine, but it should be consistent across objects in the lib, like:
[osc/packOSC] [osc/unpackOSC] [osc/routeOSC]
.hc
..b.
Hans-Christoph Steiner wrote:
On Apr 26, 2006, at 11:01 PM, Piotr Majdak wrote:
Hi Martin,
Martin Peach wrote:
Sure...[routeOSC] is based on [OSCroute] but the routes are settable after the object is created. It is also standalone in the sense that you don't need to load lib OSC to use it. It's basically the same code, cleaned up a bit. [unpackOSC] is based on [dumpOSC], again nearly the same thing but cleaned up and made independent of lib OSC. For instance the messages to the user use 'post' instead of printf and OSCerror or whatever it was. [packOSC] is based on [sendOSC] but doesn't do the network part. That can be handled by [udpsend] or [tcpsend] or possibly [comport] and [midiout] with some extra massaging of the lists they output. That makes the OSC objects transport independent as the spec intended (but nearly every implementation is hard-wired to use udp).
That's a nice thing. So, as far as I understand you, [packOSC] outputs something (a stream of messages, one message per byte?) which can be sent to a communication object such as [udpsend] or [comport]?
But, the oposite object to [packOSC], [unpackOSC] is hardcoded to UDP, like [sendOSC], right?
These are really great, it should make things much more flexible.
I used different names for all of them so as not to break existing patches.
That's a good idea. Thanks for watching the weird compatibility things :-)
I based them all on OSCx (the net objects are based on the [netsend] and [netreceive] objects inside pd), I consider them to be an improved version of OSCx but that's my opinion :)
I see it as an improvement too :-) Would you like to add your objects to the externals/OSCx directory in CVS? We could keep all the OSC stuff at one place...
I think it might make more sense to make a separate library for these objects. But if they are based on libOSC, then they could be integrated. [OSCroute] and [routeOSC] in the same package sounds a bit odd to me. Perhaps [routeOSC] could be renamed to soemthing like [set_route].
.hc
"I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits." - Martin Luther King, Jr.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- www.sideshowmedia.ca
dafydd hughes wrote:
Hi guys
Martin - these objects look really cool. I think they'll be incredibly useful.
Great! Thanks.
Now for the bit where I feel like a dunce... I have no idea how to compile these things without a makefile. (I'm on OSX but I'll be doing this on Linux too) I've copied m_pd.h from the 0.39-2 source into the directory I'm working in. Tried the following but I have no idea where to go from here. I'm sure it's a simple solution but it escapes me.
I don't know about OSX but on linux I use this (single line) command: gcc -Wall -O2 -DPD -shared -o route.pd_linux -I/home/martin/pd-0.39-2/src routeOSC.c -L/usr/local/lib
You need to say -shared so that ld doesn't try to find main and the other functions inside pd.
Martin
butterfly:~/cvs dafydd$ gcc routeOSC.c /usr/bin/ld: Undefined symbols: _main _class_addanything _class_addlist _class_addmethod _class_new _class_sethelpsymbol _gensym _outlet_anything _outlet_bang _outlet_float _outlet_list _outlet_new _pd_new _post _s_list collect2: ld returned 1 exit status
Any advice would be lovely.
cheers dafydd
On 4/27/06, Hans-Christoph Steiner hans@eds.org wrote:
On Apr 27, 2006, at 2:03 AM, B. Bogart wrote:
I think OSCx should be deprecated,
left around only for compatibility with old patches.
Seems to me Martin's OSC stuff does the same and more than the orginal OSCx, so keeping them both around makes little sense.
Especially when it means giving the (hopefully more used) routeOSC a name like set_route.
Actually I think we could do:
net/tcpsend net/tcpreceive net/udpsend net/udpreceive
sound ok to me.
osc/route osc/pack osc/unpack
I think these should be more descriptive. They don't work exactly the same as the core versions, so they should have different, but similar, names.
The suffix is fine, but it should be consistent across objects in the lib, like:
[osc/packOSC] [osc/unpackOSC] [osc/routeOSC]
.hc
..b.
Hans-Christoph Steiner wrote:
On Apr 26, 2006, at 11:01 PM, Piotr Majdak wrote:
Hi Martin,
Martin Peach wrote:
Sure...[routeOSC] is based on [OSCroute] but the routes are settable after the object is created. It is also standalone in the sense that you don't need to load lib OSC to use it. It's basically the same code, cleaned up a bit. [unpackOSC] is based on [dumpOSC], again nearly the same thing but cleaned up and made independent of lib OSC. For instance the messages to the user use 'post' instead of printf and OSCerror or whatever it was. [packOSC] is based on [sendOSC] but doesn't do the network part. That can be handled by [udpsend] or [tcpsend] or possibly [comport] and [midiout] with some extra massaging of the lists they output. That makes the OSC objects transport independent as the spec intended (but nearly every implementation is hard-wired to use udp).
That's a nice thing. So, as far as I understand you, [packOSC] outputs something (a stream of messages, one message per byte?) which can be sent to a communication object such as [udpsend] or [comport]?
But, the oposite object to [packOSC], [unpackOSC] is hardcoded to UDP, like [sendOSC], right?
These are really great, it should make things much more flexible.
I used different names for all of them so as not to break existing patches.
That's a good idea. Thanks for watching the weird compatibility things :-)
I based them all on OSCx (the net objects are based on the [netsend] and [netreceive] objects inside pd), I consider them to be an improved version of OSCx but that's my opinion :)
I see it as an improvement too :-) Would you like to add your objects to the externals/OSCx directory in CVS? We could keep all the OSC stuff at one place...
I think it might make more sense to make a separate library for these objects. But if they are based on libOSC, then they could be integrated. [OSCroute] and [routeOSC] in the same package sounds a bit odd to me. Perhaps [routeOSC] could be renamed to soemthing like [set_route].
.hc
"I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits." - Martin Luther King, Jr.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- www.sideshowmedia.ca
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Martin
Thanks for the help. For some reason gcc complains about the -shared option (says it's unrecognized). Any OSXers have any ideas?
cheers dafydd
On 4/27/06, Martin Peach martinrp@vax2.concordia.ca wrote:
dafydd hughes wrote:
Hi guys
Martin - these objects look really cool. I think they'll be incredibly useful.
Great! Thanks.
Now for the bit where I feel like a dunce... I have no idea how to compile these things without a makefile. (I'm on OSX but I'll be doing this on Linux too) I've copied m_pd.h from the 0.39-2 source into the directory I'm working in. Tried the following but I have no idea where to go from here. I'm sure it's a simple solution but it escapes me.
I don't know about OSX but on linux I use this (single line) command: gcc -Wall -O2 -DPD -shared -o route.pd_linux -I/home/martin/pd-0.39-2/src routeOSC.c -L/usr/local/lib
You need to say -shared so that ld doesn't try to find main and the other functions inside pd.
Martin
butterfly:~/cvs dafydd$ gcc routeOSC.c /usr/bin/ld: Undefined symbols: _main _class_addanything _class_addlist _class_addmethod _class_new _class_sethelpsymbol _gensym _outlet_anything _outlet_bang _outlet_float _outlet_list _outlet_new _pd_new _post _s_list collect2: ld returned 1 exit status
Any advice would be lovely.
cheers dafydd
On 4/27/06, Hans-Christoph Steiner hans@eds.org wrote:
On Apr 27, 2006, at 2:03 AM, B. Bogart wrote:
I think OSCx should be deprecated,
left around only for compatibility with old patches.
Seems to me Martin's OSC stuff does the same and more than the orginal OSCx, so keeping them both around makes little sense.
Especially when it means giving the (hopefully more used) routeOSC a name like set_route.
Actually I think we could do:
net/tcpsend net/tcpreceive net/udpsend net/udpreceive
sound ok to me.
osc/route osc/pack osc/unpack
I think these should be more descriptive. They don't work exactly the same as the core versions, so they should have different, but similar, names.
The suffix is fine, but it should be consistent across objects in the lib, like:
[osc/packOSC] [osc/unpackOSC] [osc/routeOSC]
.hc
..b.
Hans-Christoph Steiner wrote:
On Apr 26, 2006, at 11:01 PM, Piotr Majdak wrote:
Hi Martin,
Martin Peach wrote:
>Sure...[routeOSC] is based on [OSCroute] but the routes are >settable >after the object is created. It is also standalone in the sense >that >you don't need to load lib OSC to use it. It's basically the same >code, cleaned up a bit. >[unpackOSC] is based on [dumpOSC], again nearly the same thing but >cleaned up and made independent of lib OSC. >For instance the messages to the user use 'post' instead of printf >and OSCerror or whatever it was. >[packOSC] is based on [sendOSC] but doesn't do the network part. >That can be handled by [udpsend] or [tcpsend] or possibly >[comport] >and [midiout] with some extra massaging of the lists they output. >That makes the OSC objects transport independent as the spec >intended (but nearly every implementation is hard-wired to use >udp).
That's a nice thing. So, as far as I understand you, [packOSC] outputs something (a stream of messages, one message per byte?) which can be sent to a communication object such as [udpsend] or [comport]?
But, the oposite object to [packOSC], [unpackOSC] is hardcoded to UDP, like [sendOSC], right?
These are really great, it should make things much more flexible.
>I used different names for all of them so as not to break existing >patches.
That's a good idea. Thanks for watching the weird compatibility things :-)
>I based them all on OSCx (the net objects are based on the >[netsend] >and [netreceive] objects inside pd), I consider them to be an >improved version of OSCx but that's my opinion :)
I see it as an improvement too :-) Would you like to add your objects to the externals/OSCx directory in CVS? We could keep all the OSC stuff at one place...
I think it might make more sense to make a separate library for these objects. But if they are based on libOSC, then they could be integrated. [OSCroute] and [routeOSC] in the same package sounds a bit odd to me. Perhaps [routeOSC] could be renamed to soemthing like [set_route].
.hc
"I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits." - Martin Luther King, Jr.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- www.sideshowmedia.ca
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- www.sideshowmedia.ca
dafydd hughes wrote:
Hi Martin
Thanks for the help. For some reason gcc complains about the -shared option (says it's unrecognized). Any OSXers have any ideas?
I think it should be -dynamiclib on OSX. Have a look at the Makefile for externals in cvs, or your src folder, because there will probably be other things that need changing...
Martin
On Apr 27, 2006, at 9:57 PM, Martin Peach wrote:
dafydd hughes wrote:
Hi Martin Thanks for the help. For some reason gcc complains about the -shared option (says it's unrecognized). Any OSXers have any ideas?
I think it should be -dynamiclib on OSX. Have a look at the Makefile for externals in cvs, or your src
folder, because there will probably be other things that need
changing...
Its actually -bundle on Mac OS X. Check the top of externals/
Makefile, you can see the build target for GNU/Linux, Mac OS X, and
MinGW there.
.hc
News is what people want to keep hidden and everything else is
publicity.
- Bill Moyers
dafydd hughes wrote:
Hi guys
doing this on Linux too) I've copied m_pd.h from the 0.39-2 source into the directory I'm working in.
that is a not so clever idea. you should rather use the header file that comes with the version of pd you are using than to put the header file that you were using the first time you compiled something for pd. (right now, these 2 header files might be the same, but chances are high that they won't stay so).
the header file is not a necessary evil that you need to compile, but it is the way to tell your external how it can interface with the pd binary. thus the header file and the pd-binary belong together.
just use the "-I" flag to tell the compiler where it should look for header-files that it cannot find in the standard places. (e.g. "gcc -I/path/to/the/place/where/i/installed/pd/src")
fmga.sdr IOhannes
On Apr 28, 2006, at 9:03 AM, IOhannes m zmoelnig wrote:
dafydd hughes wrote:
Hi guys
doing this on Linux too) I've copied m_pd.h from the 0.39-2 source into the directory I'm working in.
that is a not so clever idea. you should rather use the header file that comes with the version
of pd you are using than to put the header file that you were using the
first time you compiled something for pd. (right now, these 2 header files might be the same, but chances are high that they won't stay so).the header file is not a necessary evil that you need to compile,
but it is the way to tell your external how it can interface with the pd binary. thus the header file and the pd-binary belong together.just use the "-I" flag to tell the compiler where it should look for header-files that it cannot find in the standard places. (e.g. "gcc -I/path/to/the/place/where/i/installed/pd/src")
Once these objects are in CVS, then it will be easy to integrate them
into the Pd-extended build system, then it should be relatively easy
to build them all GNU/Linux Mac OSX, or MinGW.
.hc
¡El pueblo unido jamás será vencido!
On Thu, 27 Apr 2006, Hans-Christoph Steiner wrote:
osc/route osc/pack osc/unpack
I think these should be more descriptive. They don't work exactly the same as the core versions, so they should have different, but similar, names.
Why should namespaces exist if they don't solve name conflicts?
The suffix is fine, but it should be consistent across objects in the lib, like: [osc/packOSC] [osc/unpackOSC] [osc/routeOSC]
those names all contain "osc" twice. if the latter "OSC" can't be removed, then why not removing the leading "osc/" ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On May 7, 2006, at 6:56 AM, Mathieu Bouchard wrote:
On Thu, 27 Apr 2006, Hans-Christoph Steiner wrote:
osc/route osc/pack osc/unpack
I think these should be more descriptive. They don't work exactly
the same as the core versions, so they should have different, but similar, names.Why should namespaces exist if they don't solve name conflicts?
Ok, to follow this logic, we should stop coming up with new names for
objects. All libraries will use letters for object names starting at A.
core/a core/b ... osc/a osc/b ... audio/a audio/b ... gem/a gem/b ...
Why come up with new names if you don't have to? :-P
The suffix is fine, but it should be consistent across objects in
the lib, like: [osc/packOSC] [osc/unpackOSC] [osc/routeOSC]those names all contain "osc" twice. if the latter "OSC" can't be
removed, then why not removing the leading "osc/" ?
Because if you do this:
[import osc]
[packOSC]
A fundamental idea in programming is to name things descriptively so
you can easily read the code. Just because we can reuse the same
names, doesn't mean we should. The object name should represent what
it does as clearly and compactly as possible.
.hc
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers.
- General Smedley Butler
On Mon, 8 May 2006, Hans-Christoph Steiner wrote:
On May 7, 2006, at 6:56 AM, Mathieu Bouchard wrote:
On Thu, 27 Apr 2006, Hans-Christoph Steiner wrote:
I think these should be more descriptive. They don't work exactly the same as the core versions, so they should have different, but similar, names.
Why should namespaces exist if they don't solve name conflicts?
Ok, to follow this logic, we should stop coming up with new names for objects. All libraries will use letters for object names starting at A. core/a core/b
No, this doesn't follow this logic. I'm questioning the use of namespaces and then you pretend that I question the use of names. That's not a very subtle strawman. If you were actually thinking about class_addmethod2, that one used letters for the same reason that [t] accepts letters; but that's not what you're replying to.
those names all contain "osc" twice. if the latter "OSC" can't be removed, then why not removing the leading "osc/" ?
Because if you do this: [import osc] [packOSC]
What if you did the following instead?
[osc/pack]
it seems to me as being just as descriptive and plus it's shorter because you don't have to write [import] and the name of the objectclass itself is hardly longer.
I would need an example that involves several classes called [packOSC] so that I can see an advantage related to nameclashes.
A fundamental idea in programming is to name things descriptively so you can easily read the code. Just because we can reuse the same names, doesn't mean we should. The object name should represent what it does as clearly and compactly as possible.
But is a name including the package name that it's in? In one sense yes and in one sense no. By using the slash as a separator you suggest a filename analogy, and the word "filename" has been traditionally used to mean both the local slashless name and compound names (which include both relative and absolute names).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Wed, 26 Apr 2006, B. Bogart wrote:
Actually I think we could do: net/tcpsend net/tcpreceive net/udpsend net/udpreceive
bidi connections are nice, so let's merge the send/receive parts together:
net/tcpsocket net/udpsocket
and each would be both able to run in server mode (waiting for connections) and client mode (issuing connections), and if not, call the server mode objects like:
net/tcpserver net/udpserver
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Wed, 26 Apr 2006, B. Bogart wrote:
Actually I think we could do: net/tcpsend net/tcpreceive net/udpsend net/udpreceive
bidi connections are nice, so let's merge the send/receive parts together:
net/tcpsocket net/udpsocket
But we don't have midisocket, just midiin and midiout, and it's easier to patch that way. For instance I'm using OSC to talk to microcontrollers on one port but they reply on another. To me it makes more sense to have separate send and receive objects
and each would be both able to run in server mode (waiting for connections) and client mode (issuing connections), and if not, call the server mode objects like:
net/tcpserver net/udpserver
tcpreceive accepts multiple incoming connections (maximum is set by a #define in the code but it could be a creation argument if needed), and updreceive accepts any messages sent to its port number. Both also output the ip address of the source of each incoming message.
Martin
On Fri, 28 Apr 2006, Martin Peach wrote:
Mathieu Bouchard wrote:
bidi connections are nice, so let's merge the send/receive parts together: net/tcpsocket net/udpsocket
But we don't have midisocket, just midiin and midiout, and it's easier to patch that way. For instance I'm using OSC to talk to microcontrollers on one port but they reply on another. To me it makes more sense to have separate send and receive objects
You gotta be kidding. A lot of protocols that Pd could support require a bidirectional connection. That is, you can't find a version of the protocol that works by first establishing a socket one way and then connecting back the other way. It wouldn't work in masquerading IP situations either.
DesireData is going to have those byte-based sockets for sure. The client-server protocol of Pd itself is bidi, and I believe a user ought to be able to do the same! This means that i want one class for both send and receive.
tcpreceive accepts multiple incoming connections (maximum is set by a #define in the code but it could be a creation argument if needed), and updreceive accepts any messages sent to its port number. Both also output the ip address of the source of each incoming message.
But receive is reserved for servers, and servers are reserved for receiving, while sending is reserved for clients, and clients can only send. Why?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Fri, 28 Apr 2006, Martin Peach wrote:
Mathieu Bouchard wrote:
bidi connections are nice, so let's merge the send/receive parts together: net/tcpsocket net/udpsocket
But we don't have midisocket, just midiin and midiout, and it's easier to patch that way. For instance I'm using OSC to talk to microcontrollers on one port but they reply on another. To me it makes more sense to have separate send and receive objects
You gotta be kidding. A lot of protocols that Pd could support require a bidirectional connection. That is, you can't find a version of the protocol that works by first establishing a socket one way and then connecting back the other way. It wouldn't work in masquerading IP situations either.
Oh I see...I was thinking you could just make an abstraction with tcpsend and tcpreceive in the same patch and it would work just like a bidirectional socket, but I probably didn't think far enough...I'm no good at chess either...
In my own selfish way I am using [udpsend] and [udpreceive] in a single patch as separate objects. I have pd sending messages to several micros on a subnet, with one [udpsend] for each connection; the micros can then reply to a single [udpreceive] on the same or a different port number. The protocol is just OSC over udp and it works fine for me. I use an OSC message like: /replyto/ 9999 so I can tell each micro to talk back on an arbitrary port. So as I said, to me it makes more sense to have separate objects. For other applications it doesn't. I'll work on [netclient] and [netserver] for those, when I can.
DesireData is going to have those byte-based sockets for sure. The client-server protocol of Pd itself is bidi, and I believe a user ought to be able to do the same! This means that i want one class for both send and receive.
tcpreceive accepts multiple incoming connections (maximum is set by a #define in the code but it could be a creation argument if needed), and updreceive accepts any messages sent to its port number. Both also output the ip address of the source of each incoming message.
But receive is reserved for servers, and servers are reserved for receiving, while sending is reserved for clients, and clients can only send. Why?
Why what?
Martin
On Apr 28, 2006, at 7:59 PM, Martin Peach wrote:
Mathieu Bouchard wrote:
On Wed, 26 Apr 2006, B. Bogart wrote:
Actually I think we could do: net/tcpsend net/tcpreceive net/udpsend net/udpreceive
bidi connections are nice, so let's merge the send/receive parts
together: net/tcpsocket net/udpsocketBut we don't have midisocket, just midiin and midiout, and it's
easier to patch that way. For instance I'm using OSC to talk to microcontrollers on one port
but they reply on another. To me it makes more sense to have
separate send and receive objectsand each would be both able to run in server mode (waiting for
connections) and client mode (issuing connections), and if not,
call the server mode objects like: net/tcpserver net/udpservertcpreceive accepts multiple incoming connections (maximum is set by
a #define in the code but it could be a creation argument if
needed), and updreceive accepts any messages sent to its port
number. Both also output the ip address of the source of each
incoming message.
I have to say that I really think that tcp and udp objects should be
bidirectional. TCP and UDP sockets are, so the objects should
represent that. I've done quite a bit of network programming with Pd
and I never use [netsend]/[netreceive]. I always use [netserver]/
[netclient] because of the bidirectional connection and the client
management of the [netserver].
I think the "server" aspect could be a separate object. I think the
socket objects should represent just the sockets, and how the sockets
work.
.hc
"Information wants to be free." -Stewart Brand
Hans-Christoph Steiner wrote:
I have to say that I really think that tcp and udp objects should be
bidirectional. TCP and UDP sockets are, so the objects should
represent that. I've done quite a bit of network programming with Pd
and I never use [netsend]/[netreceive]. I always use [netserver]/ [netclient] because of the bidirectional connection and the client
management of the [netserver].
OK, it looks like basically the same modifications are needed to change [netserver] and [netclient] to byte mode from pd message mode as I did with [netsend] and [netreceive]. Will have a go.
Martin
I think the "server" aspect could be a separate object. I think the
socket objects should represent just the sockets, and how the sockets
work..hc
"Information wants to be free." -Stewart Brand
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On May 1, 2006, at 6:35 PM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
I have to say that I really think that tcp and udp objects should
be bidirectional. TCP and UDP sockets are, so the objects
should represent that. I've done quite a bit of network
programming with Pd and I never use [netsend]/[netreceive]. I
always use [netserver]/ [netclient] because of the bidirectional
connection and the client management of the [netserver].OK, it looks like basically the same modifications are needed to
change [netserver] and [netclient] to byte mode from pd message
mode as I did with [netsend] and [netreceive]. Will have a go.
Just out of curiousity, why do you use byte mode rather than message
mode? Do you mean that you are sending one byte per packet?
What about just a [socket] object which could also do UNIX sockets,
or any other kind? It would probably be more work, but worth it in
the long run. Then [tcpsocket], etc. could be a Pd object.
.hc
Martin
I think the "server" aspect could be a separate object. I think
the socket objects should represent just the sockets, and how the
sockets work. .hc _____________________________________________________________________ ___ ____ "Information wants to be free." -Stewart Brand _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism."
- retired U.S. Army general,
William Odom
Hans-Christoph Steiner wrote:
On May 1, 2006, at 6:35 PM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
I have to say that I really think that tcp and udp objects should
be bidirectional. TCP and UDP sockets are, so the objects should
represent that. I've done quite a bit of network programming with Pd and I never use [netsend]/[netreceive]. I always use [netserver]/ [netclient] because of the bidirectional connection and the client management of the [netserver].OK, it looks like basically the same modifications are needed to
change [netserver] and [netclient] to byte mode from pd message mode as I did with [netsend] and [netreceive]. Will have a go.Just out of curiousity, why do you use byte mode rather than message
mode? Do you mean that you are sending one byte per packet?
I mean that netsend sends messages terminated with a semicolon and tcpsend/udpsend sends messages that are just bytes, so there is no escaping or interpretation done (except to check that each element is encodable as a single byte). It won't send a lone byte unless the message contains only one byte. For example the message [send 13 10( will send a CR/LF as two bytes.
What about just a [socket] object which could also do UNIX sockets,
or any other kind? It would probably be more work, but worth it in
the long run. Then [tcpsocket], etc. could be a Pd object.
Yes this is probably the best idea. I'm looking at the netclient and netserver code to see if they can be combined somehow. I'm moving incrementally so as not to lose everything... Unix sockets don't exist on Windows. Do they exist on MacOS? Does anybody use them, I mean is there any advantage in using a unix socket versus a udp socket? I notice that netserver/netclient use timers and pthreads while netsend/netreceive use pollfunctions. Is there any preference for either?
.hc
Martin
I think the "server" aspect could be a separate object. I think
the socket objects should represent just the sockets, and how the
sockets work.
How would that work in PD? Seems a server would have to be connected to one or more sockets that are dynamically created as connections come in.
Martin
.hc _____________________________________________________________________ ___ ____ "Information wants to be free." -Stewart Brand _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism." - retired U.S. Army general,
William Odom
But we don't have midisocket, just midiin and midiout, and it's easier to patch that way.
In/Out/Thru are intrinsic to the MIDI paradigm. agree with you in it's case. for OSC, most apps use bidirectional sockets. plus sockets in general usage are usually bidirectional..
Hans-Christoph Steiner wrote:
odd to me. Perhaps [routeOSC] could be renamed to soemthing like [set_route].
what about [routes] (as in 'route'-'S'ettable), since it can handle multiple routes and the name suggest a relation to [route] rather than to [set]?
of course one could argue that the names are too similar, but you could always make an alias to "hudriwudri"
mfg.asdr. IOhannes
Hi!
Hans-Christoph Steiner wrote:
I think it might make more sense to make a separate library for these
objects. But if they are based on libOSC, then they could be
integrated.
My 2c: It will be easier to have only one place where the OSC externals can be found, like: Newbie-Q: Where can I get the OSC externals A: Look here: (put _just one_ link here)
Regardless the internal details of the OSC package. The developers know the differences.
br, Piotr
On Apr 27, 2006, at 9:54 AM, Piotr Majdak wrote:
Hi!
Hans-Christoph Steiner wrote:
I think it might make more sense to make a separate library for
these objects. But if they are based on libOSC, then they could
be integrated.My 2c: It will be easier to have only one place where the OSC
externals can be found, like: Newbie-Q: Where can I get the OSC externals A: Look here: (put _just one_ link here)Regardless the internal details of the OSC package. The developers
know the differences.
An "osc" lib would be easier to find than an "oscx" lib. But its a
minor difference.
.hc
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
I have not had a chance to play with Martin's new OSC stuff yet, but its needed for pT, and the design is very nice.
I think it should replace OSCx personally...
I don't think it makes sense at this stage to start dealing with the idea of standard PD libs quite yet...
I think Martin should decide where he puts these new externals, but a new directory makes sense (ATM).
Thanks Martin, I never thought you would get to it this fast!!!
Frank, you are seeing this right? Very exiting for memento.
.b.
Piotr Majdak wrote:
Hi Martin,
Martin Peach wrote:
Sure...[routeOSC] is based on [OSCroute] but the routes are settable after the object is created. It is also standalone in the sense that you don't need to load lib OSC to use it. It's basically the same code, cleaned up a bit. [unpackOSC] is based on [dumpOSC], again nearly the same thing but cleaned up and made independent of lib OSC. For instance the messages to the user use 'post' instead of printf and OSCerror or whatever it was. [packOSC] is based on [sendOSC] but doesn't do the network part. That can be handled by [udpsend] or [tcpsend] or possibly [comport] and [midiout] with some extra massaging of the lists they output. That makes the OSC objects transport independent as the spec intended (but nearly every implementation is hard-wired to use udp).
That's a nice thing. So, as far as I understand you, [packOSC] outputs something (a stream of messages, one message per byte?) which can be sent to a communication object such as [udpsend] or [comport]?
But, the oposite object to [packOSC], [unpackOSC] is hardcoded to UDP, like [sendOSC], right?
I used different names for all of them so as not to break existing patches.
That's a good idea. Thanks for watching the weird compatibility things :-)
I based them all on OSCx (the net objects are based on the [netsend] and [netreceive] objects inside pd), I consider them to be an improved version of OSCx but that's my opinion :)
I see it as an improvement too :-) Would you like to add your objects to the externals/OSCx directory in CVS? We could keep all the OSC stuff at one place...
br, Piotr
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
I have not had a chance to play with Martin's new OSC stuff yet, but its needed for pT, and the design is very nice.
...
Frank, you are seeing this right? Very exiting for memento.
Being at the LAC2006 currently I'm only seeing a little bit. ;)
But a settable OSCroute sure can be very useful. Memento is only using OSCroute so the developements in the network part don't affect it directly.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hi Martin,
The other libraries (e.g. liblo) for OSC seem to be in c++ which is harder to integrate with pd's c code.
this is news to me. My version of liblo is written in C and has a C api. I once ported it to Windows so that it's ready to use with PD.
greetings, Thomas
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
Hi Martin,
The other libraries (e.g. liblo) for OSC seem to be in c++ which is harder to integrate with pd's c code.
this is news to me. My version of liblo is written in C and has a C api. I once ported it to Windows so that it's ready to use with PD.
liblo is plain C.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
Hi Martin,
The other libraries (e.g. liblo) for OSC seem to be in c++ which is harder to integrate with pd's c code.
this is news to me. My version of liblo is written in C and has a C api. I once ported it to Windows so that it's ready to use with PD.
liblo is plain C.
Um yes, I was mixed up again...liblo seems to be about the only other c implementation of OSC. I didn't use it because it's tied to the transport layer, so you have another process than pd itself operating sockets in its own way which seems to go against the design philosophy of pd. In [packOSC] and [unpackOSC] I rearranged OSCx to separate the OSC layer from the transport layer which is handled by [tcpreceive], [tcpsend], [udpreceive] and [udpsend], which are adapted from pd's internal [netsend] and [netreceive] objects. I don't see how one could easily do that with liblo. Also I don't think it will be a major undertaking to add timetags to [packOSC] and [unpackOSC], just that I don't see the use of absolute time. It makes more sense to have any performance or installation start at zero time. Either way timetags are 64-bit numbers so there needs to be some way of handling them in pd, maybe as a list of floats: (year month day hour minute second millisecond)? Then we'll need objects to manipulate (add, subtract, compare etc) timestamps.
Martin
Martin
Ciao
On Fri, 28 Apr 2006, Martin Peach wrote:
Either way timetags are 64-bit numbers so there needs to be some way of handling them in pd, maybe as a list of floats: (year month day hour minute second millisecond)? Then we'll need objects to manipulate (add, subtract, compare etc) timestamps.
My [unix_time] external produces a 3-element list: day number, second of the day (from 0 to 86399), and then microseconds (from 0 to 999999). Day number 0 is January 1st, 1970, UTC.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
B. Bogart -
carmen -
dafydd hughes -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Martin Peach -
Mathieu Bouchard -
Piotr Majdak -
Thomas Grill