Hi,
I’ve seen it noted in the forum that it’s possible for BMTP to receive midi output from Ableton when Ableton’s Mute, Solo and other controls are changed.
What’s the best way to set things up to receive that type of midi data from Ableton into BMTP?
Thom
Hi and welcome back!
The easiest way would be to use a Ableton Live Script for a controller close to your mapping and then just use Bome MIDI Translator Pro to observe the messages Ableton Live sends and convert them using MT Pro to what your controller needs.
Alternately, you should be able to use MIDI learn in Ableton Live from buttons on your controller. Usually Ableton will send back the same information that it has learned from a given button.
What are you using for a MIDI controller?
Steve Caldwell
Bome Customer Care
Thanks Steve!
What I’m using is a Launchpad v1 to control Ableton channel mutes (track activators), and to simulate the channel solo functions, also by using the Ableton channel mutes instead of Ableton’s actual solo function.
Essentially its two sets of mutes that get toggled between depending on if a “solo” has been activated.
Why? Because the Abelton solo function is not able (hehe!) to be automated in the normal fashion, so you can’t record its function as integrated channel automation. Yes you can map a midi controller to it and record that separately, but specifically I want to record the effect of solo as mute automation because its easier to work with.
So far I’ve been able to get things working by using MT Pro global variables to remember mute status on each channel through toggling their values. It should probably be done bitwise, but I need some serious study to figure out how bit manipulation works.
One issue is that I would like to have some way to initialise the Launchpad Mute and “Solo” buttons to the state of the Ableton buttons. Somehow that status data would have to be sent from Ableton to MT Pro in one burst. I think this is possible because it seems to be able to do that with the BCF2000 I have running in MackieControl mode. Presumably there is some kind of request being sent?
Also, if I could rely on data being sent back to MT Pro from Abelton as it changes mute status, then that could be used instead of the internal variable manipulation that is currently be done to simulate it in MT Pro.
This becomes a bigger issue when any change in mute status is done through something other than the Launchpad, such as by mouse or the BCF2000. Currently that makes the mute status go out of sync with the variables in MT Pro, which is a sadness.
I did try setting up another MackieControl instance in Ableton and sent its output to a BMT virtual input. Indeed, as you said, midi data starts flowing when some controls are changed. This looks promising, if its reliable.
So far I haven’t found any documentation on how this works, which is why I was enquiring what the best way to approach it might be.
For example, one puzzling thing is that moving channel send controls in Ableton makes the midi output indicator in its top right corner light up, but no midi raw data shows up as being captured by MT Pro. Changing a channel volume fader however, does send midi that shows up in MT Pro. I don’t need send data right now, but it raises questions about what is going on.
Any thoughts gratefully received.
Cheers
Thom
Hi, in Mackie MCU mode Ableton Live will send Notes 8-15 on MIDI CH 1 for Solo and 16-23 for Mute for Tracks 1-8 respectively. It will send a value of 127 (0x7F) for Solo/Mute On and 0 for Off. Although in Ableton Live the Mutes DIM when solo is depressed, the Mute status is not sent to the MCU device.
You would have to assume that if a given track is Soloed, the other tracks are Muted. There is an option with Ableton Live to change this behavior (allowing for multiple solo tracks) but I can’t remember how it is set.
Now you may know that Mackie MCU only works on 8 tracks at a time so you have to bank up to do anything with faders greater than 8.
I didn’t see anything where moving Sends within Ableton Live actually sends any MIDI at all, although Pan does.
Maybe the best thing would be to look into Remotify.io and see if you could use that tool to create a custom controller MIDI Remote Script for Ableton Live.
Steve Caldwell
Bome Customer Care
That’s very useful, thanks again Steve.
The eight channel paging is a great point. Perhaps that could also reveal how the batch sending of parameter status out of Ableton can be invoked.
In Ableton, Solo can be exclusive or non exclusive based on a preference switch you set.
I have a button switch on the Launchpad which does the same thing, but the exclusivity is being handled in MT Pro because the actual Solo functionality in Ableton is not involved.
I’ll check out Remotify, and keep looking for some documentation on what is going on with the MackieControl interaction. Something must be being sent by moving the sends in Ableton because I can see the LEDs on the BCF2000 moving. Its a bit mysterious.
Cheers
Thom
It could be the scribble strip info which is a SysEx format but probably not very useful for your needs.
Hi,
I’ve got four sets of eight global variables (32) that are being frequently updated depending on the status of eight Ableton channels, with mute and simulated solo functions being controlled by MTP from Launchpad buttons.
Timing is important because two different groups of eight variables are taking control of the Ableton mutes (Track Activators) at different times. The timing is critical when control of the Ableton mutes is passed from one group of variables to the other.
Getting this working reliably on eight channels has meant introducing a 21 ms timer delay between pressing a button on the Launchpad and the control reliably taking effect on the mutes in Ableton, when switching between the two groups of variables.
I would like to reduce this lag because it can mean the difference between cutting off the attack portion of a sound, or not.
I can think of these issues that may be contributing to the length of the necessary delay.
The round trip between the Launchpad, MTP and Ableton.
A button is pressed on the Launchpad, variables are being processed and toggled in MTP, then midi is sent to Ableton, Ableton Track activators are being toggled, sending midi back to MTP, which is then processed and variables toggled again, and finally midi is sent to the Launchpad to update the LEDs.
I can’t really see a way to optimise this, all steps seem necessary. Would a 21ms lag seem expected in this round trip?
In the MTP processing, there is a translator adding up the status of eight global variables every time an Ableton Track Activator toggles on or off.
The only way I can think of to add up the status of the eight variables is to add them two at a time, and use another two local variables to hold the subtotals on the way, like this (s8 holds the total)…
// Calculate solo count by adding Solo statuses together
rr=sa+sb
ss=rr+sc
rr=ss+sd
ss=rr+se
rr=ss+sf
ss=rr+sg
rr=ss+sh
s8=rr
This is being done frequently.
Is there a faster way to do the addition, or does it not really matter?
Seeing as there are 32 global variables needing to be processed as fast as possible, would there be a measurable speed up by doing this with bit manipulation? I don’t know how to implement that, but it would be worth spending time to figure out, if it enables a lag reduction.
Thanks for your attention, and any thoughts!
Thom
Not sure why you need to toggle things twice here. If I understand correctly you are using a combination of mute (track activator) status and solo status from Ableton Live to control the mute(track activator) function of each track, correct? So if you press solo, it shows deactivation of other tracks on your LP.
Could you elaborate further? A button is pressed on the LP. Ultimately what do you want the button pressed to do? You want to toggle all track activators, then send the mute status back to your LP? Does the button also represent something you want to do with Solo?
Not sure why you need 8 global variables here. If there are 16 states to track (8 solo and 8 track) you only need 1 global variable which would consume 16 bits and calculating the total solo count would be much easier.
Maybe if you can walk me through exactly what you are trying to accomplish and I can figure a better way.
A few tips.
Here is what think you want but not sure.
Essentially you want to see both solo state and track activator state back at your controller. Right now, Ableton Live will accurately reflect solo state back to the LP but track activator state although correct within Ableton Live is not properly reflected on the LP.
Steve Caldwell
Bome Customer Care
Steve Caldwell
Bome Customer Care
Hi Steve,
Thanks for your questions, I’ll try to clarify below.
Sorry for the lengthiness - trying to be as accurate and concise as I can.
Short version
On the Launchpad there are eight “Mute” buttons, and eight “Solo” buttons. These buttons control the toggling of the Track Activator on eight Ableton channels.
Ableton Solo is not involved.
Long version
Launchpad:
8 x Mute buttons with LED feedback
8 x Solo buttons with LED feedback
1 x Solo mode button with LED feedback (selects between exclusive and non-exclusive mode)
1 x All Solos off button with LED feedback (enabled if any Solo’s are active)
Mute buttons
A Launchpad Mute button controls the Track Activator (TA) of one Ableton channel, and simply toggles it between on and off.
Solo buttons
A Launchpad Solo button controls the TA of one Ableton channel and toggles it on and off.
However, if no other Solo button is already engaged, then pressing a Solo button also toggles the other channel TAs that are currently on (so that they turn off).
If solo is working in exclusive mode, and an additional Solo button is pressed, then that channel TA is toggled (on) and the previous channel that was soloed has it’s TA toggled (off).
If solo is working in non-exclusive mode and an additional Solo button is pressed, then it toggles it’s channel TA, but no other TA is toggled.
If solo non-exclusive mode is changed to exclusive mode while multiple Solos are engaged, then the next Solo button pressed toggles all other channel TAs that are on (to off).
Finally, when the last remaining engaged Solo button is pressed, then the TAs all return to their status before any Solo button was pressed.
Other buttons
In addition to the Solo and Mute buttons on the Launchpad, there is the “Solo exclusive/non-exclusive mode” button, and an “All Solo disengage” button. The latter button is enabled if one or more Solo buttons are engaged. If pressed, all TAs are returned to their status before a Solo button was engaged. This button is useful in Solo non-exclusive mode, when there may be several Solo buttons engaged at the same time.
TA status and variables
The way this is implemented requires that three states of a TA are available within MTP:
1. Its current status within Ableton
2. Its status when no Solo is active (referred to as Mute A mode)
3. Its status when one or more Solos is active (referred to as Mute B mode)
There are 32 global variables being used like this:
1. Note number that defines a TA x 8
2. Current TA status of 8 x Ableton channels
3. Status of TA x 8 - Mute A mode
4. Status of TA x 8 - Mute B (Solo) mode
Mute A mode and Mute B (Solo) mode variables are necessary to separate TA status when a Solo is engaged, from TA status when no Solo is engaged. When you disengage the last Solo button, the TAs need to return to the state they were in before Solo was engaged. Also, you don’t want to toggle a TA when you change modes, if that TA has the same status in both modes.
Important things to remember
An Ableton Track Activator can only be toggled via midi from its current state to its other state (on or off), it cannot be set to on or off explicitly.
When a TA is toggled it will send midi that indicates it’s new state. It reports its either on or off via note on velocity.
In other words, you can’t tell a TA to be on or off, you can only toggle it from the state that its in to the other state. However, it will report what state its in (on or off) after it has been toggled.
When you change from Mute A to Mute B or back again (go from no Solo being engaged to one or more Solos being engaged, or vice versa), the status of channel TAs needs to be compared between Mute A and Mute B so that only TAs that need to be toggled, are toggled. For example if you press the Solo button for a channel that currently has its TA on, and no other Solo is engaged, then that TA should not be toggled, or it will end up in its off state when it should remain on.
The Ableton control being used throughout this design is only the Track Activator, which is recorded as an aspect of mixer automation in Ableton.
Ableton’s Solo is not used in this design, because it is limited by not being able to be recorded as mixer automation. So, this design implements a “simulated” Solo that uses Track Activators instead.
Many thanks for your tips!
Certainly I wouldn’t introduce a delay if things worked without it. The delay is necessary when switching between updating the TAs from Mute B (Solo) mode to Mute A mode when the last solo is disengaged, as described above.
I think it may be quite challenging to make only one translator responsible for changing a given variable, but I’m looking into it,
Cheers,
Thom
I suggest these are all done with a single global variable each using a bitmap. In general bit maps are easier to manipulate than separate global variables in Bome MIDI Translator.
1- One global variable for TA x 8 bits (The current status of the LEDs) – ga
2 - One global variable for TA Status x 8 bits (What Ableton Live shows) - gb
3 - One global variable for Mute A Mode x 8 bits (LED Status in Mute A) - gc
4 - One global variable for Mute B (Solo) Mode x 8 bits
(LED status in Mute B) -gd
You would probably need another global variable or bit to control whether you are in solo exclusive mode or solo non-exclusive mode.
As you go into each mode or press any of the buttons, you copy the value needed into ga and run a timer to display the LED’s (Both Solo and Mute)
You compare gb (What ableton shows) with either gc or gd to determine what to show in ga (the actual buttons), I’m still not 100% sure whether ga should capture both mute and TA Status if they are not a compliment of each so perhaps ga should capture 16 bits (TA and Solo Status) for display.
So the main things you need to consider is
This is quite an interesting situation and I could show you some bit map save and restore routines using bitmaps if you would like. I would stop short of actually designing a solution for your specific situation which is not included in free support.
With that said, I could provide a few routines I could show you as part of free support.
Now I have a LP MINI, a LP MINI MK2, a LP MK2 and a LP Pro. I’m not sure if either of these match the button map of your LP (is it a LP S?) but it would probably be good if I showed you these routines with the same note layout of yours so you could watch them in action.
Would any of this help?
Steve Caldwell
Bome Customer Care
Hi,
Here is a demo project to show you how this could work
The first preset assumes you have a Launchpad MINI MK2. Leave it unchecked if you don’t have that.
The second preset is for a Launchpad MINI MK1 or Launchpad S.
You should only check one preset depending on the model you have.
LPMIN–demo-bitmap-2023-04-02.bmtp (7.9 KB)
I hope you one of these controllers.
The comments of the rules, should explain how the bits are manipulated.
This post should also help explain the logic.
Steve Caldwell
Bome Customer Care
Wow, many thanks for the bitmap demo and suggestions, Steve!
I looked briefly at bit-wise operations in the manual when I started this, but it meant very little to me. Your demo, hints and a bit of study should help illuminate things substantially.
I’ve got the original Launchpad mk1. The Mini mk1 has the same layout, so the second demo preset should work well.
Later in the week I’ll get a chance to go through it all and figure out what’s happening.
Great support, greatly appreciated.
Cheers
Thom
Great, yes examples often provide more insight than just theory.
I hope you find it useful!
Steve