Replace favorites with sorting by most recently used #1292
Comments
|
The only thing with doing so is if you have a new module it will take a few uses to bump it up the list possibly could be months if a module eventually comes along that will be used a lot. Reason uses a similar method in its context menu, I love and hate it because if you do have a new device it takes a good few uses to get it into the shortlist for most used, although with the module browser able to hold a large amount of modules (3 or 4 rows) it might work better than Reason and how favourites currently works for sure. Would filtering/search still hold most used count. e.g. VCO tag most used first? (as an option) Could other sorting options, be a possibility (random, author a-z, plugin name a-z, ascending / descending etc) |
|
I could trash the usage count idea and sort by most recently used. I like that idea and don't see any problem with it, since my favorite modules would always be somewhat recently used. |
AndrewBelt
changed the title
|
Something that I would find infinitely more useful would be the ability to hide modules. With the greatest of respects to the various developers, in many cases, I'm only interested in a subset of modules from any particular developer. With the way that memory works, you'll often remember the developer name for a particular module but not the module name itself (particularly with a library as large as that in VCV). Hiding modules should enable folk to navigate a large library more easily. With regards to the favourites feature, my main bugbear is that it's neither a-z in general terms nor a-z per within each developer (if you've favourited many from a single developer) so once you've favourited more than a small set of modules, it's no longer a time saver. On that basis I stopped using the favourtes feature long ago but that's not to say that it couldn't be improved for those that rely on it. As for indexing the most-used modules, this sounds very useful but I think the artist should be in control of the number of most-used modules that are displayed. |
|
I rarely browse through every single module to have a large favourites list be problematic. It's just a nice way to keep what I search for at the top with the things I enjoy most. I also don't always use my favourites most often. If something new becomes favourite, I would want that to be at the top, rather than something I have been using a lot over the months. Being able to just remove one and add the other is more useful to me. On the rare occassion I am looking through without a search term, then some sort of alphabetical sort is more useful. Either by module or by developer, then module. That way they are grouped consistently, rather than an ever changing list I can't keep mental track of. |
|
@jonmoore1 This will come later. After the Plugin Manager web app is overhauled, you'll be able to add individual modules to your VCV account. Rack will download the entire plugin and only show the modules in your VCV account.
All of them will be displayed. When you open the Module Browser with no filters, you'll be able to scroll through all 1,200 of whatever modules, sorted by date last used. |
|
Most-recently-used is a really interesting idea. My first concern is that it doesn't play well with users who switch between different patterns of module use (which I think is pretty common). Say I'm working on a synth line, and then I want to work on drums (either in the same patch or in a subsequent patch). I bump a bunch of individual drum modules up to the top of the stack. Now, if I want to go back to the synth stuff, I have to go back down to retrieve the modules I was using, and they jump to the top one by one. At this point, I'm fighting against the sort order. Another issue is that "central" modules (big, complex stuff like Geodesics or some sequencers) will probably get instanced relatively infrequently, but early in a patch. I suspect these are the kinds of modules that many people are using Favorites for. A very simple metaphor which would align this with an adaptive sort like MRU is the "pin"; pinned modules float to the top (much like Favorites) but aren't as set aside. Bump order is great for community boards because it allows each user to benefit from the activity patterns of other users. In a browser, where a user is only responding to their own patterns, it's more like "put the threads that I just read at the top." Useful sometimes, frustrating at other times. I think that module browsing is the (rare) case where there's not one 90% good way to do it and the key is to give users a few options. People are used to changing sort order--it's a familiar operation for UIs--and different orders will be useful to certain users (or at certain times). |
A couple of thoughts here, both connected. You don't know which modules you like from a particular developer until you've tried them out a few times, so I'm presuming your suggesting that the management of individual modules is handled in the Plugin Manager web app. At first you see all the modules from a developer but you can subsequently hide modules via the Plugin Manager. I think it's usual for new users to browse modules rather than search/filter for them; so defaulting to a large indexed list might make the library less useful for those that haven't spent enough time with Rack to populate useful data for the index. Plus a singular most-used list might force a 'comfort zone', where users are less likely to explore beyond the top e.g 75 modules. For browsers, it might be more inviting to only have the top 20-30 most used modules listed followed by the alphabetical developer groupings. As someone else mentioned, a most used list takes a bit of time before the index is returning useful data. Before that point a new user is possibly more likely to browse. |
|
My first thought was NO, as I have just recently tried using the favorites option. However, I've still not formed a habit of pulling from it, so it tends to get ignored. I reckon human nature being what it is, many/most of us end up drawing from the same well over and over again. Might as well make it easier with a "most-used" list. |
|
A combination of both, that could be over complicated, is to use decaying counters (floating point). Every time a module is added, the counter is increased by a delta and the other modules counters decay. The modules with a higher number will be the most recently used and the most used. |
|
@modlfo I like that. If people complain, I could just tweak the parameter. |
|
@patman023 Please increase the quality of your posts before participating in GitHub issues. |
|
I believe that abandoning an existing feature of the product in favour of something that fits your own personal preferences (ie. "I hate the favorites feature") is short-sighted, as it directly impacts the workflow of your users. If you are going to code an entirely new feature to replace something else, how much more coding overhead/time does it take to generate a new menu entry/option? |
|
@patman023 Thanks for the improvement. I'm basing the original posts' assumption on the fact that I've never seen positive feedback for the favorites feature. After it was launched, I only received more feature requests to fix it by changing its problem scope, or comments that users would either favorite too many modules, thus making it useless, or favorite too few because it was time consuming. Most users simply ignore the feature, so they never get its benefit. The proposed feature is a sort of "automatically-generated" favorites list that attempts to guess which modules you want to use the most at the current time. This saves 100% of the time spent deciding on your favorites and allows the feature to benefit all users, not just those who would otherwise click all the stars. |
|
What about something like Reaper's plugin browser? Users can add their own folders to organize the plugins in whatever way makes sense to them and also browse all/by type/by developer if they feel like it. |
|
Well.. I do use the favorites feature all the time, I even wished it was sortable to my taste, since items just get added somewhere in the favorites list. |
|
A folder for favourites would be ideal but I agree that the current (0.6) way is a bit unwieldy. |
|
What Andrew implemented is based on this algorithm Ant Colony Optimization. Since it's an optimisation algorithm, it will learn from your actual usage. The best way of influencing it is to actually use the modules. I suggest you guys giving it a try. |
|
Excellent news, I personnaly like that it will be automated, and that it will function kind of like a memory cache. As I continue adding modules to v1, I'm getting the feeling that the entire list of all modules becomes useless to browse since it is too big, and I end up always having to select a vendor to make it more manageable. As for the former favorites implementation, I'm not sad to see it improved, since I hate manually managing favorites... heck, I can't even take the time to make playlists for my offline music. Thanks Andrew and Leonardo! |
|
I always used the favorites feature, and like it, but found it not very handy the way it is in 0.62 . |
No, all modules will be scored and displayed in order. If for example, you try adding every module you have to the rack exactly once, the Module Browser will sort them by most recently added. |
|
MRU is fine by me. Thinking about how I actually work (and we're talking a dozen hours a week of VCV Racking at least), it doesn't involve favorites as all, and as soon as I mark something a favorite it seems like I stop using it. The sheer number of modules is an issue and I'm sure it's overwhelming to noobs. But the search bar in 0.6 works as expected and it makes it easier to find if you know the general category of thing you're looking for. Any more almost all of my patching involves looking for specific modules by name. After that, next most common is typing the name of a category, and last of all, name of plugin. I don't know if I'm a typical user, but I think in this context I'm fairly typical. The MRU listing interacts well with those use cases, particularly if the type-in search is maintained. |
|
@Chaircrusher If your search queries are specific enough, usually you can filter down to a handful of modules, so the display order doesn't really matter. The "favorites" feature is mostly used by people who want to find modules even faster than they would by searching. And the ant colony sorting does that pretty well. |
|
One small addition that could improve workflow though, is that when we type a good-enough filter such that the module we want shows up first in the list, it would be really cool if it could be selected by pressing enter, instead of having to go back to the mouse and clicking it. |
|
So would the entire list of modules sort in this fashion? What I always wanted with the regular hierarchical menu was for the modules themselves to be sorted alphabetically under alphabetically-sorted developer names. |
Brands are sorted alphabetically on the left at least. |
|
I'll get used to whatever. We all whine when interfaces change. I remember hating "the ribbon" when Microsoft introduced it to Office. Now I can't remember what it looked like before then. Users will adapt. |
|
Nooo don't remove the favourite option please! It's the only way I can find those few modules of which I always forget the name, the ones I use often I know their names so it takes only 1 second to type and hit enter. Having a 'sorted' list that changes over time makes it impossible to memorize the approximate positions in the list. It's like facebook deciding for users what it thinks the user wants to see first: great for some users, annoying for a lot of others, and for a few the reason to quit the platform completely. I'm also thinking about the future. What if soon there are 1000's of free modules, some people just add them all to VCV (like me) to check things out. What good is a list of 1000 modules if 950 of them are shuffling down the list making it near impossible to find it back? Taking a look at the UI: I see the header Modules (33) |
|
What @catronomix said. Foobar2000 style playlist tabs. |
|
@AndrewBelt I also totally agree with @catronomix |
|
I would argue the most important quality of any UI is consistency. Having modules move around from place to place each time I view the plugin browser is annoying. We already have filters by Manufacturer and Function. Within a manufacturer I would like either alphabetical order or maybe order determined by plugin.json so that the developer could logically "group" certain modules together (like a module and its expanders, or modules that work together). The important thing is that no matter what the order is, when I know where a module is, I want it to stay there |
Allowing the sort order to be configurable is good, but it complicates the UI. There is a standard (and I imagine cross-platform, if you use a library like e.g. Qt) object lister, with multiple columns that contain metadata. Conventionally you click on a metadata heading and that becomes the sort order; click a second time and it inverts the order. In the file browser (in Windows, X11, Mac OSX) you can sort by name, date modified, size, etc. VCVRack could -- eventually -- use something similar. But like everything else, it's a small manner of programming. This would be a good project for someone to do on a fork. Not that I'm volunteering. |
|
The module preview has no columns to click on, otherwise this would be a trivial discussion, since yes, that kind of UI has been done a million times |
|
Nothing about this discussion is trivial. Every suggestion has a multitude of problems. Remember, what you might think makes sense for you might not make sense for other users. That is the primary reason this is a difficult problem. Suppose I add module sorting options. What choices will it have? I can only think of a few, and most of them don't make sense. These are the only ones that do.
We can't sort by:
An important question is "Is inconsistency bad or good?" If your filter is good enough, the results will be consistent. If a user doesn't want to filter, wouldn't that mean they're not looking for a module in particular but rather browsing for new ideas? So therefore inconsistency is not bad? Another point is that if a decision is "on the fence", doesn't that mean that either answer has equal (or close) benefit, and therefore what I choose doesn't matter than much? |
|
@almostEric, if the problem was easy, you know I would have solved it already. I believe that I'm bringing up valid points about each design problem that will have to be addressed, but if you don't want to have a mature, informative discussion, please refrain from posting comments. |
Every program worth using has a learning curve, even (especially?) VCVRack. That because anything worth doing is complicated enough to require some amount of frustration where you learn how to do it. I find even 0.6 quite easy to use, because I've spent many hours messing with it, but I feel like I was au fait with working it after just a few hours of play. Not every program is like that; it took me weeks to get my head around Ableton Live. Both programs reward practice. So does a violin, for that matter, and for the same reason. Until you build up some muscle memory every step is painfully self conscious and uncertain. Which doesn't really say what I think @AndrewBelt should do about sorting in the browser, which is this: You've demonstrated an ability to think through and solve difficult problems, and I trust your judgement. And if you do something I hate, I'll adapt, and after a while forget why I hated it. |
|
I have set the sorting order to (most recently updated, plugin brand, module name) in 82b817e. The timestamp is obtained from the |
|
@AndrewBelt The only thing I find is a slow down with the module browser, as an example is when you are filtered by brand and you open up the browser you are still filtered by brand (sometimes you still want to be filtered though). If you want to add something different the only option is to reset the entire search which resets the filter and the text (you might still want to add a different VCF). It would be very handy if the first click on reset resets the filter/tag but keeps the search then the next click resets the text (double click). If you are not filtered then it could clear the search or if you are filtered but text is already clear then it resets the filter on first click. Or another option would be to have 3 separate reset buttons one for filter one for search and one for both. Other than that it is perfection, imo! |
|
So, i have now been using this new sorting of the browser for a week or 2. |
See my above post. This ordering has been removed and replaced with "most recently updated". |
|
Having gotten used to the sort order over the past 27 days I can honestly say sorted by "most recently used" is the far superior option IMO, besides the search/reset issue already mentioned most recently used is 1000 times better than any other methods Iv'e used in VCV, and that is across all versions. The most used modules will always be at the top of the module browser! It is pretty clear from most replies that options would be the only way to cater for everyone. Most recently updated would be a nice option to have if you add a new plugin and not remember what it was i.e. a couple days pass or you added afk, but it doesn't really help with workflow. Also the cynic in me can see it being abused with people pushing updates just to be on the top of the browser. |
|
I've used the favorites list extensively in 0.6 and its removal hurts my workflow in 1.0 tremendously. I can rig something up by using a script to run over all plugin.json files, clear up one or more unused categories (like the currently empty "Digital" one) since VCV doesn't allow custom user tags, and repopulate those based on my user favorite list, which would replicate the lost functionality. But needless to say that seems like a goofy workaround at best for what used to be an incredibly handy and constantly used feature for me. And inflexible timestamp based sorting out of my control doesn't serve the same functionality at all. Pretty much every other software with a potentially significant library has some sort of user configurable tag/rating or sorting feature to allow personalized prioritized access, so the decisions to kill it has me confused, to say the least. |
|
Quick follow-up: i've written a small tool that parses all modules in a provided vcv rack patch (descriptively named "favorites.vcv") and applies an unused tag (for example "Flanger") to all of the used modules based on a plugin-slug+model-slug mapping. So now i can manage my favorites simply by adding or removing modules to the favorites patch and drag/dropping it on the helper tool, and they show up nicely sorted in the "Flanger" category for quick and easy access. So in a way this workaround (that could trivially be expanded to multiple input patches for tiers of favorites) is even better than the 0.6 favorites system and exactly what i needed. Neat! |
|
I think having a 'Favorite' tag could be an easy way to implement it. If Rack could modify plugin tags inside their json properties, then just add a right-click option to the module previews to set the tag in the plugin. Then showing the tags is just a matter of clicking on it like any other tag, so the way the module browser works doesnt need to change. |
|
That's pretty much how my helper tool does it, with the most significant restriction being that the Rack browser only lists tags from a hardcoded list of static strings, and these don't include any reserved keywords for user sorting. Would be easy enough to add a few "0 to 5 stars" tags, but probably not worth creating a fork over. The other obvious drawbacks being that plugin patches update the associated json, so you need an external data structure (like my favorite patch) to preserve the user-side metadata, and that Rack (currently) only reads the plugin.json metadata on startup, so you can't change your favorites without a restart. |
|
Hello, and thanks @AndrewBelt for this wonderful piece of software. When trying to search if a feature request for having back the favorites list in 1.0, I ended up here, and before posting, managed to read the full thread, despite my poor programming skills. My addition to the topic though : all the ideas are very good. Just thinking totally replacing the favorites by a more clever way of sorting the plugins, lacks something for users (but how many ?) like me : |
|
I used Favorites very time I used Rack in 0.6, I'm very sad to see them gone in 1.0, since there are so many wonderful modules out there. As a producer, I feel like "my sound" is the result of the set of modules I rely on and know intimately, so not having those immediately on hand is a real bummer. |
|
What's wrong with having an option for this? I don't see how there's a single best option. Why not offer some choice. Most recently used (MRU) might make most sense for me, others might prefer a static favorites list they have to manually tend to, just like they're used to. |
Because Rack development is incremental, meaning we start with one "best" way of doing things and then gradually expand the feature set. This feature is also low priority, and I am on vacation right now. |
Have fun! :) |
|
Actually, let's close this and transfer to this issue. #1434 |
and others
I hate the favorites feature. It's too complicated to manage because my favorite modules change often, I have too many favorites to find anything, or I have too few favorites for the feature to be useful. ("I" here means my impression of most users.)
Let's replace it with a usage counter that is saved to
settings.json.{"plugin": ..., "module": ..., "count": ...}When you drag a module from the Module Browser, the counter for that module is increased by 1.When no search query is entered in Module Browser, the modules are sorted by usage.
The text was updated successfully, but these errors were encountered: