On Fri, Mar 17, 2006 at 04:50:43AM +0100, pd-list-request@iem.at wrote:
Message: 7 Date: Fri, 17 Mar 2006 03:09:53 +0000 From: cdr ix@replic.net Subject: Re: [PD] Re: [PD-dev] We've got to undo the MIDI revolution!
- Where isOSC?!
To: pd-list@iem.at Message-ID: 20060317030953.GC4071@replic.net Content-Type: text/plain; charset=us-ascii
As far as I can tell, all that would be needed to acheive this is an object called [stol] (symbol to list) in Pd canonical. This object is like Perl's "split" function and it would take a character (such as "/") as it's first argument. Then you could just go:
[netrecieve myport 1] | [list split 1] | | [stol /] | | | | | | [...list split or route value bits here...] | [...list split or route path bits here...]
Sending OSC udp packets to myport. N'est pas?
i dont think that will work..OSC is encoded a specific way, using a typetag and combinations of various kinds of big endian numbers and ASCII text, zero padding to byte boundaries to delimit messages/message-components (the typetags and path are treated as a string). netsend uses ASCII text for everything and uses ";" to delimit..
see http://www.cnmat.berkeley.edu/OpenSoundControl/OSC-spec-examples.html
its simple to implement, but impossible to implement in PD, as a patch...since you cant stream 'bytes' around the way you can floats or symbols or lists...
You are quite correct. My apologies for highlighting my ignorance quite so lucidly!
In this case, I think it would be a good idea to try and get the OSC objects that everyone is using into Miller's Pd. Why write new ones using liblo when there are ones that already work?
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
Because they don't work well (see below).
They are awkwardly named, very limited [OSCroute /test/myname] does not work, and you can't "set" the name to route.
All in all the current OSC is useless (or at least painfully inefficient) for working with dynamic OSC trees, they work great only for static ones.
I think this is really needed for pixelTANGO and RRADICAL so I'm hoping we can collaborate on a design (I have already mentioned one) which was basically around OSCroute, and dumpOSC and sendOSC should be deprecated so that we use normal PD sockets...
Also there is lots missing, like subtree querying, range of param returns, and all the stuff that OSC is meant to do in a bidirectional socket.
.b..
Chris McCormick wrote:
In this case, I think it would be a good idea to try and get the OSC objects that everyone is using into Miller's Pd. Why write new ones using liblo when there are ones that already work?
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mar 16, 2006, at 11:20 PM, Chris McCormick wrote:
On Fri, Mar 17, 2006 at 04:50:43AM +0100, pd-list-request@iem.at
wrote:Message: 7 Date: Fri, 17 Mar 2006 03:09:53 +0000 From: cdr ix@replic.net Subject: Re: [PD] Re: [PD-dev] We've got to undo the MIDI revolution!
- Where isOSC?!
To: pd-list@iem.at Message-ID: 20060317030953.GC4071@replic.net Content-Type: text/plain; charset=us-ascii
As far as I can tell, all that would be needed to acheive this is an object called [stol] (symbol to list) in Pd canonical. This
object is like Perl's "split" function and it would take a character (such
as "/") as it's first argument. Then you could just go:[netrecieve myport 1] | [list split 1] | | [stol /] | | | | | | [...list split or route value bits here...] | [...list split or route path bits here...]
Sending OSC udp packets to myport. N'est pas?
i dont think that will work..OSC is encoded a specific way, using
a typetag and combinations of various kinds of big endian numbers
and ASCII text, zero padding to byte boundaries to delimit
messages/message-components (the typetags and path are treated as
a string). netsend uses ASCII text for everything and uses ";" to
delimit..see http://www.cnmat.berkeley.edu/OpenSoundControl/OSC-spec- examples.html
its simple to implement, but impossible to implement in PD, as a
patch...since you cant stream 'bytes' around the way you can
floats or symbols or lists...You are quite correct. My apologies for highlighting my ignorance
quite so lucidly!In this case, I think it would be a good idea to try and get the OSC objects that everyone is using into Miller's Pd. Why write new ones using liblo when there are ones that already work?
The OSC objects are already in Pd-extended. So you can use that
while you are waiting for Miller to include OSC into core.
.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
-
B. Bogart -
Chris McCormick -
Hans-Christoph Steiner