jomtones

I'd like to add something like Hawtins' Kapture to my live set, but only for track arming / un-arming. Unfortunately the Kapture patch fails to record track arming, so I need to make something new but have no idea where to start! Is there a plug into the Live API for arming tracks?

I'd like to add something like Hawtins' Kapture to my live set, but only for track arming / un-arming.  Unfortunately the Kapture patch fails to record track arming, so I need to make something new but have no idea where to start!  Is there a plug into the Live API for arming tracks?


how-to-armun-arm-tracks-with-m4l

I dont know how Kapture works, but you can get into Live API to access the track's arming. Here is an example where if you drop this into any track it will automatically find the arm and map to the button arm. Just connect whatever you want to change it to the button itself. For instance connect a send or receive to it to change it.

I dont know how Kapture works, but you can get into Live API to access the track's arming.  Here is an example where if you drop this into any track it will automatically find the arm and map to the button arm.  Just connect whatever you want to change it to the button itself.  For instance connect a send or receive to it to change it.

Wow, that looks pretty cool ... I haven't got the skills to build a preset bank and send array myself, but maybe I'll suggest it to the Kapture team as an addon .. surely its got to be useful to someone more than just me!

No i agree with you all the way. As it would set up my perforamce bank really well.

If you need to create something in the meantime that would get picked up by Kapture you could just create a device based on the one I sent you (almost identical infact) except you need to make sure the arm box is being displayed in presentation mode, name it what you want to name it as and save it. Then load it onto each of your tracks. Kapture should find the parameter under its device section (if checked) and save that. Theoretically it should update and modify arming accordingly.

You could create one device to do a set number of tracks aswell.

Downside = you may need to drop the device in every single track in your set.

Upside = since you dont know much about preset banks, its really easy to do, and would work in the meantime before they would update it (if they update it)

If you need clarity of the idea just ask further and i could easily create the device for you and post it Unless someone else on the forum is going to change the program itself.

No i agree with you all the way.  As it would set up my perforamce bank really well.  

If you need to create something in the meantime that would get picked up by Kapture you could just create a device based on the one I sent you (almost identical infact) except you need to make sure the arm box is being displayed in presentation mode, name it what you want to name it as and save it.  Then load it onto each of your tracks.  Kapture should find the parameter under its device section (if checked) and save that.  Theoretically it should update and modify arming accordingly.
You could create one device to do a set number of tracks aswell.

Downside = you may need to drop the device in every single track in your set.
Upside = since you dont know much about preset banks, its really easy to do, and would work in the meantime before they would update it (if they update it)

If you need clarity of the idea just ask further and i could easily create the device for you and post it  Unless someone else on the forum is going to change the program itself.


Ah yes I catch your drift! This would be great but I've found Kapture slows WAY down when you ask it to capture DEVICES, not just mixer settings, and as I'm trying to do this on stage I need it to be very responsive.

I've got a feeling that I'm better off just changing tracks manually for now, but thanks for the suggestion!

Ah yes I catch your drift!  This would be great but I've found Kapture slows WAY down when you ask it to capture DEVICES, not just mixer settings, and as I'm trying to do this on stage I need it to be very responsive.

I've got a feeling that I'm better off just changing tracks manually for now, but thanks for the suggestion!


Hey protocol I just had an inspiration on how to get this working - perhaps I can control it with clip automation? Was just trying to test it but I couldn't get started with making your device work - where do I attach a Live button to to start it?

Hey protocol I just had an inspiration on how to get this working - perhaps I can control it with clip automation?  Was just trying to test it but I couldn't get started with making your device work - where do I attach a Live button to to start it?

If you just pasted the compressed patch in a patcher, you have to send a bang to the loadmess object to initialize it. And I think the live.text object (with the arm label) should be midi mappable and acts as a toggle, so I don't see the point of attaching a button to turn it on /off.

Somenone please correct me if I'm wrong on any point, I'm also a beginner.

If you just pasted the compressed patch in a patcher, you have to send a bang to the loadmess object to initialize it. And I think the live.text object (with the arm label) should be midi mappable and acts as a toggle, so I don't see the point of attaching a button to turn it on /off.
Somenone please correct me if I'm wrong on any point, I'm also a beginner.


Ah ok ... so I'll have to send a bang to 'loadmess' every time I start the project?

Hmm not having much luck with this so far ... I've tried attaching buttons to both the live.text object and the loadmess thing but neither seem to do anything.

Bump! Can anyone help with getting this working? Really stuck ...

Bump!  Can anyone help with getting this working?  Really stuck ...


Got a parallel thread on this over at the Ableton forum ... still not getting very far with this M4L patch though! 

http://forum.ableton.com/viewtopic.php?f=35&t=171133

Got a parallel thread on this over at the Ableton forum ... still not getting very far with this M4L patch though!  http://forum.ableton.com/viewtopic.php?f=35&t=171133


From the discussion so far it seems that you don't understand the basics of M4L.

Also, I think you should explain better what you actually want to achieve..

From the discussion so far it seems that you don't understand the basics of M4L.
Also, I think you should explain better what you actually want to achieve..


'If you just pasted the compressed patch in a patcher, you have to send a bang to the loadmess object to initialize it. And I think the live.text object (with the arm label) should be midi mappable and acts as a toggle, so I don't see the point of attaching a button to turn it on /off.'

Jomtones, you should read the reference files for 'loadmess' and live.text, you would get what I mean.

Broc, am I right about this ?
'If you just pasted the compressed patch in a patcher, you have to send a bang to the loadmess object to initialize it. And I think the live.text object (with the arm label) should be midi mappable and acts as a toggle, so I don't see the point of attaching a button to turn it on /off.'

Jomtones, you should read the reference files for 'loadmess' and live.text, you would get what I mean.


Stephane, your statement is correct. But it should be noted that the loadbang is only needed if you want to initialize the patch while in edit mode. When the device is saved and reloaded into a Live set, it's not needed anymore since loadmess will be called automatically.

broc - what I want to be able to achieve is changing record-arm states with clip-launching. I'm hoping with this M4L patch I'll be able to do it.

So far I haven't been able to get it to do a damn thing but I'll have another go at making the 'arm' label MIDI mappable since sending a bang to it didn't seem to do anything.

broc - what I want to be able to achieve is changing record-arm states with clip-launching.  I'm hoping with this M4L patch I'll be able to do it.  

So far I haven't been able to get it to do a damn thing but I'll have another go at making the 'arm' label MIDI mappable since sending a bang to it didn't seem to do anything.


Hmmm ... same result. The 'live' label lights up a healthy red when clicked but doesn't seem to do anything else. MIDI mapping it doesn't help either. Can anyone confirm if this patch really works?

Hmmm ... same result.  The 'live' label lights up a healthy red when clicked but doesn't seem to do anything else.  MIDI mapping it doesn't help either.  Can anyone confirm if this patch really works?


It would be relevant to check the M4L device that you have created from the patch.

So you may send the corresponding .amxd file as attachment.

It would be relevant to check the M4L device that you have created from the patch.
So you may send the corresponding .amxd file as attachment.


"But it should be noted that the loadbang is only needed if you want to initialize the patch while in edit mode. When the device is saved and reloaded into a Live set, it's not needed anymore since loadmess will be called automatically." That's what I wanted to underline to Jomtones.

Thanks for the help guys, time is short before the next rehearsal so I give up for now! madlab over on the Ableton forum recommended Clyphx which looks promising so I'm going to give that a go before anything else.

Thanks for the help guys, time is short before the next rehearsal so I give up for now!  madlab over on the Ableton forum recommended Clyphx which looks promising so I'm going to give that a go before anything else.


On this same issue, I am able to arm/disarm by manually sending messages, but for some reason it does not work automatically. I have set a system that listens to the transport time and then, depending other conditions, will selectively arm, fire, and disarm clips. Anyone have any insight? Look at ifmatch_record patcher for the specific problem.

Will... Can't comment on your patch since it wasn't real fun to look at. No offense intended, and its most certainly not a comment aimed at the quality of the patch. Its just that it contained so much extra unrelated stuff... that can become really distracting to get to the actual problem. Because although you pointed at a specific patcher object obviously that's not where the cause of the problem has to be.

Test cases are best setup as tiny as possible so that its easier for others to look at and to identify a possible problem (and its cause).

My guess: have you looked at the Max window when you tried your patch? If a patch triggers an error then that's where it'll be. Now, I didn't go over the entire patch and its separate subpatchers, but my guess is that your Max window gave you an error. Something in the likes of "Changes cannot be triggered by notifications" (or something similar, this is from the top of my head).

Here's a small test case which arms/disarms track 1 on every beat. As you can see this can be made to work. Pay extra attention to the "deferlow" object in there.

Will...  Can't comment on your patch since it wasn't real fun to look at. No offense intended, and its most certainly not a comment aimed at the quality of the patch. Its just that it contained so much extra unrelated stuff...  that can become really distracting to get to the actual problem. Because although you pointed at a specific patcher object obviously that's not where the cause of the problem has to be.

My guess: have you looked at the Max window when you tried your patch?  If a patch triggers an error then that's where it'll be. Now, I didn't go over the entire patch and its separate subpatchers, but my guess is that your Max window gave you an error. Something in the likes of "Changes cannot be triggered by notifications" (or something similar, this is from the top of my head).

Here's a small test case which arms/disarms track 1 on every beat. As you can see this can be made to work. Pay extra attention to the "deferlow" object in there.


Thanks ShelUser. I totally understand that my patch was too much information for testing, so thanks for your help even after. I'll keep my posts more concise in the future. And yes, I eventually found the deferlow object in another post, though I have yet to really understand how it works.

New problem (but really the same problem). I've encountered the same error with something that is structured like the patch I've copied below. Unfortunately for problem solving purposes, the patch below actually works, so I assume that the problem lies within the deeper web of my larger patch. In the larger patch, when the Live metronome updates the counter, which selects for a match and then must launch two clips at once, it only launches one. However, when I update the counter manually, it will launch both. Worst of all, there is no error message in the Max window. Could someone explain what deferlow actually does, and the effect of having multiple deferlow's in one patch? Does it screw up the priority of messages?

Will, in your last patch, I don't get what you want to achieve. In Live, you can't launch two clips on the same track at the same time, which is what would theoretically happen if you send a 'call fire' message to the two [live.objects].

I made some changes to your patch to make it alternately launch clip_slots 0 and 1 on track 1 on the 1st and 3rd time of each measure. Is that something like that you're after ? I also added a [+ 1] after the [live.observer] because the first time was counted as 0.

Will, in your last patch, I don't get what you want to achieve. In Live, you can't launch two clips on the same track at the same time, which is what would theoretically happen if you send a 'call fire' message to the two [live.objects].
I made some changes to your patch to make it alternately launch clip_slots 0 and 1 on track 1 on the 1st and 3rd time of each measure. Is that something like that you're after ? I also added a [+ 1] after the [live.observer] because the first time was counted as 0.


"Could someone explain what deferlow actually does, and the effect of having multiple deferlow's in one patch? Does it screw up the priority of messages?"

Time for my favourite link on this website(btw, not quite easy to find, which is a pitty)

https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue/

Time for my favourite link on this website(btw, not quite easy to find, which is a pitty)
https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue/


btw. this article is written on September 9th, 2004. It is still valid right?

How to arm/un-arm tracks with M4L?