Can Arduino send OSC directly to Reaktor etc?

I am currently sending OSC (Open Sound Control) messages using Max/MSP's UDPsend and UDPreceive to control Reaktor from my Arduino.

But I would like to be able to take Max/MSP out of the equation and talk straight to Reaktor. Is it possible to have the Arduino send and receive OSC information natively, without intermediary software?

Also, a bonus would be to also send and receive MIDI at the same time, so the same device could be used either as a standalone MIDI controller or as a computer-based OSC controller. Is any of this possible and if so where should I be researching this?

Anyone? :slight_smile:

(don't you hate it when you are researching something online and come across your own posts in the search results?)

Arduino can send and receive OSC formatted messages and data (see for example, d.tools for Arduino: http://hci.stanford.edu/dtools/arduino.html). However, most (all?) programs expect OSC messages to arrive over UDP, not a serial port, and so you need some program in-between to transfer messages across. Monome has a program that does something like this (http://monome.org/data/app/monomeserial), but you'd need to use their protocol for the serial communication.

Yeah, I've actually been talking to someone about writing me a monomeserial type driver, but I was hoping that somehow OSC really is the new MIDI.

But if I understand correctly, OSC will never work as a stand-alone protocol between machines, like MIDI, but will always require a computer?

I was imagining a little CPU or microprocessor on a card that could allow a device be recognized as a UDP client/host, but maybe that's a little too 2010. Will do more reading on UDP before I daydream more.

...or maybe that is why Lemur/Dexter has an Ethernet port in it? Do Jazzmutant users run a driver, too?

Well, typically (AFAIK), OSC messages go over UDP, so you can send them from any machines with ethernet support.

Maybe I can use something like this:

http://www.netburner.com/products/serial_to_ethernet/sb70.html

I found a couple of research projects where people are doing similar stuff for haptic interfaces but it seems amazing that OSC and OSC support seems to be somewhat in its infancy despite being around for several years.

Also, the Make Controller claims to support OSC - but do they just mean the OSC syntax over serial? I doubt the Make controller provides embedded Ethernet.

I think the Make controller does have embedded ethernet support actually.

Tom Igoe's new book will answer these questions for you.

If you hook up the arduino to a Lantronix xport you should be able to. I have just got one and will be having a go at osc as soon as I have some time.

The book also has alot of arduino code in it and practical info that saves lots of time troubleshooting and investigating.

Spent some time looking at Make controller - intriguing. I wonder what it would be like to port my current project - whether I would basically be starting from scratch.

The Make controller seems to offer a lot of features - but I wonder if basing my project around a commercial product in general is a good idea (Arduino, Wiring, Make) because I would like to offer it as a kit. 2 sides to this - requiring a specific controller for the kit means a built-in audience, but it also limits the audience to users of that particular controller, esp if I go the Make direction, since it is the only one that offers OSC connectivity on-board... :-/

nick: I have Tom's Physical Computing book - it definitely helped me get started but t sounds like the new one picks up where that left off. I also see it's published via MAKE so maybe that answers my question.

It mentions the make controller in passing - most examples use the arduino.

If the chip is cheap then it doesn't limit it to anyone as buying one is a trivial act.
All solutions will ultimately be built on chips that are a commercial product.

Future availablity or ease of movement of code to another product may be factors - I would say arduino scores highly on both of those -various chips used, multiple form factors and healthy clone market and kits/bareboard versions - you can even take the designs and make your own boards if you need to - ideal for kits.

You could design an arduino shield that a lantronix direct clips onto much like the zigbee board and you would be away - but with some coding to do.

Weigh against that that the make has ethernet built in and osc capability already - although I haven't seen details of how easy sending osc directed to an application is. The details here http://www.makingthings.com/documentation/tutorial/programming-the-make-controller-kit/osc
seem to indicate that the board can be queried and controlled by another program using osc - no mention of sending osc from the board to control somethin else. You may need to check it out in more detail to make sure it offers the ease of osc use for that specific case.

It appears that there is a larger community of arduino users than of the make board - depending on how much that is important or useful to you

Be interested in what you go for in the end as I am considering similar options.

Great info and thoughts, thanks!

I looked at the Lantronix stuff - I wish they made a board that would give me the Ethernet/UDP/OSC functionality via USB.

Right now I am leaning towards Freeduino/Arduino and meanwhile will wait for the technology to catch up. I agree with your point that there is (currently) a larger community for Arduino. Perhaps someone more qualified will solve this so I don't have to.

PS: I just picked up the new Tom Igoe book at Maker Faire Austin and it looks really great! A lot of stuff I've had to figure out on my own these last few months is all right there in b&w.

I've got my lantronix stuff now so am starting to fiddle. I've hooked it up to a ftdi usb to ttl serial cable and am sending stuff backwards and forwards between telnet and serial - just need to figure out formatting stuff correctly to send down serial for proper osc data to come out.

Reading the osc.org pages and looking at all the stuff that people have done with controllers already to see what is the best way to go.

I am currently sending OSC (Open Sound Control) messages using Max/MSP's UDPsend and UDPreceive to control Reaktor from my Arduino.

But I would like to be able to take Max/MSP out of the equation and talk straight to Reaktor. Is it possible to have the Arduino send and receive OSC information natively, without intermediary software?

I have been looking for an OSC implementation for Arduino too but haven't really found one that's usable yet. I guess the d.tools Arduino firmware by Stanford's HCI Group comes closest but I would prefer a bit more Arduino-like approach (like a library instead of a custom firmware). But what I did find is a tool that you might want to try: serialosc2udp which is documented to some extent in the CCRMA wiki at AVR - CCRMA Wiki.

OSC is getting quite a lot of attention these days so I really hope some experienced coder could have a look at the existing implementations for AVR and see if they could be turned into an Arduino library or sketch. You can find two rather simple implementations (both of which are using avrlib) on the CCRMA site at avrlib. Let's get hacking! :wink:

Hey, I replied elsewhere too, but since I am doing research on the topic, it seems http://adrianfreed.com/content/oscuino-arduino-osc-sketch-open-sound-control-work OSCuino is the most efficient firmware.

The OSC is wrapped in SLIP packets and I cannot unwrap it in e.g. Puredata, Processing.
At the bottom of the page, Freed supplies a Max patch, however I am running Linux now and cannot try it out. Any suggestions about that? Should I use some intermediary script that unpacks?

hello, i am new here so i cannot post my first message with links. please ignore.

so here we go:
Just wanted to point you to something i just found in the the PD externals repository:

in mrpeachs externals there is slipenc and slipdec
so following your idea of using oscuino, this should bring us closer without shelling out money for the ethernet shield, no :wink: ?