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 
)
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 
