Module Browser

A streamlined Module chooser/selector picker

maybe this post will be moot as I haven’t seen the update yet :slight_smile: ?

I’d love to see a streamlined browser for modules - where you could skim through them in maybe a category list… or sort by name … or a bubble to the top most recently etc. with an expanded description of what each module is off to the side… That, with perhaps the ability for a user defined name or category for a module

My reasons are a few:

With @thetechnobear adding so many awesome modules, it’s packed to the brim now and getting cluttered.

-the X/Y tile selection is really finicky if you move the encoders quickly… they jump tiles and the selector goes all over the place… it’s not a precise or enjoyable UX.

-such a big screen - there’s lots of space to make this area clean and quick

1 Like

the new release doesn’t change the current module browser.

however, given the number of plugins Im adding, its definitely recognised as now needing something to group the modules a bit.
in fairness, I’d not shown Bert/Celine all my plugins before SB - so, they were quite surprised how ‘full’ the browser looks with all my additions (compared to the ‘factory image’ we had sitting next to it :slight_smile: )

anyway, think categorisation would be the obvious first step…
however, we really need to think about the categories.

when I thought about this before, I had a couple of difficulties.
a) which categories?
some plugins dont neatly fall into one category…
e.g. Rings can be both an ‘sound generator’ but also an ‘fx’ (resonator)

of course, we could do this as ‘tags’ , but I think this is over complication initially…

b) spreading modules over categories
this is kind of related to (a) , if I chuck things like rings into sound generator, before you know it, we end up with some categories with lots of modules, and some with hardly any.
e.g. filter seems like a category, but we (will) have 2 modules in this category.

again, using tags might help BUT might mean we end up with too many things in multiple categories.
(e.g. LFO ends up in ‘modulators’ and ‘sound generator’)

so the trick is, having categories that dont have too many OR too few modules in them.


all that said, I dont think perfection should stand in the way of good,
so no reason to not start with a simple classification, then refine as we go along.

probably main thing is to define some good initial categories, that we can nicely spread the modules out over.

as I said, Id also like to keep it simple initially…
this includes only having a few categories, so they can all be seen without scrolling.
( I think this would be something like 10-12 max ? though we probably want less initially, so we can ‘expand’ as we find necessary.)


another related area, that Ive seen is colours of modules…

so the factory modules all used a unique colour ( * ) , when seen in the browser and network view.
this is nice, as you can start to recognise modules quickly.
( * ) actually there are a couple of duplicates

however, given I had to add colours to all my modules… its clear that this is no longer possible.( * )
there are only certain colours that work well on the display, esp when you take into account other factors (black module name, various selection borders)
( * ) I ended up pretty much using random colours in the end, and doing things like using same colour for all mutable modules.

so Im starting to wonder if there should be some kind of standard for colouring… perhaps by category?
however, not 100% on this, as it might not distinguish things enough…

probably the best approach will be to try this, once we have categories… and just see what presets look like.


as for when?
well, theres a lot of really big and important changes in this upcoming release.
therefore its important to get the release out…not only for beta, but as the stable release.

one (small) example, due to the sdk changes, my plugin development is now forked… so I cannot release any plugins to the community until this release is made.

so I really can’t imagine (or see likely) that the this release would be delayed to add new features, as devs say, Id consider it ‘feature complete’ - and the beta will mainly be to uncover any major issues, before doing the stable release.

of course, as always, these are just my personal opinions/ideas… and the things I would propose… reality may differ :wink:

2 Likes

I personally find the module selection page a bit bulky, its not a big deal but I would prefer just a simple text list of modules like when you load audio files on the left and as @NeilParfitt says a description box to the right with an explanation of function would be more than ideal. Categories like you listed your plugins in the other thread might be helpful if we end up with lots of plugins.

1 Like

I dont think a simple list of modules will work…
Im now at 50 modules, with around 10 on a ‘page’, thats 5 pages, if it were a simple list of everything.
frankly, I find the amount of scrolling on the IO side too much already…

but, indeed, I think once category is used to filter, then a simple list is all thats needed.

as for description, could be useful, esp. as the 4 char name, is a ‘squeeze’ :wink:
the new sdk exposes - short description, module version and developer.!
the factory modules also have a short description, and we could ‘hard code’ the version/developer.
so those are easy to utilise.

however, category would need to be added… as its not in sdk nor something the factory modules have a concept of. ( I had already proposed it for the sdk api :wink: )

personally, if I look at this, Id probably allow multiple categories to be specified from the outset… but perhaps a simple UI on that initially. also, rather than a fixed category list, build it from whatever the modules declare… that way new categories would be automatically ‘created’ , as modules change their definition.

so, it’s not so hard to do this, but the SDK change is a bit of a pain, due to versioning.
Id probably prefer to do this after I’ve released all my plugins, so I can update them all in one go, one release.

anyway, this pretty much is inline with the fact that this release is ‘feature complete’,
so this kind of thing will be sometime after this release is out of beta etc.

again, all just my opinion… may be Bert has other ideas.

Another option is to group the modules alphabetically, in 3 to 4 pages. Sometimes the simple approach is the best.

1 Like

I’d even enjoy a ui similar to the preset area where there’s a list of the stuff you could scroll through, and an open area for a detailed description, I/O details etc

2 Likes

yeah, I think that’s the obvious approach… esp. once we start employing filters e.g. categories.