I’m querying the status of tracks within a session script and both the muted and soloed status are straightforward from the respective track methods.
However I can’t find a way to get the record arm/enable status. The only documented method which sounds relevant - can_record() - returns an error as being undefined.
I’ve seen examples of arming a track for recording using the set_value() method of record_enable_control() but the corresponding get_value() method doesn’t seem to return anything correlated to the track’s status.
To set rec-enable status you need to use Session:set_controls() (this is required to ensure that if you rec-enable > 1 track, the change is atomic with respect to audio processing. If you were to call set_value() on tracks one-by-one, you could have a situation where in a given processing cycle, only some of them were enabled.
For detecting it, I can only quote you the C++ code used in the GUI;
if (track()->rec_enable_control()->get_value()) {
switch (_session->record_status ()) {
case Session::Recording:
Thanks Paul, that might help. I didn’t know what value might be returned by the get_value() method so I might have been interrogating it incorrectly by the look of that C++ code and hence not seeing a change correlated to the status.
A key idea, that may or may not be obvious, is that a track’s “full” record enable status is dependent on both its own rec-enable control and the session record status.
I did wonder about that and tested that situation, but I expect the same faulty interpretation of what I was seeing misled me. So the get_value() method definitely won’t indicate recording enabled unless both the session record button and the track record enable are selected, correct?
get_value() for the track rec-enable-control will always indicate the status of the track record enable status. but …
setting the value is asynchronous (like many things in ardour, the UI requests it, and it takes place in a realtime thread in the next process cycle). so if you are setting it and expecting it to immediately have the new value, that’s not going to work. You need to keep in mind that Ardour uses MVC design heavily: the UI is (for these purposes) a Controller and requests changes in the Model; those changes may or may not happen, and may happen at some arbitrary future time; the View (also the UI) needs to ensure it asks to be notified about the change (or, if appropriate, poll to detect them).
the track rec-enable control’s value is independent of and does not reflect session recording status.
Ok thanks Paul, beats me too. Reading the fora I gather Robin (@x42 ) is one of the scripting gurus, Robin are you perhaps able to shed any light on this?
Thanks Robin,. Any reason a session script should be different?
Could it be because I’m getting a the track from a tracklist rather than a routelist? Should I cast it to a route before using the method? My reading was that there should be no difference and both classes have the equivalent method?
for t in Session:get_tracks():iter() do
if (t:rec_enable_control():get_value() == 1.0 then
Ok it looks like in fact it does work in the Session script, but doesn’t in the scripting window that I’d been using to try to debug it. Hadn’t tried moving back to the real script for a while because it was hard to determine what was going on at audio cycle rates.
Right, so my problem has morphed in to a different one!
After much debugging and head scratching I realised that the track list returned by the iter() method changes when a track is record-enabled. It appear non-enabled tracks are returned first. This is part of the reason I thought things weren’t working because I wasn’t operating on the tracks I thought I was.
Neither mute nor solo affected the tracklist order so I wasn’t expecting that, but now I need a way to deterministically access tracks in the same way midi mapping refers to IDs of 1, 2… etc.
If I use route_by_name() everything works fine, but I then have to stick with generic pre-determined track names.
Is there a way to access specific tracks other than by name? I see there is route_by_ID() but this seems to not be correlated with the midi map ID and I can’t find any reference to what it might be or how it might relate to the track number/position.