Ableton Forum

Ladies, gentlemen,

The lack of time forces me to introduce the idea using the earlier discussion (check it here: viewtopic.php?f=3&t=179808 )

Il'l write a bit more on the idea, and current state of the work ASAP.

For now briefly:
two midi controllers (UC33 and Doepfer Drehbank) are supposed to be the total hardware control on every device loaded in the Live project, mixers as well.

The M4L devices itself is to be the only machine contained in the session by default, having its own midi channel and fixed midi mapping ( + the midi map for the mixer is included in the session too).
So the session starts with one midi chan only, and no matter what amount and kind of tracks You add, and what You put in them - You may always control the junk with those two controllers (this solution is for my own purposes, but the device is to be easy for rebuilding in order to work with any midi controller).

Although the work could be done by now, it's still in progress, as there's a bit to think on how to manage the devices packed inside the racks - we want the full control on them, and we want it now!

A good and mindblowing discussion on that will be very appreciated.

* * *

Digging in the thing:
There are two methods of choosing the device which is to be controlled with the patch.
Method #1which at the moment is implemented and works:
we choose the track, then choose the device, push the load button and then, if needed choose the preset (one of four containing 64 parameters). The idea is simple and frees from the computer keyboard or mouse. However, as written above, it limits the control of the racks, and forces to make the inner mapping for the 8 macro knobs, which isn't enough especially when talking of drum rack fill with several instances of operator (which has 189 parameters for control by M4L).

The rack itself has of course an ID which may be treaten same way as a track ID - to list all the devices contained within. However at this point I stopped constructing aware of potential loops in structure. I think it is the dead end, as the rack may contain another racks, and this nesting might be almost endless, in which case the procedure of selection the desired device will be simple waste of time.

Method #2 (for now it is a theoretical model that needs to be tested):
Forcing the device to use the subpatches and commands for the control surface/blue hand things, to get the desired device ID, and then simply load all the needed junk.
This method needs a user to highlight the desired device manually, but makes the patch much simpler, i.e. easier for further tweaking, and more stable.
Also the patch is thought to be used in studio rather than onstage, so there's no problem about using computer keyboard and mouse.

(...)

A few words on this idea now.
Having two controllers working together I'm about to make one of them a control surface device (UC33), with a dedicated knobs in one of the instant access presets (1-4).

The patcher will get the needed infos on the selected device providing part of them to the control surface, but mostly - creating midi mapping for the other controller. At this point if the Live is successfuly fooled, and doesn't disable the device parameters for the control surface device, then everything should work.

Will write on the results - hopefully soon.

After a little investigation I found that it is much easier to build a control mapping device w/ a "path live_set appointed_device" query, however, the patch misbehaves a bit.
Everything seems working fine when the patch is opened for edition, and as soon as I get it saved/frozen/closed - it works completely different, like part of messages couldn't reach their destination.

Time for questions:

1. Any ideas on how to toggle (enable/disable) the live.remote~ ?
I've temporarily set a trigger changing the ID to 0, but it doesn't look good.

I would not use live.remotes for so many parameters.


this would toggle control on and off.
the path message is just for example, however you feed the id's dynamically will work.

Thanks JS,

I was thinking of that, since project day one, but found it used by ableton team. I'll check yet if live.remote works fine.

In the meantime I've managed to build a mechanism allowing to tweak the parameters by controller as well as traditionally with mouse/computer keyboard. The thing looks fine, and almost as soon as one starts tweaking the controller's knob the device's one is greyed out as if it wasn't available straight in live (which is true at the moment), but when the user stops messing around with the controller the device GUI knob is again available for further tweaking, and it updates the patcher knob's value.
There's some troubles with it, as 7-bit long word is not enough sometimes, but the mechanism seems to be stable and sometimes only blinks two or three times.
The only missing things now are
+ the good mechanism for updating the value of the patcher knobs when the midi mapping is loaded
+ the mechanism to save/load own preset banks of mappings dedicated to the devices.

The rest is gonna be great fun, as the patcher is going to be probably very easy to be reconstructed for working with almost every model of the midi controller. So I'm thinking of releasing it at maxforlive.com in a few friendly versions.

Again, JS - I've checked Your solution, just to remind what kind of trouble it causes.
Although it's probably lighter for CPU, still it might nod work properly with extremal values (minimum and maximum) when rescaling the MIDI mess to actual parameter's range.

At this point it seems that live.remote is better as it smoothly translates those values.