Current stability of control surface

Installation & Configuration Linux
#1

Hi there,

Before going into more specific issue report, I wanted to inquire about what the current state of control surface is supposed to be. Is controlling ardour from any generic midi device supposed to work flawlessly ?

I’m learning ardour for a few weeks, and it has been a polished experience so far. I’ve installed it on a fresh ubuntu 14.04, using kxstudio-debian ppa. Recording audio was perfect, just like recording midi routed to external synth app, sending it back to ardour as audio, mastering the whole thing, no problem.

Then, I decided to give a shot at lv2 plugins loaded directly into ardour, like calf organ and samplv1 (coupled with midifilters “key range filter”). I’ve controlled midi notes and sequences of those using a midi keyboard (an umx490) and a sequencer (an electribe esx). Again, it was flawless, getting things done was my only concern.

Then I tried controlling lv2 plugins (still calf organ and samplv1) using my midi devices through control surface, and it got messy. I plug in my midi source within qjackctl to the midi control in port of ardour, but most of time, it won’t just work as is. I C-middleclick a control, it will ask for a cc, I’ll move a fader and popup will instantly disappear (which seems to indicated it has been recognized), but moving the fader then would not affect ardour. I have to unplug/replug my midi device / restart ardour (I haven’t identified a reproducible pattern yet, except restarting things) and control will be effective, with some glitches (I sometime move a fader half way without anything happening, and I get the control back as soon as I return it to its initial position).

That was a problem, but it’s still usable (once I have control, it can stay put the whole track recording long). What was more a problem was that, if I tried to record an automation, adding automation curve under track (through the automation section in track context menu) and setting its state to “write”, ardour would instantly crash when I move a fader while recording. My first reaction was that it must have been some bad combination of plugins or [whatever], and I tried a brand new session. But it did always the same : hard to get control, and instant crash when I get it and begin to record. Both esx behind a midi/usb converter and umx490 connected directly through usb produce the same result.

At this point, I decided to download the latest release from ardour.com, in case it was a bug specific to version from package manager and it had been fixed since then (and because I saw there has been indeed several releases since the one I used). Installer told me my cpu governer was not fit for proper usage of ardour, so I turned all cpus from ondemand governor to performance one, for the time of my session (but I would be surprised it causes such crash, I would expect mostly sound glitches, from a frequency scaling problem).

Anyway, I’ve noticed quite a difference after upgrade. It would not crash instantly when I move a fader. But I won’t have a chance to reach the end of a song without a crash if I was trying to control automation, be it in write state or even manual state, this time.

Now, I’m wondering two things :

  1. is it supposed to work just yet ?
  2. is it a problem from ardour or from my system ?

I don’t expect to see my problem solved here, and I’m fully aware the forum is not a bug tracker, but I wanted to be sure it’s worth creating an issue and I’m not just missing some obvious config. In that regard, here is more information :

  • ubuntu 14.04 (less than two weeks old)
  • ardour-3.5.403
  • jackd-1.9.10
  • midi driver : seq
  • current user in audio group with proper realtime permissions
#2

It works just fine.

You probably need to adjust the parameter called “Threshold” in the GUI for Generic MIDI control, accessed by dbl-clicking its name in the Control Surfaces dialog.

Alternatively, your controller, which you didn’t identify, sends messages of a form that we do not support.

Don’t use the “seq” MIDI driver. Please the manual for information on setting up MIDI on Linux.

#3

Ok, thanks for quick reply, I’ll try that (I’ve already read midi manual extensively, but it was a lot of information at once, maybe a second read will help).

Can you clarify what you mean with “your controller, which you didn’t identify, sends messages of a form that we do not support” ? The two controllers I’ve tried are the ones mentioned, the electribe esx and the umx490, hooked through “generic MIDI” control surface protocol. Any chance to find a list of what messages are supported and a mean to see which unsupported ones I’m sending ? (I suppose I could filter those). I can read C++ if it’s the only mean.

#4

We support all continuous controller and note on/off messages, but there are devices which, for example, have buttons which send a value when pressed and another value when released - these tend not to be very useful for most control functions because they do something (on press) then revert it (on release). Ardour’s own MIDI tracer window or gmidimon or kmidimon or even just aseqdump on the command line can be used to get a dump of the MIDI data flow.

#5

Thanks Paul, that was helpful.

For further reference, it was definitely a midi driver problem. Dropping seq and hooking jack to alsa using a2jmidid solved it.

I still have several crashes, but it won’t be the purpose of this thread anymore. Analyzing core dump revealed that one of those (happening when I jump in the middle a song and start playing) is actually a samplv1 problem, so I’ll try to isolate it a bit more further (determinating if it happens as standalone as well as lv2, to begin with) and report it to samplv1. An other one is harder to track, because it’s a freeze of gui which ends in a thread sending a SIGABRT. I’ll try to isolate it further when I’m done with samplv1 problem.