TB - UpdateOS 2.2 TB Beta - closed -> use official OS 3.0

declare paths dont work, as the location can vary, even if we put the libraries in /PdExtraLibs… there are still 2 possible locations
(or even arguably /root/PdExtraLibs!)

well, yes I could generate the libs cmd line option in mother exec, to refer to either /usbdrive/PdExtraLibs or /sdcard/PdExtraLibs - and this is perhaps a good idea anyway.
@oweno shall I ‘hardcode’ this?

but yeah, the rest is if users want to start overriding things, e.g. @Jaffasplaffa was asking the other day about changing the sample rate, something thats currently set in .pdsettings, which is read-only, so I think some users may have a requirement (=/System/pd-opts) , and potentially it may be useful for some patches (patcher/pd-opts)

Obviously this has a small cost for checking for file existence when we run a patch
… a thought I did have (also for mother.pd) for optimising this a bit, is for the the System (only) , to only do this, when the card is initially ‘loaded’ (or user hits reload) , then its just a flag to say ‘is it overridden’ rather than hitting the filesystem each time. (can’t practically do this for the patch variants yet, as we dont cache the patch file hierarchy)

its easy to do, and I think could be useful.

command line trumps .pdsettings

1 Like

Discourse question: is there a shortcut for quoting multiple parts of a post (as in your post above)?

well, yes I could generate the libs cmd line option in mother exec, to refer to either /usbdrive/PdExtraLibs or /sdcard/PdExtraLibs - and this is perhaps a good idea anyway.
@oweno shall I ‘hardcode’ this?

right… I get problem now, might be running off SD or USB… I think it is fine to hardcode this now, then it is done!

The additional pd-opts is still a good plan, in the end user should have total control over how Pd starts. The cost of checking for these files is probably not that bad, just a fraction of a second no?

command line trumps .pdsettings

Perfect, then we are good to go!

1 Like

Being able to change the sample rate would be a great addition. I like it as it is, but it just gives a little bit extra “sample head room” being able to use 48khz :slight_smile:

@thetechnobear I know you have some concerns about it. But if one has spend long time making a patch I think that person will also remember to mention that it is 48khz sample rate used. Or even make sure that the patch wil run on both 44.1 and 48. That is simple to do with “no sample patches” but with patches with samples it is a little bit more complicated, i guess.

Yeah will definitely try to run Organelle in 48khz when I get some new patches done. They are all made in 48khz and has a lot of samples, so need to figure it out sooner or later. But since you say “read only” I dont think I am going to try right now, maybe wait and see what comes up in future updates. Need to finish those patches anyway, hehe :slight_smile:

@thetechnobear never mind about the block quote. It just shows up, duh!

@Jaffasplaffa For now you might be able to send Pd an internal message from your patch to adjust the sample rate. Detailed in this topic:

1 Like

Thanks you @oweno, that is smart :slight_smile: Going to try that out :slight_smile:

Been using beta 9 for a little while now. Really liking the favorite menu feature! One thing I would love to see changed was I think when you are in a patch and getting ready to load a new one, it jumps away from the patch selectin menu just a biiiit to fast. Would love if it would stay in the selector area for just 1 or 2 more seconds.

Try beta 10 , this has changed :slight_smile:

Ha! Way ahead of me!
I’ll install it as soon as I am done with an important gig :slight_smile:

anyone try this from v1.1? the update for TB Beta 10 hangs when you run it from OS v1.1. (TB Beta 9 would run successfully from v1.1)

does 1.1 have /tmp/patch?
if not then that is the cause…

(basically, I switch to using /tmp/patch so that the update could be independent of being stored on usb drive or sd card)

ok, that’d be the issue.

hmm, I’ll have another look… I’m a bit hemmed in as 2.0 and prior doesn’t define patch directories or similar… (and I’m not sure what their current working directory is). I wonder if I can use $0, which I assume is the full path name of the script?

I really don’t want to have anything hard coding the usb stick.

ok Beta 11 released, with features discussed above

  • PD patch now runs in /tmp/patch
  • fixed issue with Organelle OS < 2.0 not upgrading (due to /tmp/patch issue)
  • PDExtraLibs added to pd path
  • pd-opts.txt in System, or Patch Dir allows override/extra pure data command line options

pd-opts.txt , any command line option, as detailed here:


1 Like

Beta 12 released

there are now 2 new ‘standard directories’ for patches to use, to help patch integration

  • /tmp/data
  • /tmp/media

(these are mapped to /usbdrive/data and /usbdrive/media (or /sdcard/data and /sdcard/media as appropriate) for permanent storage(

patches should only refer to /tmp/data and /tmp/media!

data is intended for ‘private data’ for a patch e.g. patch settings or preset saving.

media is for any kind of media file that might be used by a patch, but could potentially be used by other patches (since they are in a common format) e.g. wav, soundfonts, midi.

a typical example of how a patch might use is as follows

  • a patch has a set of default presets, when it is run for the first time, it copies these to /tmp/data/mypatch/preset.dat
  • it loads /tmp/data/mypatch/preset.dat
  • it saves presets to /tmp/data/mypatch/preset.dat

… the intention is, user changes are now always stored in the /tmp/data… if they wish to ‘reset’ a patch to default, they simply delete /tmp/data/mypatch… and then the patch will reinitialise from the patch directory.

Sound files can work in the same way, a patch can have a set of default files it uses (so its instantly playable/useable by the user) , this are copied (if not present already) to (e.g) /tmp/media/samples/808kit, the user now has the opportunity to substitute the wave files, also more advanced patches could allow for sample selection via a ‘file manager’ type UI.


Thanks @thetechnobear for all this work!!
Even I only used 2.1 for a couple of days, there is no turning back with 2.2 when using sub directories, favourites, shutdown just to name a few :wink:

I have changed the USB stick (stock, white one became unreliable) and planning on using only he SD card for everything in the future.
Now onto balancing between playing and implementing all “goodies” (wifi, all in sd card)

1 Like

Amazing! Seems like things are developing fast atm. Nice work :slight_smile: Shared sample folder and smoother presets functionality is potentially a huge gamechanger for overall workflow/convenience. Repeat. Amazing :slight_smile: Thanks for your work on this.


So I am on beta 9 at the moment.
Do I need to update my patches now that presets and samples are stored in a different way?
Or is this simply a feature, not a demand? I really like the idea, but I also don’t like it if I have to move and sort all my samples and patches.

everything I’m doing is a feature, not a demand … you can patch as you like, and it wont break any existing patch or workflow.

the reason for these changes stem from discussions @oweno and I have been having regarding issues with ‘Save New’ (which was designed to help saving of patch state)
however, Save new, copies the entire patch directory, with some patches this can result in MB’s of externals, Soundfonts and wave files get copied, even though they are the same thing. this is clearly nuts!

the idea, is to separate volatile data, assets and ‘programs’… if you think about it, this is exactly what is done on your desktop computer, and for many good reasons :wink:

(a small technical note… USB and even SD cards are not designed for constant rewriting, so copying and deleting unnecessary will over time increase the ‘failure rate’ of cards… not an issue for manual copying, but minimising ‘systematic’ copying should be a goal)

as to if/when patches will be updated… well thats up to patch developers.
obviously I have things Im working on that will utilise these features, and hopefully demonstrate to users and patchers how this will work, and the benefits.
(hence, why i stated the intention of how to be used… as this is my planned usage)

p.s. as stated previously, these ‘releases’ are betas to allow testing/feedback from users and patch developers.
all changes are being included in the C&G code base, so will be released as part of an official C&G update in the future.


I really like this feature. Just don’t have time to update everything at once so just wanted to know that I could start using these features without breaking patches that I have not yet updated.

So whatwould be awesome then would be to create a nice standardised file browser. This would really be a huge upgrade for the Organelle. It could be so easy as a sub patch or something that everyone use, but I imagine having a sample patch, and then be able to browse a medium sample library on the device with my own samples.

1 Like

Beta 14 released (includes unreleased b13 changes)

  • improved osc graphics messages and handling
    – sizex/y now accept 128,64
    – new gInvertArea, gInvertLine messages
    – graphics now can be drawn onto any screen (menu, aux or patch)
    – consistent format eg gMessage screen, x, y sizex,sizey, colour
    – note: patches using gMessages will need updating!
  • a bit of refactoring, tidying up and optimising of code.

note: screen id on gMessages is 1-3 following same scheme as setScreen ie. AUX (1) ,MENU (2) , PATCH(3)