|Anonymous | Login | Signup for a new account||2018-10-23 00:24 PDT|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002239||ardour||features||public||2008-05-07 06:51||2017-12-20 10:08|
|Target Version||Fixed in Version|
|Summary||0002239: Make OSC send useful information to OSC controllers|
|Description||I'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 Information||There'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)
|Tags||No tags attached.|
|Attached Files||OSC.patch [^] (40,989 bytes) 2008-05-15 23:55 [Show Content]|
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
* 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.
HOW TO USE
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 184.108.40.206 netmask 240.0.0.0 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.
|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.|
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...
|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.|
|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|