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).
Add new comment