on this note could someone post some examples of using OSC properly? If possible soem simple examples of OSC coming from maybe Supercollider3 to control Gem? Vice versa? I would love to explore it some more.
cheers~
Patrick Pagano, B.S., M.F.A Digital Media Specialist Digital Worlds Institute University of Florida (352) 294-2082
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at]On Behalf Of Hans-Christoph Steiner Sent: Monday, March 13, 2006 5:36 PM To: pd-list Subject: [PD] Re: [PD-dev] We've got to undo the MIDI revolution! - Where isOSC?!
The OSC objects are included in the Pd-extended builds for Windows, Mac OS X and GNU/Linux.
.hc
SourceForge.net wrote:
Feature Requests item #1447808, was opened at 2006-03-11 02:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=1447808...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: We've got to undo the MIDI revolution! - Where is OSC?!
Initial Comment: 'We've got to undo the MIDI revolution! Miller S. Puckette'
This is all very well, however it seems OSC support is somewhat limited for Windows systems, insofar as I cannot find anywhere to download OSC externals for windows...the link from the main page has been down for some months now.
Is there anywhere I can get OSC externals for Windows?
Robin
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=1447808...
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon Mar 13, 2006 at 05:45:29PM -0500, Patrick Pagano wrote:
on this note could someone post some examples of using OSC properly? If possible soem simple examples of OSC coming from maybe Supercollider3 to control Gem?
you could check out RRadical, it uses OSC throughout. and check out the OSC APIs to SooperLooper and Om-synth as examples. in /extensions/gui/ix theres a patch that automagically adds any controllabla params from Om to a puck on a X/Y controller surface.. SC also uses OSC but they had disagreements about the schema and such so theres nonstandard tricks available there...
Vice versa? I would love to explore it some more.
Hallo, Patrick Pagano hat gesagt: // Patrick Pagano wrote:
on this note could someone post some examples of using OSC properly? If possible soem simple examples of OSC coming from maybe Supercollider3 to control Gem? Vice versa? I would love to explore it some more.
RRADical is full of OSC. But using OSC is very simple, if you know Pd's [route] object, and I suppose you do. [OSCroute] is very similar, but instead of routing the first element in a list, it routes the first "path" element in a string. Example:
[/some/osc/path foo bar(
|
[OSCroute /some]
|
Result:
"/osc/path foo bar"
In Gem, you could for example work like this:
[OSCroute /cube /sphere]
|
[OSCroute /trans /rot]
|
[unpack 0 0 0] ...
\ \ \
[translateXYZ] ...
And you can send a message like: "/cube/trans 1 2 -1" or "/sphere/rot -180"
That's OSC.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
I have made this patch once for lan connections (for my improvisation
trio). it isn't comented, but it should be helpful.
I've never used SC, but we did max <-> pd with no probs (osc is osc,
doesn't matter what's sending it). better ask in the SC list for SC
examples, I presume.
Am 13.03.2006, 23:45 Uhr, schrieb Patrick Pagano
pat@digitalworlds.ufl.edu:
on this note could someone post some examples of using OSC properly? If possible soem simple examples of OSC coming from maybe Supercollider3
to control Gem? Vice versa? I would love to explore it some more.cheers~
On Tue, 14 Mar 2006, João Miguel Pais wrote:
I have made this patch once for lan connections (for my improvisation trio). it isn't comented, but it should be helpful. I've never used SC, but we did max <-> pd with no probs (osc is osc, doesn't matter what's sending it). better ask in the SC list for SC examples, I presume.
BTW why is the subjectline "We've got to undo the MIDI revolution!"? What does it mean to undo the MIDI revolution, and what does it have to do with switching to OSC ?
Isn't OSC more MIDI than MIDI itself?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
BTW why is the subjectline "We've got to undo the MIDI revolution!"? What does it mean to undo the MIDI revolution
i'm not sure.. maybe a good start would be making PD's objects default to a range of 0.0 to 1.0 instead of 0 to 127?
, and what does it have to do with switching to OSC ?
OSC was marketed as a successor to MIDI. i guess by undoing the MIDI revolution youd be going back to CV, but i dont recall Sous-Vide chefs ever clamoring to undo the microwave revolution??
Mathieu Bouchard wrote:
On Tue, 14 Mar 2006, João Miguel Pais wrote:
I have made this patch once for lan connections (for my improvisation trio). it isn't comented, but it should be helpful. I've never used SC, but we did max <-> pd with no probs (osc is osc, doesn't matter what's sending it). better ask in the SC list for SC examples, I presume.
BTW why is the subjectline "We've got to undo the MIDI revolution!"? What does it mean to undo the MIDI revolution, and what does it have to do with switching to OSC ?
Isn't OSC more MIDI than MIDI itself?
Well MIDI is a lot more restricted in that most of the messages are predefined, while OSC lets you make up your own messages.
I was thinking about doing OSC over MIDI, something like this: System Exclusive, "Educational Use" Manufacturer ID, followed by the string "OSC", followed by a text representation of the OSC message, e.g. {0xF0 0x7D "OSC" "/vco/1/freq/,f 440.0" 0xF7} This uses a bit less space than the official OSC message format which requires 4-byte padding and binary representations of numbers. Sysex is problematic because of the manufacturer ID which is supposed to be registered with the Midi Manufacturers Association. 0x7D is for non-commercial use. "OSC" is there to avoid conflict with some other use of the 0x7D message. Obviously if there was an "OSC" manufacturer ID it would be shorter and simpler. This could be useful as a way to extend OSC to microcontrollers that don't have the resources to handle ethernet packets.
Martin
non-commercial use. "OSC" is there to avoid conflict with some other use of the 0x7D message. Obviously if there was an "OSC" manufacturer ID it would be shorter and simpler.
theres OSC Software which made Metro and Deck for Macintosh. i think they changed their name to Sagan Solutions now that its owned by Carl Sagan's son..
This could be useful as a way to extend OSC to microcontrollers that don't have the resources to handle ethernet packets.
sure..if it works for you ;) there is a Drupal setup now for OSC perhaps there is someone who has already tunneled it thru MIDI, but if my experience with IP over LocalTalk (which is faster than MIDI i think) it is anything but fun..
anyways theres childrens musicmaking toys on Amazon for $7.95 that have inbuilt ethernet ports for synching multiple toys, and id imagine USB is even cheaper still..
Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
cdr wrote:
non-commercial use. "OSC" is there to avoid conflict with some other use of the 0x7D message. Obviously if there was an "OSC" manufacturer ID it would be shorter and simpler.
theres OSC Software which made Metro and Deck for Macintosh. i think they changed their name to Sagan Solutions now that its owned by Carl Sagan's son..
This could be useful as a way to extend OSC to microcontrollers that don't have the resources to handle ethernet packets.
sure..if it works for you ;) there is a Drupal setup now for OSC
I think their OSC stands for Open Source Content, an OSC of a different colour. **
perhaps there is someone who has already tunneled it thru MIDI, but if my experience with IP over LocalTalk (which is faster than MIDI i think) it is anything but fun..
anyways theres childrens musicmaking toys on Amazon for $7.95 that have inbuilt ethernet ports for synching multiple toys, and id imagine USB is even cheaper still..
Yes, I was thinking along the lines of microcontrollers like the PIC16F88, which are quite good at MIDI but don't have the RAM for anything with a protocol stack like UDP or USB. USB would work if it were possible to send UDP over USB, but I don't think it is, the way IEEE1394 can be used instead of ethernet. I've already used OSC on the Rabbit micros with no problems but they are a lot more complex than PICs: http://www.rabbitsemiconductor.com/products/rcm3700/
Martin
hi
On 3/14/06, cdr ix@replic.net wrote:
if my experience with IP over LocalTalk (which is faster than MIDI i think) it is anything but fun..
LocalTalk- arrghh!
but you are right about speed [according to wikipedia] local talk runs at 230400 bit/s MIDI at 31250 bit/s
-- \js [ http://or8.net/~johns/ ]
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Tue, 14 Mar 2006, João Miguel Pais wrote:
I have made this patch once for lan connections (for my improvisation trio). it isn't comented, but it should be helpful. I've never used SC, but we did max <-> pd with no probs (osc is osc, doesn't matter what's sending it). better ask in the SC list for SC examples, I presume.
BTW why is the subjectline "We've got to undo the MIDI revolution!"? What does it mean to undo the MIDI revolution, and what does it have to do with switching to OSC ?
The actual question is: Why did this thread move here from pd-dev, where it was started by the (closed) feature request #1447808 under the title "We've got to undo the MIDI revolution! - Where is OSC?!" Quote:
'We've got to undo the MIDI revolution! Miller S. Puckette'
This is all very well, however it seems OSC support is somewhat limited for Windows systems, insofar as I cannot find anywhere to download OSC externals for windows...the link from the main page has been down for some months now.
I think, OSC was first specified in 2002. Pd already had netsend and netreceive at that time, both were introduced five years earlier. Looking at it that way the Midi Revolution was undone by FUDI in 1997.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
I think, OSC was first specified in 2002. Pd already had netsend and netreceive at that time, both were introduced five years earlier
-See: http://www.cnmat.berkeley.edu/ICMC97/papers-html/OpenSoundControl.html
AvS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
` |Schreck Ensemble . . . . . . . . . . . . . . . . . . . . +
` |# -laboratory for live electro-acoustic music- # |
| http://www.schreck.nl/ |
| http://www.xs4all.nl/~schreck/ |
` *===========================================================++
` |Compositions http://www.xs4all.nl/~schreck/html/compo.html |
` |Samples http://www.xs4all.nl/~schreck/html/samp.html |
` |Patches http://www.xs4all.nl/~schreck/html/pat.html |
` |Videos http://www.xs4all.nl/~schreck/html/video.html |
` |Scores http://www.xs4all.nl/~schreck/html/scores.html |
*===========================================================++
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
Hallo, Arie van Schutterhoef hat gesagt: // Arie van Schutterhoef wrote:
I think, OSC was first specified in 2002. Pd already had netsend and netreceive at that time, both were introduced five years earlier
-See: http://www.cnmat.berkeley.edu/ICMC97/papers-html/OpenSoundControl.html
Argh, beaten! ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Thu, 16 Mar 2006, Frank Barknecht wrote:
Arie van Schutterhoef hat gesagt: // Arie van Schutterhoef wrote:
I think, OSC was first specified in 2002. Pd already had netsend and netreceive at that time, both were introduced five years earlier
-See: http://www.cnmat.berkeley.edu/ICMC97/papers-html/OpenSoundControl.html
Argh, beaten! ;)
If I want to plug my guitar on the computer using the FUDI protocol using an expensive cable such as an old RS232 DB9 serial cable, what should I use, PPP ? [netreceive] doesn't work with serial ports.
But if I use PPP I need a TCP/IP stack in my guitar too...
In 1997 that would've been expensive.
FUDI wasn't designed to "undo" the MIDI revolution.
Is there OSC over RS232 ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Wed, 15 Mar 2006, Mathieu Bouchard wrote:
FUDI wasn't designed to "undo" the MIDI revolution.
Is there OSC over RS232 ?
OSC doesn't specify the transport layer AFAIK, so yes, there is. If your question is if there is an implementation, then I would say I don't think so. You will see more implementations of the MIDI protocol over RS232 (MIDI hardware != RS232) because MIDI is easier to implement.
In that sense FUDI is very nice in that it is human readable, but its implementation is quite complicated as you need a parser for the number values. And it needs a bit more bandwidth under most circumstances.
MIDI is a hardware- and protocol specification, OSC is just a protocol. With a decent 8-bit clean morse alphabet you could even transmit it by drumming :) But encoding and decoding it is pretty complicated.
Guenter
geiger wrote:
On Wed, 15 Mar 2006, Mathieu Bouchard wrote:
FUDI wasn't designed to "undo" the MIDI revolution.
Is there OSC over RS232 ?
OSC doesn't specify the transport layer AFAIK, so yes, there is. If your question is if there is an implementation, then I would say I don't think so. You will see more implementations of the MIDI protocol over RS232 (MIDI hardware != RS232) because MIDI is easier to implement.
In that sense FUDI is very nice in that it is human readable, but its implementation is quite complicated as you need a parser for the number values. And it needs a bit more bandwidth under most circumstances.
MIDI is a hardware- and protocol specification, OSC is just a protocol. With a decent 8-bit clean morse alphabet you could even transmit it by drumming :) But encoding and decoding it is pretty complicated.
Complicated compared to what? It could be made simpler for low-speed serial systems such as MIDI and RS232 by simply sending the whole thing as ASCII text instead of 4-byte padded binary. Bit 7 (the MSB) can then be used to delimit packets. In MIDI it could be sent as a sysex message without having to pack and unpack 8 bits to 7 bits. It would also be human-readable for debugging. As far as PD goes, it would be nice to have the OSC objects use the same code as netsend and netreceive, that way TCP could be used as well as UDP, and all the networking would use the same code, i.e. the code in x_net.c. At the moment the PD OSC objects use Adrian Freed's htmsocket.c which handles its own (UDP or UNIX) sockets.
Martin
Indeed this is really logical.
In fact I think the whole OSC external thing needs to be rethought.
I did not read the original feature request, what was it?
maybe something we could talk about at the next dev meeting, I have some design ideas that fit into memento and RRADICAL as well as pixelTANGO. Martin, are you interested in talking about the reimplimentation of the OSC external (or collection of externals/abstractions?)
.b.
Martin Peach wrote:
As far as PD goes, it would be nice to have the OSC objects use the same code as netsend and netreceive, that way TCP could be used as well as UDP, and all the networking would use the same code, i.e. the code in x_net.c. At the moment the PD OSC objects use Adrian Freed's htmsocket.c which handles its own (UDP or UNIX) sockets.
Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mar 16, 2006, at 12:43 PM, B. Bogart wrote:
In fact I think the whole OSC external thing needs to be rethought.
why not just implement a wrapper to liblo ?
i find this OSC library to be both robust and efficient for several queues open on several machines.
dealing with the creation / performance of installation art spread across multiple computers, i'm biased towards Csound for my work as it presently uses liblo as it's OSC implementation.
just some food for thought...
./d5
day 5 wrote:
On Mar 16, 2006, at 12:43 PM, B. Bogart wrote:
In fact I think the whole OSC external thing needs to be rethought.
why not just implement a wrapper to liblo ?
Well because liblo is some other library that will probably cause trouble down the road when it changes into something incompatible with its current implementation, the way e.g. python causes problems when some apps want 2.3 and others insist on 2.4.
i find this OSC library to be both robust and efficient for several queues open on several machines.
dealing with the creation / performance of installation art spread across multiple computers, i'm biased towards Csound for my work as it presently uses liblo as it's OSC implementation.
I was thinking that pd offers a lot of flexibility and responsiveness for the user interface side of things, while csound is really good at generating sound, so it would be better to use OSC, MIDI, mouse, etc. as inputs to a pd patch which would control csound via a [csoundapi~] object. (I suppose you could just use OSC between pd and csound as well and skip the [csoundapi~]) Currently pd's OSC objects work fine, for me at least ;). Adding nested bundles just adds to the latency, and timetags in absolute time are not very useful except for archiving. For synchronization it's not hard to simply add integer timestamp arguments to an OSC message. The neat thing about OSC is that you're free to make up your own messages.
Martin
day 5 wrote:
On Mar 16, 2006, at 12:43 PM, B. Bogart wrote:
In fact I think the whole OSC external thing needs to be rethought.
why not just implement a wrapper to liblo ?
Investigating further, I see that liblo can only send via UDP and UNIX sockets, not TCP. It handles its own sockets internally just like libOSC (the basis for sendOSC and dumpOSC in pd). In pd, netsend and netreceive can do TCP as well. OSC is supposed to work on 'any' protocol, but AFAIK it hasn't been implemented on MIDI or RS232 or USB, probably for lack of interest. At least a TCP implementation would be useful for those who need guaranteed delivery of packets.
Martin
On Mar 21, 2006, at 7:23 PM, Martin Peach wrote:
day 5 wrote:
On Mar 16, 2006, at 12:43 PM, B. Bogart wrote:
In fact I think the whole OSC external thing needs to be rethought.
why not just implement a wrapper to liblo ?
Investigating further, I see that liblo can only send via UDP and
UNIX sockets, not TCP. It handles its own sockets internally just
like libOSC (the basis for sendOSC and dumpOSC in pd). In pd, netsend and netreceive can do TCP as well. OSC is supposed
to work on 'any' protocol, but AFAIK it hasn't been implemented on
MIDI or RS232 or USB, probably for lack of interest. At least a TCP
implementation would be useful for those who need guaranteed
delivery of packets.
CCRMA at Stanford University has a limited version of OSC on serial
called dumpOSCSerial. I never found the code, just hte binary.
Ideally, there would be a Pd OSC lib that had no transport built in.
Then you could choose your transport. That makes things much more
flexible.
.hc
Hans-Christoph Steiner wrote:
On Mar 21, 2006, at 7:23 PM, Martin Peach wrote:
day 5 wrote:
On Mar 16, 2006, at 12:43 PM, B. Bogart wrote:
In fact I think the whole OSC external thing needs to be rethought.
why not just implement a wrapper to liblo ?
Investigating further, I see that liblo can only send via UDP and
UNIX sockets, not TCP. It handles its own sockets internally just
like libOSC (the basis for sendOSC and dumpOSC in pd). In pd, netsend and netreceive can do TCP as well. OSC is supposed to work on 'any' protocol, but AFAIK it hasn't been implemented on MIDI or RS232 or USB, probably for lack of interest. At least a TCP
implementation would be useful for those who need guaranteed
delivery of packets.CCRMA at Stanford University has a limited version of OSC on serial
called dumpOSCSerial. I never found the code, just hte binary.
Ideally, there would be a Pd OSC lib that had no transport built in.
Then you could choose your transport. That makes things much more
flexible..hc
I agree. If there were objects called [OSCpack] and [OSCunpack] that worked analogously to [pack] and [unpack] they would output and input data in OSC binary format, I suppose as a list of floats in pd-land.
Martin
On Mar 22, 2006, at 11:09 AM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
On Mar 21, 2006, at 7:23 PM, Martin Peach wrote:
day 5 wrote:
On Mar 16, 2006, at 12:43 PM, B. Bogart wrote:
In fact I think the whole OSC external thing needs to be
rethought.why not just implement a wrapper to liblo ?
Investigating further, I see that liblo can only send via UDP
and UNIX sockets, not TCP. It handles its own sockets internally
just like libOSC (the basis for sendOSC and dumpOSC in pd). In pd, netsend and netreceive can do TCP as well. OSC is
supposed to work on 'any' protocol, but AFAIK it hasn't been
implemented on MIDI or RS232 or USB, probably for lack of
interest. At least a TCP implementation would be useful for
those who need guaranteed delivery of packets.CCRMA at Stanford University has a limited version of OSC on
serial called dumpOSCSerial. I never found the code, just hte
binary. Ideally, there would be a Pd OSC lib that had no
transport built in. Then you could choose your transport. That
makes things much more flexible..hc
I agree. If there were objects called [OSCpack] and [OSCunpack]
that worked analogously to [pack] and [unpack] they would output
and input data in OSC binary format, I suppose as a list of floats
in pd-land.
Sounds like its going down the right track. How it would work
exactly? OSC has two parts:
/my/item 11
Would these un/pack objects just handle the first part?
.hc
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
Hans-Christoph Steiner wrote:
On Mar 22, 2006, at 11:09 AM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
On Mar 21, 2006, at 7:23 PM, Martin Peach wrote:
day 5 wrote:
On Mar 16, 2006, at 12:43 PM, B. Bogart wrote:
In fact I think the whole OSC external thing needs to be rethought.
why not just implement a wrapper to liblo ?
Investigating further, I see that liblo can only send via UDP and
UNIX sockets, not TCP. It handles its own sockets internally just
like libOSC (the basis for sendOSC and dumpOSC in pd). In pd, netsend and netreceive can do TCP as well. OSC is supposed
to work on 'any' protocol, but AFAIK it hasn't been implemented on MIDI or RS232 or USB, probably for lack of interest. At least a TCP implementation would be useful for those who need guaranteed delivery of packets.CCRMA at Stanford University has a limited version of OSC on
serial called dumpOSCSerial. I never found the code, just hte
binary. Ideally, there would be a Pd OSC lib that had no
transport built in. Then you could choose your transport. That
makes things much more flexible..hc
I agree. If there were objects called [OSCpack] and [OSCunpack] that worked analogously to [pack] and [unpack] they would output and input data in OSC binary format, I suppose as a list of floats in pd-land.
Sounds like its going down the right track. How it would work
exactly? OSC has two parts:/my/item 11
Would these un/pack objects just handle the first part?
Maybe [OSCpack] would take an OSC path in its left inlet and whatever types were specified by its arguments in the other inlets, the same as [pack], so something like: [/my/item 11( | [OSCpack i] | [netsend] ...would send 11 as an int, but [OSCpack s] would send it as a string and [OSCpack f] a float.
[OSCunpack] could have one outlet for a list comprising the path separated into symbols followed by the data. This could go to [route] for further processing. [netreceive] | [OSCunpack] | [route my] | [route item] | [11\
or alternatively it could be more like [unpack] and have an outlet for
each datum:
[netreceive]
|
[OSCunpack /my/item i]
|
[11
...but that would only unpack one specific OSC address, so you would
need one for each OSC endpoint.
Ideas?
Martin
B. Bogart wrote:
Indeed this is really logical.
In fact I think the whole OSC external thing needs to be rethought.
I did not read the original feature request, what was it?
There was one about not being able to send a number as a symbol, which I made a patch for. The other was just that OSC binaries for Windows are always hard to find. Another reason to make OSC integral to PD.
maybe something we could talk about at the next dev meeting, I have some design ideas that fit into memento and RRADICAL as well as pixelTANGO. Martin, are you interested in talking about the reimplimentation of the OSC external (or collection of externals/abstractions?)
Sure, if I can figure out how to connect to the meeting ;)
Martin
On Thu, 16 Mar 2006, Martin Peach wrote:
But encoding and decoding it is pretty complicated.
Complicated compared to what?
I meant in general, but one could compare it to MIDI, for example, which is a lot easier to parse as the data types and the data come bundled, whereas with OSC you have them separated, which makes parsing harder because you have to maintain a pointer to the data and the types. Also if you start to think about timetagged, recursive bundles of messages and the way you would deliver them correctly it gets pretty hairy.
Writing a correct OSC parser is not trivial.
Guenter
It could be made simpler for low-speed serial systems such as MIDI and RS232 by simply sending the whole thing as ASCII text instead of 4-byte padded binary. Bit 7 (the MSB) can then be used to delimit packets. In MIDI it could be sent as a sysex message without having to pack and unpack 8 bits to 7 bits. It would also be human-readable for debugging. As far as PD goes, it would be nice to have the OSC objects use the same code as netsend and netreceive, that way TCP could be used as well as UDP, and all the networking would use the same code, i.e. the code in x_net.c. At the moment the PD OSC objects use Adrian Freed's htmsocket.c which handles its own (UDP or UNIX) sockets.
Martin
hi list,
coming from sc-land, i am quite a (gem) newbie, though i used a
precompiled gem on osx before.
i was trying to get Gem to compile lately, but was not very succesfull.
i use pd-0.39-1test1, first Gem would not compile, then i configured
--without-mpeg3
(basically i just wanted to generate some graphics, don't realy need
to use any media input now)
that would compile but still i got
undefined symbol: glUniform4iARB
upon starting pd, and no working Gem...
i am almost as sure this is a mistake on my side (maybe missing
proper deps/configuration)
as i am sure there's an easy recovery from this tragedy,
please tell me (also if more info is needed) :)
thanks lots, adrian (this is on gentoo-linux, pentium3)
undefined symbol: glUniform4iARB
http://www.lwjgl.org/javadoc/org/lwjgl/opengl/ARBShaderObjects.html
AvS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
` |Schreck Ensemble . . . . . . . . . . . . . . . . . . . . +
` |# -laboratory for live electro-acoustic music- # |
| http://www.schreck.nl/ |
| http://www.xs4all.nl/~schreck/ |
` *===========================================================++
` |Compositions http://www.xs4all.nl/~schreck/html/compo.html |
` |Samples http://www.xs4all.nl/~schreck/html/samp.html |
` |Patches http://www.xs4all.nl/~schreck/html/pat.html |
` |Videos http://www.xs4all.nl/~schreck/html/video.html |
` |Scores http://www.xs4all.nl/~schreck/html/scores.html |
*===========================================================++
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
On Mar 16, 2006, at 2:34 AM, geiger wrote:
On Wed, 15 Mar 2006, Mathieu Bouchard wrote:
FUDI wasn't designed to "undo" the MIDI revolution.
Is there OSC over RS232 ?
OSC doesn't specify the transport layer AFAIK, so yes, there is. If your question is if there is an implementation, then I would say I don't think so. You will see more implementations of the MIDI protocol over RS232 (MIDI hardware != RS232) because MIDI is easier to implement.
In that sense FUDI is very nice in that it is human readable, but its implementation is quite complicated as you need a parser for the number values. And it needs a bit more bandwidth under most circumstances.
MIDI is a hardware- and protocol specification, OSC is just a protocol. With a decent 8-bit clean morse alphabet you could even transmit it by drumming :) But encoding and decoding it is pretty complicated.
OSC does not specify the transport specifically but it was designed
around UDP, so its not a trivial spec:
http://www.cnmat.berkeley.edu/OpenSoundControl/OSC-spec.html
Most people just implement the namespace part of it and call that OSC
(i.e. /path/to/thing value). I don't know of anyone who uses OSC
TimeTags, for example.
.hc
OSC does not specify the transport specifically but it was designed
around UDP, so its not a trivial spec:
the spec is really simple, anything that can stream binary data can move it. Om-synth has added OSC patching this to its CVS version.. how Om handles types is: the cables dont care what theyre carrying, and will only connect xlets with matching typetags (eg control, signal, OSC, MIDI). they can carry 'chockfoo' or 'OSCviaJSON', as long as you have a plugin (aka object) to handle it..
afaik nobody uses timetags
imagine for a second you are writing OSC data to a file on disk instead of a UDP socket - when you are reading back later on..timetags would be quite useful. the most basic step of implementing an OSC sequencer (without converting a limited subset of the OSC types to say, pd types, and incurring further precision penalties when writing to disk via [textfile]) would be to store and load OSC from a file, do any apps do this yet?
liblo is nice, but would be an extra library dependency, plus its C++ - both eschewed by the pd core ethos..the more idiomatic solution? generalized transport mechanisms and OSC implemented as a set of data-parsing abstractions..
there was a proposal from matju on how to implement this, here it is again:
ack..cant find it. i think it was using some pointer tricks so the cables didnt actually have to carry OSC and other objects could somehow reference the id of the UDP or TCP object? i read it and didnt quite understand..
On Mar 16, 2006, at 8:42 PM, cdr wrote:
OSC does not specify the transport specifically but it was designed around UDP, so its not a trivial spec:
the spec is really simple, anything that can stream binary data can
move it. Om-synth has added OSC patching this to its CVS version..
how Om handles types is: the cables dont care what theyre carrying,
and will only connect xlets with matching typetags (eg control,
signal, OSC, MIDI). they can carry 'chockfoo' or 'OSCviaJSON', as
long as you have a plugin (aka object) to handle it..afaik nobody uses timetags
imagine for a second you are writing OSC data to a file on disk
instead of a UDP socket - when you are reading back later
on..timetags would be quite useful. the most basic step of
implementing an OSC sequencer (without converting a limited subset
of the OSC types to say, pd types, and incurring further precision
penalties when writing to disk via [textfile]) would be to store
and load OSC from a file, do any apps do this yet?liblo is nice, but would be an extra library dependency, plus its C+
- both eschewed by the pd core ethos..the more idiomatic
solution? generalized transport mechanisms and OSC implemented as a
set of data-parsing abstractions..there was a proposal from matju on how to implement this, here it
is again:ack..cant find it. i think it was using some pointer tricks so the
cables didnt actually have to carry OSC and other objects could
somehow reference the id of the UDP or TCP object? i read it and
didnt quite understand..
Timetags would be really useful, too bad no one has implemented
them. As for liblo, there are already so many dependencies to Pd-
extended, what's one more ;).
Seriously, if someone wrote some objects based on liblo, managing
that lib would be easy enough. The liblo source could go into the
section for external sources aka "imports".
.hc
http://at.or.at/hans/
cdr wrote:
imagine for a second you are writing OSC data to a file on disk instead of a UDP socket - when you are reading back later on..timetags would be quite useful. the most basic step of implementing an OSC sequencer (without converting a limited subset of the OSC types to say, pd types, and incurring further precision penalties when writing to disk via [textfile]) would be to store and load OSC from a file, do any apps do this yet?
MIDI files do this using "delta times" which are the number of "ticks" since the start of the file. OSC timetags are absolute times in the style of the NTP protocol ("The first 32 bits specify the number of seconds since midnight on January 1, 1900, and the last 32 bits specify fractional parts of a second to a precision of about 200 picoseconds.") so you could only ever play your sequence once ;) Something like a python script could save delta time in milliseconds along with each OSC message.
Martin
On Fri, 17 Mar 2006, cdr wrote:
there was a proposal from matju on how to implement this, here it is again: ack..cant find it. i think it was using some pointer tricks so the cables didnt actually have to carry OSC and other objects could somehow reference the id of the UDP or TCP object? i read it and didnt quite understand..
What? Do you mean the proposal about decoupling the data protocol from the socket?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sun, 26 Mar 2006, carmen wrote:
What? Do you mean the proposal about decoupling the data protocol from the socket?
yeah that...
Ok, I found it again:
http://lists.puredata.info/pipermail/pd-list/2005-12/034262.html
but there's a typo, replace "InputOutputStream" by "IOByteStream".
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
\js -
adrian -
Arie van Schutterhoef -
B. Bogart -
carmen -
cdr
-
day 5 -
Frank Barknecht -
geiger -
Hans-Christoph Steiner -
João Miguel Pais -
Martin Peach -
Mathieu Bouchard -
Patrick Pagano