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


#104

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

  • 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?


#105

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…


#106

TB 17 released

  • new menu structure
  • user system folder can now include subdirectories
  • new patch file support (see below)
  • experimental supercollider support (needs SC_Install)

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)


#107

yeah, had a bit of scare, downloaded early and installed later…

BUT all good now :wink:


#108

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

Can you share with me the internal sd directory info? do i need a different SD card?


#109

yes, you’ll need a bigger card, as the CG image ‘fills’ the 4gb card…


#110

I have a 16gb Card I can is there a how to that you’ve made? I have a nice fast one too


#111

Where do I grab the os image?


#112

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?


#113

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.


#114

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 :slight_smile:
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/

#115

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?


#116

Pretty sure that wish has already been granted, just nobody has shared a patch which uses the media folder you describe yet.


#117

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. :slight_smile:


#118

TB 18 released…

  • new “Installer”
  • changes to menu structure
  • Supercollider can now have overrided mother.scd
  • Supercollier - mother.scd updated
  • support for ‘option’ files for all patch types
  • added support for python patch files

Installer

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)

Central webserver

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.

Installer Tech Note:

the advantage of the installer are:

  • easier for the end user
  • unzip on the organelle avoids potential issues with users having issues with how they unzip it on a host computer (e.g. changes from macs to windows) so consistency
  • the installer zip file can contain a manifest including checksum to ensure that what is being install is undamaged (see below for how to create)
  • the installer zip file can contain a deployment script (deploy.sh) which can carry out any actions the developer wishes, this is how system and web files can be installed, but you could also use it to unpack media, or do other ‘installation tasks’
    (see my installs for OTC/SC for examples )

creating Install zip

  • 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)


#119

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


#120

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 :slight_smile: )


#121

yeah i think that would definitely be an interesting contribution!

i wonder if it’s possible to add it in the mother.pd to all patches, and use a conditional statement? if r~ inL — throw~ outL and r~ inR — throw~outR already exists in an opened patch, then disable the function in mother.pd? if not, then keep running?

i have very little experience with puredata so just curious~ :slight_smile:

thx for all you do and the feedback~ :grin:


#122

the same mother.pd is used by all patches. ( assuming not over-riden, which is not normal the case)
unfortunately, mother.pd cannot know if the patch as an r~ inL , so no it cant be automatically disabled… without altering the patch file.
of course, and once you start doing that, its almost as easy to add the ‘pass thru’ to the patches you need that don’t have it currently…

this is kind of where the dilemma is for Organelle… I think many of us love the experimental side of it, and the way a patch can do anything, but often there is a call for more centralised functions (midi control, mixing, recording, sample kits) … but these requires ‘rules’ and ‘standards’ which is rather counter to the experimental side.
Really, I think at the moment its left to the patch developer, to add many of these things.

Im actually working on an ‘infrastructure’ for my own patches, which will provide some of these things, that i will make available once its finished.
( I got rather side-tracked with SuperCollider and OTC, and kind of needed a small break from it ;))

and if you look closely at C&G’s recent patches, you will see they are now using a modular type approach, which could also help with these kind of things… (which other patchers could also adopt)
… I think they really have taken it to ‘another level’ :slight_smile:

anyway, i think next year we will see some interesting advances in this area.


#123

Hmmm…the b18 update patch is failing for me. Have tried downloading a few times from Patchstorage and re-unzipping. But keep getting message “Upgrade failed: files Try downloading and running this patch again”