How do I wire up my ‘RECORD’ signs in my live room.
Using my old recorder, I tapped into the physical record LED and amplified the current with a few transistors to drive the signs in the live room.
I have a Korg NanoKontrol2 control surface. which has an illuminated record button, so I could tap off that in the same way if only I could configure Ardour to send the required midi CC codes to the NanoKontrol2 when it is put into record rolling mode by any means.
Ideas and suggestions? Thanks.
Various people have done this in a variety of ways.
Ardour can emit various messages when dropping into record. You have a choice of (at least) MIDI Machine Control, Mackie Control protocol or OSC. We also have a MIDI binding map for the Nanokontrol 2 already, but my impression is that it does use feedback to drive the NanoKontrol “state” itself.
An alternative to MIDI would be to use an Ardour Lua script-hook. That can perform any action when Ardour starts recording. ie call a system-command or send an OSC message. You can run any external command and do the heavy lifting outside Ardour.
A Mixbus user recently hacked up http://mixbus.harrisonconsoles.com/forum/thread-6382-post-38113.html
A minimal Lua script would be e.g.
ardour { ["type"] = "EditorHook", name = "Tally Light Trigger" }
function signals ()
return LuaSignal.Set():add ({[LuaSignal.RecordStateChanged] = true})
end
function factory () return function (signal)
if Session:actively_recording (true) then
os.execute ('/usr/bin/lights_on'); -- change this command
else
os.execute ('/usr/bin/lights_off');
end
end end
/me wonders why I always forget the incredible lua scripting capabilities that we have, courtesy of x42 aka Robin Gareus. Thanks, Robin!
Dear Paul and Robin,
Many thanks for the suggestions.
I have quite a few control surfaces, all of whose protocols I fully understand. Apart from the transport controls on my Yamaha O2R96, I have devices like the Novation Zero and a ShuttleXpress. For both of these I’ve written proxy daemons so that they show up as ALSA midi devices and emit and receive regular MMC, as is given out by the O2R96.
I’m looking for a solution that updates the record lights, and other transport status indicators, on all the various control surfaces. Ideally, the central transport control needs to echo the transport rolling/record/stopped status to all the surfaces. I have just compiled Ardour6 from source. I guess I can add the status reflection functionality to the Ardour source if its missing or else write another daemon that coordinates all the surfaces and indicators. I also need to do MTC in the reverse direction.
The reflection of automation to control surfaces is also needed for my Behringer BCF2000 which also has flying faders as well as another set of transport controls.
I can look further into that and the Lua option.
A problem that I have at the moment is that most of my midi devices are appearing as ALSA devices. (I am familiar with patching these manually via the qjackctrl gui or the equivalent alsa API from a C program.) Whereas Ardour is only showing, under its preferences/MIDI/Ports tab, the 5-pin DIN ports on the I/O interface it is using (Scarlett 18i20) and these appear under the ‘MIDI’ tab in qjackctrl. So I cannot connect the O2R96 transport controls (via its 8 midi-over-USB ports) to Ardour either way. To recap, the two ways would be via the Ardour preferences tab (where the devices are not showing up) or via qjackctl, where the input and the output I wish to connect are on different tabs (MIDI and ALSA) and hence cannot be interpatched on qjackctrl GUI.
I guess I do not know enough about why midi ports should show up one way or the other (Jack v ALSA). Perhaps you can advise me on that? Possibly I’ve noticed a slight difference in this respect between what shows up where under Ardour5.12 (prebuild) and Ardour6 (compiled myself).
Unless I can understand further, in the meantime, a start might be to put an old fashioned midi cable between the O2R96 physical MMC output port and the 18i20 physical midi input port. Sufficient options are visible in what I’ve outlined above for me to try that.
But I need to master this a lot more: I have reverse engineered the O2R96 exclusive messages that will make it a great, motorised, control surface for Ardour. Perhaps there are some existing common control-surface profiles that suit both ends (O2R96 and Ardour) but if I am to connect multiple control surfaces, which is what I want, then it looks like I’m going to need to write some code myself.
Sorry for a very long note. I was trying to be clear. In anticipation of further hints … thanks
David Greaves
There is already a /record_tally output in the OSC code. Anything with a network connection can get that or a script on the same machine as Ardour can use oscdump to catch it and send a midi code or set a serial port pin high. I made it with the idea of using a cheap tablet connected via wifi running TouchOSC or Control with just one (Big Red) button that receives /record_tally and a small connect button that tells Ardour to start sending.
record_tally is true for any track record enable and or master record enable. It does not detect transport motion on the theory that having a big noise just as the play button is pressed would be bad too. Also punch-in can be done with the transport rolling by toggling master rec.
Just a guess, It looks like one of your devices is firewire and the others are not. So you see the firewire device midi ports as “MIDI” (AKA jack midi) and the others as alsa. The quickest way around this is to use a2jmidid -e & from a terminal after jack is running or from the qjackctl options->Execute script after Startup line. In the MIDI tab of connections you will now see a2j which when expanded will show everything from the alsa tab.
Many thanks for the feedback.
To clarify:
I do not have any firewire devices: all my devices are class compliant midi/USB or ports to local software on the same machine.
I have no motivation to use Jack instead of ALSA: I was mentioning that none of my midi devices are showing up under the Ardour Preferences/Midi Ports tab except for the two 5-pin DIN in and out on the one audio interface that is being used with Ardour and I suggested this was perhaps because Ardour is making a JACK connection to the interface. I also infer that Jack is in use since I have visibility of all the Ardour engine busses and patches under the Audio tab of qjackctrl and not the ALSA tab. But I am trying to avoid Jack in that I have always selected Audio System=ALSA and MIDI System=ALSA raw devices in the Audio/MIDI Setup transitorary page that appears when opening an Ardour session.
I can certainly bundle all my transport controls and RECORD lights under a custom OSC exchange server that I write. That might well be a good solution.
I am not yet familiar with a2jmidid. Its documentation describes it as a ‘bridge’, but is not explicit which way it bridges. If it makes all my ALSA midi ports appear as Jack, which is what the documentation seems to imply, and is what I conclude from your description of it making the midi devices appear under the midi heading instead of the ALSA heading in qjackctrl, then this would be moving things in the opposite direction from the ideal suggested by Paul.
I am using Linux 4.17.19-200.fc28.x86_64 #1 SMP Fri Aug 24 15:47:41 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
I will investigate further.
I understand the warning re Ardour6 - it’s just that’s the one I retrieved from git earlier today as my first stab at compiling my own copy. And indeed that went perfectly. I will use Ardour5 for my imminent two sessions with real musicians.
Many thanks
Ah, my mistake then. It appears that the problem is just that you are running jackd when you should not be. Switch Ardour to alsa (even if it can’t see the device you want) turn off jack using qjackctl or killall -9 jackd jackdbus, and then you should be able to choose the device you want in Ardours audio device (Window -> Audio/MIDI setup) page. Then you should see all of the midi devices from Ardour.
And a2jmidid will not be needed (or run for that matter).
Thanks very much for the advice. Yes, I am doing everything I can to avoid Jack and exploring the ALSA only route as best I can. I wonder if you’d be able to comment on any of the following 5 points?
Thanks v much
David Greaves
I take it that this is out-of-date and it is now considered better not
to use Jack unless you really want to? Is that correct?
A range of 129 values is possibly appropriate for receive if one value
is being used to denote omni. I cannot guess why a range of 129
values is useful for the Outbound MMC transmit side.
I have seen documentation that says the JACK:mmc_out port should be
selected, but I have not ever seen any such port via the Ardour GUI. I
have seen it under the MIDI tab of qjackctrl, but there was not
anything else I could suitably patch it to under that tab (that’s
perhaps were a2jmidid came in for those going the Jack route).
END
I see my inclusion of XML elements in my previous posting has messed up the formatting of the posting.
Here is part 2 again with all of the less than symbols replaced with <
Re (2), the <EngineState> in the config is a red-herring in this context. You can also ignore all those that are not maked as active="1".
(3) That is indeed a bug. Currently 128 is treated like 0. The current range is 0…127 (not 1…128)
(4) Ardour uses JACK-MIDI (not ALSA MIDI). If you have to use JACK and qjackctl, I suggest to configure it to hide the ALSA tab.
(5) Ardour-Menu > Window > MIDI connections under “Misc/Sync” there are MMC in and MMC out ports that you can connect. With JACK, they should also show up in qjackctl’s “JACK MIDI” tab ardour:MMC in.
Thanks very much Robin.
When you say "You can also ignore all those that are not maked as active="1"" this is not directly helpful since it is the ones that are in the active=0 partition that I actually want to use. I will try to find out what establishes this partitioning and how it might be varied.
But many thanks for pointing out the MIDI Connections editor. By making entries in there I have now made MMC flow in and out of Ardour. A big step forward. Ardour is displaying Device ID off-by-one compared with the O2R96, so manual correction for that is needed. Also, I should have noted in my previous posting that Device ID of 0x7F on the wire is the Omni mode for MMC and I see from reading the Ardour sources that it does respect that convention.
You say that “Ardour uses JACK-MIDI (not ALSA MIDI)” so it seems I am being pushed towards using Jack. This is despite Paul’s posting above “Unless you have a specific use for JACK (i.e. routing audio/MIDI between applications or sharing the audio interface between multiple music creation/pro-audio apps), don’t use it. Use Ardour’s own builtin ALSA audio/MIDI support. MIDI stuff just works there (and better).” What you say seems to be a direct contradiction of Paul to me.
Thanks again.
My bad. I meant to say: When using JACK, Ardour only interfaces with JACK-MIDI. When using JACK, Ardour cannot directly use ALSA-MIDI.
Hence Paul’s correct suggestion: not using jack makes things a lot simpler.
Those inactive states are just saved for convenience. The idea there is to provide defaults for different device-setup types. The engine-states always only pre-fill the Audio/MIDI setup dialog. They never apply directly and you can always modify the settings manually before starting the engine.
In any case, if you use qjackctl to start JACK, none of those matter. These settings are only meaningful if you do not use JACK.
As the name implies, qjackctl is a control program for JACK, so stop starting qjackctl if you are not going to use jackd. You need to make a firm decision, either use jackd if you have a need to route audio and MIDI between other applications and Ardour, or if that is not needed, stop starting qjackctl, don’t start jackd, just start Ardour and configure Ardour to use ALSA devices.
You have not shown how your qjackctrl is configured, but possibly it is automatically starting jackd for you, so after exiting qjackctl make sure that there are no jackd or jackdbus processes still running.
One behavior which may not be immediately obvious to you is that the Ardour developers decided to give the users the benefit of the doubt, and assume that the user intentionally started jackd if it is running, so Ardour will automatically connect to a running instance of jackd without asking what audio backend you want to use. If you accidentally started jackd without realizing it by opening qjacktctl while it was configured to automatically start jackd, you will not get an option to use the Ardour ALSA backend, so the Ardour behavior may be different depending on the order you start applications.
But yet you seem to be starting a jack control application. I keep my qjackctl set to not automatically start jackd, but I think the default behavior is to start jackd automatically when the application loads, so that may be the root of your confusion. Usually qjackctl displays the state of jackd pretty clearly so you can tell at a glance whether it is running or stopped, but perhaps if you did not know to look for that it slipped your attention.
Chris - that’s not 100% correct. If the previous audio/MIDI backend chosen was JACK, and JACK is already running, then we don’t give the option to change it during startup. But if the previously chosen one was something else, the option is still there.
And to be clear to anyone who doesn’t know this (I know that Chris does), you can go to Window > Audio/MIDI Setup at any time to change the backend being used.
Paul, thanks for reminding me how that worked, I usually have jackd running so I had forgotten how that works when you don’t have jackd started first.
I was hoping to hear from the original poster whether having jackd running already was the source of his problem with MIDI devices or not.