Smarter module layouts - Githubissues

grrrwaaa commented 4 years ago

Currently module layout is automatic, and uses a very simple heuristic; no doubt this could be better.

Collecting ideas here for future heuristic enhancements in module layout:

Prefer some standard heights of boxes, somewhat akin to the hardware modular world. I know we are avoiding skeuomorphism, but there's a practical rationale here: at some point we may add module snapping, and having more regular sizes will make that make more sense. For example, if our smallest widget (e.g. a jack) occupies 1U in MSVR terms, then we could limit modules to be powers of 2 of U (1U, 2U, 4U, 8U) etc. which will make organization much simpler.
Some widgets might want to be 2x2 etc.
It is OK to insert some small spaces if it would otherwise make the layout more legible.
Utilize inlet/outlet nos. [in 1] would always appear to the left of [in 2].
Utilize topological proximity in gen patcher to guide grouping and ordering in VR. A knob above a jack in the gen patcher should probably be above it in the module. Several inlets near to each other should probably also be near to each other in the VR module.
Display array-like objects in lines. E.g., a simple knob-based 8-step sequencer should have its 8 knobs in a row (and its 8 gate outs also in a row below, etc.). Perhaps these cases can be identified using some array notation in the parameter names (assuming the symbols doesn't cause trouble)
For larger modules it may make sense to group IO jacks in a "patch bay" either below or to the right of other items. (Though, knobs-as-jacks may invalidate this heuristic.)
User-defined module positions by means of comments in the gen patcher.
what determines the size of a UI element? (big/small/trim knob)

michaelpalumbo commented 4 years ago

added a bullet point

Zodsmar commented 4 years ago

this would clean a lot up on the module side of things. Also having everything a factor of 2 for expansion makes the most sense anyway.

grrrwaaa commented 4 years ago

The comments in the OP are now slightly out of date as the layout algorithm was rewritten in the Node port, but I agree many are still valid. At the moment there's a slight preference toward aspect ratio tending toward 1.618 (golden ratio) which is a neat idea but that doesn't really make sense for modules that are mostly 2-4 units wide and 2-5 high. In the node port I added a very basic algorithm to group inlets together, knobs etc. together, and outlets together, and to insert 'newlines' between rows at the boundaries of these if it makes sense to; but this could and probably should be revisited much further.

Missing from the list above is the fact that we'll no doubt want some widgets that are not 1x1 size.

Also missing is the idea of non-panel based modules, which I would really like to get to as part of what MS in VR could be...

michaelpalumbo commented 4 years ago

As an early pass the module layouts are helpful for legibility. Adding the outlet visualization will help distinguish in/outs perhaps to the point where their spatial positioning could be more deliberately arranged (rather than only knobs>inlets>outlets)

Also missing is the idea of non-panel based modules, which I would really like to get to as part of what MS in VR could be...

Absolutely -- we've talked about grain clouds, in manifolds, for instance, or the painting and sequencing.

worldmaking / mischmasch

Smarter module layouts #32