Ok, putting this in the Mac OS X area, because that’s the destination box for some sessions I’ve been working with on Linux (AV Linux2.0r2 to be specific, which is ardour 2.8.1). Why the OS X box is the destination is summed up in the word ‘Mixbus’. Trying to get session porting to regular OS X Ardour first, then port from OS X Ardour to Mixbus for final mixdown. And, yep, not only am I a subscriber, but I bought Mixbus (at the time not having a ‘mac’ on which to run it) and the OS X Ardour 2.8.3. So I do believe in the project…
I’m running into a few ‘issues’:
1.) Plugin ID’s are different in one case that I use (CAPS EQ 2x2 in the Debian/AVLinux package). in fact, this plugin doesn’t exist in the OS X Native Ardour, although the rest of the CAPS plugins i use do exist. The side issue of using the ‘vanilla’ Ardour plugins in Mixbus is another, off-topic, hurdle…
2.) I’m using a TASCAM US-428 on Linux to do the transport control. Full feedback works, including the PLAY LED on the US-428. However, according to a post at gearslutz ( http://www.gearslutz.com/board/4674638-post644.html ) by Paul (on gearslutz: dawhead), “On OS X, there is no specific mapping from the controls on the device into Ardour/Mixbus, so you have to set them up yourself, then optionally save as a template so that you never need to do it again.” If this means what I think it means, I will have to manually CTRL-Middlebutton map all the controls I use individually across all 15 sessions; is there no way to copy mappings from one session to another without using templates and new sessions? I’ve got nearly a hundred hours in these 15 sessions…starting over is not an option. Simple question: is there a specific reason control surface mappings can’t be dealt with like keybindings, and have ‘overrides’ available in individual sessions but the ‘template’ in an rc file? I realize MIDI control is a little more bound to the session, but a control surface is almost like an extended keyboard…
So, looking for a little advice here.
Ok, additional information.
In the MIDI Pathbay there is an option to “Allow MIDI Clock and realtime messages,” which, for better or for worse, I’m going to assume means MTC and MMC. Ok, I’ll check the box…
The protocol options for the US-428: US-428 Native, JL Cooper CS-10, Native Instruments B4, Pro Tools CS-10, Four Banks (pots), and Four Banks (encoders).
I’m going to leave it in native mode.
Ok, looking at the console with midi trace, i see the following (I pressed REC, PLAY, STOP, FFWD, and REW in that order):
10/30/09 5:10:50 PM [0x0-0x13013].org.ardour.Ardour2 control input: Channel 16 Controller 23 Value 127
10/30/09 5:10:50 PM [0x0-0x13013].org.ardour.Ardour2 control input: Channel 16 Controller 23 Value 0
[EDIT – since I now know these are regular MIDI CC messages and not MMC, I shortened the list to make the topic more readable.]
Does this enlighten at all?
I have the same problem with the caps plugins, although I’m usually doing it the other way around (osx first, then linux)
No comment on (1).
On (2), the mappings will carry over if they are part of the session but they typically involve a named MIDI port. Without a little bit of work on your part, its entirely possible that the MIDI port names on OS X and Linux will not be the same. If the ports are the same name, then MIDI CC 92 that was bound to track 4 gain will work on either platform in the same session. If not, its a simple bug, and it will be fixed ASAP.
I have consciously chosen not to define any templates for generic MIDI control. My main objection has been the way that most such templates fail when there are more than 16 tracks, or require some kind of bank switching technique that tends to lead to user confusion. At some point, 3.X will tackle this in a new way that may make pre-defined bindings more feasible. My other main reason is that managing such “device specific templates” ends up being a huge pain. Several other DAWs have these and they create more user choice and more user confusion. Its true that the very first time you do this, you face a bit more work. Its also true that it would be nice to have the bindings attached “virtually” - rather than MIDI CC being bound to track 4, its bound to (e.g) the 4th visible track in the editor. But once you set up a session template with the bindings in place, its not work and it works the way you want it to with the device(s) you have.
I'm using a TASCAM US-428 on Linux to do the transport control. Full feedback works, including the PLAY LED on the US-428. However, according to a post at gearslutz ( http://www.gearslutz.com/board/4674638-post644.html ) by Paul (on gearslutz: dawhead), "On OS X, there is no specific mapping from the controls on the device into Ardour/Mixbus, so you have to set them up yourself, then optionally save as a template so that you never need to do it again." If this means what I think it means, I will have to manually CTRL-Middlebutton map all the controls I use individually across all 15 sessions; is there no way to copy mappings from one session to another without using templates and new sessions? I've got nearly a hundred hours in these 15 sessions....starting over is not an option. Simple question: is there a specific reason control surface mappings can't be dealt with like keybindings, and have 'overrides' available in individual sessions but the 'template' in an rc file? I realize MIDI control is a little more bound to the session, but a control surface is almost like an extended keyboard....
An overhaul of the MIDI control system is somewhere on my TODO list, but don’t hold your breath at this point, I am staying much busier than anticipated on other things and then the manual is my highest priority with Ardour ATM. That being said, there should be no difference in how the Tascam is handled on Linux vs OS X, you just need to make sure the MIDI ports are routed appropriately for both, and since IIRC the MIDI mappings are saved with the session file, I don’t believe you need to worry about rebinding controls you already bound on Linux.
In as far as plugins, the issue is simply compiling them on OS X. I don’t think ANY packages have been rolled recently for any of the suites on OS X, so what you have on this site is about it. Even Audacity links to the packages here IIRC. Obviously if the plugin isn’t available, there is only so much that can be done about it, and if the plugin IDs are different that is up to the plugin author really, again only so much Ardour can do about it.
Let me clarify. On Linux the Tascam transport portion ‘just works’ with MMC and having the ALSA MIDI stuff properly cross-connected. Faders and other stuff don’t ‘just work’ without control binding, but the base transport buttons work OOTB without binding with CTRL-Middlebutton.
On OS X, nothing works, even after installing the MIDI Patch Bay and connecting things ‘properly’. I can manually bind the transport controls just fine, and they work, but the OOTB MMC control that ‘just worked’ in the Linux version doesn’t do so in the OS X version. The OS X TASCAM US-428 does give options as to the protocol to use, but the us428control Linux MMC ‘driver’ doesn’t document what protocol it’s sending up the MMC channel (although it seems it might just be the native protocol… I need to ask Rui about that)…
Would knowing the protocol variants available to the OS X US-428 help any? And how do you bind the scrubbing rewind and fastforward buttons, since they’re not on the transport toolbar? Or the PLAY LED? Seablade, the improvements to the manual are already highly useful, but this is a ‘blank’ area thus far… I’d like to help in that as I learn the stuff myself, incidentally.
Are there any default transport bindings for MMC in the OS X version? The post I quoted from gearslutz by paul indicated that the answer is ‘no.’ Am I misunderstanding things?
On the first part of my post, I guess the question should be rephrased as ‘how can I globally change plugin ID’s so that the right plugin (on OS X) gets on the insert?’ That would, I guess, require munging the session’s XML directly, possibly using a batch ‘converter’ that I guess I’d need to write (probably in Python, since good XML parsers exist there). I just don’t want to lose the EQ curves I’ve labored over, that’s all.
E-mail and the forum are my only two options for communicating, incidentally, since we block IRC at the firewall due to spam botnets on hacked Windows boxes using IRC to get ‘instructions’ from their overlords. I’m horrible at chat anyway…
@lowen: MMC should “just work” in OSX. there’s nothing different about the code for this on either platform - MIDI data arrives and triggers other code to run. You might want to check in the MidiPatchBay that its allowing MMC messages to be transmitted - I seem to recall that it had an option not to.
What are the options for MMC on the us428? The only options I am aware of for MMC are: destination ID, source ID and the MMC implementation level (higher number == more of the protocol implemented).
Plugin IDs - you would have to edit the session XML, yes.
And how do you bind the scrubbing rewind and fastforward buttons, since they're not on the transport toolbar?
I don’t believe you can, but you CAN however bind the varispeed control for a similar affect as long as you are using the internal timecode in Ardour.
Or the PLAY LED?
To my knowledge you cannot bind feedback visual states, sorry. It is a shortcoming in the current implementation as it will only send back based on what it receives, not a completely different signal.
As Paul said, the MMC is fairly standard and should ‘Just Work’ on OS X. I will have to write a Pd patch to emulate MMC and test it out here though to give you more details.
Are there any default transport bindings for MMC in the OS X version? The post I quoted from gearslutz by paul indicated that the answer is 'no.' Am I misunderstanding things?
You are misunderstanding things, however that doesn’t preclude the possibility of them not working correctly(Though this would be the first we have heard of it in that case). MMC is a standard set of messages and should be understood and followed by Ardour on any OS really if it in fact receives it on the correct port. So if Transport control that is in fact sending MMC commands is not working, there is something else going on, it should be.
Now just for clarification, keep in mind that MMC and MIDI Control are two different things. MMC is a specific set of MIDI messages that deal with Transport control only. MIDI Control can deal with any number of situations though.
Ok, will try the MIDI Patch Bay options first and see.
The US-428 has a highly programmable control mapping capability, mostly undocumented, of course. There is the US-428 Native Mode; the JL Cooper mode; ‘four control banks’ mode; and others that I don;'t remember off the top of my head (the OS X box is at home, and I’m not…). I do not know which of these the Linux us428control shim emulates.
When I get home this evening, I have some production to do anyway for my radio broadcast; I’ll get a complete list then.
This will be my first attempt with the OS X version…
@lowen: those messages have absolutely nothing whatsoever to do with MMC or MTC. there is no reason for ardour to alter its transport state in response to them - they are just normal MIDI CC messages. You will have to explicitly bind the buttons to ardour’s transport control. these pages (http://www.tweakheadz.com/midi_controllers.htm or http://253.ccarh.org/handout/controllers/controllers.html) provide a guide to pre-established MIDI CC semantics - you’ll note that these have essentially none whatsoever.
Ok. Thanks for the pointers. Interesting though that the Linux support for the US-428 at the ALSA driver level is better than the support on OS X… Learn something new every day! Many thanks for taking the time to help out.
And I now know what the us428control shim is doing in addition to initializing things… MIDI CC to/from MMC translation…spelunking in the us428control code…
The equivlants exist for OS X: MIDIPipe is one. There is a MIDI CC to/from LC/Mackie emulator called LC Xmu. And there are MIDI to Keystroke emulators, like Bome’s MIDI Translator (which can do much more)…
[EDIT: Who really would have thought that the Linux support for something, anything, would become easier than OS X’s or Windows’? And now I have two examples: compiling Ardour itself from source, and support for MMC for a TASCAM US-428 or US-224, because the Windows drivers don’t do MMC either for the US-428, just like with the OS X drivers…the US-428 on linux with current ALSA Just Works for transport…kudos to Karsten (sic?) and Rui!]