Andrew

I'd thought that all controls that are midi-learnable in Live could be controlled via the api, but I can't seem to find a couple in the LOM or the lessons/examples.

For example, if you click midi-learn, under the master track there are mappable arrows that move the highlighted session, but I can't seem to find them. In the "Max API Application View" example there's a way to scroll the arrangement, but not session. But, by combining the arrangement up/down to move between tracks and the up/down arrows to move sessions I think would do what I need.

Similarly, using midi learn if you map a control to a device title bar, when you hit it it'll change the focus and bring you to that device. I've found a way to select a device, but it doesn't move the focus, which is what I need to do.

I think I could use a round-about way of sending midi commands and doing it through midi-learn, but it's a bit of a pain, especially when I move the device to other tracks/sets since all of that has to be re-programmed.

For example, if you click midi-learn, under the master track there are mappable arrows that move the highlighted session, but I can't seem to find them. In the "Max API Application View" example there's a way to scroll the arrangement, but not session. But, by combining the arrangement up/down to move between tracks and the up/down arrows to move sessions  I think would do what I need.

I think I could use a round-about way of sending midi commands and doing it through midi-learn, but it's a bit of a pain, especially when I move the device to other tracks/sets since all of that has to be re-programmed.


are-all-midi-learnable-controls-available-through-the-api

Yeah they are, but some take a little more work than others:

In this example I've shown how to launch the selected scene (the play button on the master track), and how to select scenes. I also show how to select devices. The trick is, before calling select device, you must also select the track the device is on. At least that's how I made it work.

I'll have to spend time with it so I can understand and reproduce it in other projects. I was getting worried I was on a quest to do something that couldn't be done...which has happened before with other software.

This was actually a pretty informative exercise, especially the selecting of a device bit. I feel that there is a better way to do this, but this works for now.

So, I think I understand the first few pretty well. I'm having a slight issue implementing the last one, but I believe as I keep working with it I'll iron that out. It's a good learning opportunity anyway.

I did have one question though. Take the snippet for firing scenes; I see that it requires deferlow, since without it it doesn't work, but I'm not sure why in this case. I've used deferlow, say, when a calculation splits into two paths then gets brought back together into one object and I need to be sure one of them enters the object first. But, I don't understand why it's necessary here in a single path. I'm wondering if this gap in my understanding is to blame for issues I've had in other patches too.

Haha, when I reloaded my browser it didn't show your reply.

In case you're interested since you say the device selecting one was harder, I can't get it to reliably pick out the right device. It works perfect if there's only one device in the track (after selecting the track), but if there is more than one device, out "in the wild" it doesn't always pick out the right one, in my case, the Looper (instrument) device.

I'd like to be able to pick any device, but the most pressing is specifically the looper and I found live.function select_instrument in a M4L example, so I'm looking to see if incorporating that can iron it out. Or, I can move some devices around to leave just the looper on that track.

I wrote a patch that emulates the mouse etc. to use the "Drag Me" control in the Ableton looper to dump the loops to clips so I can clear them out and move on, but still go back. It can't be done in Ableton otherwise (that I know of) and having to set down instruments and use the mouse has been a real drag. You're help has really helped me along toward full hands-free control!

The deferlow needs to be used because as Live tells you 'Changes can't be triggered by notifications', or something like that. The API doesn't want you triggering changes from live.observers, and the dynamic output of live.path.

Not sure what you mean by 'it doesn't alway pick the right one'? you'll have to give me an example, and be more clear on the behavior, as it looks to be working fine for me with multiple devices in a track. If you don't need to have the selection be dynamic and you know the track and device index, you can do this:

The deferlow needs to be used because as Live tells you 'Changes can't be triggered by notifications', or something like that. The API doesn't want you triggering changes from live.observers, and the dynamic output of live.path. 

Not sure what you mean by 'it doesn't alway pick the right one'? you'll have to give me an example, and be more clear on the behavior,  as it looks to be working fine for me with multiple devices in a track. If you don't need to have the selection be dynamic and you know the track and device index, you can do this:


Now that you mention it, I do remember seeing that in training somewhere.

The problem I was having with the first example was definitely bcak... I misunderstood and employed it wrong, so from my perspective which device was selected (sometimes none) vs what I expected it to select wasn't consistent. I have it figured out now and it does indeed work perfectly when properly used.

The second example did really help me figure out what I had misunderstood though, thanks!

Are all midi-learnable controls available through the api?