KVR :: Loomer » Preset Managment [View Original Topic]
There are 21 posts in this topic.
rumba_codex - Thu Apr 07, 2011 9:59 pm
Nice to see the update for Aspect v1.7, Colin - well worth the wait!
OK, time to nag nag nag once again about preset navigation ...
Would it be possible to have Up/Down keys linked to the main console (i.e. not talking about the browser here) so that you can move through the presets from a keyboard. (maybe this is a bit iffy ...)
Browser window: it's great that we have this now and I like the recent tweaks - it's made a huge difference. But is there a particular reason you chose a pop-up window for the preset browser? Would it not be simpler to have a tabbed consolidated window?
Think of it this way: if you build up a collection of 100s of presets then it's going to be a lot easier to see folders and lists if the browser window = same size of main GUI. A tab would make it easier to get there.
Waddayareckon?
rumba_codex - Thu Apr 07, 2011 10:45 pm
Just a quick tip here: with the preset browser open you can quickly preview presets using the Up/Down keys. When you find something you like, hit Enter. Otherwise the previous preset you were using will remain selected. (Like this).
Tech note: on one Win7 machine using Reaper v3.73 in the last couple of weeks I have had issues losing key controls with a few VSTi (that have bindings). After closing / opening Reaper all is well again. (A colleague has almost the same setup and no problems ... interesting)
HunterKiller - Fri Apr 08, 2011 1:11 am
rumba_codex wrote:
But is there a particular reason you chose a pop-up window for the preset browser? Would it not be simpler to have a tabbed consolidated window?
Think of it this way: if you build up a collection of 100s of presets then it's going to be a lot easier to see folders and lists if the browser window = same size of main GUI. A tab would make it easier to get there.
Waddayareckon?
Think of it this way: if you build up a collection of 100s of presets then it's going to be a lot easier to see folders and lists if the browser window = same size of main GUI. A tab would make it easier to get there.
Waddayareckon?
+1
Colin is gonna kill me, as I've already nagged him about this twice
colin@loomer - Fri Apr 08, 2011 1:30 am
A re-sizable preset browser is on the big to-do list, and to be honest I don't imagine it is all that much work. When I have a spare few minutes, I'll take a look into this; it would be nice to get into the next release.
I'm not sure that using cursor keys in the main UI to trawl presets is that easy to implement: it took a lot of work to get key presses to work in the preset browser with every host and with plug-in format. Besides which, as you noted in your second post, they do work if you pop-up the preset browser. And the preset browser also has the advantage of displaying the preset information, plus you can cancel at any time and return to the previous preset state.
However, taking a good long look at keyboard handling is something I'll need to re-address soon because keyboard entry for controls is something a lot of people have asked for.
And as a final tip: did you know you can change presets using the mouse-wheel by wheeling over the preset name in the header bar?
rumba_codex - Fri Apr 08, 2011 6:10 pm
Yeah, I remember now that key control can be a real pita for devs. My tech note is one minor example of the issues involved with DAWs, OSes etc.
A re-sizable browser sounds good!
Thought of a simple solution for using key control on the main GUI panel. You simply have a minimal / expanded option for the preset browser. In minimal mode the browser frame *only* boxes the preset text box on the header bar. So you can still use keys to scan preset lists but you can access the entire GUI as well.
In expanded mode the standard preset browser is visible and can be dragged open as desired. Basically, the only code that changes here is the browser frame behaviour / positioning. If you wanted to get clever you have a latch option (see Wusik v6 - also in JUCE) where the browser rides on the side of the GUI. Would be fine for wide monitors.
PS: Yes, good old MW control - can be tricky with speed settings, type of mouse etc. Prefer to step through with keys - less eye strain, too.
colin@loomer - Sat Apr 09, 2011 11:07 am
I'll take look at the Wusik v6 preset browser, thanks for the tip.
I cooked up a resizeable preset browser this morning, and am currently playing with and tweaking it: seems to work quite nicely, but there are a few little usability and visual issues that I need to make concrete decisions on.
The plan is, I'll probably do an Aspect 1.7.1 update in the near future*, get the new browser into the public's hands, and then see what everyone thinks.
* Probably this week: I'll wait for the dust to settle on the 1.7 release before I commit to a firm 1.7.1 date.
rumba_codex - Sat Apr 09, 2011 7:54 pm
Thanks for checking this out, Colin - excellent news!
Looking forward to the update.
colin@loomer - Mon Apr 11, 2011 3:38 am
Re-sizable preset browser seems to be working rather nicely; thanks for the suggestion. The size is saved, so for those who like the current dimensions can leave it as is, and those who'd prefer the preset browser to fill the entire client area only need size it the once.
I've a few other minor niggles pertaining to the Aspect 1.7 release to fix first, but expect a 1.7.1 update sometime this week...
rumba_codex - Mon Apr 11, 2011 6:22 pm
Looking good, Colin!
OK, with the browser expanded (as you have it here) the left hand pane could be smaller or even fixed width. There's usually a character limit for preset names so that would be your measure for collumn width - allowing for folders and sub folders. Otherwise, a sliding separation bar is an option - but depends on what is easy in JUCE.
In the right hand pane maybe you could allow for a double collumn so that more presets are visible - but only after the browser is expanded x number of pixels laterally. With the browser expanded wide enough this would equal list view in Windows Explorer (not details view).
Anyway, you might have taken this stuff into consideration ...
colin@loomer - Tue Apr 12, 2011 4:55 am
Thanks!
Unfortunately there doesn't appear to be trivially easy way of having a double column: it's a good idea though, so even though it may not make it into the immediate next release, it'll be something to think about for a future one. I do agree that a sliding seperator bar and double preset layout would be particularly nice. It really depends on timescales and how much free time I have this week (so far, not a huge amount!)
(As an aside, actually there is no limit other than the file system ones in the internal length of a preset name. You'd be surprised at how many people asked for longer preset names.)
rumba_codex - Wed Apr 13, 2011 5:50 am
Quote:
(As an aside, actually there is no limit other than the file system ones in the internal length of a preset name. You'd be surprised at how many people asked for longer preset names.)
Obviously there's some confusion between naming a synth preset and a tweet. Just a fad. Next they'll be asking for abbreviated old skool DOS~ ...
Let's see how this first update goes - should be good. Thanks!
colin@loomer - Wed Apr 13, 2011 7:51 am
Aspect 1.7.1 is now available for download; see this thread for a little more information.
Unfortunately, I didn't get a change to implement a move-able seperator bar: a release was forced out because a rather nasty bug involving hung-notes cropped up. More than likely, I'll get back into preset browser improvements post Sequent update (late April-ish?) Given a few weeks to play with it, I'm sure everyone will have more suggestions and opinions as to where to take the browser in terms of improvements.
rumba_codex - Thu Apr 14, 2011 4:41 pm
Houston, looks like we've lost key control in this latest release ...
Otherwise, it's a good start...
colin@loomer - Fri Apr 15, 2011 6:52 am
Lost key controls: that's not so good! In which situation does this occur? As far as I'm aware, nothing to do with keyboard handling should have changed between 1.7.0 and 1.7.1. (Emphasis here on should: it's certainly possible the browser changes broke something else!)
rumba_codex - Fri Apr 15, 2011 5:25 pm
Reaper v3.7x on WinXP SP3.
Would be good if someone can confirm this - yay or nay. With the preset browser fully expanded just play with the Up/Down keys ... Over here, other synths with preset browsers that offer some sort key control are all working.
There is also a GUI redraw / lag issue with the preset browser fully expanded. When clicking on a folder the contents in the list are slow to appear. On an older machine the contents may blank out for a couple of secs. Clicking from folder to folder feels kludgy. (No surprises here - this is the first go with the new browser ...)
Do you have Backspace and Del (for editing preset names) mapped in this version?
colin@loomer - Sat Apr 16, 2011 2:29 am
Just checked with Reaper 3.75 / Windows XP SP 3 / 32-bit: Up and down cursor keys seem to be working fine in the preset browser. I would check that the presets list box has the focus (ie, click on it). If this is the case, I could (probably) make it so that Up and Down scroll the preset list, regardless of whether it has the focus or not. Or perhaps make it more obvious that the preset list isn't currently focused.
There has been no change to Backspace or Delete handling in this version, and it does appear to be working here. I deliberately use a modal dialog box for the save dialogs because they seem to be more reliable regarding key presses.
I can't duplicate the slow GUI redraw issue - does this only happen when clicking folder to folder, or is it also slow to scroll them? Is it particularly slow on a specific 'type' of folder (eg, Factory, Users, Categories?) There may be a few optimizations I can employ here... I also toyed with the idea of multi-threading this, which will make it much more responsiveness: perhaps this is something I'll need to seriously look at soon?
rumba_codex - Sat Apr 16, 2011 3:30 am
There it is again! Now it's working in Reaper. Very interesting. Hmm ... might be an anti-malware issue ...
Still a little slow when you click from folder to folder. But no re-draw issues going from one list to the next.
OK, try out Minihost - just copy the Minihost.exe and OpenAsio into the folder and drop Aspect onto the *.exe.
Key control won't happen (that's Minihost, not you). But you *might* see the browser GUI re-draw issue. Over here, it's the same as reported. This will be noticeable on an older machine - you won't see it on on your quad core with 192 Gig of RAM.
colin@loomer - Sat Apr 16, 2011 5:22 am
If the slowness is folder to folder, I expect the cause is not GUI related, but rather file system related. Enumerating and opening the presets is a pretty slow operation, but I strongly suspect a multi-threaded file reader would fix this. I'll make sure this gets looked into at some point soon.
HunterKiller - Mon Apr 18, 2011 1:05 am
CPB wrote:
Re-sizable preset browser seems to be working rather nicely; thanks for the suggestion. The size is saved, so for those who like the current dimensions can leave it as is, and those who'd prefer the preset browser to fill the entire client area only need size it the once.
I've a few other minor niggles pertaining to the Aspect 1.7 release to fix first, but expect a 1.7.1 update sometime this week...
I've a few other minor niggles pertaining to the Aspect 1.7 release to fix first, but expect a 1.7.1 update sometime this week...
That's beautiful.
That's pretty much what I've always wanted, a full screen browser. It just looks right on big screen.
Will you port it to all Loomer stuff?
colin@loomer - Mon Apr 18, 2011 2:57 am
Great, thanks for the feedback.
Still a little work to be done on the browser - I've had a lot of good suggestions regarding this - but yes, the re-sizeable browser will be "as standard" in the next updates of all the products.
colin@loomer - Sun May 08, 2011 6:12 am
I've been going over the preset browser with a fine-toothed comb in order to fix some fairly obscure graphical and redraw bugs which seem to have manifested as a result of the re-sizeable browser.
After spending the best part of a day looking into this, I'm convinced that the best thing to do would be to always make the browser fill the plug-in client window, and remove the resizing. I've had a lot of positive feedback regarding the bigger browser, so I'm fairly confident that the vast majority - if not everyone - just maximizes it anyway.
Additionally, and thinking about the direction that I will be taking the preset browser over the next few iterations - this does make more sense from a design point of view. It really solves a lot of problems, from my perspective at least.
So, my question to the floor: How do you feel about always having the full-sized browser as standard, and losing the ability to resize it? Perhaps I should just make this change for the next Aspect update, and if anyone feels short-changed by it, I can look into adding the resizing back in a later update?
I don't like to remove features, even little ones like this, but I'm in a position where I could be spending days looking into fairly obscure graphical bugs, when I could be working on much more interesting new features.
Any thoughts regarding this?
There are 21 posts in this topic.