Record enable status of a track in a session script

Getting Stuff Done How do I .... ?
#1

Another quick question about lua scripts in 6.2.

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.

Any pointers?

Thanks!

#2

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:
#3

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.

#4

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.

#5

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?

#6

get_value() for the track rec-enable-control will always indicate the status of the track record enable status. but …

  1. 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).

  2. the track rec-enable control’s value is independent of and does not reflect session recording status.

#7

Ok cool, thanks for the clarification. I’m not concerned about its asynchronous nature I just need to be able to detect once it asserts.

#8

Apologies, but no matter what I do it appears the return value from

rec_enable_control():get_value()

is 0.0 regardless of the state of the track’s enable control. I must be missing something?

#9

I checked the C++ code:

cerr << track()->name() << " rec-control: " << track()->rec_enable_control()->get_value() << endl;

and it works as expected. I have no particular idea why the Lua equivalent would not work.

#10

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?

Many thanks.

#11

Works in this action script:

#12

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
#13

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.

Thanks for the help, much appreciated.

#14

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.

Any pointers?

#15

Crisis averted! I stumbled upon get_remote_nth_route() which I’d somehow missed previously. All working as desired now!

Thanks for your help Paul and Robin.