Important Info about Testing

We are changing some of the naming conventions of Zynthian. Future major versions will each have a name. This is not just a marketing gimick. It helps us with managing the development, testing and release processes as described in more detail below.

The next release will be named “Oram” to honour Daphne Oram, an amazing early pioneer of electronic music. Daphne was a British audio engineer who pioneered the use (and misuse) of tape to create soundscapes.

What you need to know

If you use the stable Zynthian release then you do not need to do anything. Any hot-fix patches for 2401 stable will be available via the current manual update mechanism. When the next major version is released, you will have the opportunity to manually select it for update or (as we recommend) install a fresh image onto a separate microSD card.

If you are one of our intrepid testers, i.e. you are currently on the testing branch then you have a choice. You can stay there and test any hot-fixes to the current stable version or you can switch the the oram branch. Please be aware that oram is substantially different to stable / testing so this is a big change. Only do this if you feel confident in doing so. As always, we recommend backing up your data and using a separate card for such significant changes.

If you are already using chain_manager branch then please switch to oram which is directly derived from chain_manager. There will be no further development of chain_manager and the branch will be deleted soon. (Please note that other stale branches will also be deleted so if you are on a branch not mentioned in this post then it may soon stop working.)


Here is a more detailed description of the new deply process.

Each version will have a code name. The next release will be called oram. (Please note we use lowercase for the git branches. This is git best practice.) The git branch called oram will be used as the development and alpha / beta / release candidate testing until the release of the next major version at which point the oram branch will become the staging branch for any hot-fix patches to that version. This means that you can join the testing at any point and remain on the same branch all the way through to stable release and if you choose to remain on that branch, get the hot-fixes to test before they are applied to the stable version.

When we release the next major version, we will create a tag called, oram-YYMM and apply it to that release version (git commit). (YY is the year and MM is the month of release.) Another tag oram-YYMM.0 will also be applied which indicates this is the first, unpatched version of this stable release. Users may opt to use the oram-YYMM version which will get hot-fix updates or they may choose to use oram-YYMM.0 version which will never change. A new, named branch will be created to act as the development and testing branch for the next major version.

After release there may be significant bugs that need to be resolved. These will be fixed and tested in the staging branch (called oram for the next release) and then a new tag called oram-YYMM.1 will be created and the existing oram-YYMM tag will move to the tested version. This means that a user update will receive these tested hot-fix patches. (oram-YYMM always points to the latest stable release of the oram version and each point release is also tagged, allowing roll-back as required.)

I hope this makes sense. It isn’t really that complicated. You choose:

  • Stay on 2401 stable if you wish to maintain the current behaviour and receive hot-fixes (via manual current update mechanism)
  • Stay on testing if you want to test hot-fixes to the current 2401 stable version
  • Move to oram if you want to enjoy and endure the bleeding edge development

Thanks @riban : this new approach to Zynthian OS releases sounds logical and well-conceived, characterising each major stable update with a mentally traceable symbolic name.

1 Like

@riban’s education cost us a lot… but now we have our satisfaction… Thanks Riban

1 Like

Riban, thanks for the explanation. It’s logical and the described change will bring order to version labeling.
And one question. Will oram be 64bit?

1 Like

The aspiration is for oram to be released as a 64-bit image. This will almost certainly require a full image flash to deploy. (I am not sure we have the effort available to build and test an upgrade from 32-bit OS to 64-bit OS - although it may work…) We are considering how to track and report significant changes. We may add a changelog that updates during development.

Also, whilst we are here… The issue tracker now has a milestone called Oram which will be used to tag issues resolved in the oram branch or issues that the development team feel need to be resolved before the stable release of Oram. Please don’t add these tags yourself (I don’t know if that is locked down in GitHub) but you can use the milestone to see issues resolved and due to deploy in the Oram release.

1 Like

And what about developers? Is there any substantial change in oram that will render the controller drivers unusable? Should we switch? :slight_smile:

YOU should definitely switch. You have been using chain_manager. Chain manager is dead! Long live Oram.

1 Like

I’ve switched already :wink: , but I was curious about how much dangerous was the zone… :laughing:

It is the direct descendent of chain manager. Moving from stable to oram is a substantial change but we have done lots to ease the migration. Old snapshots should port across.

Be aware that things like snapshot, configuration, etc. may change during the oram development. We will only provide migration from 2401 to Oram. This means that snapshots built in oram may not work in future revisions of oram. That is the nature of using the testing branch.


I’ve done a bit of stuff on this and am still using sequences, snapshots and captures from several versions ago.

I switched as well. It looks so much nicer. I really like the chain management.
But I have issues with zs3. Has it been moved? No double learn anymore?


  • Short press the top right encoder to access a context menu
  • Select “Manage ZS3” to access the ZS3 menu


  • Press the ZS3 / SHOT button


  • TBC

V4. I found what you meant. I can create new zs3 entries. And if I trigger them via UI, it seems to work. But I want to trigger them using midi program change.
Now I entered the learn midi screen with this new mixer window. When I scroll the upper left encoder, the mixer is displayed with a yellow label. Now I can press the program change and yellow becomes white again. After I saved this by overriding a zs3, I expected to trigger this zs3 with midi program change. But it doesn’t.

Hi @mheidt !

I’ve solved several issues with ZS3 in oram in the latest days. Are you updated to the last, right?
Also, the device you are using to trigger the Program Change, is in ACTI or MULTI mode? Or are you using internally generated Program Change (i.e. zynthian push buttons configured for Program Change)


I was triggering from my V25 externally as ACTI. But I will give the internal buttons a try next.
But I found the process to get there a little bit unintuitive, btw.
that you have to rotate the upper left (layer) encoders!?

You are totally right. We are quite focused in V5 layout and sometimes we “forget” V1-4 layouts, although we shouldn’t as we really want to keep older layouts fully operative. I will try to improve it.


I would expect an entry in the zs3 context menu that would wait for the program change event

Update and try!

The UI is working again. If after updating it doesn’t reboot automatically and remains stucked in the splash screen, simply “force” the reboot.

Regarding MIDI learn / ZS3 / snapshots:

  • short-learn => Enter MIDI learning (control screen) or MIDI learning menu (mixer screen)
  • bold learn => ZS3
  • long-learn => snapshot

It’s difficult to find a better solution for the classic 4 encoders + 4 switches layouts.
If you have extra switches, you could make your custom assignments.


1 Like

yes, oram works again.
But I don’t get the switching of zs3 via midi program change events working.
I am runngin V4 stage, which means, that the 4 extra buttons are sending midi program change events. But I don’t see them in the Midi Log either.
And is it correct, that I have to rotate the upper left encoder, so that the name in the mixer is becoming yellow? I saw, that the volume is set to 0, btw…

1 Like