Problem with Midi Learn

First of all: i’m new here in the forum, so let me say “hello folks” ! :slight_smile:
i’m pretty new to ardour, but learned a lot of stuff, although i still have some issues, i can’t find a solution for. one of these is, how to get midi learn to work.
i use ardour 5.8 on linux mint 19.2 with alsa to jack midi bridge for an m-audio axiom air mini 32 keyboard. i can see the a2j inputs and outputs in ardour and they do work, when i directly choose them as input for a midi channel for example. but i need to control faders, mute and solo buttons etc., so i activated generic mid in the preferences, chose my axiom keyboard as input device and activated feedback. but when i use the ctrl / middle-click for a fader of a track, nothing happens. i tried a thousend times, changed settings, connected generic midi control to the track, but midi learn won’t work, the message “operate control now” won’t appear. what am i missing? please help and thanks in advance!

Optimal solution:

  1. Get ardour 5.12. Version 5.8 is not a lot older, but there’s no reason to be using anything other than 5.12 (which is itself a couple of years old because of the time we’ve taken working on 6.0)

  2. Stop using JACK and just use Ardour’s own ALSA audio/MIDI backend

  3. It should just work. Let us know if it doesn’t.

hello paul, thank you for your quick reply. :slight_smile:

  1. the version i use came with my linux mint distro, but yes, i want 5.12 to get, but i need to know, if midi control work for me, as that is a very essential feature for a smooth workflow.
    2.+ 3. unfortunately that didn’t work too. tried alsa as audio-driver and alsa raw as midi (but tried alsa seq too), but i had no luck. the alsa midi inputs do work to record a midi track in ardour for example, but generic midi still doesn’t work. the “operate controller message” now appears (with jack too, seems that i was to clumsy to get a middleclick on my mouse… :D), i activated generic midi with my keyboard as input device for incoming midi, but still nothing… :frowning:
    any other ideas?

You can get a free/demo version of 5.12 from http://ardour.org/download and install it in parallel/alongside your distribution version.

If that doesn’t work, I’ll ask some more questions :slight_smile:

hey paul, thanks again! i followed your advice and installed the demo 5.12 - still no luck! :-/ same like in 5.8. what am i missing?

P.S: Uhh, i recognized, i got it wrong with the version, i actually had already 5.12. running on my pc since i installed it via kxstudio repository.

Just tried it on 5.12. Works precisely as expected. Can you post a screenshot of the MIDI Connection patchbay with “Hardware” selected on the left (vertical) axis and “Ardour Misc” selected on the bottom (horizontal) axis?

Also, Window > MIDI Tracer (select “MIDI Control In”) … does it show any messages arriving when you operate the controller?

hey again! :slight_smile: the midi tracer shows incoming cc messages and note events on midi control in. but still not working…

oh my goodness… i’m so silly! i thought, i had to left-click the message “operate controller now”… :-/ now it works! 1000 thanks for your patience! and sorry for my dumbness and my poor english! :slight_smile:

There should be no need to left click the message. It should vanish when a suitable MIDI message arrives and is “bound” to the control you clicked on.

1 Like

the ‘surface controller’ also needs to be set accordingly in the preferences… the term ‘midi learn’ is something advance plugins use for having per-midi-key effects… It took me awhile to find out that my MIDI instrument also supports HUI as well as Mackie, and to have better surface-controller support for my Midi instrument, I needed to apply button settings from the Midi instrument (which altered the ‘surface controller’ behaviour coming from the midi instrument)

If I am correct, the ‘General Midi’ surface controller setting is for the classic “HUI” and the “Mackie” things is something more modern to use…

Almost nothing in ahms post, alas, is correct.

Your description of MIDI Learn is effectively incorrect. Plugins should never attempt to implement MIDI Learn themselves - this is a task for the host application (around these parts, that mostly means Ardour).

Ardour does not support HUI. We do support Mackie Control, which is related to HUI but not identical. HUI is absolutely not “part of Mackie Control”. Mackie used HUI as inspiration for Mackie Control, that’s all.

“General MIDI” has nothing to do with control surfaces, but is a definition that maps specific instrument sounds to MIDI program/patch numbers.

What Ardour calls “Generic MIDI” just means “any old control surface that simply sends its own special conception of Controller and Note messages when you use it”. There are still quite a few of these around.

1 Like

I recently purchased a plugin that has something called a ‘Midi Learn’ feature which maps notes to different effects. I suppose the context here would mean to use the terms differently.

The Pro-Audio Key 88-Key Midi instrument ( – this one https://m-audio.com/products/view/keystation-88 ) – is detected as a compliant Midi device here on Linux, but also has a special “HUI/Mackie” toggle on they keyboard instrument… I use a MIDI tracer and can see that the Midi messages are more complex when set to one of these modes.

I do not know what pertains for the base definition device/maps for ‘General Midi’ in Ardour’s settings, and I was not sure about it so I can only have presumed it pertains to HUI-related settings in its definition files…

That should help clarify/answer an earlier post I requested details on this because I couldn’t figure out why 3 or 4 high-end play keys were also the same “values” as transport buttons on this midi instrument… Toggling between HUI/Mackie on my instrument and changing the surface control in Ardour helped to overcome this, … and I went as far as attempting to generate my own binding maps to fix a fader.

“The Ardour Manual”
http://manual.ardour.org/using-control-surfaces/midi-binding-maps/

“The Ardour Manual”
http://manual.ardour.org/using-control-surfaces/generic-midi/midi-binding-maps/

For what it is worth, I’m using other things than Ardour, and may have forgotten how some Daw’s explain to use “Midi Learn” in different ways, but I’ve grown accustomed to reading about them in the plugins, totally forgot that it is also referred to by the way ardour uses this approach of supporting legacy Midi messages as a form of Surface control input.

^ This area I struggled a lot with and couldn’t find any documentation on Ardour’s site what “General Midi” was actually referring to – so thanks for clearing this up for me…

kudos!

Again, HUI has nothing to do with Generic (note: not General) MIDI control surface support. HUI uses existing MIDI messages but defines entirely new meanings for them. Ardour does not support this, but it does support the quite similar Mackie Control protocol.

Any plugin that tries to implement MIDI learn is making a mistake. This is a task for the host, not the plugin. MIDI Learn in this industry/sector means “the user selects some control, then causes a particular MIDI message to be delivered, and hence forth, that MIDI message and related ones will affect the value of that control”.

MIDI Binding Maps in Ardour are in some sense the opposite of MIDI Learn. Rather than dynamically select controls and associate particular MIDI messages with them, a binding map is a fixed definition that connects controls and MIDI messages. Someone has to write a MIDI map for a particular control surface, and they have a lot of freedom to decide what controls will be managed.

If a device supports Mackie Control (and does so reasonably compliantly with the definition of Mackie Control) then it is always preferable to use Ardour’s Mackie Control support instead of trying to create a MIDI binding map.

thanks for your extra explanation, would you happen to be kind enough to let me know if you see an issue pertaining around “Midi Ports” with “Control Surfaces” in preferences? As far as I know the ‘surface control’ is the only area I know that would allow it to be possible to set controller mappings to transport controls on the daw along with the midi ports section. The problem I have with this midi instrument is it has two midi ports(via 1 usb connection): one for “control”, and another that “sends notes”. It’s my first midi instrument and I do not know well enough of the trends, but in order for me to fully use all transport/fader controls means I have to do the following: Set both midi ports as a surface controller and set the appropriate settings in ‘Midi options’…

The result is: all the controls work and I can map the one-fader. < just one problem: I cannot send “play notes”… :slight_smile: (“why”?)

So this USB midi keyboard has these two midi ports.
“a2j:Keystation Midi 1” which I call port #1-> sends the play notes AND 1 fader control data.
“a2j:Keystation Midi 2”, which I call port #2-> only sends mackie control data.

I just verified this again on Ardour6 beta -> If this is a BUG and Ardour6 is not “honouring” the “Music data” option settings then I will file a bug. Let me know if this is a bug and I will send in a report…

[Focusing just on port #1]
The problem I am having on this midi keyboard is the one fader which sends a “CC-7” message on the “send note” port (port#1). Ardour honours the “Control Data”, but NOT the “Music data”.

Is it normal to have “CC-7” with Midi notes? I supposed it is. But then if that is the case, then why does Ardour not honour the “Music Data” option from the Midi options?

Here port#1 is set to “Generic Midi”, and Port#2 (same 1 midi instrument-- I only have 1 midi instrument), is set to ‘Mackie’. The Midi options reflect what is enabled for ‘Control’ and ‘Music data’. Music data is never sent from port#2.

Despite setting port#1(“a2j:Keystation Midi 1”) to having the “Music Data” option in Midi options, I am no longer able to set port#1 to the Midi track.
Screenshot_20190927_004919

Here are my Control Surfaces,

If I remove the “Generic Midi” surface controller, I can then set the Midi track to using port 1 and then everything works except just for that one fader. I don’t know why it is not sent on port 2 along with the other transport controls.


when I look at settings here I noticed there’s “m-audio axiom” available(for Toxonic’s case)


I suppose then this is selected, and then the Midi options could be verified that proper music/control data options are set. My understanding is the “Left click” did nothing because the surface controller settings prevented any changes to the defined bindings… If a user is able to change a mapping it is because it is not defined in the surface-controller definition. (here I tested this theory and came to this conclusion)

http://manual.ardour.org/preferences-and-session-properties/preferences-dialog/#preferences-midi_ports

I suppose if there are other midi devices like the one I have, it means some “fader control data” are not sent from the same midi port as the rest of the “transport” messages. This is the case with the M-audio keystation 88-key…

I’m not sure if there’s a bug here or maybe it’s the way Ardour6 is behaving. I do not know why the “Music data” option does not apply after a midi port gets set as a surface controller – the midi port is no longer selectable to be binded to a track, … I tried looking for this information online, and couldn’t find an explanation. Maybe this is the way Ardour is supposed to work, but then what’s the point ---- shouldn’t “Music data” also encompass “Midi note events”?

http://manual.ardour.org/preferences-and-session-properties/preferences-dialog/#preferences-midi_ports
“MIDI Inputs…Music Data if checked, Ardour will consider this device as a source for musical data input (notes, etc…)”

As usual your responses are informative and helpful to us.

thanks again

Not sure I agree with this honestly.

There are multiple plugins, generally instrument plugins, that could benefit from binding controls in this fashion. I understand your response that the DAW should be able to do this, but it can be difficult in the DAW to navigate through literally hundreds of parameters to find the one you want to bind that the plugin UI brings to the front and center.

If the host is passing thorough MIDI to the plugin anyways, why shouldn’t the plugin allow for that binding, other than the possible redundancy?

Seablade

Welcome to the club, Toxonic … bienvenidos, добро пожаловать oder willkommen :sunglasses:
Is your midi-learn issue resolved? I had similar problems with my midi-controller when I started.

Please note, with Ardour, you will find some good direct support - even from the people behind the applications and plugins.

1 Like

the loomer plugins have Midi Learn and are easy to spot,

I would of thought Midi Learn meant beyond mapping controls. I was wondering if the terms could encompass more things as I can see support for them in certain plugins… so this is why I would of thought different.

I think this confuses other users as well when they are first looking it…

thanks

Hey somethis, thank you! :slight_smile: Yeah, it’s working fine now, it was my own fault! Thanks anyway! :slight_smile:

First of all, the host may not always pass through MIDI data to the plugin. – This is why Ardour has a dedicated control-input.

But more importantly, a plugin must never change its own control inputs. That would lead to ambiguities.

Say a plugin internally binds “gain” to a MIDI CC message. Now Ardour’s automation playback sets “gain” to -10dB, but a CC message arrives concurrently and the plugin changes it internally to +10dB. Now what?

The only way to resolve this is to go via the host, Ardour in this case can ignore the event or record it (if automation write or touch-is enabled).

PS. it is valid for a plugin to handle MIDI-CC if, and only if, it affects internal state that is not exposed as automation control.

So this is probably a conversation I should take up in IRC with you, so let me know if we should move there:

But here is a counterpoint, many synths especially utilize LFOs internally to modify control information automatically. Your example would conflict with this operation as well, which has nothing to do with control data from host one way or another.

In these cases it should be up to the plugin to determine what to listen to or not I think. I don’t see it being the hosts responsibility to keep track of every possible choice a plugin makes, but rather it is the hosts responsibility to pass along the appropriate control information to the plugin. Yes you will get some odd occurrences, particularly when talking about automation lanes, but I think that is part of using the plugin that the user needs to learn.

  Seablade