v3 Beta Feedback And Discussion (Bugs, Features, Suggestions)
-
- KVRAF
- 1508 posts since 30 Nov, 2013
If I assign different colors on the lines and on the parts and then drag them ( swapping them ), the lines will again take the color of the parts in which these lines belong. Is that intended ?
-
musicdevelopments musicdevelopments https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=223336
- KVRAF
- Topic Starter
- 5435 posts since 9 Jan, 2010
No, you did not misunderstand it, I want to move the inspectors on the right side, so the floating inspectors will be gone.sj1 wrote: ↑Fri Jul 31, 2020 11:27 am Could you please expand on the issues in this area a bit?
Immediate access to the relevant Inspectors, as now available via right-click, is very useful and very "rapid". I can't imagine upside in this going away.
Presuming that the right-side dock is generally open would be a bad presumption, IMO. I know in my case I work with the right-side dock generally closed and out-of-the-way for maximum viewing real-estate. It's great to be able to open it when/as needed, but having to go thru the dock to reach the Inspectors, oh no, please no.
Perhaps I misunderstand the proposal?
I wanted to do this because some forum posters were fed up by the inspectors always hiding information in the background, and they had to keep moving the inspector windows around. I agree, I also think of inspectors as pop-up menus, that you can move around, and I found it a good idea. I was disappointed when not everyone agreed
I am not sure anymore if this is a good idea. I want to avoid spending a lot of time with something that you don't find useful, or think that this would make things worse.
I show you a screenshot with the browsers and inspectors:
By clicking on the small icons (or using keyboard shortcuts) you can show/hide the browsers and inspectors. So you can have
- only the browsers,
- only the inspectors,
- both the browsers and inspectors (shared), or
- none of those
on the screen.
Really, we must agree if this is useful, or not. From time to time I receive criticism because the UI is non-conventional, now this is how it is done in other DAWs.
Thanks,
Attila
https://www.musicdevelopments.com
Home of RapidComposer, Melodya, MIDI Mutator and Syne
All software 40% off during the Anniversary Sale until April 29!
Home of RapidComposer, Melodya, MIDI Mutator and Syne
All software 40% off during the Anniversary Sale until April 29!
-
musicdevelopments musicdevelopments https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=223336
- KVRAF
- Topic Starter
- 5435 posts since 9 Jan, 2010
No, this is wrong, the colors are overwritten. I am fixing this now.
https://www.musicdevelopments.com
Home of RapidComposer, Melodya, MIDI Mutator and Syne
All software 40% off during the Anniversary Sale until April 29!
Home of RapidComposer, Melodya, MIDI Mutator and Syne
All software 40% off during the Anniversary Sale until April 29!
-
- KVRAF
- 1508 posts since 30 Nov, 2013
Thank you, Attila!
I am 1000% supportive of your plans to move inspectors to File Browser. But perhaps for those who are completely irreconcilable with this, it will be possible to make the option "Floating Inspectors"))))))
I am 1000% supportive of your plans to move inspectors to File Browser. But perhaps for those who are completely irreconcilable with this, it will be possible to make the option "Floating Inspectors"))))))
- KVRian
- 995 posts since 13 Mar, 2017
That's an interesting path. It does work! Thanks.BluGenes wrote: ↑Fri Jul 31, 2020 12:14 pm Hey sj1.. here is a quick work around..
double click on a part to bring to focus.. double click again to show composition, it leaves all the chords selected. Right click one of the selected chords and on the gear tab, near the bottom is "set as timeline region".
The cost though is:
mouse-move to chord area
right-click on chord area (to open inspector)
move-move to 'Set As Timeline Region'
left or right-click on 'Set As Timeline Region'
mouse move to top left red X of inspector
left or right-click on top left red X of inspector (to dismiss inspector)
which pretty much sums up why I would much prefer "just being there" as an option! (it's more Rapid)
-
- KVRAF
- 1857 posts since 15 May, 2017
I actually agree with you.. to be honest, I have done this myself in the past.. anything to get RC to time warp compositions is always welcome..sj1 wrote: ↑Fri Jul 31, 2020 1:12 pmThat's an interesting path. It does work! Thanks.BluGenes wrote: ↑Fri Jul 31, 2020 12:14 pm Hey sj1.. here is a quick work around..
double click on a part to bring to focus.. double click again to show composition, it leaves all the chords selected. Right click one of the selected chords and on the gear tab, near the bottom is "set as timeline region".
The cost though is:
mouse-move to chord area
right-click on chord area (to open inspector)
move-move to 'Set As Timeline Region'
left or right-click on 'Set As Timeline Region'
mouse move to top left red X of inspector
left or right-click on top left red X of inspector (to dismiss inspector)
which pretty much sums up why I would much prefer "just being there" as an option! (it's more Rapid)
-
- KVRAF
- 1857 posts since 15 May, 2017
probably because the area of RC that needs it, doesn't have keyboard focus. It is another area of the software that does need some love from Attila, I think..
- KVRian
- 995 posts since 13 Mar, 2017
Hi Attila,
Seeing more of your current plan as you lay it out above provokes much thought, and probably some more experimenting. I hope we have more than a few hours to respond before you deeply commit. I will comment more later today.
Seeing more of your current plan as you lay it out above provokes much thought, and probably some more experimenting. I hope we have more than a few hours to respond before you deeply commit. I will comment more later today.
-
- KVRAF
- 1857 posts since 15 May, 2017
On the subject of the new inspectors.. I'm on the fence there.. Wouldn't really know how I feel until I try it.. I think maybe, while you code this in, use a conditional define just in case you need to quickly need to undue all of that??
- KVRian
- 995 posts since 13 Mar, 2017
Here is a potential framework for thinking about it, before we drill in too far to see the forest:
Issues around this subject:
1. Speed of invocation (minimizing time and motion)
2. Size of Inspector display
3. Location of Inspector display
4. Relative developmental ease or difficulty of offering/maintaining user-configurable choice about this
5. Speed of dismissal
Suggested Definition of goal:
a) Immediate invocation of Inspectors, at user's desired size, in user's desired location, with the code base being sufficiently maintainable so as not to become a notable burden on all future development. Also, simple, quick one-operation dismissal.
How would others add to or modify this?
Issues around this subject:
1. Speed of invocation (minimizing time and motion)
2. Size of Inspector display
3. Location of Inspector display
4. Relative developmental ease or difficulty of offering/maintaining user-configurable choice about this
5. Speed of dismissal
Suggested Definition of goal:
a) Immediate invocation of Inspectors, at user's desired size, in user's desired location, with the code base being sufficiently maintainable so as not to become a notable burden on all future development. Also, simple, quick one-operation dismissal.
How would others add to or modify this?
-
- KVRAF
- 1508 posts since 30 Nov, 2013
About the speed of access to the inspector .. In the picture that Attila showed, as a prototype of the future inspector, you can see that he found an excellent solution.
You do not have the required permissions to view the files attached to this post.
- KVRian
- 995 posts since 13 Mar, 2017
I notice that the current pop-up inspectors invoke immediately with a right-click. Good!
I notice that the current (V 3.9b25) pop-up inspectors pop up at their prior size in their prior location. Double Good!
I notice that the current pop-up inspectors have already been developed. There is no extra work to leave them as-is. Good!
The current pop-up inspectors do not easily dismiss. Neither Esc nor Ctrl-W will accomplish a dismissal. Nor does the user have a choice between "Stay open until I dismiss you" and "Do the selected operation and then go away!". Improvement in this area is to-be-desired, IMO.
I notice that the current (V 3.9b25) pop-up inspectors pop up at their prior size in their prior location. Double Good!
I notice that the current pop-up inspectors have already been developed. There is no extra work to leave them as-is. Good!
The current pop-up inspectors do not easily dismiss. Neither Esc nor Ctrl-W will accomplish a dismissal. Nor does the user have a choice between "Stay open until I dismiss you" and "Do the selected operation and then go away!". Improvement in this area is to-be-desired, IMO.
- KVRian
- 995 posts since 13 Mar, 2017
As for everything being (only) in the browser dock area -
The Browsers are mostly lists. At the top level, we don't need a very wide docking area to use them. Of course if we navigate deeper into a hierarchy then we'll need to expand the docking area. That is already available.
Inspectors (e.g. Phrase Inspector) often need to be wider than simple lists in order for their menu items to be readable.
So, I'd say there is a bit of a mismatch if we get stuck with a "last used" size default for the docking area. It's less of an issue if the docking area dynamically opens/closed/resizes for invocations of different Inspectors, but that seems like a big developmental/maintenance complication (depending on what the internals actually are).
If the code is object-oriented in a way that very simply allows the object of any Inspector to be flowed into a matched-size docking area then OK, perhaps all possibilities can be easily accommodated as options. OTOH, if we are going to be stuck with a "last used" size default, or pay a huge price in developmental/maintenance effort for dynamicism because it all has to be custom written and maintained then I question the relative worth of that.
Considering that a user can currently choose to leave any/all Inspectors with a "last used, next open" size and location on the right-hand side if desired, I'm not seeing the shortcoming in the current way of doing things. Maybe someone else can speak to this.
The Browsers are mostly lists. At the top level, we don't need a very wide docking area to use them. Of course if we navigate deeper into a hierarchy then we'll need to expand the docking area. That is already available.
Inspectors (e.g. Phrase Inspector) often need to be wider than simple lists in order for their menu items to be readable.
So, I'd say there is a bit of a mismatch if we get stuck with a "last used" size default for the docking area. It's less of an issue if the docking area dynamically opens/closed/resizes for invocations of different Inspectors, but that seems like a big developmental/maintenance complication (depending on what the internals actually are).
If the code is object-oriented in a way that very simply allows the object of any Inspector to be flowed into a matched-size docking area then OK, perhaps all possibilities can be easily accommodated as options. OTOH, if we are going to be stuck with a "last used" size default, or pay a huge price in developmental/maintenance effort for dynamicism because it all has to be custom written and maintained then I question the relative worth of that.
Considering that a user can currently choose to leave any/all Inspectors with a "last used, next open" size and location on the right-hand side if desired, I'm not seeing the shortcoming in the current way of doing things. Maybe someone else can speak to this.