This part is a little more subjective, but I feel like the Zynthian UI has a weird font and that legibility might be improved with an uglier but more normal / boring / less unique looking font.
I hate to be so negative all the time and I know my use case might be a little outside the norm since I’m trying to make the Zynthian work together with external gear, but I really am stressing out over this stuff.
Advice from the peanut gallery:
Use stable branch when you’re in a ‘high pressure’ situation. Obviously you get to decide what is high pressure, but it does sound like this was for you. If you need some new features that are only available in testing, you might have to wait.
Try to do simpler things with less instruments connected for starters.
Get the powered hub, although of course that introduces its own set of potential problems.
I don’t speak for Zynthian, but I thought the feedback was valuable. Hopefully it wasn’t at too great a cost in sanity-annoyance-[giving up]-etc for you. After all - we’re all in this together.
edit: and although your use case may be a bit ‘demanding’ with all the Yamaha Reface and midi initialization stuff, I think it is well within what we want Zynthian to support well. I would use the phrase ‘within the outer perimeter’ but it has become somewhat overused in the US.
Your item 4 above - I’m not particularly fond of the ‘short-long-bold’ distinction on button pressing, but it and many of the idiosyncrasies of the Zynthian UI have historical explanations - we didn’t always have the keypad - it’s new in V5 - and our benevolent leader’s stubborn refusal to abandon older versions explains a lot. You can help with taking advantage of the new hardware interface available, and even extend it via the even newer “driver” interface.
Right now I was just using SFizz and Midi Thru so maybe if those are already on stable and work the same way on stable as on testing then I could try the same things again on stable.
It might be beyond the scope of what people working on Zynthian might ever want to attempt, but if I was a company making this and trying to sell it as a product to people then I’d consider making a tutorial program that runs on the device itself, ideally with a voiceover. I know that’s not something other groovebox makers are doing but it’d be innovative. The voiceover would walk the user through a simulated or restricted version of the main program’s UI, saying what buttons to press or knobs to turn to accomplish a few simple tasks and correcting when the wrong button is pressed. The first lesson of it could be run right there in the music store on the demonstration model to show how easy it is to start creating music with the device. This is just an idea I had but I know that’d be a lot of work to make so it might not be worth it.
1 Like
Are you aware of the recent capability added to make tutorials on Zynthian?
See:
if not.
Hi @BenMcLean! Thanks for such long and detailed feedback. This kind of information is very useful in providing information of issues and possible enhanchements. Do remember that Zynthian hardware is sold at very low cost with minimal profit and the software is developed by a community of volunteers. This is not a large company that provides a single, finished product with limited updates. Zynthian is an organically changing entity with very regular development that is visible in the testing branch. The developers aspire to provide a stable release as often as possible (but not as often as we would like) that is as stable as we can make it. There is not a team of testers so the stable tends to have some issues, the most impactful being resolved as soon as we can. We love to hear use cases, feature requests and bug reports. Ideally bugs and features should be reported in the issue tracking system which ensures they are tracked. Stuff said here in the forum can get lost due to the sheer amount of discourse.
As @tunagenes mentions, there is a strong ethos of supporting all models so the UI and backend may have some constraints that seem odd. We do our best to improve UI, e.g. there is more use of the capacitive touch screen in later versions of the software but we need to consider those users who don’t have the same devices, e.g. V4 had 4 encoder/switches and a smaller resistive touchscreen.
Always use a version that you feel confident with. There may be features in unstable versions that you want to use but if you chose to do this then you need to perform extensive tests on that version and avoid updating. Anything other than the Stable version is liable to breaking changes. We develop in the open so that all can see and partake in its progress and test new features or bug fixes early (which differs from most product designers) but this comes with the inherent risk of breaking changes.
Looking at your list of issues:
-
This really looks like insufficient power for the MIDI devices. I would strongly advise a powered hub that you are confident can provide sufficient power for all the devices attached. In the next version we will have a mechanism to associate each physical USB port with a device, i.e. plugging a device into USB socket 1 will present it the same each time. This is particularly useful when you have multiple devices of the same type that cannot otherwise be distinguished by Zynthian. You have some other points in here that I suggest you raise change requests for.
-
We try our upmost to avoid crashes in the stable version. Any crash should be reported in the issue tracking system with details of how to recreate it, the conditions and configuration, etc.
-
I am not familiar with sustain pedal causing issues. There is some clever logic to handle pedals, e.g. when changing active chain for an input configured as Active mode. We test this logic extensively before release. I suggest you try to reproduce the issue then raise a bug report.
-
The UI has grown organically over many years and until (and including) the current stable release has some contraints that make it challenging to redesign. We are making changes to the core software architecture that will allow the UI to be modified more easily (with fewer dependencies on other code) so some of the issues you raise could possibly be considered. I suggest raising change requests or, if there is an area worty of discussion you could open a subject here in the forum. I am the culprit that designed the audio mixer as a horizontally spaced set of vertial strips. This was a choice I made but we did have some discussion about horizontal and vertial layouts. The current layout won because it allows more chains to be presented and controlled due to the aspect ratio of the screen. It also presents a familiar view for many musicians who have used a traditional mixing desk. This may not be the focus of some users but others (including me) use it as the core audio mixer. (I have a multiple channel soundcard and use the Zynthian as an audio mixer for mics, guitar, etc. as well as for internal synths.) The UI does receive some critism but it is very thoughtfully considered for ease of workflow (which trumps good looks - obviously). “Pretty but useless” is a poor cousin to “Ugly but effective”. We try to be somewhere between the two extremes!
Regarding short, bold, long press - this was born from the previous hardware implementations that demaned a lot of UI from very few physical controls. The mechanism remains in place but is used less due to the extra buttons. The ALT button was planned to be used for one purpose but later changed, hence it currently has less use but it does provide some button modifiers which are indicated byt the buttons that change colur when it is pressed, e.g. the transport control buttons control MIDI instead of audio.
The font can be changed using webconf. There are a few fonts to chose from. We limit the quantity of fonts available because we need to test that all work well which is a time consuming task.
Regarding scope of use - I don’t think you are stretching it further or in different ways to how I use mine. The Zynthian is a versatile device that is used by many people in many ways. We do sometimes have to remind the odd user that their usecase is unique and that we don’t have the effort to support such esoteric workflows but mostly we are able to help users to get their device to do what they want.
I may have missed some of your points - there were many - but I hope this (rather long) response puts some context around things and gives your some answers / pointers.
2 Likes
Doesn’t everybody have a Zyncajon…?
Could you do it?
Wasn’t but it looks like great progress.
I’ve started breaking down various problems I was having last night into actionable issues. Here’s two I have come up with so far:
I am thinking I will definitely be writing up more issues from my experience last night soon.
I ordered the powered USB hub from Amazon so I’m going to try re-testing with it once it arrives and then report back.
Would it be better to do my tests on stable or on testing?
Does the “MIDI Thru” chains and the timbrality modes work the same on stable as on testing right now?
About the whole: “We’re a community of volunteers” thing. Yes, I realize that. I totally recognize this is a passion/hobby project for the people working on it and it is not paying their bills. But it sure still frustrates me to no end when what is for me some rather expensive technology isn’t working right.
Is there any way for me to actually check on what the power situation is in the UI?
I am a little suspicious of this because it could mean that any time anything is ever plugged into a different port (like if I swap out a different powered USB hub) then that could break everything. (all my snapshots could be useless) Instead of which physical port, I’d suggest going by the name of the device. Admittedly, that could cause a problem for people who have multiple instances of the same device type plugged in, but it’d be preferable to a setup where plugging in just one thing into the wrong physical port could break everything, especially in the middle of a performance.
Using physical ports to map devices allows us to handle multiple instances of the same device reliably, otherwise there would be no way to identify them and you would have rather random behaviour. I would suggest that it is reasonable to expect a musician to know what hole to stick their plug into. If you plug an electric guitar into the speaker output of a power amp you will get rather hot fingers! A bit of labelling or coloured tape can be very helpful.
Couldn’t it at least fall back on the device name if it’s not found at the expected port?
Yeah, I could do that, except that USB hubs are disposable items by nature. They wear out and get replaced. Swapping them out shouldn’t require starting all over to redo all the snapshots ever made.
Maybe there could be a warning in the UI when a snapshot is loaded without the expected devices present?
(later edit)
Imagine someone steps on my USB hub and it breaks and that there are 18 songs in my band’s repertoire with six chains in each song, with MIDI In and MIDI Out options for each chain. That would mean that, in order to have all the songs ready for next practice after I replace the USB hub, I would need to check 216 different settings to have all the songs ready. What are the odds that I’m going to get all of those right? OK maybe that number is a little high since I almost certainly wouldn’t need every device on every song, but what if this happens on the day of a live show?
Just no. Swapping out the USB hub shouldn’t break all the snapshots. That’s horrible. The snapshots need to be capable of finding all the devices from last time based on their being the same devices, even if all the ports are different.
Swapping the usb hub would not break the snapshots. The 3rd port on the hub connected to the 2nd USB port remains the 3rd port on the hub connected to the 2nd USB port. The device would be recognised the same. The mapping is hierarchical based on hardware port indices.
Oh, OK. That could work then. Thanks for the info.
Anyway, as I told some weeks ago, I would prefer a device-name matching system by default. If you need the physical-port matching, then you could enable from admin menu.
I agree with @BenMcLean that everybody is used to plug USB without worrying about the hole you use. And it works most of times because most of us don’t have repeated devices. Let’s make it work nicely for the most, and let"s add a flag for the few.
Cheers
1 Like
OK so just now, I installed the new powered USB hub. I found the next time I booted that only three out of the four Reface keyboards were being recognized and once again, it wasn’t the same one missing as last time. So I turned the Zynthian off and back on again.
Now all four keyboards were found, but stupidly, the newly found keyboard was selected as an input on every single chain everywhere ever. That is stupid beyond all reason and I refuse to believe there is a good reason for that, although I’m sure there is a reason: it just isn’t good.
So I remade all the chains again, with the correct devices coming in and out and tested it. The MIDI traffic was coming through correctly! Great! I saved that as a subsnapshot. By the way, why is there a difference between a snapshot and a subsnapshot when they are both clearly the exact same thing!? Anyway, apparently all this time, my “snapshot” was really a “subsnapshot” or in other words, my thing was the exact same thing as my other exact same thing with no difference at all discernible to anyone who didn’t write this software. Moving on.
Next, I turned the Zynthian off (I am going through the menu for a safe shutdown every time by the way) and back on again, to test whether or not my assignments can survive a power cycling.
When it finishes booting, I find that all my chains are now randomized. Their ins and outs are now pointing at all different devices seemingly at random: not the ones I selected. What’s even worse is that the UI doesn’t warn me about this at all. If it expects a device to be there when loading a snapshot/subsnapshot/whatever and that device is not there, then I should be getting a dire warning on the screen like this is a horrible emergency, so do I even want to continue trying to load the snapshot/subsnapshot/whatever? Ideally with flashing red and yellow crap all over it to give epileptics some good seizures because missing hardware is a big, big problem. It’s not something that should just be skipped over so that the rest of the band starts playing before the keyboardist realizes that his MIDI controller isn’t controlling anything. But no, it just randomly scrambles where the MIDI traffic goes like as if there were demons inside the box intentionally plotting to ruin everything.
This is unusable. At this point, I don’t know if Zynthian is something that even should be fixed: like maybe this whole thing isn’t actually supposed to work. Like it’s got a destiny, to only work enough to fool the user into thinking it’s working. I’m considering just writing my own MIDI routing script that’ll run on Raspbian for this and not even running Zynthian OS.
Why not trying to figure what is failing and help us to fix it?
If you can write your own script, you could probably help us to fix the issues.
Perhaps you could start taking a look to your snapshot file. Have you tried to inspect the snapshot zss file with a json viewer? It’'s easy to understand and BTW, you will see the difference between snapshot and subsnapshots. Also, you will see how device configuration is saved for each chain. Perhaps you could determine if the issue is saving or restoring.
I would love to help you, but I have not your device setup. My zynthian restore nicely with my device setup.
For helping you, we need your patient and collaboration.
Thanks
1 Like
OK I can probably try that next: examining the snapshot file and looking at changes in it is a good idea.
What about my question about snapshots vs subsnapshots though?