Hi,
I have two questions on Dorico’s foreseeable future: Are there any future prospects for Dorico to implement Open Sound Control (OSC) as a protocol? And are there any future prospects for it ever being possible to work directly in Midicents?
Any hints or insights on this would be most welcome.
All the best,
António
The OSC spec is still at version 1.0 written 17 years ago. The links to the “best information” about version 1.1 on the “OSC official website” http://opensoundcontrol.org/introduction-osc are broken.
The last post on the OSC development forum was about 7 years ago. The links to the devs mailing list and archives on the official website are broken.
The latest of the “new applications” links is dated 2011.
Apart from one link about a computer game engine dated 2017, all the links to applications on the official website are from 2011 and older (and in some cases, 10 years older).
“Dead in the water” seems a reasonable description of it.
Midicents are just the French (or maybe IRCAM’s) name for “cents”. Dorico already uses them to define tonality systems.
Rob, OSC is definitely not dead in the water, quite the opposite… Steinberg DAWs have it: Nuendo has it, and I’m pretty sure Cubase has it too. Besides nearly every other top player in the DAW market has implemented it: ProTools, Ableton Live, Logic Pro X… and on, and on. And more and more applications of OSC appear with every passing day, week, month…
Midicents is the translation of Midi that allows for the numerical representation and implementation of, you guessed it, cents between Midi notes. And so, 0 … 127 becomes 0 … 12700 — that’s the crux of it. If the possible, and many actual uses and applications, escape you…
The truth of the matter is that on both counts, you are wrong, and quite crudely so.
Respectful discussion, or incendiary jab? There’s plenty of forums on the internet that are filled with the latter.
Incidentally, this sounds very similar to the recent discussion of whether Finale is “dead.” As I recall, there was a disagreement over whether “dead” meant “nobody’s using it” or “nobody’s developing it.”
Incendiary jab, Dan?! With that expression you quoted, which is innocuous both in form and content, I just qualified how far off the mark most of his statements are… He is not somewhat wrong, he is quite crudely wrong.
We have no current plans to implement support for OSC in Dorico, but I would certainly not rule it out for the future if there is sufficient demand.
Thank you, Daniel. These past few weeks have drawn a clear-cut picture of Dorico as a commercial venture, what is its scope, what are its aims, who constitutes its niche market, and where it’s heading… It was fun, even funny at times.
One last remark, Daniel, concerning the representation of pitch content in Dorico. Dorico allows, foundationally, the representation of pitch at least in 12000 EDO… As a spectrally-minded musician, the fact that I can’t work directly with pitch content even in Midicents (when Dorico’s precision level is at least ten times greater) is mind-bending as a waste of potential. It would be great if it was possible to import/export pitch content in Midicents (and even in 0 … 127000, given Dorico’s precision level), both for compositional and data visualization purposes — a simple format like CSV could easily accomplish this.
And no, this isn’t meant as an indictment of Dorico or its aims or its scope, this is yet again the remark of an end-user of Dorico who has been trying to branch Dorico, as thoroughly and plentifully as he can, into his multi-platform and multi-layered composition toolkit. Data flows are essential to it.
I would also like to see OSC support, specifically for better integration with Max for score-following situations in live performance. The idea is that one would press play in Dorico, and Dorico would fire off the specified OSC values at the specified moments in the playback. Of course this requires the operator to monitor the situation and press pause if the Dorico playback gets ahead of the performers. At the moment I am able to do this using unpitched percussion in Dorico to send MIDI to a Max patch (entering notes that act as event triggers), and Max then converts the MIDI data to internal Max messages or OSC. I end up needing a very large “percussion” battery if I have a lot of discrete messages that I want Dorico to send.
Since OSC / VST bridges already exist, what do you really need that isn’t in Dorico already?
Hi Rob,
There is one OSC/VST bridge but it has been out of development for many years and I believe is only 32-bit. I am pretty sure I tried it before and it was very buggy - I wouldn’t want to rely on it. Even if there were such a thing, it probably wouldn’t be as convenient as using a built-in function. The bridge you you refer to is also more suited towards automation (ex. using the automation lane to send floating point values).
Instead, I would be more interested in something like this (screenshot from another notation program):
Those are Max messages, not OSC, but it is a very similar idea. Basically, it would be nice to be able to send certain values (string or integer or floating point) to certain user definable OSC addresses at specific points in the music. Play mode might be a more obvious place to have such commands of course instead of appearing in the score like the above example.
Mducharme, I don’t know if you’re interested in seeking other alternatives, and you may even know them already, but just in case:
IRCAM’s Antescofo package, Ghisi and Agostini’s bach package (you can install its latest stable version through the Package Manager) for Max/MSP.
Or, if you’re in for fine-grained, minutely detailed graphical scoring/sequencing with great support for both MIDI and OSC, there’s also IanniX.
All of the above are great, and free.
Thanks - yes, I am already familiar with all three. For score following, of course Antescofo is great, but I’m also looking at things from a workflow perspective. I like to be able to compose directly in Dorico and write the live electronics at the same time (without having to do a lot of back and forth, ex. export from Dorico->import to Antescofo, repeating the process every time I make revisions). The current unpitched percussion workaround that I’ve come up with allows me to do that, and then I can route the audio from Dorico into Max and have Dorico automatically trigger the specified actions in Max synchronized with the playback so that I can get a better idea of the overall result as I am writing. OSC support would be even nicer, of course.
I know what you mean, mducharme. Actually, that’s part of what I meant in a previous comment on this thread: “Data flows are essential to [my composition toolkit].”
Yes. As one example of a crazy workflow, a few years ago before I switched to Dorico I wrote a piece for piano and live electronics. I wanted to be able to compose all elements simultaneously, and it took me forever to find a solution. I had to have Sibelius connected via Rewire to Reaper which in turn connected via Rewire to both Cubase (where I composed the bed tracks) and Max, basically using Reaper only as a Rewire hub or router of sorts. It took me forever just to figure out how to even get it working before I could start composing. In that case I was doing very limited processing in Max that just affected a few sections of the piece. It would have been even harder if I had to keep triggering different things manually as I was listening to it. It is just too many hoops to jump through.
I’m afraid you have a misunderstanding of how ubiquitous it is now. Essentially, all modern live electronics works utilize OSC.
It is a fairly simple protocol, essentially comprised of name-value pairs where the names are hierarchical, with different levels separated by slashes. The names themselves are essentially arbitrary, and the standard does not attempt to prescribe a preferred naming scheme. The lack of development since 2011 is simply because the format is so simple, adaptable and well established that it needs no further revisions. OSC usage is heavy and widespread. If OSC did not exist, you essentially could not compose a live electronics work in the modern day.
The protocols that run the internet have been around for 30 years without significant recent changes. Does that mean they are dead? Of course not. We rely upon them daily. Protocols are different from software programs. If a software program has not been updated in 7 years, you might be able to make the assumption it is dead. If a protocol is not updated in 7 years, it may in actuality be far from dead.
I would be interested to learn more about what your ideal envisioned support for midicents (feels odd to write that in all lower-case, very French) would look like, António. I can’t promise it’s something we can jump on right away, but if you could tell me how you would like this to fit into your workflow, we will certainly consider it. With OSC I think I already have a reasonably clear understanding of the requirements, but I am less familiar with midicents.
+1 for OSC someday. It’s not very high on my wishlist priority though.
Sending OSC events from a stave would be nice in the short term, but not a huge priority for me.
On receiving them…It would seem this sort of remote control support won’t be all that useful unless Dorico also adopts some sort of VST automation lanes, intended to do live mixing/tweaking while the score is playing as well. Otherwise, how does one connect the events to specific registered controls, and record/play back the tweaks in sync with the project? If we’re just going to ‘transform’ OSC events into standard CC events, and vice verse, then we already have some fairly robust third party options for that (Bome, Bidule, etc.).
Currently, OSC support is something I don’t need very often for a Dorico project. If I do, I kludge it in using Bidule. One example is the ability to do some basic routing (to different rooms/head-phones/monitor setups) and volume controls using a wireless tablet device. In this scenario I can put an instance of Bidule in the last main effect slot of Dorico’s mixer. From there I can send streams to different locations using reaStream, each with independent volume control. I can use a virtual port assigned in the Bidule instance to filter out and pipe transport controls back into Dorico. Bidule does the OSC server/client thing, and can control an audio stream matrix using tablet based OSC apps connected to the WiFi.
If I wanted to drive lights or something using a Dorico stave over a network, it could be done with rtpMIDI drivers, and if OSC is needed/preferred, a bidule instance running as a VSTi.
Daniel, thank you for considering it. In order to work with Midicents while writing and editing a score, I often appeal to a Max/MSP patch such as the one in the attached screenshot — in this case, it imports a text file with pitch content in Midicents, and allows me to notate it in 12 EDO, 24 EDO, 48 EDO while keeping the background-independent pitch content always available (actually, you’ll notice that it allows for a representation of pitch in 12000 EDO), and then export it as a MusicXML file:
I accept it is still there being used, but it seems like a child of its time, just the same as notation programs that were built around the physical appearance of the music on the page were children of their time.
Trying to locate the OSC protocol somewhere in the OSI 7-layer networking model, it seems to be down at about level 3, not at the application-layer level 7. Apart from node names (which as mducharme says are arbitrary) and time stamps (which are not guaranteed in any way - there are no requirements for different devices to have synchronized clocks for example) there are basically no predefined semantics to the messages.
It’s not a perfect analogy, but saying “I want Dorico to support OSC” is a bit like saying “I want Dorico to support email.” We all know what email is, but the first response to that request would most likely be “OK, what exactly would you want to Dorico to do with email?” And if the answer to that was something like “Well, when I save a project I want to automatically mail a message to a contacts list stored in the project info, telling people there is an updated version available” the discussion would be getting somewhere, because it is then about the semantics of what you want to do, and the fundamental design of Dorico is all about semantics.
If there are some shared semantics between the OSC data used by different hardware and software devices used for live electronic music, then IMO that is what you really want Dorico to support - not just “OSC”.
The basic difference between OSC and say Rewire or MIDI is that Rewire and MIDI messages do have predefined semantics for the data that is being networked. Of course you can subvert those semantics if you want (in principle you could build a driverless car using MIDI messages for all its internal communication, if you felt so inclined) but IMO the point is that Dorico can “support MIDI” or “support Rewire” without knowing or caring about that.
If MIDI CC1 controls the gas pedal of a car and CC10 controls the steering, so far as Dorico is concerned it is still just MIDI controller data. But with the bare OSC standard, a “message” is just a lump of binary data - even the most basic semantic information to say whether represents an integer, a character string, or whatever is optional.
