Main menu
You are here
Fader in Plugins
There are two related requests from Qtractor users.
- Faders in plugins:
This would allow post-fader workflows, necessary for sends, and still be able to use the original Qtractor faders.
- Audio faders for tracks and midi buses:
It would simplify the control of software synthesizers.
Unfortunately I am not able to develop it, but I can conceive how it would work.
I have proposed it as an intellectual exercise. This is the result, and I want to share it with all of you.
The plugin would be inserted from the plugins menu.
It would only allow the activated/deactivated option. That is, only an audio fader could be inserted in audio strips, and a midi fader and/or an audio fader in midi strips.
The strips would have to be slightly redesigned, so that the faders have the same height. This would allow you to switch between audio and midi faders in the midi strips without any problems.
This is my solution. Move the icon down to the fader area. This also allows you to gain space in the title and a larger display of the icon.
If the last fader selected is the midi one (image 1) it would show the midi fader with the midi meter in the first position.
If it is the audio fader, it would behave in the same way, putting the Volumeter before the midi meter, as shown in image 2.
Everything would be done from the plugin programming.
Basically it would consist of a fader position plugin.
This simply lets the signal pass to the lower plugins and forwards the signal to the plugin box output.
It also inserts a signal cut just before the plugin box output (logically this part would not be visible to the user.)
However, the midi strips would have to be reprogrammed so that they can also have the audio faders.
| Attachment | Size |
|---|---|
 insert-fader-plugin.png | 45.46 KB |
| strips.png | 110.9 KB |
| flow.png | 46.6 KB |
re. Fader in Plugins
remember this one?
much of what's there addressed and discussed is quite primordial :)
I do also remember some exchange taken with @bluebell about this very subject, and for long dismissed to (cough, cough) v2.0,... or was it just post-the-unthinkable-v1.0 ?:)...
anyway, let's think deep about it, on whether this feature is insurmountably necessary, will you?
cheers
ps. I hear (all of) you! just not in the mood right now ;)
There are many ways to solve
There are many ways to solve it. My way is leaving builtin fader and pan alone (0 dB, center) and use an simple LADSPA stereo amp plugin for volume and x42balance for pan.
Plugins before the amp plugin are pre fader, after it are post fader. Simple and good.
But it's a pity that I can't use the builtin fader and pan as controllers.
My favourite solution would be that builtin fader and pan are configurable per track: either they work the old way or they do nothing but can be configured as a plugin's parameter control source.
re. Fader in Plugins & There are many ways to solve
Hi, Rui:
__"remember this one?"
I didn't know it. There you say:
"i'm sure there's at least one of many LADSPA plugins that can certainly function as a fader pseudo-plugin, same for EQ. plugins you're welcome to try."
It's the solution we all end up arriving at :).
__"this feature is insurmountably necessary?"
The questions I ask myself are:
1_
Would Qtractor be more usable with this feature?
Yes, because we could use faders that are much more handy, more comfortable, and more precise than plugins.
Yes, because faders would never lose their functionality.
Yes, because it would allow us to use the audio streams of Software Synths as what they are, audio.
Currently they are unusable in the case of auxiliary sends, as shown in this screenshot of my template.
2_
Considering that post-fader flows can be created with external plugins,
Is it worth the effort to develop this feature?
That can only be determined by someone who is qualified to do the development. I am not.
However, I do have an opinion and I have communicated it to @windowsrefund
https://www.rncbc.org/drupal/comment/10922#comment-10922
There I say:
"Too many problems to solve for something that would not really improve the workflow.
It would simply prevent the original faders from no longer making sense.
In the end we would have movable plugins, something we can do now with external plugins."
3_
Does it make sense to come up with solutions even if they may never be implemented?
For me, yes. It sparked my curiosity: What could be the most efficient behavior of this feature?
Coming up with solutions and sharing them:
- Satisfies my curiosity.
- I learn.
- Maybe they will be useful in the future for this case or others.
---
Hi @bluebell
"My favourite solution would be that builtin fader and pan are configurable per track: either they work the old way or they do nothing but can be configured as a plugin's parameter control source."
I have considered several options. I am glad you brought up this solution because I can now explain the pros and cons that I see in each one.
1_
Controlling external plugins from Qtractor faders (the one you propose):
For PAN there is no conflict, because a range between -1 and 1 is standardized.
However, for gain each plugin provides its own scale.
With some plugins the Qtractor fader would appear completely down, in others halfway down etc.
This would be solved if someone develops or adapts a gain plugin already made, so that it corresponds to the Qtractor scale.
I had not considered this until now.
With that plugin it would probably be the most viable solution. It wouldn't involve modifying anything in the Audio Engineering, nor in the behavior of the interface.
It would just have to create a way to send those signals to the plugins from the Qtractor faders, and add color codes to identify which fader is affecting which plugin.
2_
A dedicated Fader plugin that is always present, Ardour style:
I think it would cause confusion for those starting out who haven't considered or don't need post-fader flows.
3_
The proposal with which I open the thread:
Requires touching up the interface and the behavior of the plugin box.
My conclusion for now:
I think the first one (the one you propose) is the most viable. It fits better with the philosophy of Qtractor and does not require changing anything in the behavior of the current code. It just need to add new functions that only affect the interface signals, not the engineering.
Of course, it is necessary to develop or adapt a lv2 or ladspa plugin to be compatible with the Qtractor scale (maybe I'll try it myself).
I'm still thinking about
I'm still thinking about option 1: "Controlling external plugins from Qtractor faders."
1_
There's really no need to color code faders and plugins.
Thanks to the new Alias feature it would be clear just by naming the plugins appropriately.
There's also no need to create a plugin tailored to the Qtractor scale, just choose a plugin that gives you a scale you're comfortable with.
2_
However, if we assign a fader, the boxes that show the value should change to a generic one.
They would no longer be "dB" or "%" but a generic value that admits positive and negative values with at least 2 decimals from the plugins.
This option is perhaps the easiest to develop.
But I find it more confusing than my initial proposal, "Faders in plugins"
It's not easy
The schematic I posted is incorrect. Not only is it inaccurate, but it also requires sending the signal back to the plugin box... confusing to program and error prone.
There is no way to adapt the functionality to existing code. I'm studying the Qtractor code and I see that there is no simple solution.
Many things would have to be rewritten.
It would have to be reprogrammed so that the faders were actually a plugin process and not a post-plugin process. The midi meters (I mean the file that creates the midi fader) would also have to be reprogrammed so that they had two modes, the current midi and an audio mode.
I've been looking around a bit to see if I could try to develop the feature myself, little by little, by learning. But no. There are many specific things about audio that I don't know about.
I also lack an overall vision, and this feature touches on many deep points, such as audio and midi engineering, plugin system, interface generation... spread across many files.
In the world of software development, audio is by far the most difficult.
Amen! That said, I still
Amen! That said, I still think the Insert mixdown method is the move. Maybe take a break from the complicated and give it another spin? Not saying a spooky gremlin of some kind or another doesn't exist in there somewhere (I mean, how would I really know?) but it just works too well to purge from our collective consciousness IMHO.
Add new comment