I don’t know, but it looks like there is a problem with Testing. I posted the instructions for changing to testing, and two people have had problems with it:
Wapata, on a V4 gets “error screen (exit:1 and IP) but… no access to WebConf anymore, neither by wifi or ethernet”
BenMcLean, on a standard RPi “get an “ERROR” screen on boot when I try that.
The web interface won’t come up anymore and I couldn’t even shut it down properly.”
I’m running Testing on a V5 and have not seen a problem, but have not updated recently.
Don’t change all repositories to test at the same time. Change them one by one, update and reboot every time when the system asks you. I don’t recommend to change repositories without some experience of use ssh, linux command line and git.
I switched from testing to stable and then back to testing OK on my V5.
I’m wondering if this is a matter of waiting for the update process to finish with the message that it is saving state. Webconf helpfully puts up a red line at the bottom with a Reboot Now button, but it puts it up immediately, while the update process is still running.
I wouldn’t dispute that - I’m no expert, but my experience has been the opposite - I change them all at once, even using the stable checkbox to go back to stable rather than the individual drop-down menus, and it works for me. Changing them individually sounds like a very time consuming process.
I think it should be important for the web interface to not instruct the user to restart until the device actually is ready to restart even though I know that could potentially be a rather difficult challenge to program way beyond anything else I’ve suggested in this thread.
I will improve the reboot button issue as soon as I’m back. Please, open a ticket in the tracking system so I don’t forget it.
BTW, testing now have a some nice surprises, like the improved per-device midi output routing. Also de new midi-capture screen, that allow per-device multi/omni mode (proof of concept, but functional,)
Hi, to be sure : it mean that device 1 channel 16 have unique -jack-wire to a specific point and that device 2 channel 16 can be used for an other thing ?
Like… one device dedicated to Zynthian UI and the other to SooperLooper engine ?
If so it mean that I can stop thinking about osc setup and run everything from good old midi-cables and USB devices…
When changing repositories, Webconf puts up a Reboot button in red bar, which invites the user to interrupt the update while running - possibly making Zynthian unable to boot! #911
So, I have a question about buying a Zynthian device.
I see that there’s an option to buy a v5 kit together with a Raspberry PI 4 4GB version. But I know there’s an 8GB Raspberry PI 4 available as well. Would my device work better from the extra RAM if I opted for an 8GB version?
A fascinating question!
Short answer: Probably not.
Longer answer: It depends on what instruments-(Zynthian Functions) you want to run. And the answer may change when Zynthian changes to being based on 64 bit Debian in the not too distant future. If you can get your hands on an 8GB RPi4 and afford it, I would.
I never have seen the used ram over 1GB. I doubt you can reach 2GB of used ram with current zynthian software, not matter what sound fonts you load or plugins you use.
Perhaps the most ramnivore element is the audio player, and if we improve the use of zynthian as sample/loop player, certainly more ram will be used. Anyway, 4GB is a very decent amount for almost any use-case.
Current 32bit image can’t use ram over 4GB but the 64bit zynthian version will be available before Christmas, allowing access to any amount of memory you can buy. If your use-case is so memory hungry, you could buy the 8GB version and wait a little bit for the 64 bit version. IMHO, most real use cases for zynthian will keep ram usage under 1GB, so you would pay for ram you will never use.
Simply for checking my words, could some of you send a screenshot of the webconf dashboard while using your zynthian very hard? Try to use as much ram as you can for a real use-case.