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

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

HI!
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?

Thanks

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’

pd-opts?

@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:

/Patches
/System
/PdExtraLibs

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
/usbdrive/PdExtraLibs
/sdcard/PdExtraLibs
(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