I think it would be a lot better for the featured video having a MIDI clip editor's Controller events pane (the one with the vertical bars and now lollipops) showing some in-the-zone evidence ;)
what do you think?
cheers
ps. you seem to be removing the "[How To - Contents]" from the heading, please don't :)
PDF, page 132: The video link is incorrect (file:///home/rncbc/work/qtractor-doc/qtractor-backup-2024-02-28-143921/attachments/video_midi_plugin_parm.mkv)
epub: Couldn't check it, download has been cancelled.
HTML: all of the links above "Qtractor Wiki Home" don't work.
Downloads were very slow. Maybe it's better tomorrow.
the links in the epub and pdf of the preview won't work until, I guess, they get into their final location (https:/qtractor.org/doc/attachments/..."); though, the link on the html should work alright.
the same with the links above the title header: it only makes sense to the final menu.
thanks
UPDATE: It's now LIVE (as of 2024-02-28 18:00+0000):
There seem to be a few methods of inserting automation data but the hardest part comes after. Every method seems rather cumbersome to work with (what, where, how) once the data is in the session. With the traditional automation lanes, you only get to see 1 at a time and only through a menu that starts with a right click. With the MIDI used to control volume and pan sliders approach (discussed recently), everything is buried under a right click you'd have no idea even exists unless you........ remember you added it. This seems cool but again, seems to be another example of an approach that makes adding data possible but will be difficult to identify and manage later.
This does seem to be an improvement over the previously mentioned approach using MIDI since everything is maintained in a particular track (unlike the other where a dedicated track is maintained for all controller messages). This is good.
So Rui, to your question, anything that can be used in the sense of improving ease-of-access and provide greater visibility gets my vote (I think that's where y ou were heading?)
About the properties dialog of the plugin where, in this case, the Modulation Wheel (Coarse) controller will be selected...
I noticed the Type and Parameter fields update dynamically based on the active MIDI data. Is there a reason it does that? Seems like a bug. The net effect is one (most likely) has to stop playback in order to reliably create this assignment.
I'm feeling a little envious and confused since after setting up this exact workflow, I get the sonic and functional result but don't see my calf filter's display updating in real-time as shown in the video. Not sure what I could be missing? Any advice would be greatly appreciated.
Everything is working but I don't see the visual updates in real-time occurring in the calf plugin when I'm moving my controller's pitch wheel up and down. I hear the changes, but I can't repeat the exact (visual) experience your video shows. Also, I notice that once I click "OK" after assigning the controller (modulation wheel in this case), the "dot" next to "Frequency" doesn't light up green which to me, would serve as a visual indicator that a thing underneath it has been set. Is this your experience as well? Seems to me it should light up and persist across sessions.
Update: I just realized you were asking if I see the "Frequency" slider move once everything has been set...... no, I do not. I only hear the desired results.
Oh silly me. It's all working now that I assigned the controller to use Pitch Bend. Duh! My controller has one of those sliders for modulation so I guess my brain just associated my actual Pitch Wheel when I read your instructions referring to the Modulation Wheel (coarse) controller. :)
OK, now that my brain is working again, I do still wonder if that dot can be made to illuminate in order to show us something is assigned underneath. What says Rui?
One more observation: Clicking "Reset" doesn't restore the default value of the (in this case) Frequency slider. Instead, it just leaves it in the state it ended up in as a result of whatever controller had been assigned and used to manipulate it. Is that expected? Seems to me, a reset function's entire purpose in life is to simply "make a thing look like it never happened".
In addition to asking for the properties button to be illuminated and persisted across sessions, I'd also like to ask for another button or some indicator of sorts to be added at the highest level.
You'd never know the Calf Filter plugin had a controller assigned to it behind the scenes. Imagine looking at the project 6 months or a year from now :D
Perhaps another "green light" could be added to the right side? Just a quick thought; maybe there's something cleaner. The real goal is to get some observability added at this highest level so you know something exists underneath.
If we're talking 1 to 1, then yes; I see and agree with the point of view and would then just advocate using external documentation like a README.txt in the project directory.
Due to the sheer numbers, I'd never advocate for a 1 to 1 relationship at the highest level (the sequencer view). Rather, this level should (at the very least) present and maintain a one-to-many relationship in order to simply leave a clue that some state exists. What we have now is the worst of all cases since there is absolutely nothing left in place indicating something exists under the hood. To your point, you could spend an entire working session configuring and working with dozens of controller assignments across even just a few tracks... a very reasonable thing. Now, how would you rate your chances of finding and understanding those configurations should you maybe come back to the song a week later. How about 2 weeks?
While I do understand the benefit of maintaining external documentation, it's important to understand that approach is actually just a clunky hack since all you're attempting to do there is maintain state........ something the software should be doing in a far better, standardized, and reliable fashion.
How many times have you not understood the things you wrote a week ago? A month or year ago? That's because we as humans, are not predictable.
So far, I've been talking about things at the highest level (the sequencer) since it essentially serves as the gateway to all the things.
But what about the indicator icon we're clicking on in order to assign a controller to a property of a plugin? I mean, it seems quite obvious to me that it should be flipped green if it ends up getting assigned to anything, no? And what does the reset button actually reset?
There's certainly lots of room to build on this area of the workflow.
You are partly right.
For example, Qtractor's standard Automation is perfectly documented with its menu.
However, if Qtractor is characterized by something, it is by providing enough foundation to create almost any workflow we want, without the need to program new functions.
You wanted to be able to record several automations at the same time. With CC it is possible to change the meaning of the midi track, to automation track.
You don't have to program anything, just call the automation midi bus so it's AutoCC.
Now they are no longer midi tracks, but CC automation tracks.
You cannot view all the midi automations at once in the editor, unless you go to the trouble of duplicate the track for each CC element and in the editor delete all CC that does not correspond.
But it is not necessary, because you can view its consequences them at the same time in the plugins.
In the screenshot I show you a possible workflow. I haven't tried it but it should work.
If it is the same color but lighter, it is below, it is a midi track, and its bus is AutoCC, it is an automation track.
We use the name box to register the different elements that are being automated with the code "NumberCC: Automated Element".
Before seeing what visual aids we need, we have to create functional flows, and Qtractor allows this.
I can appreciate the hack. Seems to me we can control all of those parameters via Automation though which is (to some extent) visible at the highest level. Originally, I had become interested in controlling bus faders via cc data since those specific things can't be scoped. I think I'm realizing these 2 approaches largely overlap so I'm debating which side I want to lean into. Each has their pros and cons but this approach seems to incur more grunt work. In the 1-to-many "automation track" approach, we have no way of knowing what controller data is mapped to which plugin (unless we keep even more detailed notes). It's a really non-intuitive workflow because you could be working with a track 20 rows down and have to go find the related data every time. It's kind of like documenting your source code in a word document or something which is stored on a file server rather than in your VCS. It's just too disconnected to make any real sense. Of course, controller data is part of the MIDI standard so using that to capture performance state is certainly a big plus as it keeps the exports DAW-agnostic.
Last night I realized I could drive my plugin's "Master" parameter via automation which essentially solves the original issue I was trying to overcome related to automating a bus fader. That just leaves pan (since many plugins don't provide it). I suppose a plugin can be thrown into the mix (Calf Stereo maybe) and then controlled.
I'm probably leaning toward Automation though I do wish it were a bit more accessible and quicker to work with. That said, I have certainly been having a tough time as it relates to Automation data mapping cleanly to db values. That certainly makes it a challenge on a track by track basis but I've read some things in the forums which tell me the plugins are not providing the data Qtractor would need in order to map.
PS. I never wanted to record multiple automations at one time; maybe somebody else did. I've simply been focusing on trying to figure out what cleanest and most usable approach to automation actually is :D
Automating the builtin volume and pan fader is possible but can have side effects.
I recommend using a simple amplifier plugin and automate that. That has the positive side effect that you can decide if you place another plugin pre or post amplifier. Some plugins or aux sends to plugins work better when placed pre amplifier (compressor), some work better when placed post amplifier (reverb).
re. New How To - 8 Controlling a Plugin's Parameter...
Thanks, added also to How To - Contents
Qtractor Manual & How To's PREVIEW: [epub] [pdf] [html]
Hi Bluebell
Hi Bluebell
This flow you propose is great.
It allows us to record complex automations of several CCs at the same time from external midi controllers.
Thanks for sharing
re. New How To - 8 Controlling a Plugin's Parameter... video
hi @bluebell,
I think it would be a lot better for the featured video having a MIDI clip editor's Controller events pane (the one with the vertical bars and now lollipops) showing some in-the-zone evidence ;)
what do you think?
cheers
ps. you seem to be removing the "[How To - Contents]" from the heading, please don't :)
Hi Rui, I replaced the video.
Hi Rui, I replaced the video.
I didn't remove "[How To - Contents]", I just didn't know that I have to add it. It's now fixed in How To -8.
re. replaced the video...
hi, atm. I still see the same video there (simplescreenrecorder-2024-02-27_10.59.13.mkv), the same as in yesterdays preview of 11:00+0000 (this video)
what did you replace exactly?
thanks
It's the same file name but
It's the same file name but updated content. Now you see the lollipops in the video.
Do I have to use a different filename?
re. use a different filename?
yes, it would be the right choice.
Done.
Done.
re. Done.
thanks, a new staging preview is now up (2024-02-28 14:00+0000):
Qtractor Manual & How To's PREVIEW: [epub] [pdf] [html]
please confirm all is good, to make it official into qtractor.org. cheers
QC
PDF, page 132: The video link is incorrect (file:///home/rncbc/work/qtractor-doc/qtractor-backup-2024-02-28-143921/attachments/video_midi_plugin_parm.mkv)
epub: Couldn't check it, download has been cancelled.
HTML: all of the links above "Qtractor Wiki Home" don't work.
Downloads were very slow. Maybe it's better tomorrow.
re. QC
oh yes
the links in the epub and pdf of the preview won't work until, I guess, they get into their final location (https:/qtractor.org/doc/attachments/..."); though, the link on the html should work alright.
the same with the links above the title header: it only makes sense to the final menu.
thanks
UPDATE: It's now LIVE (as of 2024-02-28 18:00+0000):
enjoy
There seem to be a few
There seem to be a few methods of inserting automation data but the hardest part comes after. Every method seems rather cumbersome to work with (what, where, how) once the data is in the session. With the traditional automation lanes, you only get to see 1 at a time and only through a menu that starts with a right click. With the MIDI used to control volume and pan sliders approach (discussed recently), everything is buried under a right click you'd have no idea even exists unless you........ remember you added it. This seems cool but again, seems to be another example of an approach that makes adding data possible but will be difficult to identify and manage later.
This does seem to be an improvement over the previously mentioned approach using MIDI since everything is maintained in a particular track (unlike the other where a dedicated track is maintained for all controller messages). This is good.
So Rui, to your question, anything that can be used in the sense of improving ease-of-access and provide greater visibility gets my vote (I think that's where y ou were heading?)
About the properties dialog
About the properties dialog of the plugin where, in this case, the Modulation Wheel (Coarse) controller will be selected...
I noticed the Type and Parameter fields update dynamically based on the active MIDI data. Is there a reason it does that? Seems like a bug. The net effect is one (most likely) has to stop playback in order to reliably create this assignment.
All the best
Hmm... not doing it anymore
Hmm... not doing it anymore after I recreated the pieces. OK, I'll take the win.
It's some kind of "MIDI learn
It's some kind of "MIDI learn" and can be convenient.
Reaction to live played data depends on "Track -> Auto Monitor" and if the track is selected.
Very interesting. Thank you.
Very interesting. Thank you.
I'm feeling a little envious
I'm feeling a little envious and confused since after setting up this exact workflow, I get the sonic and functional result but don't see my calf filter's display updating in real-time as shown in the video. Not sure what I could be missing? Any advice would be greatly appreciated.
Best
Do you see the slider moving
Do you see the slider moving when you right click on Calf Filter and select Properties… ?
Hi bluebell,
Hi bluebell,
Everything is working but I don't see the visual updates in real-time occurring in the calf plugin when I'm moving my controller's pitch wheel up and down. I hear the changes, but I can't repeat the exact (visual) experience your video shows. Also, I notice that once I click "OK" after assigning the controller (modulation wheel in this case), the "dot" next to "Frequency" doesn't light up green which to me, would serve as a visual indicator that a thing underneath it has been set. Is this your experience as well? Seems to me it should light up and persist across sessions.
Update: I just realized you were asking if I see the "Frequency" slider move once everything has been set...... no, I do not. I only hear the desired results.
Oh silly me. It's all working
Oh silly me. It's all working now that I assigned the controller to use Pitch Bend. Duh! My controller has one of those sliders for modulation so I guess my brain just associated my actual Pitch Wheel when I read your instructions referring to the Modulation Wheel (coarse) controller. :)
OK, now that my brain is working again, I do still wonder if that dot can be made to illuminate in order to show us something is assigned underneath. What says Rui?
One more observation: Clicking "Reset" doesn't restore the default value of the (in this case) Frequency slider. Instead, it just leaves it in the state it ended up in as a result of whatever controller had been assigned and used to manipulate it. Is that expected? Seems to me, a reset function's entire purpose in life is to simply "make a thing look like it never happened".
Best
To get a "reset" state when
To get a "reset" state when starting playback there is View -> Options -> MIDI -> Reset all controllers on playback start
re. Reset button
on the MIDI Controller dialog, the "Reset" button is for clearing the current assignment
br.
In addition to asking for the
In addition to asking for the properties button to be illuminated and persisted across sessions, I'd also like to ask for another button or some indicator of sorts to be added at the highest level.
You'd never know the Calf Filter plugin had a controller assigned to it behind the scenes. Imagine looking at the project 6 months or a year from now :D
Perhaps another "green light" could be added to the right side? Just a quick thought; maybe there's something cleaner. The real goal is to get some observability added at this highest level so you know something exists underneath.
re. Imagine looking at the project 6 months
I think adding visual indicators wouldn't help.
A plugin can accept dozens of controllers.
Projects, if they grow in complexity, must be documented. There is no other solution.
And that doesn't depend on Qtractor.
Perhaps adding a description/notes/comments box to the track and bus properties forms might make sense, just as it now exists in document properties.
But for very complex things, you have to resort to external tools (libreoffice...) that allow you to include diagrams and screenshots.
I'm not sure I agree.
I'm not sure I agree.
If we're talking 1 to 1, then yes; I see and agree with the point of view and would then just advocate using external documentation like a README.txt in the project directory.
Due to the sheer numbers, I'd never advocate for a 1 to 1 relationship at the highest level (the sequencer view). Rather, this level should (at the very least) present and maintain a one-to-many relationship in order to simply leave a clue that some state exists. What we have now is the worst of all cases since there is absolutely nothing left in place indicating something exists under the hood. To your point, you could spend an entire working session configuring and working with dozens of controller assignments across even just a few tracks... a very reasonable thing. Now, how would you rate your chances of finding and understanding those configurations should you maybe come back to the song a week later. How about 2 weeks?
While I do understand the benefit of maintaining external documentation, it's important to understand that approach is actually just a clunky hack since all you're attempting to do there is maintain state........ something the software should be doing in a far better, standardized, and reliable fashion.
How many times have you not understood the things you wrote a week ago? A month or year ago? That's because we as humans, are not predictable.
So far, I've been talking about things at the highest level (the sequencer) since it essentially serves as the gateway to all the things.
But what about the indicator icon we're clicking on in order to assign a controller to a property of a plugin? I mean, it seems quite obvious to me that it should be flipped green if it ends up getting assigned to anything, no? And what does the reset button actually reset?
There's certainly lots of room to build on this area of the workflow.
re. I'm not sure I agree.
You are partly right.
For example, Qtractor's standard Automation is perfectly documented with its menu.
However, if Qtractor is characterized by something, it is by providing enough foundation to create almost any workflow we want, without the need to program new functions.
You wanted to be able to record several automations at the same time. With CC it is possible to change the meaning of the midi track, to automation track.
You don't have to program anything, just call the automation midi bus so it's AutoCC.
Now they are no longer midi tracks, but CC automation tracks.
You cannot view all the midi automations at once in the editor, unless you go to the trouble of duplicate the track for each CC element and in the editor delete all CC that does not correspond.
But it is not necessary, because you can view its consequences them at the same time in the plugins.
In the screenshot I show you a possible workflow. I haven't tried it but it should work.
If it is the same color but lighter, it is below, it is a midi track, and its bus is AutoCC, it is an automation track.
We use the name box to register the different elements that are being automated with the code "NumberCC: Automated Element".
Before seeing what visual aids we need, we have to create functional flows, and Qtractor allows this.
I can appreciate the hack.
I can appreciate the hack. Seems to me we can control all of those parameters via Automation though which is (to some extent) visible at the highest level. Originally, I had become interested in controlling bus faders via cc data since those specific things can't be scoped. I think I'm realizing these 2 approaches largely overlap so I'm debating which side I want to lean into. Each has their pros and cons but this approach seems to incur more grunt work. In the 1-to-many "automation track" approach, we have no way of knowing what controller data is mapped to which plugin (unless we keep even more detailed notes). It's a really non-intuitive workflow because you could be working with a track 20 rows down and have to go find the related data every time. It's kind of like documenting your source code in a word document or something which is stored on a file server rather than in your VCS. It's just too disconnected to make any real sense. Of course, controller data is part of the MIDI standard so using that to capture performance state is certainly a big plus as it keeps the exports DAW-agnostic.
Last night I realized I could drive my plugin's "Master" parameter via automation which essentially solves the original issue I was trying to overcome related to automating a bus fader. That just leaves pan (since many plugins don't provide it). I suppose a plugin can be thrown into the mix (Calf Stereo maybe) and then controlled.
I'm probably leaning toward Automation though I do wish it were a bit more accessible and quicker to work with. That said, I have certainly been having a tough time as it relates to Automation data mapping cleanly to db values. That certainly makes it a challenge on a track by track basis but I've read some things in the forums which tell me the plugins are not providing the data Qtractor would need in order to map.
PS. I never wanted to record multiple automations at one time; maybe somebody else did. I've simply been focusing on trying to figure out what cleanest and most usable approach to automation actually is :D
Automating the builtin volume
Automating the builtin volume and pan fader is possible but can have side effects.
I recommend using a simple amplifier plugin and automate that. That has the positive side effect that you can decide if you place another plugin pre or post amplifier. Some plugins or aux sends to plugins work better when placed pre amplifier (compressor), some work better when placed post amplifier (reverb).
I like it
I like it
Add new comment