Patch sub menu (and more)

Organelle
1

Hi

So I got my Organelle yesterday, and Im really enjoying it… love the factory patches :slight_smile:

I also love that Organelle is open source, and given Im a C++ developer, and also I like contributing to open source projects, I thought Id jump in …

so Ive forked the Organelle_UI to make some changes I wanted.
the primary change is to implement patch sub menus, since I wanted to have a structure like

Patches ----- Factory
     |------- My Patches
                     |---- sequencers
                     |-----synths
     |------- Community
                     |------- bob

anyway, so Ive implemented this on my fork…

Ive also took the liberty of making the code a bit more ‘generic’, basically implementing a ‘callback’ system on the menu, so that in my next version, I can do ‘structured’ sub menus. (i…e menus containing menus)
and a few other changes related to helping me build/compile on macOS, and using makefiles.

so the questions are:

  • would C & G like this submitted as a Pull Request, for potential future release? @oweno @chrisk ?
  • are other users interested? would they like to test? whats the easiest way to distribute?

obviously, Ive tested already, but more fingers pressing buttons always helps in case Ive missed something?
… and is useful if C&G want to potentially release it.

of course, Ive still ideas for improvements… we can discuss these as well :slight_smile:

for those interested my fork is at :

the changes are on the ‘subdir’ branch, which was forked off master.

2

This is exciting. I’m glad you are working on this, and I’d love to give it a try. Patch subs have been often requested so it would be good get them in the next OS release.

Did you receive your Organelle with OS 2.1 (under Info on OLED menu)? or did you run the update patch?

https://patchstorage.com/update-os-v2-1/

The update patch provides a general method for installing new stuff on the Organelle. It is just a Pd patch that runs the included deploy.sh shell script. It just copies the files (the mother binary and scripts / other junk), but it would be nice to get this stuff wrapped in a pacman package.

1 Like
3

yes, Ive got OS 2.1 installed, I need to dig into this a bit… as I need the multi page menus for the Mutable Instruments patches

Sure, I saw the deploy script… I’m just a little wary of installing over the official release, whilst users are testing.

currently, for development, I run off of /usbdrive/System/mother … though Ive had copy scripts across because the scripts currently refer to /root/scripts/

however, Ive already started to abstract this, mother, can now have the system path overridden, and I will update the shell scripts to take the system path as an environment variable (but defaulting if not supplied, as I did with save_new for patch_dir)

what I think ideally Id like, is if you run /usbdrive/System/mother, then it will look for /usbdrive/scripts… and then use scripts from there… this may not work 100%, we have a ‘chicken and egg’ situation whilst starting mother, but I think once its running, the other scripts that mother uses could be overridden.

the idea being… if a user wants to use a dev/beta version, its can completely run from /usbdrive/System… and if they have an issue with it… then they can simply delete it from there usb drive then they are back to the ‘official’ release.

pacman, yeah this would be nice, but Im not familiar with the process for building these packages, nor distributing :frowning:

(similarly, it would be nice if we could distribute PD externals via deken, but there architure is ‘primitive’ to say the least)

btw: what do you think about me moving the System items, into a sub menu?
so we have something like

Shutdown
System 
     |---- CPU
     |-----Info
     |-----Eject
     |-----Reload
Critter Patches
     |---- sequencers
     |-----synths
     |-----effects
My Patches
     |---- sequencers
     |-----synths
     |-----effects
Community Patches
     |------- bob

Im keen to make it quicker to get to patches, so to avoid having to scroll past lots of items.
but on the other hand, dont want it to be a massive menu diving experience.
(id also like to remove the blank lines, and headers… again on a small screen they make it more difficult)

in code Im hoping to make it fairly easy to move things around the menus, and flexible,
e.g. we could have most of the System on a sub menu, yet have shutdown on the top level (as you need it every session)

a few related items, Id like to get some comments on, which users might prefer?:

  • Startup?
    I think organelle should start with some patch running, i.e. so its immediately 'doing something’
    But should I make it the last patch used, or allow a patch to be explicitly ‘marked’ as the default for startup

  • Recent or Favourite Patches?
    I suspect, many user load their organelle with lots of patches, but then will quite often use the same few (10?) patches.
    so Id like to provide easy access to these patches, via a submenu… rather than having to go find them.
    Similar to startup, then do we have it implicit (recent patches) or explicit (add to favourites)

in both cases, I think my preference is for the user to explicitly say what they want as the startup patch, and what they want as favourites. (of course, if they specify neither, then the menu item need not appear)

something like

Shutdown
System 
     |---- CPU
     |-----Info
     |-----Eject
     |-----Reload
     |-----Add to favourite
     |-----Make default patch
Favourites
     |---- Breakbeat
     |---- Rngs Reverb
     |---- Elements
Critter Patches
     |---- sequencers
     |-----synths
     |-----effects
My Patches
     |---- sequencers
     |-----synths
     |-----effects
Community Patches
     |------- bob

thoughts?

I think these things would help me a lot…
(after that, Im interested in presets , but thats a whole new topic :slight_smile: )

1 Like
4

Hi!

Startup?
In my opinion: start with some patch running would be not desirable because: what happens if I want it in silence till I start the patch? There are autogenerative patches that is better they dont start since you press over them.

Recent or Favourite Patches?
Very important to be able to choose the patches you want to use for a gig, sesion. So I would implement favourite and forget recent.

I’m also ok with the current menu. I just try the patches and erase the ones I don’t wanna use. I tent to number them so I have the one I use the most on the top of the list. In fact, there I noticed that if you number them once you get to 10 the consequent orden is lost and you are forced to choose letters.
Anyone noticed that?

Delete from usb would be also a nice thing, practical.

Let’s try these MI !!!
Thanks thetechnobear!

1 Like
5

yeah, those were my thoughts…

if you dont want a default startup, then dont specify one :slight_smile:
… we could also make it that holding something down (encoder/aux?) whilst booting would prevent the startup patch running.
but also, dont most auto generative/sequencers have start/stop, and when loaded, default to ‘stopped’ - even if you load a patch manually, its unlikely if it started automatically it would be timely… and thats ignoring things like midi clock to do sync

for gigs, there is something to be said for using some kind of’preset + patch combo to create a ‘set list’, but thats for latter, Im sure favourites will help initially.

note to self: need remove startup patch, remove favourite.

current menu - yeah, I can see if you manage the usb stick that it can work, but I personally dont like having to manage it much… sure I can now sync over wifi, but still not ideal.

all that said, Ive only had it for a day, so I’m still working out what Im doing with it… so I’m sure my ideas will develop, and really happy to hear how others are using it.

it does an alpha sort, so that is expected, always happens if you try to sort filenames (strings actually) like this,
no real alternative, without parsing the filename, detecting numbers, and then sorting these specifically… but thats pretty horrible to do.

6

yeah, the old alpha sort… you can always name patches with leading 0s like 001, 002, 003.

The Save New system command is designed to work as basic preset system, saving the knob values and restoring them next time patch is loaded. It also signals the patch to save any other resources (like samples it recorded, sequences). What it doesn’t do is save into a new folder like “Presets”, the new patch is just saved in the Patches folder with an incrementing number. We thought doing a full blown copy of the patch you were making a preset of was the most fool proof way to do a preset, otherwise you have to deal with preset data separate from patch files which might lead to problems if the patch ever changed…

The other ideas are cool, definitely worth trying… How are you handling navigating back from inside sub menus?

1 Like
7

currently Ive a simple solution , where I just rebuild the menus.
I can do this, as i now don’t rely upon menu position, instead there are ‘menu items’ which include display text, argument and function pointer.

next step is building a menu hierarchy, such that buildmenu is really only building a particular ‘level’ of the menu, and then you can go up/down it… easier to code than describe, as its an extension of the direction Ive already started :wink:

Yup, been groking that… seen how you have the ‘state’ stored and copied.

the issue with loading a whole PD patch is it could take quite a lot of time to do a switch , and will interrupt/glitch audio (no?)
but yeah , I’m new to PD, and was surprised PD didn’t have a proper preset system like Max :frowning: … and as you say building something like that is non-trivial.
but yeah, a topic for another day.

8

I personally like a lot the absence of a preset menu for different savings of the same patch.
That the new patch is just saved in the Patches folder with an incrementing number is really fast and practical in live situations.

9

But anyway, I’m sure you both know better the enviroment and I’m talking more from the perspective of: "oh no, they are gonna change it!"
As long as favourites like is posible, the rest of implementations will be practical.
Thanks for the efforts!!!

1 Like
10

I’m definitely missing a way of properly subdividing patches into categories. I use a lot of different patches and alpha sorting has kinda ceased to be useful for me at this point! Having to fit too much info on the small screen. I have lots of different version of the same patch (mostly for sample based patches) so sub menus would be very very helpful in this regard. Favourites would be a handy tool for the live situations you describe anttumad :slight_smile:
Are the folder names going to be editable or would proper navigation and patch launching depend upon them being fixed as in your layout @thetechnobear? I currently alphasort mine into these categories 0=synth,1=noise, 2=effects processing 3=sampler/mangler 4=drums

1 Like
11

@anttumad - all ideas/thoughts are appreciated, my experience is all musicians use synths (etc) differently, so have a different perspective. my hope is to have something flexible enough to cope with different ways.
(also theres a feedback loop, as things change, so people change their usage… which sparks new ideas)

@Wannop - ‘categories’ , these are just the folder names I’m using, you can name the folders as you choose… you can arrange these, as you can today, just by editing the file structure on the usb stick.
(I’m not planning on editing within organelle, as i tend to find entering ‘names’ etc thru encoders on a small screen a bit of a chore)

as you mention the small screen is a challenge from a UI perspective, its not very wide (21 characters), and only 6 lines, and realistically, i think the font is as small as you would want it, and we currently have restricted navigation (the encoder)
so the trick is allowing as much of this to be usable as possible, whilst retaining context… this is why I’m not a big fan of sub menus, especially on small screens… its easy to get lost quite quickly.

anyway, Ive lots of ideas of how to overcome the limitations , so once Ive got the basics done, I’ll throw up a ‘beta’ for people to play with.

@oweno, I assume if I do the deploy, as update 2.1 was done… I could put this in patchstorage (as you did), then users can install… and if they want, they can then simply revert to 2.1 by just reinstalling 2.1 from patchstorage.
(i.e. the deploy is mother + all scripts, so a full install (obviously not OS) , rather than incremental)

1 Like
12

This is really exciting. Keen to test. I’m a UI designer by day for a company you’ve definitely heard of, so happy to get very involved with this if you’d like some more input.

A couple of new ideas from me:

  • To combat the small display problem, could we find a nice way for the user enter a patch select menu where the entire display is taken over by large text? I’m thinking like when you turn the sound knob on the Elektron Analog Keys.

  • I have a bit of a problem with how the arbitrary positions of the knobs affect the patch when it loads. When I’m trying to run a robust live show it would be really helpful if the patch that is recalled is precisely the patch that I saved until I move an encoder. It is kinda more fun the way it is now for creative play at home, but crap on stage. I’d be sad to lose it completely - how about a toggle either in the PD patch or in the organelle to turn on/off knob recall on patch change?

3 Likes
13

Very exciting to hear you speaking of enhancing the user interface, what you are talking about would be fantastic and make this great instrument even greater to use! Organelle is growing big time!

1 Like
14

my plan is to do ‘low hanging fruit’ changes initially, things that what make help workflow - especially whilst I get used to the code base, and also whilst I’m building up experience of using Organelle, and getting a ‘feel’ for the screen/knob limitations etc… after that, I’ll see what I have the appetite for changing :slight_smile:

that sounds ‘odd’, as far as I understand it, if you have saved the ‘knobs’ on the patch, then those are the values that should be recalled when the patch loads… regardless of position of the physical knobs.

there is the ‘age old problem’ of potentiometers, of physical positon vs value position (from preset/page switching) … so that you have to use a ‘pickup’ methodology, this is always a bit counter-intuitive.
though I do think, a better visual representation on the oled could help
e.g.
imagine the value on the screen is for transpose, and its currently at 4… and the physical knob is currently at half way… which way do you need to turn the knob, and by how much? you don’t know, because it entirely depends on the range of the transpose, if its -12 to 12, its one thing, if its 0…36 its another…
the problem is further compounded because when you change values on the screen, you look at the screen, you don’t tend to go and look at the knob to see wheres it currently pointing.

if on the screen it indicated, that currently, the value was ‘unlatched’ and that the knob needed to turned clockwire to latch, this would help a lot.
but if you went further and graphically indicated, where you were within a range, and where the pickup position was, then it would be relatively intuitive.
as you say this is where you need a ‘zoomed’ of the knob when you change values, so you can display more info…
personally, id say the overview should be a ‘dial’ rather than a value, then when you start turning the knob, it zooms ins, shows the position/lock and also a meaning value (e.g frequency in hz)

anyway, that’s quite a lot of changes, but could be interesting :slight_smile:

15

I like your thinking on that stuff.

Am I experiencing something weird then? I’m certain that when I recall a patch the positions of the knobs immediately affect the sound that I hear. Will double check tonight.

16

Are you using the new OS v2.1? check Info in the System menu, if the version is less than 2.1, then what your are experiencing is normal. After updating to 2.1

https://patchstorage.com/update-os-v2-1/

there will be a Save and Save New command in the System menu. These will save the knob state for next time the patch is loaded.

17

Well, i encourage you to test my patch https://patchstorage.com/re-tape-echo/ and my library it’s built on : https://patchstorage.com/o-knob/
It has embedded presets, settings that does not move from one page to the other, no display quirks afaik. talking about pots and presets, i’ve taken the “reach” route : if the pot and the value do not match, you have to turn the pot until you reach the actual value. It works well most of the times.

I’m sad to see so much sweet patches that are unusable because of a bad UI… invisible parameter until you move a pot, inconsistent names, non-scalable paging systems, bad screen updating, decimals all over the place… someone should release a practical patch creator’s library. I tried to work on the pots issue but my time is limited…

My next goal, if i have some time, is to make accessible to pd the functions that draw pixels on the screen, so we can clear it and draw cool stuff. It should be pretty easy to do (wink to y’all).

1 Like
18

Hi! I’m having trouble accessing some of the newer patches for organelle. Using this new sub-patch OS, a display reading ‘Organelle OS 2.1 higher needed to run this patch… please update at…’ Anyone else had this?

19

Oh, this is because the version check mechanism in those patches requires the version be a number. On @thetechnobear beta release there are letters in the version string which is causing the problem. The version check could just be removed for now.

Screen Shot 2017-07-15 at 8.41.32 AM.png1138×196 9.31 KB

Just delete [versioncheck 2] and connect [loadbang] right to [t b b]

1 Like
20

Ah cool, I’ll introduce some kind of sub version for next beta to fix this.
I’ll put out a new one soon as I’ve made some small
Improvements including automating the ‘image build’ for release so now very quick easy to do :slight_smile: