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

Adding a path to the pdsettings file is fairly easy. I did this yesterday : https://github.com/bapch/Organelle_scripts/blob/master/addapath.sh

It adds a path and increments the npath value. As i can’t test it for now (no proper way to debug : no screen, no network adaptor) it’s been tested only on my computer.

yes but there are a few problems with this approach:
pdsettings is in /root . which is on a readonly partition by default… and you dont want users routinely (e.g. just adding new patches) to be switching it to rw… if you do, it kind of negates the idea of making it ro to start with.

if you plan to do global paths, then there is the versioning issue.

if you plan to add patch specific paths (to avoid version issue), then you have to have an install process (to add paths) , and uninstall (to ensure you dont keep redundant paths)

anyway, the environment variables are there (and we can add more, if required , e.g. patch name/locatioin, default sample location etc) - do you see a problem with this approach?

As i noted in the readme, i can’t test it on my Organelle for now and it indeed needs a call to remount-rw and remount-ro as well as a path redundancy check.

Totally cool with this :slight_smile:

This OS has been working nicely for me so far. One thing that I haven’t tried is MIDI program change messages. Are these changed, or how do they map to sub folders? With the sub folders it might be a little confusing, so maybe they should just be mapped to the favorites? this would give users a little more control from device itself and make the mapping more obvious.

2 Likes

Good idea, I’ll do this asap.

updated 2.2TBb6, program changes now select from Favourites, as suggested by @owen.

Install keeps failing one me. :confused: Error code is sha1 or something, any idea what might be the issue?

I’ll check and get back to you

ok, just tested from the patch storage download - and works fine here…

fyi - the sha1 error indicates that (at least) one of the files has been corrupted, I automatically generate this when I build the package, to ensure you don’t get a corrupted organelle install.

most likely your usb stick has corrupted it… you could try to copy it again, if that doesnt work, there is probably an issue with your usb stick, so Id recommend formatting it.
IF you have had issues with your usb stick before (I remember someone here, having issues recently) then its possible your stick is ‘on its way out’, they do have a limited life (counted by number of writes, though it is quite alot :wink: ) … so Id be tempted to try a new usb stick.

Twas I, with the corrupted patches on his USB stick before, now seems to have happened again. Might have to try a new stick indeed! Thanks for the help.

1 Like

ok, so Ive been noticing quite a few people recently having issues with external midi with the organelle.
(and I also previously had issues with one device, which I hacked around)

I thought Id see if rather than using OSS we could use ALSA which is (in my experience) a bit more stable and better features too :wink:
so Beta 7 contains a new experimental support for using PD with Alsa

as its experimental, for now you will need to edit the MIDI-Config.txt file manually.

on your USB drive , you will have MIDI-Config.txt (if not, then set the channel then you will )
its contents is something like

channel 1;

to use alsa you will need one new line,

channel 1;
usealsa 1;

these need to be entered exactly as above

usealsa is 0 or 1, if 0 (or key not present) then PD will use OSS (as it did before) , if this is present and not zero , it will switch to using alsa for midi input and output

with just usealsa 1, we default the PD midi input and output to ‘client 28’ which is client number allocated to a usb midi device. most of the times, this is fine, but sometimes it may need tweaking, which I detail below.

note: the above config file will be reloaded if you use the midi channel option… but changes will not be used until a PD patch is launched.

advance use

there is an additional config parameter, called alsaconfig, this is actually defaulted as follows, but you can override it, by adding something like

alsaconfig 28:0 128:0 128:1 28:0;

alsaconfig determines which alsa devices to map, what does this mean?
well its actually have two pairs of numbers, the first represents input, the second output

what does this mean?

input

28:0 128:0

28:0 is commonly the first midi device (and first port) and this is being routed to Pure data midi input (128:0), so this says routing device 28:0 to 128:0 (pd)

output

128:1 28:0

128:1 is PD alsa midi output, and this is being routed to 28:0 , again the usb midi device.

(dont worry, midi ports can be input and output, 28:1 would NOT work… that would be midi device 28, port 2 something different entirely)

so this is the default, but what if that doesn’t work with your device?

configuring other devices…

how do you know what to use?

now, since beta 8, there are 3 options

  • plug in a keyboard /hdmi monitor
  • use networking login (via ssh)
  • use Diagnostic Log (see my patchstorage account)

for the first two, type at the prompt.

aconnect -l 

(thats a lowercase L )

or if you run Diagnostic Log, you will find in diag_log.txt the output from aconnect.

my output for this is:

client 0: 'System' [type=kernel]
    0 'Timer           '
    1 'Announce        '
	Connecting To: 15:0
client 15: 'OSS sequencer' [type=kernel]
    0 'Receiver        '
	Connected From: 0:1
client 28: 'Virus TI' [type=kernel]
    0 'Virus TI MIDI   '
    1 'Virus TI Synth  '
client 128: 'Pure Data' [type=user]
    0 'Pure Data Midi-In 1'
    1 'Pure Data Midi-Out 1'

here you can see the pure data ports (which will always be 128… assuming no other clients running ;)) , as I had a patch running, with alsa setup (i.e. usealsa 1; ) … but your not interested in that.

your looking for your devices… if you plug in multiple, then you’ll see many ‘clients’…
(I’m only supporting one input, one output for 2.2 betas)

so in this case, you can see my Virus, which actually has 2 ‘ports’ , one represents a usb connection to the MIDI ports (ie. acts as a midi router) , then seconds goes to/from the synth engine.
so actually for the Virus, I want the second port (Virus TI Synth), so I need to configure using:

alsaconfig 28:1 128:0 128:1 28:1;

if you start plugging in multiple midi devices then only one of them will be 28, the other will be something different…

in time, we could then actually send these to different Pure Data inputs, which might be useful for (e.g.) keyboard and drum pads to go to different parts of a patch.
anyway, thats all for later…

3 Likes

Great this worked for me.
Tested with OP-1 usb cable directly into Organelle on endless sequencer.
Wasn’t getting midi to sync that way since the 2.0 software upgrade.

1 Like

glad its working for your , and thanks for the feedback @mec1
… did you use the default config?

alsaconfig 28:0 128:0 128:1 28:0;

it would be good to know if this works for all devices that others are currently using…
I think for the next beta, I’ll make it such that if ‘usealsa 1’ , then it defaults to this config, so its a bit easier to setup.

what I’m wondering though is… I suspect the above is as at least as compatible as the current OSS implementation, if it is, then we could switch in 2.2 to use this as the default.

ideally, to do this we need to test with as many midi devices, that already work with organelle as possible, so we know its not a step backwards (which would understandably upset some :wink: )

what I think I’m going to do is:

  • release a new beta with improved defaults, and improved communication with PD
  • release a system script to ‘activate/deactivate’ alsa , so users don’t have to edit the config file
  • release a system script which collects various ‘system information’ into a log file on the usbstick, that users can then post here… this will allow me to help setup ‘problematic devices’ … can also be used for other diagnosis of midi related issues.

dev notes, (primarily for @oweno )

in Beta7 , Ive started a move towards the ‘mother executable’ being responsible for midi configuration… the idea, going forward is that it will communicate with PD via OSC various config information - rather than PD read it from config files - now this means midi channel, but can be extended. this will allow ‘tighter integration’ of midi setup in mother exec.

in b7, I currently send the /midiCh message in mother exec but have left PD reading config file too, but in b8, I plan to make two small changes to mother.pd

  • remove parsing of MIDI-config.txt, this is now superfluous (from b7)
  • add a new OSC messages ‘patchLoaded’ which mother.pd will send when its loaded, this will means that mother exec knows , that pure data is ready to start receiving data.

I guess, I could add a ‘timeout’ for patchLoaded to allow for ‘old mother.pd’,
though this raises a more ‘general issue’, really those adapting mother.pd need to understand when new releases are made, they made need to integrate their changes into their own version.
… I wonder if we can somehow improve this ‘issue’ with better encapsulation of the changes users are making to mother.pd… or if mother.pd can be extended to incorporate the changes they require?
(its a bit concerning, ive seen a few posts on the forum, where ‘upgrades’ are failing/acting odd, because users have copied previous versions of mother.pd)

EDIT: ok this is all done for b8, accept for the alsa switching script.

also importantly as I mentioned above, if we can get some positive feedback for the alsa route, and backwards compatibility, then I think we can consider using alsa as the default… with a fallback route for OSS. (I’m not suggesting we remove OSS)

another small question, going forward, is perhaps ‘advanced configuration’ should not be done on the oled… sometimes its going to be pretty difficult to cram the information onto it, and for 90% of users its unnecessary… of course your ‘web browser’ could provide an ideal place for this advanced config… or editing of config files if users don’t have a wifi card.

Yeah I used the default script for the .txt file as you described above.

I will try with my new iconnectivity cable tomorrow and another sequencing device when it arrives and let you know. :wink:
Thanks for this, great work.

Maybe @monsieurtopu and @glloyd who recently posted in the forum should give this a go and post their feedback also.

1 Like

ok, Beta 8 is out… which now will default alsaconfig, so you only need to add 'usealsa 1’
also it has a better way of synchronising with the PD patch… which as involved some small changes to mother.pd
(but there is a timeout, to retain backwards compatibility)

Ive also created a new System script called “Diagnostic Log”, this creates a log file on the usbstick called diag_log.txt, which contains various system information, from this information we can diagnose midi device issues, and also help with configuration.

https://patchstorage.com/diagnostic-log/

for those that like details it reports … alsa connected devices, lsusb details, dmesg (last 20 lines) … obviously its trivial to extend if we thing more is needed.

I’ll do the alsa switching script this evening :wink:

This is exciting! better / easier / working-at-all MIDI functionality is always a good thing.

checking it out.

The diagnostic script is great idea. It should come in handy.

Most of the problematic MIDI devices so far have been those that create two devices or ports. (Korg minilog, maybe monolog, SQ-1 are known to do this) it would be good to test this alsa stuff with those. Also being able to use multiple devices (different one for input and output) is something that would be useful for people, so that is a big bonus.

Re: dev stuff:

This is great, I like the idea of mother exec being the boss, the one entity that is responsible for the overall system state, so any move in this direction is cool.

Yeah, this has been an issue, but all the new MIDI features lesson the need to edit mother.pd moving forward. I reckon most users were only editing to change things like MIDI channel, and now that you can do that in System messing with mother.pd is not necessary. After 2.1, we only suggest messing with mother.pd if you know what you are doing. One thing I’ve used a customized mother.pd for is setting up a global recorder, so you can do things like record all output. I pictured a system script where you could enable the global record, but none of this has really materialized, so still probably goes in the category of ‘if you know what you are doing’.

The config does get to be a pain. Part of the idea with extra System scripts was people being able to add the functions they need. So if you needed to use 2 MIDI devices, you use the “Config Extra MIDI” System script to set it up. The scripts just operate on the midi config file for you. Then all this stuff doesn’t have to be coded in mother exec, it could just receive a message to reload the file. (and you could always edit the file by hand or through web interface)

1 Like

great to know I’m moving in a direction your happy with :slight_smile:
yeah, I think your right about config… I think it should work ‘out of the box’ for most common setups, then system scripts can be used for ‘corner cases’ … and yes, B8 already contains a message to reload the midi config file, its (unimaginatively) called ‘/midiConfig’

yup, the 2 port midi devices that have issues will probably all work with the same ‘alsaconfig’ I mentioned for my virus (as its the same issue), if not then if they run the DiagnosticLog I can advise the what is needed.

as for mother.pd changes, perhaps we just need to details these things in release notes.

hmm, I could make it so when the mother.pd returns the ‘/patchLoaded’ message this includes a ‘mother.pd’ version… so that it can report a warning when its not as expected.
(this would be a ‘protocol version’ i.e. it only gets updated, when osc messages are changed)

… the only issue I see here, is where to report it, most don’t run mother exec from console, so wont see its warning, similarly its likely they are not running the pd console, and the oled could be ‘annoying’ (unless, I suppress it after the initial warning perhaps)

just wanted to chime in and say, just having the patch subfolders and favorites has made an AMAZING difference to me, because scrolling thru 100+ patches every time was killing my workflow. Organization brings this piece up to new levels, thank you again for your work on this beta OS.

2 Likes

One thing I noticed is if you are in a multi page patch (encoder override) and you eject the USB drive, reinsert, then select Reload in a few seconds the menu flips back to the old patch screen (when you ejected) and it is stuck there (because Pd got stopped but never released the encoder lock… I think)

yeah seems likely.
basically its ‘eject’ its needs to be a bit ‘cleaner’ it currently just kills pd, and sets the menu screen.
really we need to update the mother exec state to know no patch is running, and in turn remove any overrides, and ensure the ‘menu’ is active.

I’ll make the necessary changes, and then test this use-case explicitly

thanks for the heads up… I’m not using the usbdrive, so would never have spotted it :slight_smile: