Forums
I think Qtractor has evolved a lot and probably there will be no changes before the next release 1.5.10. So far, so good.
Is there some hope that we can expect fader and pan to be configured as source for plugins' parms, e.g. the fader (both in MIDI and in audio tracks) to control the volume of a simple amp plugin. That would be one way to allow post fader aux sends while retaining full backward compatibility.
re. Maybe ... fader and pan...
you mean PRE-fader/panning?
gosh, maybe in next year round ? =:)
cheers
depends
Pre/Post depends if MIDI or audio track.
My solution at the moment is not using fader and pan (both in MIDI and audio tracks) and placing a volume and pan plugin in the plugins box. Compressors are used best before, aux-sends to reverb and echo buses best after these plugins.
Of course you can split the plugin box into a pre fader and a post fader part, but that would be only possible in audio tracks.
I'd say the Qtractor way of doing it is leaving it to the user by providing a checkbox to make fader and pan losing their old function and becoming controllers for plugins. Default should be the binding to the old function to stay backwards compatible.
After version 1.8, I thought... now what?
Qtractor had finally managed to incorporate all the MIDI and audio functionalities. :)
There's still room for improvement in the user interface, and this is one of those areas.
I said it a while ago, and I stand by it, that I think @bluebell's approach is the most suitable.
Just a few nuances. For me, the functionality would be that right-clicking on the fader would bring up a selection menu identical to the automation menu, although in this case, "Assign to" might be a more appropriate title. This way, you select which value of which element the fader controls. As for the values, it should work the same way the shortcut fader in plugins does now; that is, it takes and displays the values and scales offered by each plugin. If you select track or bus values, then the values offered by the track or bus would be displayed—that is, the current values.
The only thing that still bothers me a bit is that I think the fader heights on MIDI and audio tracks should be standardized, since the MIDI fader now needs to be able to display any other value.
One solution could be to distribute the elements across two columns. One for the fader, and another for scales, meters, and, in the case of MIDI, the channel and activity indicators. This division would achieve a unified fader height.
These are just my thoughts. :)
There's another UI improvement that I'm not sure is worthwhile, or if you'd find it useful. The pseudo-plugins should be the same color as the audio or MIDI (as appropriate) instead of the generic color. This would help locate sends (audio, MIDI, or CC control) quickly within the plugin chain.
how automate
I like your ideas.
I thought about how to automate it. If the fader is bound to parameter x of plugin y, what should be automated?
parameter x (As it is now, that doesn't change)
The values are automated, not the fader itself. However, if this is implemented, just as we can now use the fader to automate gain, we could use it to automate any other value.
Currently, we're not automating the fader itself, but rather the gain values. The fader represents the values assigned to it, whether as an input or output (record, play).
We can also now use shortcut faders or plugin properties to animate automations.
If implemented, it would be much more convenient, with a large, precise fader accessible directly from the mixer, without having to open plugin properties and deal with floating windows that make it difficult to view and organize the space.
Imagine automating CC sends to automate a bus directly from the track's fader in the mixer. It would feel so natural. :)
In summary: for example, the vertical faders currently only link to the gain value (in audio). The implementation would allow them to link to any value on the strip. (The same would apply to the horizontal faders).
Bus automation
While we're at it: a big thank you to G3N-es for https://sourceforge.net/p/qtractor/wiki/How%20To%20-%2014%20Automate%20Buses%20and%20Tracks%20by%20Layer%20with%20Insert%20Controller/ and Rui for implementing Insert Controller.
Now it's so easy to automate my buses, e.g. my vocal bus.
assign faders
All credit goes to Rui. He's the one who manages to give meaning to some of our requests, shape them, and bring them to life.
Regarding the request at hand, as I see it (I could be wrong), nothing needs to be changed in the current logic.
The files that define the faders (Meter, AudioMeter, and MidiMeter) remain functionally intact; only the layout needs a slight tweaking.
However, Mixer needs to be expanded with functions that replace the properties of the current "fader/spinbox/menu MIDI controller" with those of the one it will represent. It should also be possible to restore the original properties.
The layout would need to be modified slightly to allow all faders to have the same height (as indicated). A layout should be added to the right that contains the MIDI indicator and the scales/meters. As is currently the case, the layout corresponding to the MIDI indicator would be hidden within the audio sliders.
If implemented, the advantages are numerous.
The ability to manage pre-pan/gain from the bus faders.
The ability to assign audio gain to soft synths from the track fader.
These are features that have been requested many times.
And also...
This would be truly versatile.
But I also know it's not easy to implement :)
configurable vs. 2nd fader
There was a time when I tought a 2nd fader that's freely assignable would be a good idea. But it would require lots of space. So I don't think it's a good idea anymore.
re. assign faders...
you're right, it is not easy to implement... at least, it is not dead-easy, for sure... and like so, it raises the risk and the potential to break or bug something else...
question remains: is it all worth the trouble?
cheers
Maybe a 2nd set of faders isn't that bad
… if we put it on a 2nd tab. This would leave the old set of fader/pan as it is.
See attached mockup.
For me the assignment of faders – either the existing ones or a 2nd set of them – would be such a cool and versatile feature like the aux send matrix.
re. Maybe a 2nd set of faders isn't that bad...
but somewhat redundant IMHO, as you already have the Direct Access controls
byee
agreed, but
my plugin boxes are often overcrowded, so I have to scroll, and faders are much cooler :)
I trust your judgment
Not all of our requests make sense. I trust your judgment.
(It's not a clean solution for the same element to perform multiple functions; it can create not only programming errors but also usability issues. Although it might seem strange at first and from the outside, the current Qtractor flow actually works well.)
See my post with a 2nd tab
I think that would make it safer to implement assignable faders.
Add new comment