OSC question
Jon Szanto
What does OSC have to do with microtunable synths?
I keep seeing OSC pop up here as one of the protocols to get playback
going. From what reading I've done tonight, it appears to be a very
new protocol and seems to have a lot more to do with external control
devices. I can't figure out how it fits into the picture.
Mike has posited that we start with support for OSC and MTS. I don't
have a single frickin instrument that supports MTS (as far as I know),
and I have a *lot* of hardware and software instruments. How in the
world is this going to be an application for general use in this
sense???
Mike Battaglia
based on what people were saying, that there were synths with OSC
support.
Jon, either way, those were just ideas. The real point was that we
have flexibility of design. We have the event list and we can output
it however we want. The main thing is that we're not tying the event
list down to MIDI. Carl posted a huge list of instruments that
supported MTS a while ago on the original "Composition Software"
thread that I made on MMM. I'm not sure if all of those really have
MTS, but some of them do.
I suggested using only MTS and OSC or something straightforward like
that (i.e. not pitch bending and channel swapping) for the first
version because at least we'll be able to have a working sequencer. If
we really want to get at compatibility with other synths that don't
support MTS, pitch bending and channel swapping is one way to do it,
and I'm sure it's not the only way.
Just to get the core done, I suggested only MTS and OSC simply to have
something that works. As for other ways besides those two to implement
microtonal playback... We need to carefully examine how people are
doing it NOW, and see what parts of the process we can automate. Do
people use Scala files, for example? Then if we make it so the
software can read Scala files, we load the same file into the software
that we load into the synth.
You are correct in stating that coming up with completely revamped
underlying technologies to handle microtonal playback is too lofty of
a goal for right now. And that never was my goal - I only want to
round up what we have now into one complete package, which in and of
itself is enough of an improvement over what I've got that I'd find it
useful.
The technologies we have right now, as far as I know, are MTS, OSC,
Scala files, and MIDI with pitch bends and channel swapping - is there
anything else that people do? And if by the time we have all of that
implemented, Yamaha meets up with Roland and drafts a brand new
microtonal spec and all of the new synths are using it, then we'll add
that too. Adding different MIDI-esque output engines is simple with
the model I've been using. It's as trivial as following the spec.
It's, in a sense, as easy as writing a "plugin" to read the events
list differently. There are going to be a few extremely complicated
parts to this project, but formatting the output data shouldn't be one
of them.
The question is, how much of this should we tackle as part 1 of this
project, and how much is stuff to worry about later?
-Mike
Mike Battaglia
short, it ends up being long. :P
I really don't think it's possible to condense this discussion into
short posts. I'm trying the best I can here. I lack the relevant
skillset, perhaps.
Either way, I'm going to bed. Good night, sir.
-Mike
carl
-Carl
Jon Szanto
Carl said "We're relying on 3rd party synths for audio production.
The
notation editor needs to send signals to the synth(s). MIDI
is one way to do that, OSC is another. MIDI will require the
user run multiple instances of synths in some cases, due to
the 128 note wall. OSC doesn't have that limitation, but I
only know of two synths that support it, and I don't know if
either of them support it enough to make it work microtonally.
But it's the only alternative to MIDI, and supporting it would
perhaps help it along. There seems to be a real desire on the
part of synth makers to support microtonality, and they all
recognize the limitations of MIDI for doing so. If there were
an application producing a microtonal OSC stream, we might see
synths crop up to support it in relatively short order."
OSC/MTS aren't a viable solution for me. I hardly see the point of an
application that will force me to purchase/gather *another*
application (a synth/sound device) just to enable listening to the
playback. I don't have a single instrument, soft or hard, that
supports MTS, even though I have at least half a dozen or more
softsynths/VSTi that support microtuning via either .scl or .tun
files.
Notion includes playback.
Finale includes playback.
Sibelius includes playback.
I don't know the answer, folks, other than one suggestion I made:
there are a couple people with connections to MMM that have created
microtunable VSTi, and if one could find some decent code for basic
VST hosting, you could have someone write a Very Simple Instrument
(hell, sine or square waves or something!) that would be internal, and
could at least give you aural feedback as to what your score is
sounding like.
I need something like this. My stuff sounds like crap so often I'd
like to stop writing a piece as soon as I know it sucks. :)
carl
> Notion includes playback.
> Finale includes playback.
> Sibelius includes playback.
mean is "bundle". They bundle a single synth with the app.
You (Jon) already more than one synth like this. Why
do you want us to write another one?
I don't plan to implement MTS, but why, may I ask, is it
not good enough for you (other than the 128 note limitation)?
> I don't know the answer, folks, other than one suggestion I made:
> there are a couple people with connections to MMM that have created
> microtunable VSTi, and if one could find some decent code for basic
> VST hosting, you could have someone write a Very Simple Instrument
> (hell, sine or square waves or something!) that would be internal, and
> could at least give you aural feedback as to what your score is
> sounding like.
or something?
-Carl
carl
Tonescape died.
-Carl
Jon Szanto
> > Notion includes playback.
> > Finale includes playback.
> > Sibelius includes playback.
>
> And they all use MIDI to do it. By "includes", all you
> mean is "bundle". They bundle a single synth with the app.
> You (Jon) already more than one synth like this. Why
> do you want us to write another one?
use get:
- set to a new tuning via a tuning file
- accept the standard 128 MIDI notes, which then trigger the
associated MIDI note on the synth (which does *not* then create the
12tet note that might have been associated with that MIDI note number,
but an arbitrarily tuned note).
That being said...
> I don't plan to implement MTS, but why, may I ask, is it
> not good enough for you (other than the 128 note limitation)?
already got a couple of instruments, so within the 128 note limit, I'm
still ok. But this isn't just for me - I was thinking about an
absolutely new user. I know *you* are well aware of the problems with
pitch bending through MIDI for implementing microtonality, so I don't
need to reiterate. Mostly, I guess I haven't gotten a clear idea of
how the team plans on having aural feedback, but that may be TBD
anyway.
Nonetheless, as a standalone app, I'm guessing you are going to have
to state in the requirements, besides the OS, some sort of sound
module. Am I on the right track now?
> Are you allergic to running two apps at once on your OS
> or something?
some of the more complex situations I run include Sonar, energyXT,
Bidule, and maybe another one or two, plus hosted VSTs. My impression
was the notation editor was a one-stop shop, and it may simply be that
I was confused. Two days of paint fumes can do that.
Hope that clears up at least some of this. Frankly, I don't know how
much I'd ever *use* this notation editor, but that is hardly the
point; I think there *are* a lot of people that could use it, and
*that* is why it interests me.
Jon Szanto
carl
from their successes and failures. I told Joe he'd get
bogged down in synthesis, and that came true.
-Carl
carl
> > > Notion includes playback.
> > > Finale includes playback.
> > > Sibelius includes playback.
>
> > And they all use MIDI to do it. By "includes", all you
> > mean is "bundle". They bundle a single synth with the app.
> > You (Jon) already more than one synth like this. Why
> > do you want us to write another one?
>
> I guess I thought it was pretty transparent, sorry. All of the ones I
> use get:
>
> - set to a new tuning via a tuning file
> - accept the standard 128 MIDI notes, which then trigger the
> associated MIDI note on the synth (which does *not* then create the
> 12tet note that might have been associated with that MIDI note number,
> but an arbitrarily tuned note).
> > I don't plan to implement MTS, but why, may I ask, is it
> > not good enough for you (other than the 128 note limitation)?
>
> Let me try this: "It's not all about me!" Seriously, yeah, *I've*
> already got a couple of instruments, so within the 128 note limit, I'm
> still ok. But this isn't just for me - I was thinking about an
> absolutely new user. I know *you* are well aware of the problems with
> pitch bending through MIDI for implementing microtonality, so I don't
> need to reiterate. Mostly, I guess I haven't gotten a clear idea of
> how the team plans on having aural feedback, but that may be TBD
> anyway.
> Nonetheless, as a standalone app, I'm guessing you are going to have
> to state in the requirements, besides the OS, some sort of sound
> module. Am I on the right track now?
> Hope that clears up at least some of this. Frankly, I don't know how
> much I'd ever *use* this notation editor, but that is hardly the
> point; I think there *are* a lot of people that could use it, and
> *that* is why it interests me.
-Carl
akjmicro
experience with it at all, or understand the protocol?
-AKJ.
thor
Carl said "We're relying on 3rd party synths for audio production.
The
notation editor needs to send signals to the synth(s). MIDI
is one way to do that, OSC is another. MIDI will require the
user run multiple instances of synths in some cases, due to
the 128 note wall. OSC doesn't have that limitation, but I
only know of two synths that support it, and I don't know if
either of them support it enough to make it work microtonally.
Jon Szanto
carl
-Carl
carl
than they could chew on a number of fronts? If so, they
were planning more than they could handle, but they actually
implemented the most important stuff first, which was good.
And the app as it stands is pretty impressive.
-Carl
Jon Szanto
inclusion of synthesis that killed off that project, mostly to support
your thinking this might happen here as well.
But you know what? In the end, it doesn't matter much. I'll move on,
let's move on to other tasks.
MDK
> Regarding OSC, I'm curious---has anyone used it? Does anyone here have
> experience with it at all, or understand the protocol?
Yeah, like Carl said I do understand OSC. Conceptually its quite simple and just
takes a couple of days to figure out. Programming encoders and decoders is a bit
more complicated but its not hard, also there are a number of existing libraries
for dealing with OSC so that in itself isnt really a concern.
For me the important aspect would be to define a protocol on top of OSC because
OSC itself doesnt define anything specifically related to audio or music it just
defines an addressing scheme and how to format data for transport from one place
to another.
I sent a link in an earlier email which has ideas of how to control synths via
OSC which takes microtuning into account :
http://stud3.tuwien.ac.at/~e0725639/OSC-SYN.txt
So something like that can be used for tuning and triggering instruments.
Then the other side is the possibility of making various bits of API available
as OSC commands so each tool is open to communication from anywhere : other
tools in the toolset we're trying to establish here, from existing OSC capable
tools (reaktor, plogue bidule, super collider, max-msp) and also directly from
scripts and code that anyone wants to create for themselves.
Graham Breed
> I don't know the answer, folks, other than one suggestion I made:
> there are a couple people with connections to MMM that have created
> microtunable VSTi, and if one could find some decent code for basic
> VST hosting, you could have someone write a Very Simple Instrument
> (hell, sine or square waves or something!) that would be internal, and
> could at least give you aural feedback as to what your score is
> sounding like.
We can embed Timidity or FluidSynth or something. Not a big
deal. Not something we need to discuss now.
Graham
carl
> deal. Not something we need to discuss now.
>
> Graham
MDK-- If we came up with a microtonal version of MIDI and implemented
it in OSC, would Reaktor be able to play it? Or is Reaktor just
implementing OSC for knob automation and such?
I get the sense that OSC is so vague that no synth will be able to
use it as a MIDI replacement without an additional standard on top.
Is that wrong?
-Carl
MDK
>> We can embed Timidity or FluidSynth or something. Not a big
>> deal. Not something we need to discuss now.
>>
>> Graham
>
> Agreed.
>
> MDK-- If we came up with a microtonal version of MIDI and implemented
> it in OSC, would Reaktor be able to play it? Or is Reaktor just
> implementing OSC for knob automation and such?
OSC ends up in Reaktor as any other event data. Reaktor does have some
limitations in its OSC implementation which I cant remember off the top of my
head, but i think its something stupid like no strings in the data section and
no bundles.
But for doing something like transmitting tuning tables or note events its got
everything you need.
> I get the sense that OSC is so vague that no synth will be able to
> use it as a MIDI replacement without an additional standard on top.
> Is that wrong?
No, thats absolutely correct and I think this an area which needs to be dealt
with so that anyone creating an instrument (hardware or software) and who is
considering OSC can find that the hard work is done. Then they can just pull the
bits they need 'off the shelf' and we all live happily ever after in a world of
microtonally capable instruments where MIDI is but a distant and sordid memory. :)
Martin.
thor
I get the sense that OSC is so vague that no synth will be able to
use it as a MIDI replacement without an additional standard on top.
Is that wrong?
No, thats absolutely correct and I think this an area which needs to be dealt
with so that anyone creating an instrument (hardware or software) and who is
considering OSC can find that the hard work is done. Then they can just pull the
bits they need 'off the shelf' and we all live happily ever after in a world of
microtonally capable instruments where MIDI is but a distant and sordid memory. :)
Mike Battaglia
Certainly looks easier to deal with than MIDI for microtonal stuff,
unless MTS support is there from the outset. I think the sequencer at
least should support it, just because if anyone does come along and
tries to program a synth with OSC support, we've already got it
covered.
As for the score editor, if all an OSC implementation requires is to
write an alternate output engine to deal with the sequential list,
then I don't expect it would be too much of a problem. Might be
something someone focuses on in a separate branch.
-Mike
carl
> So in my view it's nice to have a standard like the one MDK pointed
> to:
> http://stud3.tuwien.ac.at/~e0725639/OSC-SYN.txt
> but this can never be exclusive. It will have to be open and
> flexible with room for many additions (hardware changes etc.). So the
> problems there are abundant.
trying to read this list on the web, and if so, have you found an
easy way to get all the posts since your last visit in one place?)
Am I missing something, or is there no 'note' abstraction in
this thing? I don't see how the music gets played.
-Carl
Jon Szanto
> (Is anybody else
> trying to read this list on the web, and if so, have you found an
> easy way to get all the posts since your last visit in one place?)
Seriously, yes, and no. Be nice if this were vBulletin or something,
but you got it up and running fast, I'll deal.
Mike Battaglia
kind of subforum thing. If this project gets complicated enough, I'll
set one up.
Being as this this list is about making micro tools, and since it's
inevitable that there is going to be more than one tool we're making,
at some point some further organization and subforuming will be
necessary anyway.
-Mike
Torsten Anders
advantage over MIDI: MIDI note pitches are limited to 0-127. In OSC,
the pitches can be floats. For example, you can specify 60.5 to mean a
quarternote above the MIDI pitch 60 (middle C). This means that you
can specify any microtonal pitch with a single note message -- you
don't necessarily need something like pitchbend.
In general, the advantage of OSC is that the user can define what the
messages mean (as with the pitch spec above). On the other hand, this
can also be a disadvantage, because there exists no fixed/standard
mappings as for MIDI.
Nevertheless, the protocol is relatively easy to understand. As a
user, you don't need to know the binary representation (as you don't
need to know that for using MIDI). But even including these details,
the spec is rather short, see http://opensoundcontrol.org/spec-1_0.
There exists a range of sound synthesis software which understands
OSC, see http://en.wikipedia.org/wiki/OpenSound_Control for an
incomplete list. BTW: many of these applications are open source and
freely available.
Best
Torsten
Daniel Wolf
wrote:
> For microtonal music, Open Sound Control (OSC) has a very important
> advantage over MIDI: MIDI note pitches are limited to 0-127. In OSC,
> the pitches can be floats. For example, you can specify 60.5 to mean a
> quarternote above the MIDI pitch 60 (middle C). This means that you
> can specify any microtonal pitch with a single note message -- you
> don't necessarily need something like pitchbend.
>
Two very early music languages -- both in FORTH -- Formula and HMSL --
allowed for decimals past the midi pitch number to control pitch bends.
djw
Mike Battaglia
>> advantage over MIDI: MIDI note pitches are limited to 0-127. In OSC,
>> the pitches can be floats. For example, you can specify 60.5 to mean a
>> quarternote above the MIDI pitch 60 (middle C). This means that you
>> can specify any microtonal pitch with a single note message -- you
>> don't necessarily need something like pitchbend.
>>
>
> Two very early music languages -- both in FORTH -- Formula and HMSL --
> allowed for decimals past the midi pitch number to control pitch bends.
This is sort of how MTS works, but support for it is pretty limited right now.
-Mike
Torsten Anders
Sure, many formats support this (synthesis systems where users freely
define the meaning of parameters like Csound scores, and also several
compositions systems like Common Music, PWGL's ENP, ...).
The advantage of OSC, however, is that you can use it much like MIDI.
You can send it in realtime to many applications (including
commercial apps like Reaktor), even across the network.
Best
Torsten
--
Torsten Anders
Interdisciplinary Centre for Computer Music Research
University of Plymouth
Office: +44-1752-586219
Private: +44-1752-558917
http://strasheela.sourceforge.net
http://www.torsten-anders.de
MDK
He uses the concept of a 'voice' rather than notes :
In the SYN proposal, you don't turn on notes, you turn on voices which have got
a note or frequency argument. The big advantage of this system is that you can
e.g. have as many 'c3' notes playing as you like, each one with different filter
cutoff values set.
Then he defines a selection of voice commands with features like absolute or
relative pitch, velocity, volume, pan and arbitrary control parameters.
Although the paremeter section is something where I would say the same as Thor
in that rather than specifically mapping synth params to a non-meaningful
namespace (P1, P2 etc.. in his proposal) it would be better to have a system
whereby the you can discover the synth parameters dynamically and use the
appropriately named messages e.g. filter1/cutoff, osc1/pulsewidth etc..
Also what helps me to mentally tackle OSC from a technical perspective is just
to consider it another type of RPC (remote procedure call) albeit one where you
dont necessarily get a response.
From there its easy to imagine mapping an OSC namespace to an API which could
be generated dynamically either at compile time or runtime (or a mixture of
both..). Of course that leads into the realm of things like type conversion /
mapping and other fun stuff, but all those kinds of ideas can wait until there
is actually something more concrete to deal with.
Martin.
carl
different
tuning extensions to MIDI, which all work in different ways. See
http://www.midi.org
-Carl
MDK
If anyone wants to go straight to the technical details its here :