Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Half-Baked Feature Idea: Control Surface Optimization #13

Open
ratherlargerobot opened this issue Nov 20, 2020 · 7 comments
Open

Half-Baked Feature Idea: Control Surface Optimization #13

ratherlargerobot opened this issue Nov 20, 2020 · 7 comments

Comments

@ratherlargerobot
Copy link

ratherlargerobot commented Nov 20, 2020

This is more of a half-baked idea than a specific feature request.

I use Ardour. I use x42-eq as my go-to channel EQ. I have a Presonus Faderport 8.

The Faderport lets you edit controllable plug-in parameters, including for x42-eq. Presumably it's tapping into something in the LV2 layer. The way the x42-eq controls are presented in the Faderport seem to match the way they are presented in the Ardour generic controls for this plug-in.

The (slight) inconvenience is that the Faderport 8 only has 8 faders, but x42-eq appears to have 23 parameters that get mapped to faders. What would be ideal (for me, in this particular scenario with a Faderport 8, but not in the common case generally for everyone else in the world) would be to have the most generally useful parameters show up first.

The Faderport 8 workflow to edit the x42-eq on a channel is:

  1. Select the channel
  2. Edit Plugins
  3. Select the x42-eq plug-in
  4. Start moving faders around

Since there are 23 parameters mapped to faders, but only 8 faders, at this point you have to turn the pan/param knob back and forth to find the desired parameters. Which doesn't sound like such a big deal. But if you're working quickly and intuitively on a mix, imagine if the first 8 parameters were a four band EQ, with sweepable mid frequencies and adjustable bandwidth. Or in other words, the controls could be mapped out like this:

Fader 1: Gain 1
Fader 2: Frequency 2
Fader 3: Bandwidth 2
Fader 4: Gain 2
Fader 5: Frequency 3
Fader 6: Bandwidth 3
Fader 7: Gain 3
Fader 8: Gain 4

Instead of what they currently are:

Fader 1: Gain
Fader 2: Highpass Frequency
Fader 3: HighPass Resonance
Fader 4: Lowpass Frequency
Fader 5: LowPass Resonance
Fader 6: Lowshelf Frequency
Fader 7: Lowshelf Bandwidth
Fader 8: Lowshelf Gain

I realize this is a half-baked idea. I'm well aware. I'm not, even for a moment, suggesting that you just reorder the parameters for everyone, to benefit me with my particular control surface. I know better than that.

One other idea I had was to create my own local TTL file for fil4, but to change the LV2 index values around (or otherwise try and influence the order in which the controllable parameters appear). Would this even work? If it did, it seems like it might improve things for my idiosyncratic workflow. But how much trouble would I be asking for if I wanted to keep up with future changes to the plug-in? It seems like there are probably some traps for the unwary there.

Another possibility is some sort of configurable something-or-other to allow more generally creating local mappings that people could customize. That might be a whole lot of extra work and complexity for a feature that might not be used very often.

Or maybe there's something else that I haven't thought of.

Or maybe I should just do a bit more menu diving, or use the mouse.

Again, I really want to reiterate that I know this is kind of a strange request. Having been on the receiving end of requests that would make some strange workflow better for someone else at the expense of the general project, I know what you're probably thinking. So please interpret this as more of a report from the field, and some brainstorming about something that could be kind of cool, but only if it was possible to do so cleanly.

Finally, thanks for fil4, and the other x42 LV2 plug-ins. They are all uniformly fantastic!

@x42
Copy link
Owner

x42 commented Nov 20, 2020

With Ardour 6.3.352 the parameters are sorted by http://lv2plug.in/ns/ext/port-props#displayPriority

So in fil4.lv2/build/fil4.ttl you can add

pprop:displayPriority 500;

to input control ports. In case two ports have the same displayPriority, lv2:index (current default order) is used.

@ratherlargerobot
Copy link
Author

Thanks! That's extremely helpful. I'll give that a try.

@x42
Copy link
Owner

x42 commented Nov 20, 2020

Quick example, for the mono version only: https://paste.debian.net/1173560/
That assigns freq + gain of the 4 filters banks to the first 8 available controls.

I might make that the default with the next release. I'll have to play with it a bit, your mapping to add the bandwidth control might also have some benefit.

@ratherlargerobot
Copy link
Author

Thanks for the suggestion, example, and considering it. It's much appreciated!

My inspiration was an old Soundcraft 500 series console I mixed live shows on, and a Soundcraft Signature board that I have now. Four band EQ, with sweepable mids. If you add up the knobs, that gives you six. But of course, some consoles also have bandwidth/Q adjustments for the sweepable mids, which brings you to 8.

I'm not sure if there's a way to do this in the general case that makes sense for everyone. However, the Presonus Faderport series seems to have especially good support in Ardour (better than most DAWs actually, due to the custom driver).

Most of these control surfaces from every company, much like mixers, of course seem to come in banks of 8. There's probably some sort of sweet spot where things get displayed in groups of 8, with more features getting progressively added as your control surface gains more channels...

@ratherlargerobot
Copy link
Author

Just wanted to follow up and say that this worked perfectly.

For my own local setup, I decided to map the following parameters to the first 8 channels of the Faderport, to most closely approximate the familiar analog 4 band console:

Lowshelf Gain
Frequency 2
Bandwidth 2
Gain 2
Frequency 4
Bandwidth 4
Gain 4
Highshelf Gain

Basically, I just put "pprop:displayPriority 1000 ;" on each of those entries in the fil4.ttl locally, and it worked perfectly.

I realize that this might not be the best combination for everyone with every control surface, but it works great for me anyway.

Thanks again!

@x42
Copy link
Owner

x42 commented Nov 24, 2020

Glad that it worked for you

Eventually it would be nice to also allow to override/configure this per plugin in Ardour.

Also in case of LV2 it should be possible to specify the properties in a separate file.
I'll leave this issue open for a while to remind me to eventually build on the current infrastructure.

@ratherlargerobot
Copy link
Author

I agree, allowing this to be configured in Ardour would be ideal. Being able to have separate LV2 files could be good too for people using other platforms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants