Add new comment

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).