looking in the crystal ball: OSC replacing MIDI?

Miscellaneous
1

I suppose you all read the big news in the “scene” from yesterday:

API calls for Ableton Live via Python!

http://liveapi.org/

with the LiveOSC code one can access many internal LIVE objects directly (clip names, colors, clocks.) as well as get some response from LIVE about what the user is doing on the GUI. Basically, the Python code is accessed by assigning a “virtual” controler surface within LIVE. As I was playing around with OSC, Python and CHUCK some weeks ago, I found some interesting properties of OSC when compared to MIDI in this thread of the Ableton forums:

“…OSC can send arbitrary blobs, floats, ints, strings – as well as arrays of those values…”

http://www.ableton.com/forum/viewtopic.php?t=66118&start=0&postdays=0&postorder=asc&highlight=

Unfortunately I am not a “coder”, but theoretically, this development makes me think if the MIDIBOX of the year 2012 (or 2010?) might not have two MIDI-Ports and no USB port, but one Ethernet-Connector, and sends/receives OSC commands to the host application.

I have no idea if this is within the capabilities of a PIC, but I want to ask the experts about their thoughts, as for me, this is the first real paradigm shift away from MIDI towards a more capable protocol…

2

maybe MIDI won’t get obsolete by that, but the liveapi.org site definitely looks very interesting indeed :smiley:

I was struggeling just a while ago writing a launcher/shutdown script for Live and I whished I had access to internal commands suppressing some dialog confirmation boxes.

Cheers for the link,

Michael

3

I’m sure that OSC has a future, and I’m also sure that there will be MIDIboxes with ethernet support sooner or later. It could even be possible to connect an external ethernet controller like the ENC28J60 to a common core module to prevent a major hardware re-design.

But I fear that for a decent application which satisfies all the request we normaly get from you guys, an 8bit controller is not sufficient. In this special case (complex controller which supports OSC) maybe an ARM based microcontroller with Embedded Linux installed would be fine and easy to handle…

However, for simple OSC controller applications the PIC could still be sufficient.

Best Regards, Thorsten.

4

thank you tk,

maybe I am just a little “envious” at the MONOME crowd, they have all the attributes like “hip” and “cool” connected to their poject, whereas MB seems just so much more powerful to me, or did I miss something (i.e. the monome is box with 8/16/64 lighted buttons..)??? As I just checked, it also connects via SERIAL to the PC, no USB or MIDI or ethernet…

also, tk, how would a SIMPLE OSC MB controller application connect to the computer? MIDI and then convert to OSC with some python code???

5

OSC is a protocol like MIDI, there is no need for using python in order to convert messages, you can just send them directly to the host, e.g. via ethernet; you could also use an alternative interface, like CAN, USB or similar.

But as most computers are stuffed with an ethernet interface today, and in OSC host applications this interface is also prefered, it’s the first choice.

Best Regards, Thorsten.

P.S.: for LiveAPI it seems that OSC is only available through the python interface, but I haven’t digged so deep into the docs (not really interesting for me…)

6

MB seems just so much more powerful to me, or did I miss something (i.e. the monome is box with 8/16/64 lighted buttons..)???

Yeh it’s a fashion trend for sure… OSC aside, it’s nothing that MB64 wasn’t doing years ago. Pretty buttons making people go ga-ga :wink:

I still have trouble seeing any real use for OSC that MIDI doesn’t cover off… Timestamping is about the only thing that interests me so far. And the costs of introducing OSC are much greater than MIDI alone. It seems obsolete to me.

Maybe it’s because I don’t use software.

7

yeah;

still see it that the greatest strength of mb is it’s use without any computers, from tiny to huuuuge.

But once you have one computer running software, it doesn’t make much sense to write complex apps on a tiny chip if you could do the same 500% faster on the PC itself.

not that I’m misunderstood: I think of mb more like a specialized basic tool - use your pots, buttons, levelers like a mouse or a keyboard - and once this data is in the computer you could do a lot more sophisticated things with it.

So to say: I haven’t seen no PC-mouse with a LAN-extension card ;D

Cheers,

Michael

8

stryd:

wouldn`t make sending ARRAYS and strings via OSC bidirectionally make many “conversations” with the host app much easier for some MB applications?

MIDI always just sends one or two bytes per message…

I do agree that complex “intelligence” should reside in the host app and not the interface, but I still think that most MB applications could benefit from a more efficient exchange protocol…

9

One word: Sysex :wink:

10

One of the big advantages compared to MIDI is the replacement of strict data structures and MIDI channels.

Take MBSID V2 as an example: the full stuffed version allows to run 4 multi engines, each multi engine controls 6 voices, makes 24 independent voices. But there are only 16 MIDI channels - so, not only that the user has to define suitable channels and keyboard splitzones (to overcome the channel limitation) - has has to do this at both sides (synth and keyboard/sequencer), which makes the handling difficult, inflexible and error-prone.

With OSC you are working with pathes instead. E.g. voice #3 if SID2 could be addressed with /sid/2/voice/3, voice #6 of SID4 with /sid/4/voice/6

And now the power of OSC: by using wildcards, you can access a set of voices the same time, like: /sid/*/voice/* or /sid/2/voice/*

What I don’t like on OSC is (but I could have missed this in the past), that there is still no solution for a client to find out which parameters are supported by an OSC server.

Or in other words: wouldn’t it be nice if you plug a MBSID and MB64E together, and MB64E would automatically get a list of all parameters on a standardized way, so that you only need to assign the named and characterized parameters (resolution, center value, long and short name, button behaviour) to the faders, knobs and buttons?

And that the same would work, when you select other servers from MB64E like your favourite host sequencer or VST instrument without changing the cabling?

If such features would be supported by the protocol, it would be a killer argument against MIDI. So, does anybody know more about this topic?

Best Regards, Thorsten.

11

Hello!

Very interesting topic!

TK:

I don’t see any way to handle the parameter declaration in a standard way using only OSC. However, and this is the power of the LAN, you could easily imagine a protocol stack to handle that and many more case. Here is what would be the puzzle pieces:

  • The parameters and capabilities of the device would be expressed with RDF (Resource Description Framework) as a description document.

  • Discovery of OSC devices on the LAN would be made through ZeroConf/Bonjour or another discovery protocol.

However, it seems there is already an upcoming protocol stack for doing all that. It is the future replacement of DMX which is called ACN (Architecture for Control Networks - http://en.wikipedia.org/wiki/Architecture_for_Control_Networks). But it is really lot more effeicient and broad than DMX. It can be used (and will surely) to control audio devices from audio consoles.

I’ve yet seen only 2 spotlights compatible with ACN at the last SIEL but there might be a lot more arriving this year. And also some consoles and software are said to be ACN compatible.

The question is how to things like this based on the MBHP. It appears handling all the Ethernet/protocol stack with the PIC is completely imaginary. But i imagine that MBHP core could communicate through CAN with a very little PC board, embedded in the midibox, running linux with an ad hoc driver and software. However i can’t figure out how the CAN bus could be connected to the PC. Could give me your views on this ?

(Edit) A bit more on ACN. It is divided in three parts: Configuration, Test, and Control :

  • The Control part is similar to ArtNet and OSC, and is the part of the protocol highly optimized to be used during performance. I think one could an analogy  to MIDI’s short messages in terms of efficiency.

  • The Configuration part enables to configure remote equipment. Here you get discovery, parameter descriptions and al. It is only to be used before performance and is as efficient as MIDI sysex.

  • Finaly the Test part is to enable reporting of device failures. For example a spotlight could report its bulb is dead.

I think all this could open lots of new applications for MidiBox! :slight_smile:

Regards, Didier.

12

Thanks for the input!

Seems that ACN really is a step forward. I especially like the clear separation between control and configuration part, so that each package type is optimized for its purposes.

However, it depends on the audio software industry, if they are starting to support such a new protocol or not. And before this doesn’t happen, it doesn’t make much sense to build up a MBHP based infrastructure…

At the technical side, you are right - such complex protocols shouldn’t be handled by an 8bit controller, 32bit is a better choice. There are many ARM development boards available which support CAN (sometimes with multiple nodes for parallel networks), but there are also CAN-to-USB and CAN-to-Ethernet bridges (which are mostly ARM based as well…)

Just got a quick idea: did you know that some Linksys routers are running under embedded Linux, and that the firmware can be easily modified - see also http://openwrt.org/

Assumed that there are some unusued IO or interface pins in this router, it could be possible to add a MBHP_IIC_MIDI or CAN controller interface to this device. It would be the cheapest MIDI->Ethernet or MBNet->Ethernet bridge ever — and it would support WLAN by default :wink:

Best Regards, Thorsten.

13

thorsten,

your specific question about finding out the parameters offered by a server seems to be covered theoretically, I found this reference on the cnmat.berkley.edu site:

“Query system to dynamically find out the capabilities of an OSC server and get documentation”

Now I will dive into google to look for a real-world implementation of this feature…

regards, karl.

14

i cant contribute on the subject, but am reading this with interest. It´s posted above that midi propably won´t be overcome. Just the same with many old technology. People want to relai on what they´re used to, musicians are especially conservative maybe.

But everyone knows the old technology is really overcome.

I have hated midi many times for the reasons tk explained. Simultanius switching of channels… That´s doing the same thing over - just what computers are supposed to save us from. That can kill a studio.

But on the other hand, midi does all the things you need, but many devices don´t use the possibilitys. When i look at how the midibox lcs are comunicating and interacting with the software - that´s perfect!

But almost all of the midi stuff and software out there doesn´t act like that. (the projects here proof better!!)

Then i look at stuff like the virus ti and i think: it´s the future. 

15

TK:

I had a LinkSys WAP54g and a friend of mine has made it run openWRT for years now (until it died in fact ;)) and it worked like a charm. However we did not open the box to look at what it’s in it.

As for ACN and audio manufacturers, i just think that having standard Ethernet you can just handle the protocols you need OSC, ArtNet or ACN in the future. But nevertheless, i have faith that ACN’s support by audio manufacturers will grow in the year, pushed by the light ACN-enabled devices. This one should be easier than the entry of AES50 in the market (despite it is better than Ethersound).

Your CAN-to-USB and CAN-to-Ethernet bridges suggestion are nice. (I’ll dig first in this direction) However, as i already need to embedded a PC-grade computer in my midibox (to handle two touch screens), i was wondering whether it would be possible to connect that PC directly to CAN and avoid yet another controller chip in between.

Regards, Didier.

16

You can get CAN-PCI cards sure, but they ain’t cheap :frowning: and of course there’s another micro on the card, you won’t avoid that :wink:

Chances are you don’t need a PC to do it, and you could DIY it on a micro for sure, I’ve pointed out the Make core module before, it comes with CAN and OSC out of the box, ready to go. Be prepared though, it’s a heck of a jump in price from an MBHP core :wink: (US$149 for a kit)

I guess that’s the trick with so many of the ‘futuristic’ stuff around, DIY becomes difficult and expensive when you are talking about that kind of hardware (32bit, FPGA, SMD IC’s, etc)

I’d be surprised if there’s not an OSC implementation on a useful IC… Let’s see what Google has to say… darn, no Propeller :frowning:

Engin Karabulut has ported uIP 0.9 to the Microchip PIC 18F452, using the Salvo RTOS and the HITECH PICC18 Compiler. The code also includes drivers for a Realtek 8019AS compatible ISA NIC, a HD44780 compatible LCD, and a Maxim DS75 I2C temperature sensor. Download from here.

http://www.geocities.com/engink_projects/uip/uip.htm

That uses an 8-bit PC NIC as an ethernet interface to the PIC. That was via http://www.sics.se/~adam/uip/ports.html … uIP looks interestingChoose your platform… make an OSC client… There’s a SDCC compiled Z80 version, between those two examples anyone with some C skills and lots of time could port uIP to MIOS and use MBNET for IO to a MBHP Core… But I doubt it’d have the grunt…

Links to read:

http://www.makingthings.com/products/KIT-MAKE-CTRL/

http://www.nabble.com/Embedding-OSC-t1072989.html

http://www.interaccess.org/aid/list/msg00762.html

http://www.atrox.at/projects/877eth/index.html

http://www.piclist.com/techref/microchip/tcpip.htm Those 3c509 cards were everywhere

http://opensoundcontrol.org/spec-1_0

Sorry for the half-written semi informative post :-\

17

Not in the least!

Your google-fu is strong  Oh Stryder.

18

I gathered some additional information regarding thorstens earlier question:

“…What I don’t like on OSC is (but I could have missed this in the past), that there is still no solution for a client to find out which parameters are supported by an OSC server…”

here is a pdf paper from 2004 on exactly this topic:

http://a2hd.com/query-system-open-sound-control

but the names added just recently this comment:

“…This work will be superceded by a forthcoming publication on recommended practice for integration of Open Sound Control with Web Services. The material is provided here for historical purposes…”

along this line a found a thread in the OSC-forums, where the query mechanism within OSC is declared “flawed”:

“…However, my current line of reasoning is that putting the query  system into OSC is technically flawed for a number of reasons (e.g.  violates the state-machine-free requirement and also needs assured  delivery), and furthermore is a redundant effort because query  systems have already been defined in more appropriate meta-languages  and are already sufficiently expressive for our requirements (e.g.  web services)…”

another interesting finding for me was “Open Sound World”:

http://osw.sourceforge.net/

this really seems useful to work with OSC on a practical level, I will try this out for sure:

http://osw.sourceforge.net/html/osc.htm

my next links points us to OSCULATOR:

http://www.osculator.net/wiki/Main/HomePage

although it looked promising at first sight, it is MAC only, and does not support MIDI input, just midi output…

there is an interesting free plication called CPS, they also have (basic) OSC implementation:

http://cps.bonneville.nl/manual/appena.htm#OSCparam

finally (ta taaa!), here is a library with the “best match” for thorstens remark:

http://wosclib.sourceforge.net/doc/index.html

they provide several complex methods, one is “callback list”:

http://wosclib.sourceforge.net/doc/index.html

to me this sounds exactely like “polling an OSC server for its available methods”

of course, I will also look into CHUCK and PD, but I do not think they have the query mechanism implemented. BIDULE could have this, but it is not free any more, and I do not want to shell out 69€ just to find out what it can NOT do..—))))

best regards, karl.

19

from the ever-evolving thread about the LIVEAPI over at the ableton forums, here are the OSC commands which the MONOME can handle at the moment:

QUOTE:

OSC Out:

/box/press

OSC IN:

/box/led

/box/led_col

/box/led_row

/box/alloff (same as /box/clear I assume)

/box/intensity

/box/shutdown

/box/test

In my OSC implementation (monochrome vst), besides box/clear on startup (to quickly blank all 64 LED’s), I only use the two “most important” messages (/box/press and /box/led) which both have 3 ints following (x,y,bool state), e.g. “/box/led 0 0 1” (enables top-left LED)

UNQUOTE.

so this leaves me with the impression of a VERY simple box, again…

regards, karl.

20

I know most of those wireless routers have at least two serial ports inside, on the chip or even out to pads.

One is generally used as a terminal by some hackers…

I have even seen WRTs used as robot brains..  With some code bending, Im certain a midibox could be hooked up to one..  getting anything really usefull out of it would require quite a bit more code bending.. would make an interesting project: Wireless Midi server