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

Yeah, that makes sense. Eject changes the system state behind mothers back… looking over other System commands, I think eject is the only one that does this, I guess shutdown too, but at that point it doesn’t matter!

I figured this!

I also noticed something weird with shutdown. Haven’t figured it out exactly, but if I’m in a patch and then select System > Save, a few seconds later it might start shutdown. trying to reproduce, might have something to do with shutdown shortcut ?

1 Like

seems likely…
I once thought Id selected a patch, and it shutdown on me :slight_smile:

I dont think its a bug , as such… the logic is simple
if you hold down the encoder for > 3 (?) seconds it starts the shutdown

I think the ‘issue’ is the lack of feedback… or anything that interrupts this…

so say you want to go to the menu, and you keep holding the encoder down , and start scrolling around, its possible when you raise it, you’ve taken more than 3 seconds, and bang it shuts down.

so I think i need bit more logic, which ‘aborts’ the shutdown timer…
e.g. perhaps turning the encoder
also more feedback… perhaps after (say) 2 seconds, its says ‘keep holding to shutdown’… i.e. you know to lift your finger off :slight_smile:
… and of course, probably should be a config option to disable it all together e.g. for live performance :wink:

the thing about the shutdown shortcut, is its obviously only useful if its short enough you dont have to wait for ages… but too short, and its to easy to trigger.
originally I was going to use AUX+Encoder, but the problem is many patches used AUX in different ways, so thats not really feasible.
another option perhaps, is say the shutdown shortcut only works if volume < 0.1 … its a bit ‘odd’ but its a reasonably good failsafe for accidental triggering (your not likely to have the volume set to 0 in normal use)


(EDIT: actually I think I have got it checking for encoder movements, I will double check)

ok, Beta 9 released …

Beta 9 (19 August)

  • improved shutdown shortcut
  • fix usb eject issue
  • improved deploy script
  • install now:
    • sets root password to organelle (all lowercase required for X11 remote login)
    • updates sshd_config to better defaults
    • move user ssh environment to tmp (writeable)
    • removes c&g git config

@oweno , I think this address the issues you have mentioned above, so Ive also merged this over to the C&G repo.

shutdown shortcut: hold down encoder… if you turn it, it aborts, after 3 seconds, you will be warned of imminent shutdown , if you then release, it will abort, hold to continue to shutdown.
I think the warning makes if feel much more ‘natural’, as you know something is going to happen :slight_smile:

1 Like

When I press the aux button “installing…” appears endlessly on the screen.
Any idea?

Problem solved!!!
I did change the update folder so it was not recognising it

1 Like

yeah, you can’t rename it…
(this is due to older versions of firmware that you might be upgrading from not having /tmp/patch, so i cant use that)

next time Im looking at it, I’ll look to see if I can improve the PD patch, to see if the user has renamed the patch, and warn accordingly :slight_smile:

seems I cant edit OP now, perhaps as its too old?.. no matter :slight_smile:

Beta 10
– improved update scripts
– no menu timeout whilst doing shutdown shortcut
– reset menu timeout whilst navigating menu
– allow mother.pd in patch directory, where patch needs to override mother functionality
– version check mother.pd

menu timeout should feel more consistent now with shutdown and patch navigation … rather than occasionally leaping back when you dont expect it

mother.pd from patch directory… so an individual patch can override

update scripts changes , use /tmp/patch , so upgrade can be done from sdcard or usb drive… also had to move image around, so that the new mother.pd was not used whilst running main.pd for upgrade :slight_smile:

yeah, this is what I was thinking. loading / unloading would be problematic, so something in the patch file that could be checked. A bunch of the pd-extended files have a [pd META] sub patch that has extra info in comments. (one is attached for example)

abs~-help.pd (1.5 KB)

Sounds cool. But i am wondering if I now have to copy the mother.pd into every patch folder on the SD-card? Or if Organelle only looks for it in the patch folder and if nothing is found it then loads the original mother.pd?


No… this is an extended feature… it will use the system mother.pd if it doesn’t exist.

yeah, I’m familiar with META , its the same thing really, version as a ‘text’ field, just kind of giving it a ‘namespace’
making sure its within the META (embedded ) subpatch, means I’ll need to resort to using awk, so that I can ensure I only pickup version ‘text’ within that one some patch… even then I’m not sure if we get into problems if you start embedding up patches, that have embedded other META patches… but I guess that is very unlikely.
I’ll give it a go with awk, and see how it pans out :slight_smile:

also doesn’t have to be in a META sub. just a comment ‘VERSION x.x’ would be fine.

for letting user know a overridden mother patch is being used, there could be an icon in the VU meter info bar on top of patch screen. If they were expecting mother.pd to be overridden and the icon didn’t appear they would know there was some problem, version or otherwise.

more about the VU meter: I was thinking we could do away with some of those bars to include some other info (like overridden mother). Are there other infos that might be useful? maybe a MIDI status info?

already done :slight_smile: … a new b10 is available.

mother.pd now contains a pd META, which contain VERSION, this is checked , currently for 1.2.
if the expected version is not found, then the mother.pd is renamed to mother.pd.review

(note: all current customised mother.pd will ‘fail’ this test, which is correct since there is now a patch loaded messages sent from PD back to mother exec, since beta 7)

Im hoping then users will notice there ‘extended’ functionality is missing, and then go check what is wrong.
… and, organelle will resort to a working version (/root/mother.pd)

Im sure this can be improved on, but seems like a good starting place.
(I’ll push it, so feel free to tweak it, or suggest improvements here)

sounds like a nice idea… how about the vumeter being replace with a signal and peak indicator only, this would take up less room, leaving as you say space for 'indicator icons’
indicator icons ideas:
a) warning (exclamation mark) - such as mother override, or some potential error
b) incoming midi clock/ableton link (sync indicator)
c) incoming midi notes/cc
d) beat flash (bpm indicator)

if we did this, I think it would then be useful to allow mother.pd to revert back to a level meter, which is useful for initial gain staging… we could potentially do this off a ‘menu option’, allowing the whole screen to temporarily be taken over solely for looking at gain levels (so we could report things like peak values)

(I tend to find when im playing with patches, I look at input /output levels first… set them, then after that I’m not really that interested in them, unless i change the input signal … could be useful if the levels screen had a global input gain knob)

1 Like

hmm - I do find an indication that there is sound coming in or playing useful (sometimes I’ve got the organelle turned down and want to know there is stuff ready to turn up perhaps) but doesn’t need to be levels - a ‘flickering’ single character would do the trick. midi indicator would help with a lot of “why’s that not working then?” as well

1 Like

I think a few VU bars are useful, just doesn’t need to be so many. We could squash them down a little and add the extra info. (also the current beta 10 version now supports a patch message to turn off the VU meter entirely, so a patch can now do its own thing, more on that soon…)

For the MIDI indication it could be omni – any MIDI input makes it flash? or only MIDI on the current channel? the issue being a patch can ignore the default channel and do its own thing with MIDI, so might be best to make it omni.

1 Like

agree doesn’t need to be so many VU

For midi - the usual issue is not routed right rather than the wrong channel - if it is getting midi at all then it’s easy to work out what channel it should be.

1 Like

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