You are here

Bus automation using track automation

Is it possible to automate buses with the Qtractor automation tool?
Of course, Qtractor offers you enough modules so that you can do almost anything possible.
You just have to create the way (the workflow) to achieve it.
You just have to combine the automation tool with the CC control tool.

(As a transmitter event we have the 7 volume and the 10 panning. I will continue investigating how to use more. On the other hand, the receiver can be any element on the bus)
*See P.S. 2

The only problem is the data backflow. But it is solved by a midi filter plugin. With this filter at the beginning of the plugin box we get that automation track to receive CC on channel 15, and emit on 16. There is no conflicting loop anymore.

Another added advantage is that we can now have an exclusive layer for each automation.

Attached files.

P.S.
If you need more controllers you can add a midi clip and send the CC events from there, it is not as comfortable as the automation tool, but it expands the possibilities.

Another option is to use more midi channels, but of course we are very limited with only 16.

P.S. 2
We can use the fader (CC7) and turn it into any CC message with the "MIDI CC map" plugin.
This means:
We only use midi channels 15 (input) and 16 (output). We have 127 CC messages to automate 127 track and bus elements from each main fader of each midi automation track. If we fall short (I don't think I will) we can always have 127 extra controllable elements using 2 more midi channels (13, 14 for example).
This means being able to create automation layers, and have them all visible at the same time.

Now, it can no longer be said that Qtractor has any limitations when it comes to automation.

AttachmentSize
Binary Data BusAutomati.1.qtz2.41 KB
Image icon BusAutomati.gif228.12 KB
Forums: 
rncbc's picture

Can I hear a new How To coming in?

cheers && happy NYE

It seems like a powerful and affordable workflow. So yes, my intention is to do a how-to at the beginning of this New Year that we hope will be prosperous for everyone.

I don't know why, but with the "Midi CC Map" plugin the backflow doesn't occur. So one midi channel is enough.

The key is to always transform the CC7 message type into another one using the "Midi CC Map" plugin.

Important: Generic CC messages must be used to avoid conflicts (for example from 20 to 31, from 46 to 63, etc.).

The image shows how we can also automate plugins.

I have now used a midi bus for the sends, which simplifies the connections.

I also attached the .qtz for those curious.

If new filters are added, the harmful backflow reappears.
On the other hand, I have the feeling that the midi signal does not work in series like the audio signal, but in parallel. If so, it is impossible to cut the backflow.
I will continue investigating, but it seems that this is not a recommended working method.

Midi faders (Volume/Pan) always receive CC 7/10 of their channel, even if they have another CC assigned, or none at all.

I ask, is that a desirable behavior? I guess it was a feature at the beginning of Qtractor to make it easier to control mixers with external devices.

Considering that we can have several midi tracks with the same channel and different plugin synths, it's confusing and counterproductive.

When you assign a CC to a fader, Qtractor takes the precaution that it is not a previously used CC message. However, it allows all midi tracks with the same channel to share the same CC and channel.

If an element does not have a CC controller assigned, it should not receive a CC message. I think that would be the desired behavior always.

It seems that disabling it eliminates the reflux.

The default CCs of midis tracks are also reset if that same CC is assigned to any other element.
Everything worked fine, it seems that it was just auto-monitoring.

I'm still curious.

I think I've finally found the problem.

It's the auto-assignment of CC controls on faders 7/10 of midi tracks.

For example:
I want to control the Fader and Pan of an audio bus.

I configure it to receive from channel 16 CC 7/10 respectively.
Everything works fine, because when I assign it in the Audio Bus, the midi tracks stop receiving that CC control by default. They lose the default CC reception.

Now, if I remove or change the CC reception on the audio bus, the midi tracks recover it, and the loop arises again.

Conclusion:
The midi track faders should work like any other fader element in Qtractor. They should not receive CC controls if they are not expressly assigned to them.

Hi Rui:
I know we are on a holiday. So it is not necessary to read this now.
Whether it should be solved or not is up to you.

When developing this flow I think I have stumbled upon a bug. Maybe not.
To avoid the reflow loop we have to perform midi filtering.
If I do it with an external application, there are no problems, everything works correctly. For that I have used Qmidiroute.

However, if it is done with internal filters it does not work.

I have confirmed that the error is not in the filtering plugins (I attach and develop the tests later).
I think the error is in the inserts and auxiliary sends.
--- Update ---
The error may not be in the MIDI insert/auxend.
I can't diagnose the problem and I don't want to confuse either.
--- End Update ---
They do not only send the filtered information, but also the original.

This is the test that shows the bug:

A midi channel has been created as a CC signal transmitter.
It has been filtered in the following way:

Plugin 1: Ensures that all channels are now channel 16, the one chosen for CC transmission. As long as no tracks are used with channel 16, there is no risk of backflow.

Plugin 2 and 3: Convert the original CC signals from Gain7/Pan10 into the desired ones.

Through an insert, the signal is sent to the input of the Master midi bus. Just before the insert, I place a midi monitor to view the send. It is checked that the pre-send filtering is correct.

I place another midi monitor at the input of the Master midi bus.
It is checked that in addition to the filtered midi signal, the original is received. Hence the errors and blind shots that are being suffered.

If this is solved, I think that the How to could be created, because it would be a relatively simple workflow to carry out (somewhat complicated to understand, but in general the whole subject of connections is always complicated, whether in audio or midi), and it would really allow for much more powerful automation than the current one.
For example, it allows nesting automations, creating automation groups, staggering, inverting, limiting automations through plugins, etc.

Related topics:
I've noticed that the increase in plugin shortcuts is only in odd numbers. It would be nice if you could set any value from there, not just odd numbers. This would allow you to target channels, specific CC messages etc without having to go into the plugin properties.

I also stand by my previous comment.
MIDI track faders should not receive CC or have a CC assigned by default, unless it is expressly applied to them (as is the case with the rest of the MIDI tracks and buses).

Happy New Year :)

P.S.
Discard Unmached Events

Without this option, the evil loop also occurs with QMidiRoute.

rncbc's picture

you'll have to understand that all MIDI that goes into a bus or track's plugin chain also goes through to the designated output bus if the "monitor" switch is on (aka. "pass-thru")...

when Track/Auto-Monitor is on, it functions as if "monitor" is temporarily turned on for the current highlighted track, with the extra convenience to automatic MIDI-track/channel filtering--a convenience that maybe welcome for single live keyboard/controller players but probably nuisance to general orchestration workflows...)

this is all like so since the beginning, eons ago, so don't try to call it a bug ;)

seeya.

This MIDI thing is really complex, and your answer has made me understand it a little better.

In the end I think there will be a "how to".
I find it annoying to have to use external applications, but in the end it is not that complicated, you just have to remember to launch QMidiRoute before Qtractor, and the connections will be reestablished as if it were an internal plugin.

I will continue experimenting and when I have a mature workflow I will make some musical themes with intensive automations. It has always been a pending task for me to exploit automation as a creative tool.

So if everything goes my way, there will be a How To next year.

Greetings

I have finally achieved a reliable workflow without the need for external tools, just plugins.
Carla allows you to redirect the midi flow in such a way that there are no parallel leaks.
To be able to see the examples you also need to have the midi plugins installed: https://x42-plugins.com/x42/x42-midifilter

The possibilities are endless. You can control multiple parameters with a single fader, which means creating groups and cascading events.
See the attached example file: OK_test_CC_bus.qtz
(Don't forget to activate input/output CC Control in Qtractor)

---

Also, with this channel filtering system it is possible to automate tracks with synths without the need to assign CC (learn MIDI), or use the CC Control input.
This may be of interest to @windowsrefund , as he appreciates insert sends (in this case midi) and does not enjoy assignment through CC assignments (learn MIDI).

See the attached example file: OK_test_direct_midi.qtz

---

Developing this workflow has been a small Christmas auto present for me, which I also share with all you.
I can't contribute code, but I can contribute workflows and "How to" (pending).

Now yes... finally Happy New Year to all.

Sounds quite interesting! I'll dig into this .qtz tonight. Glad you've been having fun with this.

In Carla (now alias: Faders To GROUP) I've added a value inverter so that the behavior is similar to the example with CC Control.

It should be noted that the same VOL/PAN value is imposed on the entire "group". This invalidates the MIDI faders of the tracks. If we want the elements of the group to have their own mix of gain and balance levels, the best thing to do is to include an audio plugin!!! (not midi) in each track.
That is, the synth volume/pan is controlled with a synth controller. The audio gain and balance are mixed with an audio plugin. I think that's what makes the most sense.

I've done it with https://x42-plugins.com/x42/x42-balance, which I'm increasingly convinced by for this purpose due to the decibel scales it offers (much more manageable than those of the Calf plugins).

P.S:
To better understand the behavior, disable playback of the automations, and move the group faders while it plays.

File attachments: 

G3N-es, just a quick mention that I encountered the "Cannot find missing plugin" warning as it relates to the ShowMIDI plugin. Obviously not a big deal here but it does provide an opportunity to better organize ourselves in terms of sharing these .qtz files from time to time. It looks like you are using the vst2. It wasn't found on by running instance of Qtractor since I have the .clap binary on my disk (though this scenario made me aware of the fact my version is behind the times which means I'll pull down the latest today).

OK so, I realize these .qtz don't bundle the plugins used by a given file so my suggestion would be for us to get into the habit of using the File/Properties/Description field to communicate any setup expectations. Again, we know "ShowMIDI" is just a debugging tool and therefore, not going to impact performance but if I did want to exactly match your "debugging" experience, I wouldn't know what track to assign my clap version to. You get my point.... it could be ShowMIDI today but something far more interesting and relevant next time around.

Going to muck with this today and see if I can join in on the fun. Thanks again for all you're doing and Happy New Year.

EDIT: Ooh! How nice would it be if Qtractor had some kind of "plugin fallback" detection feature? Like, if it can't find format foo, check for bar, then baz, and fail only when nothing is found. I'm only 2 seconds into thinking about this but it may be a big win from the perspective of portability (most importantly on the same system that is maintained and upgraded over the course of several years). Behavior might look something like "Format x of plugin foo not found on (track/bus [name]), update to format y?"

EDIT2: G3N-es I'm LOVING this little jam!

I don't like VST (because it's proprietary), but the LV2 version (which isn't a standard I like either, but in this case because of the standard itself) didn't work.
I haven't found CLAP, which is a format I like.
Send it to me if you can.

Regarding this "documentation"... Has anyone thought of making a plugin for Notepad? Something that has midi/audio input and output, to make it compatible with any track or bus, but that doesn't use them. It simply offers a text field to enter block notes.
It would be very useful.

ShowMIDI releases are over at https://github.com/gbevin/ShowMIDI/releases. I need to update :D

About the plugin idea, wouldn't that just provide the same opportunity that already exists with the File/Properties/Description filed? If what you mean is, something DAW-agnostic, the closest I've seen to what you've described ships with Carla... maybe it's called notes or something... I can't remember. It's exactly what you said, just a blob of text. The problem is it's baked into Carla itself and therefore, not accessible outside of that app. That said, using a plugin to scratch this particular itch kinda feels like a chicken/egg scenario.

Yes, that would simplify things.

As for ShowMidi, indeed, in this case it is irrelevant.
Load it wherever you want to check the midi stream.

I can't focus on learning your workflow because I'm enjoying this little jam too much. :D

I'm gonna go grab a cup of coffee and when I get back, maybe I'll be able to actually focus.

G3N-es, I am so impressed with what you are doing here and think you're exposing a whole new area of productivity. Full disclosure: I do not understand each element of what you've stitched together but am confident I'll understand more when I have a chance to evaluate this while reading whatever documentation/HOWTO/etc is forthcoming. That said, here are just a few observations I have (all good!)

  1. The use of Carla Rack (or maybe it's Carla Patchbay, I'm not sure) does not incur the cost of heavy DSP Load. I figure this is worth mentioning as some of my older workflows which used Carla to host instruments, did end up showing quite high usage. Granted, this is surely due to the fact only the MIDI plugins are being loaded as opposed to instrument plugins. Very nice.

  2. It does seem this workflow looks more and more like what Ardour does in terms of providing "Automation tracks". Regardless of lingo, I'm specifically talking about the practice of maintaining automation performance independent of instrument tracks. My instinct tells me this is quite manageable with a session like this which is made up of just a few tracks. However, it may end up becoming difficult to understand and/or work with as the number of things grows. All I mean to suggest with that is the possibility this stuff may be SO GOOD and useful as to justify some additional UX work. For example, even with this small data set, I see how nice it would be to have a "high level" means to collapse a track to its minimum height (and then toggle back to previous size). I'm not talking about what's currently available via right click, use the menu.... that's too burdensome. Dedicated automation tracks like these feel more like the kind of thing we spend some time focusing on when needed and then we want to kinda "get out of the way" easily. Imagine if each track had a Arrow icon (or something) in the Nr column which acted as a toggle. Upon clicking, it would minimize or reset the height of the track. Of course, I'm running with this thought under the assumption we'd (potentially) be talking about a workflow involving many of these automation tracks. Maybe I'm wrong. I'll know more as I learn more about this workflow.

Thinking about scaling, I also find myself wondering how easy (or difficult) it may be to associate a given automation lane with its target(s). Hopefully you know what I mean when I say that.... Right now, I get the impression the association is made clear by the text description "Drum and Bass" itself. Granted, that may be the best we can do but I feel compelled to point out how messy that may become over time.

So I think those are my only thoughts for now? The most important thing I can say is that it does look (and sound) like everything is working exactly as intended. I'm looking forward to looking at this again while reading more details about what it took to put this together. Great job!.

THE WORST:
It really is a nodal workflow.
All node workflows share a pro and a con:
* Pro: Powerful and flexible
* Con: Difficult to understand and visualize from the outside.

It doesn't matter the context, image, video, 3d, audio...

In this case it is even more difficult:
1 MIDI flows tend to propagate in parallel configurations, filtering becomes unintuitive, which causes flows that are difficult to detect (hence ShowMidi).

2 There are 2 nodal systems coexisting and interacting Carla, and Qtractor connections, which in turn are divided into inserts, buses and sendAux that can vary in behavior to the same MIDI events, and to top it off Control CC messages, which propagate throughout qtractor because they do so at the interface control level.

3 The MIDI filters that are available lack a GUI and the concepts they handle are very abstract.

So while these flows I propose are functional and allow to expand the possibilities of Qtractor, it is true that they are not intuitive.
Hence the need to document and give custom names to each element. (Plugin Aliases are very useful here).
That is why I need a plugin that allows to include text (comments) at any point in the chain.
I am going to take a look at the LV2 plugin examples, to see if I can build myself a "Notebook".

However, I do not think that these nodal flows can help to improve and expand the automation tools of Qtractor at the level of functionality and GUI. Because the moment the flows are defined at the programming and GUI level, they will stop being nodal.

That said, it can be useful to improve the GUI and functionalities of Qtractor when implementing nodal flows.

---

THE BEST:
If we limit ourselves to using midi tracks as an internal Automatable Midi Controller capable of sending "learn midi" to control things through Qtractor's CC Control, everything is greatly simplified. We create a duplex Midi Bus and call it CCA (Automatable CC Midi Controller). Done. All the tracks dedicated to sending CCA are assigned to this bus.

The filtering work is done from Carla.
You can create presets for tracks with everything already preconfigured according to the flow you want to achieve.

The user does not have to understand how the track works if he does not want to. He will only have to read the "note" to know what values ​​are available to assign to the CC receiving faders.

But of course, for that you need a notepad plugin.

While I certainly trust your experience and insights, I still wonder if you're perhaps overthinking the benefit of a text plugin? The entire point of a plugin is to decouple a piece of functionality or data so it can be used by multiple things. So what else would be using it? Also, by "it", are we still talking about a helpful collection of words used to describe this and that (plugins used, routing instructions, anything) or are you now thinking about an actual language? In other words, are you now thinking about this text playing more of a scripting role?

Maybe I'm reading too much into this? Just trying to understand the big picture.

For me, a plugin is something different. It must comply with:

* External software that extends the functionality of the native software.
* External software that can be shared between several applications that share the same host (or plugin system).

That a plugin can share information with others may or may not be necessary, but it is not essential.

What is essential is to "extend functionality" and "be compatible between applications."

In the case at hand:
* Extend functionality: Comment on any point in a plugin chain, including the track or bus that hosts the plugins.
* Be compatible: Allow commenting in Qtractor and also within Carla.

Of course, someone had to have thought of this before, it exists but for VST Windows:
https://codefn42.com/vstnotepad/index.html

Again I have tried to understand lv2 and I have crashed again.
My logic tells me, take an example, insert a text field, and delete the faders.

But no, lv2 doesn't work like that. :)

rncbc's picture

like the plugin alias, but just free text that would show on the tool-tip, perhaps?

cheers

That would fix what I need 99% of the time.

It would also be nice to add a pseudo plugin called "Notes".
Left click on the plugin box:
* Add Plugin
* Add Note
* Inserts >
...

And you would see:

File attachments: 

Right but why wouldn't you just make use of the text field already provided under File/Properties/Description? I feel dumb :D

I'm asking because all we're talking about here is having a facility to manage (and maintain) unstructured text. There's already a suitable facility in place to accomplish that task. It seems bolting on that same endgame to unique plugin instances ONLY results in a session where you'd have any number of "notes" in who-knows-how-many locations. I just don't get what the win would be?

Add new comment