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

the idea of signal + peak is … am i getting anything? is it clipping? … after that I suspect a small vu starts becoming less valuable… but perhaps we have more room than that to play with.
(one issue is the smaller it gets, perhaps it will be harder to see if its clipping, but we can see this once we get there)

midi, agreed i think omni… and as mentioned, I think ‘sync/clock’ is different from notes/cc.
however I will say, probably sync could become more general… e.g. Link/Midi Clock are both external sync , and with another icon for ‘internal clock’


@oweno what did you think of a pd-opts file , as I proposed (a bit off topic ;)) here
… or do you think a more specific approach to libraries, would be better?
(Im think the pd-opts, gives a bit more flexibility, whilst sorting out the library issue too)

curated library?

I agree with @shreeswifty , that a ‘curated’ set of externals for organelle is a great idea. less for patches to distributed, and would give users something to ‘get started with’… as vanilla pd is very limited :slight_smile:
(I dont think versioning is too problematic, since patchers will/should just target what is there, or provide there own versions to override)

I think if we do this, its important that the ‘curated externals’ are properly sourced/credited.
what I mean by this is:

  • a repo which contains the source code, with makefiles to build
  • details of origin e.g. who was the author, where the source comes from (website), what licence covers it usage

as an open source developer, I think these are important points not to be overlooked, I get frustrated when I come across projects, which use others code but don’t credit it properly - and also you cant track back to where it came from, this can make it very difficult to update later on.
(also not doing this can lead to us potentially breaching licence terms esp. with GPL!)

I don’t think this has to be an onerous task, but has to be done from the outset.

I really like the volume meters! Sometimes I am playing the Organelle in situations where you can not hear the original sound but only after it has been processed. In those scenarios it is really handy to have a visual representation that the patch is indeed making sound.

@KristofferLislegaard totally agree, the meters should stay in some capacity.

@thetechnobear @shreeswifty I think the curated library is a great idea. One single repo with source code and makefiles like you mention, so it could be built on whatever platform one chooses to develop patches on. I totally agree about properly crediting the author(s), and I think having this single resource will make that easier. So on the drive (USB or SD) it would be:


or whatever it would be called? So a user can just download the extra folder and move it on and they are good to go. One issue is how to handle the externals which themselves require extra software (LADSPA, Fluidsynth). I guess those will always require an extra install step…

For the extra config, if we have the pd extra libs in a standard location, what is the need for extra config flags? I still think it is a good idea to have this extra control…and having it work just like the mother.pd override is a good idea. But I can’t remember, if you pass command line args to pd do they override the .pdsettings file, or vice versa?

1 Like

Is having config flags better than just a [declare path -path] object for devs?

Volume as a single or double ASCII char width and single line height would work I think. That is how the new electribes work. On peak the bar changes into a warning ASCII char. Not sure if it’s really enough pixels for this, but a possibility.

As I’ve been building patches I think any more controls over what the screen displays would be extremely useful. Possibly separate flags to output in PD to designate what kind of status symbols are needed on the top bar. Some patches will require very minimal input volume info while others it may be very important to have that information. Same with MIDI, output, etc.

I also very much would like a double screen line font available for creating a nicer scrolling menu system.

I worry that this will make the Organelle more confusing while switching through patches, but with the variety of interfacings already available I’m not sure if this is an issue.

1 Like

@wo3 I was working on proper write up, but Beta 10 now supports graphic messages from the patch: simple shapes, text in 4 font sizes, waveform display, pixel control, etc. You can also tell it to turn off default VU meter entirely for full screen control. check this example patch

main.pd (54.0 KB)

1 Like

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