-
Notifications
You must be signed in to change notification settings - Fork 14
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
Comments
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
to input control ports. In case two ports have the same displayPriority, lv2:index (current default order) is used. |
Thanks! That's extremely helpful. I'll give that a try. |
Quick example, for the mono version only: https://paste.debian.net/1173560/ 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. |
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... |
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 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! |
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 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. |
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:
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!
The text was updated successfully, but these errors were encountered: