PaulStoffregen
Well-known member
I am considering someday (perhaps in the distant future) adding a Teensy 3.0 Tools > USB Type option for OSC. This thread is intended to discuss how USB-based OSC might (eventually) work. If you're interested in OSC on Teensy3, please subscribe to this thread. When/if a test version is ever made, preliminary info or invitations to beta test will be posted here.
First, I must confess I have never really used OSC. Well, there was one project where I used KineticSpace to control a pyrotechnic fire art installation, but I just wrote a program in C that listened for UDP packets (on the same machine, 127.0.0.1) and parsed the text for a couple specific numbers. I've also read about OSC and exchanged several emails with Adrian Freed, but still my knowledge and experience about how people actually use Open Sound Control for real musical projects is rather limited. That's where I really need your input and help.
My thoughts on OSC so far are implementing a limited USB Ethernet interface. Fortunately, OSC uses only UDP protocol, which makes this doable, since all the complexity of TCP isn't needed. Lower level stuff like ARP, ICMP and maybe DHCP are probably needed, adding to the complexity a bit.
How the IP number, netmask & gateway are assigned is a big question. I believe all 3 operating systems will default to looking for a DHCP server, so if the OSC implementation responds to DHCP queries it should be able to set this stuff up, right? If it implements a response-only nameservice, it could give itself a name which could be used, but probably only on that computer.
This actually leads to all sorts of questions.....
Do you see OSC applications on Teensy 3.0 listening for messages, where the sender needs to know the name or IP number of the Teensy 3.0? Would the sender be on the same computer where the USB cable is plugged in, or somewhere else on the network.
Or would you need your OSC project to embed the name or IP number of some other OSC entity. Would it be on the same computer, or would the computer need to route packets to deliver your OSC messages elsewhere?
While a lot of this stuff is normal IP networking setup, I feel it's important to make a system that's easy to use. Sure, it's possible to make things work in lots of ways by manually editing network numbers and routing rules on your computer, but that's a difficult and error-prone process (and the reason protocols like DHCP and DNS exit). I want to consider how this stuff is actually going to work for any USB-ethernet OSC option.
Another question involves maximum packet size? I've looked at a few Arduino OSC implementations which limit the message size to only a couple hundred bytes. Presumably that's enough? There will be some sort of limit, but what is a useful threshold?
I'd also like to hear what sort of things you'd actually do with OSC, which can't be done with MIDI?
And again, I want to mention this is all very early discussion about a feature that might be implemented eventually, but highly unlikely to happen within the next few months.
First, I must confess I have never really used OSC. Well, there was one project where I used KineticSpace to control a pyrotechnic fire art installation, but I just wrote a program in C that listened for UDP packets (on the same machine, 127.0.0.1) and parsed the text for a couple specific numbers. I've also read about OSC and exchanged several emails with Adrian Freed, but still my knowledge and experience about how people actually use Open Sound Control for real musical projects is rather limited. That's where I really need your input and help.
My thoughts on OSC so far are implementing a limited USB Ethernet interface. Fortunately, OSC uses only UDP protocol, which makes this doable, since all the complexity of TCP isn't needed. Lower level stuff like ARP, ICMP and maybe DHCP are probably needed, adding to the complexity a bit.
How the IP number, netmask & gateway are assigned is a big question. I believe all 3 operating systems will default to looking for a DHCP server, so if the OSC implementation responds to DHCP queries it should be able to set this stuff up, right? If it implements a response-only nameservice, it could give itself a name which could be used, but probably only on that computer.
This actually leads to all sorts of questions.....
Do you see OSC applications on Teensy 3.0 listening for messages, where the sender needs to know the name or IP number of the Teensy 3.0? Would the sender be on the same computer where the USB cable is plugged in, or somewhere else on the network.
Or would you need your OSC project to embed the name or IP number of some other OSC entity. Would it be on the same computer, or would the computer need to route packets to deliver your OSC messages elsewhere?
While a lot of this stuff is normal IP networking setup, I feel it's important to make a system that's easy to use. Sure, it's possible to make things work in lots of ways by manually editing network numbers and routing rules on your computer, but that's a difficult and error-prone process (and the reason protocols like DHCP and DNS exit). I want to consider how this stuff is actually going to work for any USB-ethernet OSC option.
Another question involves maximum packet size? I've looked at a few Arduino OSC implementations which limit the message size to only a couple hundred bytes. Presumably that's enough? There will be some sort of limit, but what is a useful threshold?
I'd also like to hear what sort of things you'd actually do with OSC, which can't be done with MIDI?
And again, I want to mention this is all very early discussion about a feature that might be implemented eventually, but highly unlikely to happen within the next few months.