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…
1 Like
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
When fully functional, yes. It needs some work on midi channel mapping yet …
2 Likes
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.
1 Like
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.
Regards
2 Likes
I elected to just order the normal 4 GB version but thanks for the info.
3 Likes
My Zynthian v5 kit arrived yesterday and I managed to get it assembled and booting on a fresh micro SD card. Also ran updates via the web interface.
Now, if I just want to get on whatever test branch is necessary to use the external gear SysEx feature discussed above, what would I need to do for that?
The feature is not yet developed. It will be soon, but not today 
Anyway, you should change to testing branch in all repos and update to get the latest MIDI routing improvements.
Regards
1 Like
Oh! I had just gotten mixed up about which feature was ready.
1 Like
We are quite close now. It’s a low hanging fruit…
1 Like
Great. Thanks for working on this.
I read that the new version of the Linux kernel has SMB network sharing support built right into the kernel. I would presume that, once Raspberry PI OS gets that new kernel, Zynthian would eventually get it too, which should make supporting SMB network shares easier?
Also I would like to somehow mount the Zynthian v5 above the Casio CDP-S360 keyboard I’ve got but the Zynthian is a little too big to stay on there. I am trying to figure out the best approach for that. Maybe some kind of stand which tilts the Zynthian upwards?
1 Like
We will announce a vesa mounting gadget for the V5 in the next weeks. I think this should solve most of the “mounting” problems.
Regards!
1 Like
SMB sharing has never been a problem, but we prefer SFTP 
Regards
1 Like
Great to hear about the vesa mounting solution. Looking forward to that.
I know how to use scp and sftp with WinSCP and FileZilla respectively, but you can’t actually mount those to the file system in Windows, which severely limits how you can use them as compared to SMB, so I would like SMB to be supported for full Windows compatibility.
For example, let’s say there’s a large audio file out on the Zynthian that I need to open in my Windows Audacity app. With scp or sftp, I’d need to download the entire file to local storage, and then import into Audacity, which makes another copy of the entire file run through ffmpeg as part of its import process, and then delete the local copy after I’ve got it in Audacity. However, if SMB is supported, then I can skip the intermediary step of making a copy of the entire file on local storage. Instead, the network share can go directly to Audacity / ffmpeg, downloading as it imports in one seamless operation.
The way Linux handles this, where anything can be mounted in the file system, is objectively better than how Windows handles this, where each protocol gets its own third party app except SMB which is built into the OS. But unfortunately, for a lot of use cases, a lot of people are still stuck on Windows anyway. If I thought that not supporting SMB would somehow put pressure on Microsoft to fix their crap then I’d say don’t support it, but that isn’t what’s happening. Instead, what’s happening is that the Linux kernel itself is getting SMB support.
(I edited out some comments about being frustrated with Linux elitism)
I tried this today and I get that same error screen on boot after changing just one. (zynthian-ui ) I was real careful to wait for half an hour after switching to the testing branch before telling it to reboot.
I’ve actually got a system going at this point where I have two outwardly identical 32 GB micro SD cards and while I’m testing with one of them, I’m already flashing the Zynthian OS to the other one since I’m pretty sure I’m going to screw it up.
Let me know what logs I should be capturing or other actions I should be taking to find out what’s wrong. Thanks.
(later edit) I forgot to mention that the web interface also goes down when the Zynthian hits that error screen. I haven’t tried to SSH in but I would guess that would be the way to retrieve any logs of why it’s failing so I’d just need to know how to turn on the logging and/or what the path to the logs would be.
You MUST change all repositories at once.
This advice is deeply wrong. There are dependencies across repositories. Please, ignore it and change all repos to testing, update and wait until it finishes.
Regards
1 Like
Hi @zynthianers!
Please, ignore this advice. It’s wrong. Repositories have cross dependencies. For changing to testing branch, you MUST change all repositories at once and update.
Sometimes, it’s useful changing a single repository to a given development branch for testing a new feature or fix, but it’s not the case with the testing branch.
Regards
2 Likes
I did already try that with the same result earlier today, but I can try it one more time to be really sure.