Main menu
You are here
Feature Request: Improve visibility of automation
Greets,
Not so much an exact feature request but some comments which I hope might result in something...
- Automation is awesome.
- Automation is possible.
- Automation is labor intensive as it requires a bunch of tedious steps essentially working from the dropdown maze that starts with clicking the track's A button.
The end result is quite functional but difficult to work efficiently with since only a single automation can be kept visible at any one time. Granted, I understand this shouldn't matter as our ears should be the final judge of all things but I think we can admit our eyes get heavily involved during the creation process.
In short, I'm starting to understand just how much I'd appreciate being able to see all automatons for a given track at the same time. This would allow me to see how things relate to each other and in general, spare me from that nagging wonder if I'm overlooking anything simply because it is "out of sight and therefore, out of mind".
On the topic of automation and increased visibility, I have been amazed at this incredible post by Mela that speaks to how to automate busses with MIDI controller data. Wow!!!!!
As Mela correctly points out toward the end of that incredible post, it would be nice if the existing Automation work flow could accommodate this MIDI control data as well so all automation could be driven via a standard work flow rather than being split between A and Piano Roll.
So yea, I've touched on a few things and admit to not having a specific ask. Rui, I'm especially interested to know if there's any thoughts you have in terms of what might be low hanging fruit or if you see potential to expand on the current work flow.
re. Improve visibility of automation
hi,
I understand your pain(s) but as track folding groups, multiple automation curves per track are off the radar screen at this time, at least on my plans. sorry.
having automation to accommodate MIDI Controller data is yet another topic that has been severely procrastinated for so long, but, sorry to tell, is not in the plans either--sorry again.
of course, the plans could be shortened if someone else steps in for the (daunting?) task, this is FLOSS, remember? we'll be pleased to help and encourage it, have no doubt.
cheers
I'm no developer but I can
I'm no developer but I can fund the development. Can we maybe find a number that makes it worth your while? Assuming we can, I'd think the most important first step would be to get our collective heads around what exactly the end result would look and feel like before a single line of code is written. Not trying to send anyone down any rabbit-holes.
Just to share some thoughts
Just to share some thoughts about functionality, I'm not so sure what I envision would translate exactly to "folding". I mean, it could........ but I realize that is a concept that is completely foreign to Qtractor itself. I'd think the quickest path would involve making use of existing functionality (where possible). In other words, more like rearranging furniture in an existing home as opposed to buying new.
So right now, we can add a track. When we do this, we select between 1 of 2 choices; Audio or MIDI. What if we were given a 3rd choice of Automation? If that option were made possible, it would also stand to reason that the user would also be required to associate this new Automation track with an existing track. With the relationship established, the logical result might be that the new track is inserted/injected below the track specified as the owner/parent. That's probably not a huge lift as it would seem to imply extending a form, adding a new subform, and tapping into Qtractor's already existing capabilities of adding and moving tracks.
If the above is a reasonable starting place, I'd think an Automation track would be different from a "normal" track in that it would not be able or responsible for hosting clips. Rather, it would simply act as a container to display automation data (again, something already possible so I'd hope the lift wouldn't be massive).
Then a parent track would obviously need to offer the user a means to hide or show all automation tracks. Again, this doesn't necessarily need to look like "folding" as much as it just needs to achieve the objective of simply showing or not showing.
An automation track itself might contain the widget used to discover/assign the actual automation property. Again, I'm talking about relocating existing functionality rather than creating anew.
Just some thoughts off the top of my head. Also, everything I'm throwing out here is specific to the first part of the ask which is to end up with something where it is possible to view multiple automation lanes simultaniously. I'm just thinking about them as tracks rather than sticking to the "lanes" convention since, based on other wares, that term does (even subconsciously) seem to imply "folding".
re. Just to share some thoughts
note that, in the current and foreseeable design and implementation, automation curves are in fact properties of a track.
iow. automation curves are not separate tracks on their own; making them like so would be an entirely rewrite to the data model and, even more gruesome, will let the current external representation on file completely hard to convert into a (backward) compatible format; not impossible though, but quite hard and years long to re-implement, let alone all the new bugs and what not it would surely introduce...
unless funding is undeniably generous (please don't), I just don't have the time, motive nor incentive to do it single-handedly. I'd rather keep with minor but progressive changes/improvements, as it's been the norm anyway.
hyu.
I can absolutely appreciate
I can absolutely appreciate this. I'm guessing that puts a wrap on the first half of the ask. Any thoughts on the second involving the addition of cc data into the Automation matrix?
re. the second [half of the ask]...
feasible but no promises not before 2024Q2 ;)
cheers
thumbs_up_emoji_thing
thumbs_up_emoji_thing
Add new comment