MIDI Port-specific mapping

[loopology]

When doing MIDI Mapping, Live does not distinguish between separate MIDI Ports:
If you map some MIDI CC to a parameter in your Live Set by sending data via one MIDI Port, that parameter will also be controlled by the same data when coming from a separate MIDI Port.
I'm puzzled by this design choice. Isn't it more likely that you want to assign Remote Control to a specific MIDI Port? E.g. if you have several performers controlling the same instance of Live, the fact that Live does not distinguish between MIDI Ports is a limitation rather than a feature: If the performers are limited to use the same build of unconfigurable controller, they are forced to distinguish themselves by limiting their gestures to different parts of the controller. Even if said controller were configurable, e.g. by allowing the setting of the MIDI Channel, 16 is not enough wriggle room.
What is the rationale behind this design choice?
At least it should be a choice in a MIDI Mapping whether the specific MIDI Port is part of the mapping or not.
I'm not the first to struggle with this:

• After 10 years : why is midi mapping in Live so archaic?
• MIDI-mapping with multiple virtual MIDI ports?
• MIDI Mapping in Live - no MIDI port selection???

[S4racen]

ClyphX Pro Bindings allows you to map according to MIDI Channel, from the settings txt.

#********************************** [SETTINGS] *****************************************

# Below you can specify a list of MIDI Encoder/Knobs/Faders to bind parameters to.

# The entry format is: NAME = TYPE, CHANNEL, CC, MAPPING_MODE, NEEDS_TAKEOVER, BINDING

# --------------------------------------------------------------------------------------
# | ENTRY | DESCRIPTION
# --------------------------------------------------------------------------------------
# | NAME | A unique one-word name for the control.
# --------------------------------------------------------------------------------------
# | CHANNEL | The MIDI Channel number in the range of 1-16.
# --------------------------------------------------------------------------------------
# | CC | The CC number in the range of 0-127.
# --------------------------------------------------------------------------------------
# | MAPPING_MODE | The type of mapping mode the control uses. See the MAPPING MODES
# | | section below for information on mapping modes.
# --------------------------------------------------------------------------------------
# | NEEDS_TAKEOVER | Either TRUE or FALSE. This specifies whether the control needs
# | | takeover, which will typically be TRUE for standard knobs and faders
# | | with a fixed range of motion that aren't motorized.
# --------------------------------------------------------------------------------------
# | BINDING | The parameter to bind the control to. See the BINDING OPTIONS
# | | section below for information on the available bindings.
# --------------------------------------------------------------------------------------

# Example: MY_KNOB = 1, 10, ABSOLUTE, TRUE, SEL/VOL


https://isotonikstudios.com/product/clyphx-pro/

Cheers
D

[dave baker]

I'm pretty sure the reason for mappings to not be port specific is for portability. You can map stuff on your rig, and then it will still be mapped if you open it on your friend's machine, with whatever controllers he or she has (which would of course have different port names). That wouldn't be the case if mappings were port specific. For now, you'll just have to make do with 16 channels worth of available controllers. With 128 CC#s per channel, that's 2048 potential individual mappings. It's plenty for probably 99% of use cases, so that explains Ableton's design choice.

This is another one those things that will cease to be problem when MIDI 2.0 inter-device profile and protocol negotiation come into use. There are a bunch of things like that that Ableton and others are conspicuously not fixing or improving, and I think the reason is because they don't want to devote a bunch of resources towards implementing solutions (kludges) for an old system, when they'd rather be designing better, slicker, more powerful feature sets for the new system.

I, for one, have long wondered why we are limited to six controller scripts, or why decent MPE support is missing, or why there isn't a better way to use 14-bit controllers and stuff like that. I've stopped hoping for Ableton to expand on those though, because I think it's far likelier that those questions will soon be rendered moot by new protocols and self-configuring device profiles and whatnot.

[Catalyst-T]

I totally agree this should be implemented ASAP.
As great as Ableton is, it's been around for long enough now where we can respectfully expect to be able to independently midi map the same midi channel on two different devices...

I use three different midi controllers. The process of avoiding mapping conflicts is such a pain.
I'm legitimately considering to change to another DAW because of this.

[Crystal Jack]

Ableton, can we get a response to MIDI ports please? This is a significant limitation specifically with Ableton for trying to conserve CPU, whether you're doing orchestra or not.

Since Ableton doesn't provide any way to completely disable tracks, we are forced to rely on 3rd-party M4L devices like Mudo, but this is still not sufficient because it requires loading Mudo itself on each track which must remain enabled and also takes some CPU itself.

You've effectively blocked every opportunity to conserve CPU when either doing orchestra music requiring a large number of instruments, or when trying to build a template of curated sounds for EDM or any other genre.

This is a long-time active issue with support from many many customers. Several other major DAWs support this functionality, and it makes no sense for VSL and VEP to change it. This is something that needs implementation in the DAW, to support multiple ports.

Without either this or completely being able to disable a track to conserve CPU, you are seriously impeding my workflow and productivity.

Please give us a response, please make this a priority.

Thanks

[S4racen]

Ableton, can we get a response to MIDI ports please? This is a significant limitation specifically with Ableton for trying to conserve CPU, whether you're doing orchestra or not.

Since Ableton doesn't provide any way to completely disable tracks, we are forced to rely on 3rd-party M4L devices like Mudo, but this is still not sufficient because it requires loading Mudo itself on each track which must remain enabled and also takes some CPU itself.

You've effectively blocked every opportunity to conserve CPU when either doing orchestra music requiring a large number of instruments, or when trying to build a template of curated sounds for EDM or any other genre.

This is a long-time active issue with support from many many customers. Several other major DAWs support this functionality, and it makes no sense for VSL and VEP to change it. This is something that needs implementation in the DAW, to support multiple ports.

Without either this or completely being able to disable a track to conserve CPU, you are seriously impeding my workflow and productivity.

Please give us a response, please make this a priority.

Thanks

This is a user forum, you'll not get a response from Ableton here, one of the mods would be best to direct you with your request.
Cheers
D