[SOLVED] Automation
Moderators: MattKingUSA, khz, spamatica
- oscillator
- Established Member
- Posts: 1127
- Joined: Sat Jan 17, 2015 6:07 pm
- Location: SWEDEN
- Has thanked: 725 times
- Been thanked: 298 times
- Contact:
[SOLVED] Automation
has something changed in the handling of automation?
Using the Surge soft synth (+600 automation channels), they are now grouped but I cannot see and select all of them.
MusE DAW running on Debian 11 Testing/XFCE4.
https://oscillator.se/musik
- oscillator
- Established Member
- Posts: 1127
- Joined: Sat Jan 17, 2015 6:07 pm
- Location: SWEDEN
- Has thanked: 725 times
- Been thanked: 298 times
- Contact:
Re: Automation
Sorry for the vague description! I cannot scroll down in the menu. I like the (new) grouping. But with 600+ possible automation channels, I cannot access the ones that do not fit on the screen. When the parameters were not grouped I was able to access for example Cutoff (and didn't notice that the last parameters were drawn outside of the screen).
So, the problem was there before, but it didn't bother me.
I have some vague memory of discussing this, @Tim E. Real was involved, a couple of months ago.
BTW @kybos , I am running your tabbed interface all the time now. I like it very much! How is the progress with saving window state etc? Also, would it be possible to put a close box on the tabs, a small X or something. I noticed I can right-click and close, but a keyboard shortcut would be awesome.
MusE DAW running on Debian 11 Testing/XFCE4.
https://oscillator.se/musik
Re: Automation
Yes, Tim improved the menu some time ago, for me it's working nicely. The menu is not supposed to be scrollable, the list just continues in the next submenu. It shouldn't be drawn outside of screen - when it reaches the right end of the screen, the submenu opens to the left (at least for me).oscillator wrote: ↑Thu Sep 24, 2020 6:55 pm Sorry for the vague description! I cannot scroll down in the menu. I like the (new) grouping. But with 600+ possible automation channels, I cannot access the ones that do not fit on the screen. When the parameters were not grouped I was able to access for example Cutoff (and didn't notice that the last parameters were drawn outside of the screen).
So, the problem was there before, but it didn't bother me.
I have some vague memory of discussing this, @Tim E. Real was involved, a couple of months ago.
Certainly it's not so easy to find an individual menu text when you have so many entries, but it's much better than before. Some kind of search function is planned for the future, I think.
The windows/docks should behave quite sensibly already. Are you missing something particular? The state of some of the docks is not (yet) saved/restored in the song file, but I am not even sure if it's really desirable.BTW @kybos , I am running your tabbed interface all the time now. I like it very much! How is the progress with saving window state etc? Also, would it be possible to put a close box on the tabs, a small X or something. I noticed I can right-click and close, but a keyboard shortcut would be awesome.
Close icon on tabs: I tried that, but it doesn't work well, as Qt then puts the icon on all tabs, no matter if they are defined as closeable or not. But there are lots of other ways to close the tabs - middle mouse button, context menu (right click), or the key shortcut Ctrl+W (Qt default to close subwindows).
- oscillator
- Established Member
- Posts: 1127
- Joined: Sat Jan 17, 2015 6:07 pm
- Location: SWEDEN
- Has thanked: 725 times
- Been thanked: 298 times
- Contact:
Re: Automation
Unfortunately for me, it doesn't continue on the left (as I think is shown on my image). Parameters are just cut, and sometimes I can see the menu continue on the right (just a few pixels of it).kybos wrote: ↑Fri Sep 25, 2020 6:51 pm Yes, Tim improved the menu some time ago, for me it's working nicely. The menu is not supposed to be scrollable, the list just continues in the next submenu. It shouldn't be drawn outside of screen - when it reaches the right end of the screen, the submenu opens to the left (at least for me).
Certainly it's not so easy to find an individual menu text when you have so many entries, but it's much better than before. Some kind of search function is planned for the future, I think.
I am running on a 1360x768 display, maybe that is not enough. Debian 10+XFCE4.
Ah, Ctrl+W is just what I was looking for. Thanks!Close icon on tabs: I tried that, but it doesn't work well, as Qt then puts the icon on all tabs, no matter if they are defined as closeable or not. But there are lots of other ways to close the tabs - middle mouse button, context menu (right click), or the key shortcut Ctrl+W (Qt default to close subwindows).
Is it possible for the interface to remember which tabs are already opened? Right now, I can double click a part to open a tabs, switch back to the Arranger (tab), click the part again, and I get two tabs with showing the same part. That's the only thing that is missing, I think.
Anyway, awesome job!
MusE DAW running on Debian 11 Testing/XFCE4.
https://oscillator.se/musik
-
- Established Member
- Posts: 667
- Joined: Sat Sep 15, 2012 12:36 am
- Has thanked: 38 times
- Been thanked: 107 times
Re: Automation
The menus are supposed to allow arriving at any sub-menu waaay down the line,
although with so many entries, it may end up really awkward with sub-menus popping up on top of sub-menus and so on.
These custom menus are actually supposed to scroll wholesale horizontally when too much appears on the screen.
You might wish to try a Global Setting which turns the menu into scrollable menus. It's there somewhere, someone added it...
That should, hopefully, present the menu as a familiar vertically scrollable style menu.
Although with that many entries it might be more annoying.
For the record, I mentioned recently, that a long time ago I started working on a better solution which involves
an actual tree or list view instead of popup menus.
Although it got left behind, I recently dug deep in my old archives and retrieved the code unit and stuck it into our
current source tree, in the hopes of finishing it.
The unit is found in components/control_mapper.cpp/h
It was quite ambitious. I think I was trying to combine midi and audio controllers and all manner of current check boxes,
settings and interconnections - even a custom colour picker! - in one tree or list.
It was my first attempt at using the then-new Qt4 item delegates and so on.
Maybe it could be reworked into something less ambitious / more practical / more expeditious for the time being.
Or start over from scratch.
Re: Automation
That's unrelated to my implementation, it has always been like that. I was wondering too why this was the case, but Tim explained that it was intentional, as you could e.g. have a very long part and want to display its start and end in different windows, to copy events between them or similar things.oscillator wrote: ↑Fri Sep 25, 2020 7:50 pm Is it possible for the interface to remember which tabs are already opened? Right now, I can double click a part to open a tabs, switch back to the Arranger (tab), click the part again, and I get two tabs with showing the same part. That's the only thing that is missing, I think.
As you are not the first user that finds this behaviour unexpected, or even buggy, I think we should give it a second thought...
At least I changed this behaviour already for both of the mastertrack editors (graphic and list), where it really didn't make any sense. There is now only a single instance for each of them.
-
- Established Member
- Posts: 667
- Joined: Sat Sep 15, 2012 12:36 am
- Has thanked: 38 times
- Been thanked: 107 times
Re: Automation
But it does make sense, for now, because
a) The master has no cut/copy/paste facility, and adding that would be a major effort not worth the time right now because
b) How many tempo changes would one realistically expect to have in a song, requiring a wholesale cut/copy/paste facility?
For the other editors, I think it would be unwise to make them single instance.
The ability to view the same part in different places at one time is valuable, the cut/copy/paste facility being one reason.
- oscillator
- Established Member
- Posts: 1127
- Joined: Sat Jan 17, 2015 6:07 pm
- Location: SWEDEN
- Has thanked: 725 times
- Been thanked: 298 times
- Contact:
Re: Automation
Ah, Settings > GUI Tweaks > Scrollable submenus!Tim E. Real wrote: ↑Fri Sep 25, 2020 10:58 pm You might wish to try a Global Setting which turns the menu into scrollable menus. It's there somewhere, someone added it...
That should, hopefully, present the menu as a familiar vertically scrollable style menu.
Although with that many entries it might be more annoying.
Fixed it for me. Thanks!
MusE DAW running on Debian 11 Testing/XFCE4.
https://oscillator.se/musik
- oscillator
- Established Member
- Posts: 1127
- Joined: Sat Jan 17, 2015 6:07 pm
- Location: SWEDEN
- Has thanked: 725 times
- Been thanked: 298 times
- Contact:
Re: Automation
Ok, I understand the design choice. Maybe I will change my workflow using this. Thank you for clarifying!Tim E. Real wrote: ↑Sat Sep 26, 2020 4:19 pm For the other editors, I think it would be unwise to make them single instance.
The ability to view the same part in different places at one time is valuable, the cut/copy/paste facility being one reason.
MusE DAW running on Debian 11 Testing/XFCE4.
https://oscillator.se/musik
Re: Automation
BTW: Another useful shortcut for the tabbed UI is Ctrl+Tab. With that you can switch the tabbed windows quite quickly.
- oscillator
- Established Member
- Posts: 1127
- Joined: Sat Jan 17, 2015 6:07 pm
- Location: SWEDEN
- Has thanked: 725 times
- Been thanked: 298 times
- Contact:
Re: Automation
That works too? I was just going to ask for something like that!
MusE DAW running on Debian 11 Testing/XFCE4.
https://oscillator.se/musik
- oscillator
- Established Member
- Posts: 1127
- Joined: Sat Jan 17, 2015 6:07 pm
- Location: SWEDEN
- Has thanked: 725 times
- Been thanked: 298 times
- Contact:
Re: [SOLVED] Automation
MusE DAW running on Debian 11 Testing/XFCE4.
https://oscillator.se/musik
Re: [SOLVED] Automation
Must be a bug in Qt, as this can't be changed programmatically.
The highlight is apparently displayed in the default tab position, which is at the top. I chose to display the tabs at the bottom (makes more sense to me) - this is "official" Qt function, no hack, so it's supposed to work as well. Obviously the Qt guys forgot to adjust the Ctrl+Tab placeholders in that case, or it's a window manager issue.
I could create a user setting to select between the top and bottom display of the tabs, if you (or someone else) prefers the top version .
- oscillator
- Established Member
- Posts: 1127
- Joined: Sat Jan 17, 2015 6:07 pm
- Location: SWEDEN
- Has thanked: 725 times
- Been thanked: 298 times
- Contact:
Re: [SOLVED] Automation
No, no problem, spend your time making more awesome improvements instead of fighting qt!
MusE DAW running on Debian 11 Testing/XFCE4.
https://oscillator.se/musik