Beta 15 released
Pots/Expression/Volume are now all smoothed in mother host rather than mother.pd, this means:
Ive also fixed a couple of bugs which meant full parameters ranges were not being achieved (e.g. 2400 cents/100% etc)
Wow!! one more great release!! great work 
This one had me head scratching since day one… but now some patches go to %101… I’m sure not a big deal and correctable.
yep!! Was experimenting with this yesterday; stable
Yeah, I guess some have been working around the issue , but always better to fix the underlying issue 
@oweno
so for the next update… Im Ive implemented a couple of new things…
(not pushed yet, as would like some feedback - and I’m still complete the supercollider updates)
my issue is my ‘System’ menu is getting way to crowded, due to utilities etc.
so two changes:
Ive made is to allow sub-directories for User system command, in the same way as we have for patches. (non - contentious, just works, and you can ignore if you wish 
)
added Submenu for the ‘system functions’… we did discuss this before, but I wondered what your thought for the layout should be, here is what I have so far
------- System -------
Shutdown
Patch Functions >
Other Functions >
...users stuff.. possibly in menus
--- Patches ---
....
--- Patch Functions ---
Shutdown
Save
Save New
Show Favourites
<--- System
...users stuff.. possibly in menus
--- Patches ---
....
--- Other Functions ---
Shutdown
MIDI Channel
Info
Eject
Reload
<--- System
...users stuff.. possibly in menus
--- Patches ---
....
basic idea is Shutdown is always there… and the patching and other functions, are not really related…
(e.g. when your working a patch and likely to save, its unlikely you then want to do ‘eject’ … midi channel i think is ‘arguable’, perhaps more patching function?)
the way the code is structured it would be easy to add other menus as needed (e.g. Midi might gets its own menu)
Ideally Id like to keep the number of options quite small (ideally 4, but thats quite tricky, as shutdown is one of those) , as scrolling around the display is no fun, similarly we dont want too deep menus.
(what Ive done would allow for nested menus, but I dont think we need)
one thought I had was to also move the ‘User functions’ to a submenu , it would be nice and tidy, but the drawback is, if a user comes up with a really frequently used function (e.g. start web, or start wifi) , it means they have to go into that at startup … so as yet I have not done this.
of course now with ‘sub menus for system’ they can just place all their stuff in a sub menu called user if they wish.
thoughts?
I think it is a good idea, the menu is getting a little unwieldy. I’ve been working on a single WiFi menu item that has its own sub menu for selecting networks or AP mode, starting the file manager, so that will be easy to place wherever makes sense…
yeah it does come down to how organize the items. I agree that User could be always a sub (called Extra or something)… true that there might be a frequently used user command where quick access would be better, but such a command doesn’t exist yet, and the user commands are still rarely if ever used anyway…
good to keep shutdown always on top to encourage proper shutdown.
there is a little ambiguity with the Other / Patch functions… one idea is to separate the actions from the settings/config:
Actions:
Eject
Reload
Save
Save New
< Home
Settings:
Info
MIDI Channel
WiFi Setup
Show Favorites
< Home
I like this separation, and Settings sub makes sense. But ‘Actions’ might be confusing, could be called ‘Commands’ but this isn’t much better… another option is no sub for the actions, so the main menu looks like this:
Shutdown
Eject
Reload
Settings >
Extra >
And then put Save and Save new permanently in extra with any other user scripts, since in a way that is what they are: extra functions that don’t necessarily work with all patches…
Ive extended the meaning of patches, beyond pure data, to anything that a user would like to ‘run’, to generate sound or process sound… or anything musical i.e. non utilities.
This means, patch directories can now include:
Supercollider patches - main.scd is run.
Native patches - run.sh is run.
Native patches.
If you wish to write a native patch (i.e. an Executable) you should wrap with a run.sh file, any sub process you start should create a PID file in /tmp/pids
when patches are ‘switched’ , killpatch.sh is killed, which will first send a SIGTERM to each process identified in /tmp/pids. and then a SIGKILL…
EDIT: I noticed the OS2.2TB17 and SC_install zip previously uploaded were corrupt on Patchstorage.
Ive just uploaded new versions, which work fine now (00:30 CET)
yeah, had a bit of scare, downloaded early and installed later…
BUT all good now
hey i just wrapped on my semester so i am going to try this today, predominantly so i can start authoring patches for my SuperCollider Files [about 800MB of them
Can you share with me the internal sd directory info? do i need a different SD card?
yes, you’ll need a bigger card, as the CG image ‘fills’ the 4gb card…
I have a 16gb Card I can is there a how to that you’ve made? I have a nice fast one too
Where do I grab the os image?
i grabbed the 20170622v2.1.img from the C&G repository and etcher to write it
I am just not sure about writing the partitions, i assume they need to be fat32 correct?
okay got it all working
This is really nice thanks @thetechnobear for this hard work.
One last question for the SC_install – i assume i have to create a “System” directory in the new /sdcard folder correct?
i am going to copy my sdcard with SDCARD copy utility on Raspi with ALL the Shreeswifty patches on it.
I am going to make a fun set of SuperCollider patches for it as well. This will be great for the MEGA-SET with all the Abstraction and external libraries pre installed.
Suite.
yes, treat the /sdcard volume the same as /usbdrive, so place a system/patches folder there.
its worth noting… if you mount (in motherhost) a usbdrive then it will default to that i.e. usb takes priority over the internal drive… this can be handy
of course /sdcard is still mounted, so its possible to copy things from ubsdrive <-> sdcard
(though in fairness. i tend to just scp things directly to the organelle)
something like:
scp file(s) root@organelle:/sdcard/Ok so maybe this is a bit of a wish. But with the potential to put patches on the SD could we move towards a different approach to sample storage in a future iteration of the OS? With samples stored in one or more folders on the USB stick and the patches capable of being pointed at a particular bank of samples?
Pretty sure that wish has already been granted, just nobody has shared a patch which uses the media folder you describe yet.
matt - this is precisely what i want to do for both reading and writing and i am very hopeful that we’ll get better performance.
TB 18 released…
If you now place zip files into the Patches directory you will be offered the option to install them
(so you do NOT need to unzip the file first), once the install is successful, it will delete zip file.
… you can place zip file in a sub directory, if you want to have it installed into a subdirectory
the installer is for more than just patches, it can also install other system utilities, web apps etc.
(see below for tech note, if you are releasing software for organelle)
C&G have also been updating the wifi setup, which I have included here… (I need to keep my code base in sync with C&G) but it may or may not be complete.
however, importantly for OTC_Web, there is now a centralised ‘webserver’ , which OTC_Web uses.
so you use your web browser and go to :
http://ipofyourorganelle/
and you will find all web apps that are available, currently OTC_Web (assuming installed, and FileManager)
again , please remember this is a beta, so any issues, please post here.
the advantage of the installer are:
for a straightforward patch
only requirement is that the patch is zipped into a single directory, and unzip into it.
e.g. use
zip -R MyPatch.zip MyPatch/*
this is pretty much what all patches have been doing to date, and so are compatible.
improvements/manifest
If you are distributing a large number of files, then corruption on a USB drive has proven not uncommon, and causes quite a bit of issues to track down, so to build a patch file with a manifest is simple on the organelle ,
simply ssh into it then use
~/script/create_install_zip.sh MyPatch
(where your patch is in the sub folder MyPatch)
… this will create a zip file with the appropriate manifest, so that upon installation the files will be checked
advanced use… deployment scripts
within your patch directory you can include an script called ‘deploy.sh’ , this will get called after patch has been unzipped, and verified. you can do pretty much as you like.
and depending upon the return code, can then restart mother, reboot or shutdown the organelle.
(see my installers for SC/OTC for examples)
is there any easier way of having my dry signal on all the time for all patches rather than adding r~ inL — throw~ outL and r~ inR — throw~outR to every single patch that I want to use? is this toggle-able via the OS? or possible in an update?
i’m trying to use my organelle and bass through the same pedalboard without having to use a mixer or aby pedal for seamless switching between the two when needed
currently the ‘mother host’ (the thing that presents the patch menu) does not process audio at all, its all done by the patching host (Pure data normally).
if you want something to be done for ‘every patch’ , the place to put this, for pure data, is in mother.pd,
so you could copy this, and ‘override it’ , and simply patch the in->out there…
of course the issue is this in not going to work great with all patches, since some patches are already doing this… so you may also need to rework some of the patches you use.
i think there is an interesting area here, which is… extending the mother host and mother.pd (et al) to support more ‘global functions’ e.g. mix/vol levels, midi channels etc, perhaps this is a direction to explore once the next official release is out.
(oh my, am i already thinking about a TB beta before the official release is even out there )