Works like a charm, thanks for the quick fix! 
And the new OS, beta or not, is amazing. I wonât be surprised if before long youâll be joining Team Organelle ⌠
Noticed a (possible) bug under beta 2.2 TB Beta 4: you canât save multipage patches - at least this is what I experience on my device. Whenever I have any multipage patch loaded and want to go the âHomeâ - âSaveâ route, the same patch is automatically reloaded as soon as I hit âHomeâ with the encoder. Earlier, after hitting âhomeâ, the main menu was accessible while the patch was playing with the last settings. Thanks a lot for looking into this.
1 Like
good catch ⌠Ive fixed for beta5, Iâll wait to see if you (or anyone else) finds more, before releasing b5
dev note: ok, Ive fixed this by not responding in the menu to actions it didnât trigger.
the issue is actually caused by the multipage synth (MPS), because it switches the screen to the menu on encoder down, the menu sees the release events (since at this point we are out of the patch screen)
this is another good reason why encoder events should be activated on release not down.
the âworkaroundâ ive done is required, because although we could fix MPS and the template, there is nothing to say other PD developers wont follow action on encoder down.
(I reference you back to my earlier post, about why actions on encoder release are better 
)
I may have stumbled upon something else, though this may as well be related to my MIDI setup: I had MIDI clock + pgm chnge coming to the Organelle from the Moog Sub 37 while I was playing with the Bash Bastard 2 patch, and at one point the output audio started lagging and the Organelle became unresponsive. I was unable to either âquick shutdownâ or exit back to the home screen so I unplugged the device. It came back on OK after rebooting.
unfortunately, Id need it to be narrowed down⌠this could easily be the patch/midi setup⌠or a whole host of other things,
⌠and frankly, whilst its not impossible its more likely to be a patch/midi/pd issue.
(also, if you have pgm changes coming in, remember Organelle will start switching patches, they could create quite a bit of load)
generally, Id need reproducible steps, that are proven to work on 2.1, but not on this beta.
I agree the release is better and more versatile, and any multipage setup could be updated. There is a large amount of debounce delay on the encoder release (about 300ms), so I thought that would be annoying, but after playing around with this, might not be so bad. What did you think about appending a ââ>â to folder names to differentiate them from patches?
Thanks, this MIDI thing is not really an issue, just mentioned it. Look much forward to beta 5! 
oops, just forgot it⌠will do âŚ
actually I had the folders in square brackets initially e.g. [Community], but didnât like it much, looked a bit like an old dos program 
how about a single > at the end, might be quite tidy ( and later perhaps substituted with a graphic), so we have something like
Critter >
Community >
Mine >
Analog Synth
Poly Synth
1 Like
[quote=âthetechnobear, post:28, topic:1433â]
how about a single > at the end
[/quote]was thinkin the same
glad you agree
yeah the single > is great idea
ok b5 is released⌠> on folder names, and multi page synth saves
Great fix! This OS is a game changer. Thanks for making it happen!
@thetechnobear first of all, awesome job. Thanks for pushing Organelle UX boundaries.
But after installing the latest update (itâs is the first one I installed so do not know about the rest) I seem to be having trouble with getting any sound out of some patches: âBatchfest3â, "Varese, â+matrixâ, âshmorphagene0.3â, âCloudsâ & âDuetâ.
Does anyone met the same problem? Or know what it may be causing?
nothing has changed on the PD side, so this cant break midi/sound.
I couldnât find all the patches you mention on PatchStorage, but I note a couple of things in two within the description.
(note: I did not attempt to run, as I dont have time debug individual patches, and all patches I have installed work ok)
a) one seems to mention its using pd-extended, from a âshared directoryâ, if it is referring to this via a relative path this will break if you put in a subdirectory ⌠but could be fixed by editing patch or moving/copying pd-extended.
b) another patch, seem to mention dont rename it, again moving the patch into a subdirectory may break it.
again id assume this can be fixed by editing the patch.
generally⌠for determine the cause of issues i would say, if you have a problematic patch on 2.2TB, you should
a) install the official release 2.1, does the problem still exist? ⌠if it does its a patch issue.
b) try the patch in the /usbdrive/Patches directory (not a subdirectory) if it works there, and not in a sub-directory, then it has hard coded paths, contact the patch creator to see if they can remove.
I think for patch development we should strive for:
a) self contained externals⌠to prevent versioning, and other dependencies
b) patch to be âlocation independentâ , not only is this important for renaming, sub directories, but also the patch might be run from the sdcard rather than the usbdrive.
c) id recommend patch developers dont pack every external into a patch directory, rather pack only the externals they use⌠its easy enough to get this list, just open the patch without any externals⌠and the console will list all the missing ones.
also, I think there is an open question, about if pd-extended should perhaps be included as part of the âOSâ, so that individual patches do not have to ship it, they can just rely on it being present⌠then patches can just ship other extras they need.
Pd-extended is a dead project, better stay away from it. Pd vanilla >=0.47.1 has a menu to download externals and such (âfind externalsâ iirc, sometimes called âDekenâ).
-
externals used in a patch should ship with the patch in a subdirectory, with their individual help-file. I agree that you should only ship needed files and not the whole library when possible, but it brings the issue of versioning. What if you want to improve the patch with another object from the shipped library but canât find it ? Youâll have to download the same lib version and extract the needed files⌠Cumbersome. Then, actually, itâs probably better that the OS provides a selection of libraries. It brings another issue : which version of the library should the OS ship ?
-
location-independent patches : if patches need to access some shared folders (samples, recordings, externals, libs), itâs easy to declare the needed paths in Pd.
-
as a side note, iâve been thinking of a system to download the latest patches uploaded/updated on PatchstorageâŚ
-
another side note : pd 0.47.1 has several nice features : [clone] (VERY useful for polyphony) and integrated externals download system notably
I kind of agree with deken vs extended ⌠but the arm support seems a bit patchy, and whilst it makes sense for interactive patching, not sure its quite so true when your not using the GUI.
( Iâm very rarely connecting my organelle to a X/hdmi display)
yes, sharing libraries, often creates a version issue, its the main argument for copy to patches dir.
paths - again, having to edit the PD patch is cumbersome if your using organelle without a display.
patchstorage, yeah, Ive looked at this for Axoloti, they do have an JSON api to query and download, which I thought about using, but youâd have to make a few assumptions, in particular the patch is zipped (and then weâd need to use a zip library to unpack, as organelle by default does not have unzip installed)
⌠and of course, its really only useful if you have wifi card installed (which I always do :))
47.1 yeah, Id quite like clone
⌠but updating organelle to later packages raises interesting questions, like do you assume wifi, and so can use pacman, to do you have to do this as âsystem packagesâ via the usb stick.
You are totally right @thetechnobear, the problem was solved once I took the patches out of the subdirectory and just placed them at /usbdrive/Patches directory, I should have noticed beforehand though. Sorry about that.
It is a pity anyhow, because it means that the newly acquired folder neatness due to your magic coding is now disrupted with those particular patches laying in no mans land.
I will send a message @shreeswifty as those were his patches to check if it is possible to make them âlocation independentâ.
Thanks again!
no worries, its good to flush out these âissuesâ
as for solving in patches, what I should probably do (for now at least) is set environment variables, so that the patch knows the directories (already do this for âsystem scriptsâ), then the patch can use the âshellâ object to quickly determine where it is when it needs to do file access.
Iâll make the necessary changes to âmotherâ , and quickly push out b6 (and a PD example) if @shreeswifty says his willing to update his patches accordingly.
( I could update the patches myself, but I donât really want to be releasing modified forms of others patches, that would get messy quickly 
)
just checked the code, actually Im already setting the PATCH_DIR environment variable in 22b5, so its good to go
a patch can determine the current patch directory with:
shell $PATCH_DIR
notes:
- PATCH_DIR = the parent of the actual patch, so if its in old location this is /usbdrive/Patches⌠so you might want to add the patch name to it. (example if in a subdir of âcommunityâ you will get /usbdrive/Patches/community)
- PATCH_DIR does not exist prior to 2.2b5 e.g. 2.1, so in that case you will not get output on outlet 1, but you still get a bang on outlet 2, so you can use this to default to /usbdrive/Patches, to remain compatible with < 2.2
- USER_DIR is the equvilant of /usbdrive , you should use this for âuser configurationâ e.g. I use it for midi config, this is important when running patches from sdcard rather than the usbdrive.
- there is also FW_DIR, which is where the firmware/scripts are running from, but thats probably not needed by PD patches.
These environment variables are great, and definitely will make life easier for keeping patches location independent.
I agree with the common dev practices mentioned above for creating patches. Keeping them self-contained and location independent is best from a usability perspective, and it has worked for the most part so far.
Remote downloading / uploading to patch repository would be cool too!