View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002239ardourfeaturespublic2008-05-07 06:512017-12-20 10:08
Assigned Toovenwerks 
PlatformOSOS Version
Product VersionSVN/2.0-ongoing 
Target VersionFixed in Version 
Summary0002239: Make OSC send useful information to OSC controllers
DescriptionI've been trying to work out a good way for ardour's OSC to talk to controllers like the tranzport, alphatrack, monome, etc.

The principal problem is that ardour's view of time is continuous, while any given controller I've played with can only respond to events on a 10ms interval, at best.

Adopting a "subscribe" paradigm for events a given controller is interested in (a la sooperlooper) is probably the best way to go. The first crack at it is in a nonworking (yet compiling) patch here, so we can discuss how to move forward.

The only thing really worth looking at is the broadcast_state and broadcast_track routines here. It looks like, even for large projects, that packet size will stay well within udp's limits.

Sending 100-200 packets per second shouldn't stress any modern hardware in the slightest. We could even multicast...

Ideally I'd just be able to loop through the tracks and pull out the current information (gain,pan,name,etc) for each, but it's looking more like I have to attach callbacks from hell using routes, on everything, and I'm hoping I'm just dull, rather than misunderstanding things. (I'd rather be working on getting a client to understand the sent messages than delving deep into ardour to convince it to send them, hint, hint)

Additional InformationThere's also a small bugfix in here. If you disable OSC then re-enable it, it fails, currently, due to not resetting _shutdown.

Need to move to select with a timeout rather than poll as poll uses millsec, and everywhere else I have microsec resolution. select can do nanosecond resolution (theoretically)
TagsNo tags attached.
Attached Filespatch file icon OSC.patch [^] (40,989 bytes) 2008-05-15 23:55 [Show Content]

- Relationships

-  Notes
mtaht (developer)
2008-05-15 23:55
edited on: 2008-05-16 00:01

The attached patch is a snapshot of my progress this week towards a more complete OSC implementation in ardour

It implements:

* A quick and dirty linux 2.6.24 and later "timerfd" mechanism to implement timeouts and a reliable clock. This is much cleaner than the equivalent poll and pipe mechanism used elsewhere in ardour. (The abstraction can be retrofitted to use the older mechanism for older kernels and other os's, but I haven't got around to it)

* OSC multicast (via the current svn version of liblo)

* Deletion of the old unix_server code which never worked anyway

* A start at broadcasting useful information (global state and track data).

The proof of concept here was to see if could send 110 BIG packets a second containing OSC data without affecting the rest of ardour (xruns, etc).

At least on my hardware (quad core 64 bit), running OSC doesn't even tweak the 'top' utility's process load meter, so the network usage appears to have trivial impact on ardour, even with 32 tracks enabled. We'll see what happens when I start extracting peak gain and the like, but my feeling is that the existing automation code for extrapolating pan and gain points is going to be much harder on ardour than the OSC code.

Actually, I'm sending 220 BIG packets a second. (one multicast, one unicast) It really hurts my wireless access point to do this (dhcp has trouble getting through), but the wired network shrugs it off.


* Standard address/port combination for multicast

* A little help in probing the depths of ardour for right magic for the commented out function calls in broadcast_track and broadcast_state would be helpful

* It would be good to know if this causes xruns on weaker hardware.

* Comments on additional useful information for use by surfaces are welcomed.


Run Linux 2.6.24 or later. RT is not required. (but helpful for all the reasons RT is helpful)

Pull down liblo from svn.


On a multicast enabled system, add a multicast route:

route add -net netmask dev eth0

And make sure iptables isn't blocking multicast.

and you can then see the multicast packets go by via a sniffer.

I have preliminary python and C clients in the works, as well as some progress on the transport and alphatrack. This is far from a final protocol definition, or truly useful code. I have a start at that too (not in the patch), for a mostly stateless command set.

paul (administrator)
2008-05-16 05:06

mike, not sure what you're thinking of when you comment about using poll/pipe in relation to timeouts. all the uses of poll/pipe that i can think of are really related to inter-thread wakeups, and are not timeout based.
mtaht (developer)
2008-05-16 09:17
edited on: 2008-05-16 10:24

Originally I was going to implement a poll and pipe thread for this to implement the various reliable timers required. I still will, for older/other OSes, but I'll use the timerfd abstraction to embed those threads in that class, unless I come up with a clean way to support mac (kevent?).

For the stateless stuff, clocking the remote device by the outgoing stream's packets is basically how voip works. (after the raging success of the 10ms clock I'm thinking of trying 1ms!)

For stateful stuff (e.g. I've sent a command, and need a reply), there needs to be a per-command-outstanding-per-OSC-device timer to send retries...

ovenwerks (reporter)
2017-08-20 16:47

Ardour's OSC has moved on a fair bit since this was entered. There is a whole set of controls that are fed back to the controller. At this point, feature requests that shows holes in the current feedback structure would be more helpful.

- Issue History
Date Modified Username Field Change
2008-05-07 06:51 mtaht New Issue
2008-05-07 06:51 mtaht File Added: osc.patch
2008-05-15 23:35 mtaht File Deleted: osc.patch
2008-05-15 23:55 mtaht Note Added: 0004937
2008-05-15 23:55 mtaht File Added: OSC.patch
2008-05-16 00:01 mtaht Note Edited: 0004937
2008-05-16 05:06 paul Note Added: 0004938
2008-05-16 09:17 mtaht Note Added: 0004940
2008-05-16 10:24 mtaht Note Edited: 0004940
2017-08-20 16:47 ovenwerks Note Added: 0019987
2017-08-20 16:47 ovenwerks Status new => resolved
2017-08-20 16:47 ovenwerks Resolution open => fixed
2017-08-20 16:47 ovenwerks Assigned To => ovenwerks

Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker