Midi in Device 2 not working in teach in table

Thanks for your reply.

I’m with you on the main point: the ideal endgame is proper MIDI TeachIn with feedback and OSC. That’s also my preferred workflow. Less manual config = fewer chances for users to break things.

The difficulty in practice is hardware reality. The APC40 MK1 layout may have been the reference originally, but it’s getting rare and expensive. In some cases a used MK1 costs about the same as a brand new MK2. Newer controllers are cheaper and support more LED colors, and they often come bundled with Ableton Live Lite so people get basic beat detection out of the box. The downside is build quality — a lot of modern controllers feel disposable. So users end up buying whatever they can actually get, and that’s often not the MK1.

To give you context on why I’m pushing the “profile file” idea:

I wrote a C# adapter using NAudio to translate controller messages into Live.

I also pull musical structure info (build-ups, drops, etc.) from Rekordbox via DMX loopback with an Enttec interface. That drives lighting and timing.

Because there’s no clean trigger for certain actions, I even simulate keystrokes (like ESC) just to sync visuals with musical changes.

And because control is limited to the first 10 banks, I currently have to emulate mouse clicks just to access anything above Bank 10. There’s no direct way to address higher banks from external control.

On top of that I’m currently building a DSP layer for live beat detection and prediction of drops/section changes, with the goal of training it per genre. The idea is to get similar behavior without needing to rely on Rekordbox + Pioneer hardware forever. It’s not fun work, but it’s needed if you want proper sync outside that ecosystem.

All of this is basically me working around something I’ve personally been waiting on for ~3 years now: a finished TeachIn table with feedback. You can also see that a lot of forum questions are about MIDI TeachIn and supported devices, while other new features keep landing in Live. So clearly the demand is there.

About config files / .ini / .xml etc.: I get why you’re not a fan. Parsing user text input, validating it, dealing with edge cases like “this controller only ever sends NoteOn,” or “this one needs a SysEx init before LEDs accept color,” is annoying to maintain.

But from my side, I already have to solve that anyway.

Right now I keep per-device .ini files. When a new controller comes out, I don’t ship a new build — I just ship the file. Users drop it in, restart, done. I don’t always even need the hardware because manufacturers like Akai now publicly document a lot of their MIDI/LED behavior, so one user in the field can confirm it.

That approach solves a few real problems:

You don’t have to hardcode every controller in the main app.

Users don’t have to wait for a full software update just to get working LED feedback on “the new controller that just released”.

Things like “send this SysEx on startup to unlock RGB mode,” or “treat NoteOn with velocity X as release,” or “this is how Bank Active / Bank Inactive should light” can all live in that file.

You can also define behavior beyond Bank 1..10, which matters a lot for remote/OSC control. When you’re not physically on the hardware and you’re driving from a tablet (TouchOSC, etc.), you really want access to more than just the first 10 banks. Right now the only way to touch those higher banks is automation of UI clicks, which is obviously fragile.

To be super clear: I’m not asking you to maintain everyone’s mappings forever. I understand why that doesn’t scale.

What I’m suggesting is: keep developing TeachIn+feedback+OSC (please do), but also allow an optional “advanced device profile” file format. Even if it’s officially “use at your own risk,” that alone would unblock a lot of people doing shows right now.

In that file you could declare, per device:

how to light buttons for active/inactive states

what SysEx (if any) to send on startup

how to interpret press vs release when the hardware doesn’t send proper NoteOff

how additional banks/scenes/effects/sliders are mapped, without needing code changes

That would already remove a lot of pressure on you to immediately support every new controller and at the same time remove a lot of pressure on users to reverse-engineer the software.

And honestly, OSC support plus something like TouchOSC running on a tablet with a custom layout would already cover 80% of what I’m doing right now with hardware workarounds.

Thanks again for taking the time to read all this, and for even considering OSC feedback. I know it’s more work under the hood, but for people like me who build full show control around your software, it would be a massive step.

Regards,
Bart

Thanks for your reply,

You can test this with loopmidi, from the moment in my case when i create a vitual midi port "APC mini mk2" i get the following:
- Depending if the ID off loopmidi commes before the hardware device then all feedback is sent to the loopmidi and not to the hardware device anymore, this tells me the output is sent to the first device in the midi device list with the same name (this happens even when the loopmidi channel just exist, not even assigned)
- from the moment you connect the loopmidi channel to the 2nd input and you press on the hardware device, the program therefor keeps looping (normal behaviour for loopmidi) meaning it can't seperate 2 devices properly, while if you want to select in the Live the same device as the 2nd or 1st device it tells you they have the same ID

The question about the more then 10 banks is mostly for remote control, with artnet and the midi learn you can only use the 1st 10banks (That's why i tried to emulate the Akai device to get those more banks using the codes), i would prefer artnet or like mentioned in one of you latest online video's the OSC commands, that would be great, programs like TouchOSC can run on a tablet (with OSC or Midi) and offer for not that much money (I think like 10$ the ability to create your own custom controller on a tablet).

it would be a nice addon to be able to define default devices with a ini file for example, where you can customize for example "APC mini mk2.ini" to make it more flexible and still provide default values, while enabling the option for users to adjust colors etc with the use of sysex or hex values like in this example, this way people can share devices they have, or even decide to make custom themes like this example:

# MIDI Mapping (per-category defaults first, then per-item overrides)
# msg_type: 'sysex' or 'hex'
# send_code / receive_code: space-separated HEX bytes
# SysEx examples use non-commercial manufacturer ID 7D.

############################
# BANKS: defaults, then items
############################

[default_bank_on]
msg_type=hex
send_code=90 30 64
receive_code=90 30 64

[default_bank_off]
msg_type=hex
send_code=80 30 00
receive_code=80 30 00

[bank1]
# Override defaults for this item if needed:
default_on=90 30 64
default_off=80 30 00
msg_type=sysex
send_code=F0 7D 01 01 00 F7
receive_code=F0 7D 01 01 00 F7

[bank2]
# Example override to a different velocity:
default_on=90 30 50
default_off=80 30 00
msg_type=hex
send_code=C0 01
receive_code=C0 01

[bank3]
# No override means use category defaults above (fields optional)
msg_type=sysex
send_code=F0 7D 01 01 02 F7
receive_code=F0 7D 01 01 02 F7

############################
# SCENES: defaults, then items
############################

[default_scene_on]
msg_type=hex
send_code=90 31 64
receive_code=90 31 64

[default_scene_off]
msg_type=hex
send_code=80 31 00
receive_code=80 31 00

[scene1]
default_on=90 31 64
default_off=80 31 00
msg_type=sysex
send_code=F0 7D 01 02 00 F7
receive_code=F0 7D 01 02 00 F7

[scene2]
# Override to different note (e.g., 0x33)
default_on=90 33 64
default_off=80 33 00
msg_type=hex
send_code=B0 10 40
receive_code=B0 10 40

[scene3]
# Use defaults
msg_type=sysex
send_code=F0 7D 01 02 02 F7
receive_code=F0 7D 01 02 02 F7

############################
# EFFECTS: defaults, then items
############################

[default_effect_on]
msg_type=hex
send_code=90 32 64
receive_code=90 32 64

[default_effect_off]
msg_type=hex
send_code=80 32 00
receive_code=80 32 00

[effect1]
default_on=90 32 64
default_off=80 32 00
msg_type=sysex
send_code=F0 7D 01 03 00 F7
receive_code=F0 7D 01 03 00 F7

[effect2]
# Override to lower velocity
default_on=90 32 30
default_off=80 32 00
msg_type=hex
send_code=B0 20 01
receive_code=B0 20 01

[effect3]
# Use defaults
msg_type=sysex
send_code=F0 7D 01 03 02 F7
receive_code=F0 7D 01 03 02 F7

############################
# SLIDERS (CC examples)
############################

[slider1]
msg_type=hex
send_code=B0 10 00
receive_code=B0 10 00

[slider2]
msg_type=sysex
send_code=F0 7D 02 10 00 F7
receive_code=F0 7D 02 10 00 F7

[slider3]
msg_type=hex
send_code=B0 12 00
receive_code=B0 12 00

############################
# DEVICE LIFECYCLE
############################

[device_on]
msg_type=sysex
send_code=F0 7D 7F 00 01 F7
receive_code=F0 7D 7F 00 01 F7

[device_off]
msg_type=hex
send_code=B0 7B 00
receive_code=B0 7B 00

Is this version already up? And does it support more then 10 banks?
Do you also know if there can be a option to have like a standard set, for instance we can do a checkmark and then be able to send default defined values and responses with a bridge or virtual midi (This has the problem if i name it for instance i can use more pages, the problem is devices are mapped by device name, so if you have 2 controllers with the same name both respond, link by device id or "usb mapping key" would be more suited to link a default supported controller)