Why should I care about OSC support?

[beats me]

What am I missing out on here?

[t1mp]

The future.

*all I can really say to sum it up.

[beats me]

The future.

*all I can really say to sum it up.

So OSC is like an apocalyptic wasteland?

[t1mp]

The future.

*all I can really say to sum it up.

So OSC is like an apocalyptic wasteland?

lol, no I guess it is just a better platform to send massive amounts of messages for complicated interfaces. (lemur, monome, touchosc iphone) ie: The Future.

[beats me]

So it's like the difference between a dial up and high speed internet connection?

[t1mp]

So it's like the difference between a dial up and high speed internet connection?

I guess....if you want to equate that.

[Mesmer]

why should we care?

Let's see.

MIDI birth date: 1981
CPU Speed around that time: 10MHz
CPU maximum addressable memory: 1MB
CPU supported languages: IMUL, PUSHA, POPA, BOUND, ENTER LEAVE, INS, OUTS ...
CPU RISC?: NO
CPU x86?: YES 80186
(386 comes along 1986, 32-bit, supports modern OS)


Anything computer related from that era is so long gone ... it's not even funny.
That's not to say we should change standards every other year ... but almost 30 years Come ON!

[beats me]

I hear what you guys are saying but I'm not hearing anything specific that is going to revolutionize working on music and yet a lot of people are screaming for this.

[t1mp]

From what I have been told, the data bandwidth of OSC is huge compared to midi. I dunno, i guess a program called quadrants is a good example.

I can break my monome up into 2 big regions. One region controlling midi messages and another region controlling _mlr. With light feedback, from one virtual interface. Can you do that with midi?

[Mesmer]

Think about 8-bit.
3125 bytes/s is the maximum nominal bandwidth.

from wiki:

MIDI messages are extremely compact, due to the low bandwidth of the connection, and the need for real-time accuracy. Most messages consist of a status byte (channel number in the low 4 bits, and an opcode in the high 4 bits), followed by one or two data bytes. However, the serial nature of MIDI messages means that long strings of MIDI messages take an appreciable time to send, at times even causing audible delays, especially when dealing with dense musical information or when many channels are particularly active.

To further optimize the data stream, "Running status", a convention that allows the status byte to be omitted if it would be the same as that of the previous message, helps to mitigate bandwidth issues somewhat.

Some questions:
why 16 channels? why not 32 channels, or 128 channels?
why change values at a resolution that only allows 128 steps?

for more see:
http://www.linuxjournal.com/content/introduction-osc
and for the other side of the coin:
http://www.midi.org/aboutmidi/midi-osc.php

for me it comes down to:
Do I wan't to use my father's protocol? no, I want my own.

[Poster]

What am I missing out on here?

currently: nothing.. if you don't own an expensive toy like lemur..
future: saturated market of plastic controllers that do more than the current plastic knobs..

for sure it'll change the possibilities but essentially its like going from USB to FW..

[Tone Deft]

essentially its like going from USB to FW..

that's not accurate.

OSC is a similar messaging system like IP but it's designed for audio applications (it doesn't care if you drop a packet, it's more focused on staying in time.)

it's not limited to Lemurs and other pieces of gear you resent. max/msp supports OSC, so just having max lets you use OSC, so just computer to computer you can use OSC or even between max modules in one computer.

midi is limited to 32kbaud, 32,000 bits per second of data, OSC is not limited. it's more like going from a 32 kbaud modem to very fast DSL, that's not an analogy, that's what they really are.

OSC is also not limited by the number of parameters it can handle.


what does it mean with Live?
if the Abes assign OSC commands for every parameter in Live, one could make a simple max patch to control it by sending commands like this (this is all speculation):

launch.clip.1.2 <-- launches the second clip in track 1

control.bpm = 128 <-- change bpm to 128

control.fader.1 = 76 <-- change the volume of track 1 to 76

status.clip.1.2 = x <--- x = 1 if that clip is playing, 0 if it's not. which in turn could be sent to your own max GUI to turn an LED on or off on your screen.


people could very easily make their own GUIs for Live and only run Live for its sound engine.

I could finally make a proper looper because I could poll Live for
- global bpm
- quantize setting
- number of tracks
and set it to
- start recording on track x, clip y
- make all the loops the length of the first recorded clip
- set any clip into play or record mode
- etc.



did you read the OSC wikipedia page? it's been a while since I have IIRC that's what you can do with it.

[beats me]

So sounds like a programmers paradise (which I was already kind of thinking) but at this point in history not something I would be too excited about.

Something I've taken for granted in a very short period of time is switching from a mostly hardware setup to all software and no longer dealing with MIDI channels and limitations. I see my current setup as virtually limitless as is....except that damn CPU/RAM issue.

[dj_huck]

the thing i like about midi is it has been around forever. everything i have uses it and it works. is it limitless? no can i have a thousand increments for a knob? no do i need more that 128 possible knob positions for something ? i doubt it. it seems like osc is one of those things that has been just around the corner for a few years now but it has not really gotten into the market. of course if i had a lemur i would be screaming for it too

[Tone Deft]

So sounds like a programmers paradise (which I was already kind of thinking) but at this point in history not something I would be too excited about.

Something I've taken for granted in a very short period of time is switching from a mostly hardware setup to all software and no longer dealing with MIDI channels and limitations. I see my current setup as virtually limitless as is....except that damn CPU/RAM issue.

no, that's like Poster's response, putting OSC on the pedestal, like it's some unapproachable giant living on a mountaintop. same goes with max programming, it's not that hard, but you will not need to know max or own max/msp to use this.

you could, for example, go to the Covert Operators site, download a max object from them, open in the FREE max runtime environment, go into Live, set an OSC address like 128.120.20.1 and the max object would just work, you would do no programming. I could see Ableton making their own 'max runtime environment' where you would just open a .alo file (ableton live osc) with Live and the new Live OSC window would open showing the widget you downloaded.

when I asked Cycling74 at NAMM about all this being not DJ friendly (ie idiot proof) he got a HUGE smile on his face saying 'nobody will be diappointed.' what Ableton does will NOT be some geek toy, in hindsight it makes sense, it's software for performing musicians, not programming geeks.

I get such a hard on for all this... we could fix some of the 'broken' logic inside Live ourselves. (CovOps I'm looking at you!!) I could definitely make a Live looper that would simply just work, no input from the user required.