combine multiple midi remote scripts in max to free up slots in ableton
Hi all,
Can anyone shed light on this matter for me?
Abletons' six slot limit for midi remote scripts is preventing me from controlling my set the way i'd like to. I use multiple Launchpads (currently 4) for clip/mixer control of a large performace set. using up one midi remote script slot in Ableton per launchpad is preventing me from accessing all my channels via a dedicated launchpad strip. It also prevents me from adding any more remote scripts, as my six slot limit is full up!
I can imagine a workaround which merges the launchpads in max, and presents the new merged 'superlaunchpad' as either a single midi remote script, or a m4l device.
The beauty of this method is that one could add more hardware into the max environment, without increasing script slot demand in Ableton .
Is M4L the environment to realise this? I would appreciate any info/opinion/warnings about how to go about this.
I am pretty much a noob in max - I do a fair amount of osc routing in pd, and made some midi stuff in max a while back, but have pretty much no knowledge of objects/dataflow specific to max.
Max != python.
If you wanted to recreate the Live API that's used for writing control scripts in Max/M4L, that would take you a LONG time (and probably wouldn't be as smooth as Ableton's implementation).
Someone can correct me if I am wrong, but I believe that the Launchpad is one of the devices that needs a 'handshake' in Live to function. I think that's hardware specific, and you wouldn't have a way around that.
The alternative is writing a script that takes input from all four launchpads (routed together as one MIDI input in Max) You can't have multiple MIDI ins/outs going to/from one instance of a script.
My advice is figure out another way to control your set. Unless you're really good with Python, or have a ton of time on your hands.
Evan,
Thanks very much for your reply, and your candour.
Your idea of an alternative is interesting, and a had occurred to me in a more primitive form - routing all four LPs into a single midi port with each LP forced/remapped on it's own midi channel, and then into a single remote script which communicates along the different midi channels.
you wrote:
'You can’t have multiple MIDI ins/outs going to/from one instance of a script.'
but can you have seperate midi
channels
addressable from a single script?
I understand that it propbably wouldn't be a case of simple duplicating the python code in the script and changing device ids/channels for each duplication, but is this realistically speaking the simplest way to achieve the outcome?
thanks again,
dp
Yeah, you could do that, route all the LPs through a channel adjuster max patch thing. Then you could duplicate all the controls and components in the Remote script and make them listen/send on a particular MIDI channel. MIDI Channel is one of the arguments of most control elements in the API (buttons, encoders etc.)
That being said, Ableton doesn't provide you with editable python files, all the scripts in the Live distribution are compiled .pyc files. There is a github repository that has most of the scripts around decompiled (search for live remotes scripts on github), but you can't copy/paste the code from this repo. Some arguments/characters are incorrect and they won't compiled at runtime.
It's not impossible to reverse engineer the script with these files, but it would be time consuming and frustrating. You have to restart Live every time you make a change in the script when developing. It sucks.
Thanks again, Evan.
I'm familiar with the work of Julien Bayle, decompiling the stock scripts. It is positive to hear that this could potentially be a route through! Cheers aswell for the headsup regarding the headache of rebooting ableton after every change - I already have to do that when modding ClyphX .ini files, and have a basic project file which helps minimise the disruption caused by legnthy load times.
Looks like a crash course in python is moving up my to-do list!
If anyone else can chime in with thoughts on the matter - or indeed a way to identify the appropriate elements of the python files to spped up the process, i'm all ears!
cheers,
dp