Feature: Lazy sliders

When using a control surface with passive sliders, and you add/remove tracks, the slider positions will no longer correspond to the actual value as seen by Ardour. That’s understandable.

With ‘lazy slider’ I mean a settable feature so that Ardour only changes the value when the controlling slider crosses the current value. For example: Ardour setting is 60, slider is at 40, when moving the slider up nothing changes until it reaches 60, and then Ardour starts moving with the slider.

This greatly reduces the chances of screwing up slider settings. My Boss ME25 guitar pedal has this feature (with turn knobs that control several settings) and it has proven to be very handy. Citing the docs:

When you call up memories, an effect’s parameters may not reflect the actual position of the control knobs. You can set how the parameters behave when the control knobs are moved in this state.

  • The value changes immediately as the knob is turned
  • The value changes once the knob is turned past the position corresponding to the currently set value.

This is the usual behavior of lighting desks without motorfaders. Maybe more important in a live show situation than with a DAW, but not a bad idea. There usually is (and should be!) an indicator if the position of the physical fader does not match the value of the virtual fader.

This is exactly what Ardour does, if you disable “motorized” in Generic MIDI Settings. You can also set the max allowed difference between the values (“smoothing”). Keep in mind that setting it too low may cause issues if you move the slider too fast.

I must be doing something wrong then.
In preferences, I have enabled generic midi, connected the control, no feedback, no motorized (both default). When I add a track (default slider @0db) while the corresponding surface (Zoom R24) slider is at minimum, a slight move of this slider immedeately jumps the Ardour slider to the actual position.

And what smoothing setting? try lowering it, perhaps

Korg Minilogue has this cool ‘scale mode’ which is alternative to the "lazy sliders’ mode. It would be great to have something like that in Ardour. It works like this (quote from Minilogue’s manual):

Scale Mode : When you turn the knob, the parameter value will increase or decrease in a relative manner in the direction that it is turned. When you turn the knob and it reaches the full extent of its motion, it will operate proportionate to the maximum or minimum value of the parameter. Once the knob position matches the parameter value, the knob position and parameter value will subsequently be linked.

I don’t know if it can be implemented purely on software side but it’s really useful.
Basically as soon as you move the slider, parameter reacts - you don’t have to make this ‘dry’ move to ‘catch it up’, risking that you’ll go too far. The parameter will not jump right to the slider value, but it will rather go up or down smoothly and proportionally to the slider movement.

Even with smoothing = 1.

Just for my understanding: the R24 controlls via the Mackie protocol. Does that get in the way with generic midi?

Yes. They’re separate protocols. If you use Mackie, generic MIDI settings have no effect (and vice versa). Pick one.

In that case I change this feature request to ‘lazy sliders in Mackie mode’.

That’s fair. Feature requests should go to tracker.ardour.org though.

I’m not involved with Mackie device development (since I don’t have access to one), but I have a feeling that this is unlikley to happen. As far as I know, most all Mackie compatible devices are motorized and touch-sensitive. The lack of touch sensitivity likely also already causing issues.

Other more experienced with the issue may chime in here or on the tracker.

That is indeed a smart way to deal with the issue!

For me, the main point is to be able to manually move the physical slider to its current (ardour) position without changing the (ardour) value. Unfortunately, I always forget to inspect the current value until I have moved the slider :frowning: .

The control surface you have is likely the only Mackie Control Protocol device without motorized faders (or perhaps one of 2 or 3).

Although I agree with the suggestion, its not going to be a high priority item given the low number of devices that are impacted.

Please do file a feature request for this at tracker.ardour.org.

Generic-midi and a bindings map seems a lot more appropriate.

You don’t have access to 99% of what the Mackie protocol provides for: no touch-sensitivity, no scribble-strips, no meters, not even solo, mute per track, no flip or strip modes, no automation-mode controls.

You may already have more luck by using generic-midi and the midi-bindings “Behringer BCF2000 Mackie Control”. Did you try that?

Does the Zoom-R24 have other modes than Mackie emulation?

NOTE: I’m not complaining! This is pure luxury…

Wow! I didn’t know I had such an unique device :smile:.
The Zoom R24 (and all of its siblings) are advertised as:

scrot20190506164614

They only speak Mackie protocol. Ardour “generic midi” and the “Behringer BCF2000

Mackie Control” give access to the track sliders, nothing else. Not even the master slider. And even then still the “jump” behaviour of the sliders, with settings no feedback, not motorized, and smooth = 1.
I can add additional bindings, but these seem to be tied to the actual track, instead of to the visible/active tracks. (E.g. slider1 should control the top track, slider2 the 2nd top track, even when tracks are shuffled/removed/created).

I guess there’s a lot to learn for me.

I own a Samson Graphite 49, which is definitely a non-touch, non-motorised, MCP-speaking device, so there are at least two such kinds of devices out in the world.

Not that the faders are that much use in MCP mode, but they’re better than nothing, and the transport controls are also nice to have.

The Samson has assignable encoders and can be programed. It just happens to have a preset that uses PB for faders like a MCP does. Same for some M-Audio keyboards. I guess that’s provided for some compatibilty, but it’s pretty much useless.

Yes, I agree the faders aren’t that much use in MCP mode, but the transport controls can come in handy occasionally. Definitely not worth changing anything in Ardour that’d compromise support for “proper” control surfaces for the sake of devices like this.

That seems to be intentional (otherwise you could just use the MCP surface).
I think you may have to copy+edit the file. In particular you’ll have to override the “motorized” setting:

Even if support will be added to MCP in Ardour to ignore mismatched surface faders, it won’t happen before Ardour6.x which is still some time away. – Meanwhile I’ve confirmed that catching up with mismatched values works correctly with 5.12 and a m-audio device, so if you want it now… mapping it using generic-midi is your best choice.

Hey sciurius. I don’t want to derail the thread but since you’re here can you share your opinion on Zoom r24 as audio interface? Does it play nice with Gnu/Linux? Are all of those 8 inputs available as separate tracks when it is in interface mode?
And are you happy with it in general as a device? Any nasty drawbacks?
Oh, and is there a time/size limit of samples you can use per track or per project?