Thoughts on OSC in Ardour

"Guy Sherman" <[email protected]>
Newsgroups gmane.comp.audio.ardour.devel
Message-ID <[email protected]>
Hi All,

As some of you, who I've interacted with on IRC will know, I'm working out how to build an open-hardware, modular, expandable controller for Ardour. My plan is to use OSC. The general idea of the system is that it would have a centrepiece with transport and mastering controls on it, and then 1 or more channel strip modules, which are connected to the centrepiece via some sort of bus, yet to be determined. The centrepiece will have an ethernet connection, and will plug into the same network as the DAW PC, and it will talk OSC with Ardour.

There is a whole lot that you can already do with ardour and OSC, and a few things that can't be done yet, but wouldn't be too hard to put in.

From my perspective the two most important things that are missing are:
* Querying ardour about the mixer layout. At present you can get it to list the routes, but it doesn't tell you if tracks are created or deleted. I would need the ability to query the list of plugins for each route, and the list of parameters for each plugin.
* When listening to a route, you only get a few values reported about the route. I would like the ability to listen to any plugin parameter value as well as any other data (such as transport etc).
Now, there are obviously many ways to approach this problem, which is why I'm writing this email, as I don't want to start working on changes to ardour only to have them shot down later (better to have them shot down before I even start!).

Approach 1 - extend what Ardour has already, and tidy some of it up.

I think the simplest way would be to leverage the mechanisms Ardour already has for querying and listening (eg /routes/listen), and expand it so that any endpoint address can have /listen appended to it. One thing to change, though, would be that any messages ardour sends with the "#reply" address should have the address that triggered the reply as the first argument, so that the receiving end knows what the reply is in response to. That would bring Ardour roughly in line with the paper here: http://opensoundcontrol.org/files/osc-query-system.pdf

Approach 2 - HTTP+WebSockets-based OSC implementation

The problem with OSC at the moment is that there isn't really a standard for how querying should be performed or facilitated. When I asked the osc_devel list about it they pointed me here:  https://github.com/mrRay/OSCQueryProposal [https://github.com/mrRay/OSCQueryProposal].

This would involve adding another layer into Ardour, using http and web sockets. The main advantage of this approach is that the queries could return single responses with much larger messages wrapped in JSON. This makes querying simpler from the client side, but would clearly be more work to put into Ardour. On the other hand it wouldn't have to change any of the existing UDP-based OSC stuff, so anything that people have built that relies on the slightly incorrect #reply mechanism wouldn't get broken by us cleaning it up.

I think that Approach 2 would be cleaner for ardour, and for what I want to build, but I'm not wedded to it, and the more important thing for me is that we can come up with an approach that will remain supportable in Ardour, because if my Ardour control surface doesn't continue to work with Ardour, that would be a bit of an epic fail.

I'm keen to get feedback from the community on this.

Cheers,


Guy Sherman
e: [email protected] [mailto:[email protected]]
w: http://guysherman.com [http://guysherman.com/]

_______________________________________________
ardour-dev mailing list
[email protected]
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.