Patch sub menu (and more)

@Wannop - this is now fixed in OS2.2 beta 2 - available on patchstorage

Ive started looking into the multi pages systems, as a few externals I’m releasing have quite a few parameters, so Ive been seeing what others are using.

yeah, I think its tricky to get all these things working nicely, as theres quite a lot of corner cases… and often we just want to concentrate on the functionality (effect/sounds) rather than the UI.
but I agree, work in this area can hugely affect usability… Id place a bet, that C&G put a good amount of effort into there patches.

ah, the tricky bit, everyones busy, to difficult to find ‘mr someone’ :wink:

anyway…
Ive been thinking about this, I think actually PD sub-patch are perhaps a bit ‘limited’ to do this justice, I think perhaps either the ‘Organelle UI’ should handle it, or an PD external.
(I will say this is possibly partly because Im a PD newbie, but proficient at C++… so might just be I see it as easier in C++, as Ive tended to only use PD as glue)

my current thoughts are , that this ‘thing’ should really have a few things:
encourage consistency, so the Organelle experience is as consistent as possible between patches
I think patches shouldn’t need to worry about saving/loading/displaying values, this should be the thing’s responsibility.
so rather than dealing with raw knob values, a patch specifies a number of ‘parameters’ in logical groups, then ‘the thing’ displays these as values etc, and just sends messages that the parameter has changed.

all this is not that difficult, and of course, if parameters are specified, then these are the things saved, not knob values.
(i.e its then a basic preset system)

I only see one ‘issue’, and that is mapping of ranges of parameters…
eg. a pot is 0 to 1… but you want to display for example frequency to the user.

I think there are two ways (that come to mind) to ‘fix’ this…

  • leave it to the patcher, i.e. the patcher supplies a ‘rendering function’
    e.g. its told parameters is 0.5, and ask to provide the value for the display.
    this is ‘ok’, but is not particular efficient, and makes the interface to the ‘thing’ more complex for a patcher to use

  • provide some standard types (and range) , so when you specify a parameter, you supply the name,type (midi note) , and range (c2-c8) , this achieves consistency, and makes it easy for the user… but there could be quite alot of ‘types’ and even then there will always be ‘extras’ (e.g. frequency, linear or exponential?).

I guess you could combine the two approaches, i.e. some standard renderings, and then allow custom renders.

of course, this would only be successful IF (and only if!)

  • its easy to use, and add sufficient value for patchers to want to use
  • its ‘standardisation’ does not make it creatively restrictive (or boring ;))

I won’t quote because your entire post is very relevant :wink:
All your remarks about what the “thing” should do were on my mind when i started to code what i erroneously call “a library” : https://patchstorage.com/o-knob/. Please try it, you’ll see that we think alike on a lot of things :slight_smile:

The available version does not consider the knob to be something of importance, but rather the parameter. An [o-knob] is a parameter and takes a page number (aka logical group), a knob number (which also defines the screen line it will appear on) and a name. Each o-knob is tied to a mechanism that tracks if the parameter should be displayed or not, changed or not, recalled, etc. The object has 2 outputs, one for the display only and one for the patch only. Scaling is left to the user. It only saves the pot value for now, which is not really a problem for me as it is scaled anyway, and the scaled parameter is all we want in the end.

I’m working on a new version with more nice things : each o-knob has a setting window into which you can set several things :

  • for the value to be used in the patch : minimum value, maximum value, integer rounding, and a lin/exp modifier.
  • for the value to be displayed : is it displayed, display name, unit, decimals number
    As arguments at creation, same as before : page (group), knob, short name. And this time, it saves the scaled parameter because only fools do not change their mind :stuck_out_tongue:

There still are some corner cases, like a knob used to browse in a list (eg : knob 1 selects a sample by its name).

I find it easy to use and it takes out a lot of stress UI-wise, because you don’t have to manage all the display side. I think it could be a set of objects, in Pd or in C++/C, as long as it is still usable on a regular computer with the mother desktop patch.

2 Likes