This is a transitional image, but it includes some important changes and a lot of fixes and little improvements:
Per-device MIDI-input mode:Global stage/multi-timbral mode has been dropped. Mode is now selected for each MIDI input device, from the chain options menu. You can bold-click any device for changing the mode globally. There is 3 available modes: ACTI, OMNI, MULTI. You can learn the details in this post:
This is transitional and it’s been simplified and improved in the upcoming “chain_manager” refact, so please, don’t complain too much about it. In the next release you will be pleased with the final result.
Per-chain MIDI-input devices: Now you can enable/disable MIDI-input devices for each chain. When combined with the device mode, this simplifies some use-caes and allows new ones that were not possible before.
MIDI Controller device drivers: The new MIDI controller device driver system has been improved quite a bit. Again, this is transitional, and you will see the final result when “chain_manager” arrives. Until then, you can enjoy of Plug & Play drivers for some popular devices:
Akai MIDI Mix
Novation Launchkey MINI MK3
Novation Launchpad MINI MK1
Novation Launchpad MINI MK3
Novation Launchpad PRO MK2
Novation Launchpad PRO MK3
Novation Launchpad X
Driver are auto-loaded when you plug the device, and you will see they are marked as “-----” in the MIDI in menu, being unavailable for chain input.
More are coming in the next release. If you want to program a driver for your favorite MIDI controller, you better jump to “chain_manager” branch (it will be the new testing branch very soon!).
Improved MIDI chains: Routing has been improved & fixed, so now you can route MIDI output to selected devices.
New options in the main menu:
Remove sequences
Remove chains
Nicer check-boxes in all menus
A lot of fixes and little improvements.
This is the last 32 bit image we will release. The next one will be bookworm-based 64 bit and it will include the “big chain manager refact”.
You could try and it should work, but it will take some time to update everything and things could go wrong. Anyway, i would recommend to have a backup of snapshots, captures, etc.
I did an update from stable on a V4 which worked. I have observed an issue with Aeolus that I will look at. Aelous is fine. I was playing outside its key range!
Same upgrade procedure. From UI admin, command line or webconf.
Regarding your snapshots, think that clone will be dropped in the next release, so you would need to re-build the routing to adapt to the new paradigm, that is a lot better, BTW.
It was a problem of perception. It didn’t actually “crash” Zynthian, it was just taking a long time to load because the gigdump utility was analyzing my giga library collection (which is extensive).
After it creates all the “.ins” files, it is able to load the snapshots (although they are empty) now I have to reconfigure the snapshots with the correct instrument, since now it needs to indicate the instrument within the gig file in each snapshot channel, not just the .gig file as it was before.
I installed 2401 once more step by step and I discovered the cause of Internal error:500: it was a bad snapshot here attached 001-RedGrand.zss (23.3 KB)
Could you explain your install procedure, step by step? It’s really strange that you have the plugins unticked after first boot.
Are you copying files from your old zynthian image to the new one?
If so, what is probably failing it’s not the new stable image but the backup/restore procedure, what is a quite different thing. In such a case, i would recommend trying to backup/restore only data files.
Steps 1 -5 are the installation of the new stable image. You should test that everything works before trying the next 2 steps (aka restoring the data+config from older image). If you find issues here, you should report as issues with the new image.
Steps 6-7 are the restore procedure. Any issue in this procedure should be reported as this. If not, we don’t know where the problem is. Any issue when loading restored snapshots, should be noted as this.
Same if config is broken after restoring, etc. You don’t simply say “i’ve problems with the new stable image” or “it doesn’t work”. You better say “i’ve issues when restoring my old data/config in the new image” or “i’ve an issue when loading a legacy snaphot from the previous version”, etc.
Also, when reporting ANY issue, context is VERY IMPORTANT! We need ALL the details:
Hardware setup
Procedure, step by step
Screenshot from the dashboard
Logs from UI or Webconf
etc.
For instance, we have spent 5-6 messages to reach this point where finally i’ve the needed info.
Why are you using WinSCP instead the webconf tool for backup/restoring? Restoring the config from an older version is not so easy as smatching the new image’s config folder with the older one. You probably are breaking things by doing this. You should try using the backup/restore tool from webconf. If you find issues with this, please, report it and we will do our best to fix it.
