That’s what I was looking for only I didn’t see that offer you mentioned in the UI.
When saving a snapshot on the Zynthian, I’m not inclined to go find a networked computer just to type in a few characters of a name so I can remember what I did so it’s good there’s an option to name it right there in the UI. Thanks.
OMNI is good to have.
Another oddity I noticed was that there were two Salamander Piano options … and they looked like they were the same. Maybe there were different characters on the end that were cut off? So … how to see the full names of things in the UI?
The last really important thing for me is getting the presets for the four Reface keyboards to save and load on the Zynthian.
It would be fine for each configuration of presets for this external gear to be a snapshot that just sends the presets once when the snapshot loads, and if I want them sent again, I could just load the snapshot again. I’d have one “base” snapshot which doesn’t send presets at all for just playing around, and also a snapshot which adds the presets for each song when it comes to be performance time. But having the option to also re-send just the one chain would be nice. I will be trying out the sending capability on the testing branches soon.
But I’m also really going to need the capability to not just load presets from the Zynthian’s micro SD card and transmit them out to the Refaces but also to save them from the Refaces onto the Zynthian’s micro SD card. I know there are a good number of third party softwares out there which will import a preset from the Reface keyboards onto a computer to make a .syx file. Would it help for getting this feature into Zynthian OS if I figured out where they do this in their source code and linked that?
My thought would be that this feature to save presets from the external gear onto the micro SD card would be an option in the menu for the same MIDI chain that sends out the preset, like it would say, “Import preset from external gear” or something like that and have another option to “Save preset” maybe.
Also, about my samba server idea. I haven’t tried this yet, but apparently using sshfs-win with one of its GUI front-ends on the Windows side might potentially accomplish what I need.
So … just now, I tried to have the first practice session with my band where I tried to use the Zynthian, like, at all, for anything. It didn’t go well. I constantly had a multitude of problems which didn’t show up in my earlier testing and only manifested when the band was here, wasting everybody’s time. Some of the problems might be hardware related, but I am feeling pretty confident that at least some of them are the software. This was all on the testing branch, but not updated since last time earlier in the thread since I had tested on that version. I’ll try to remember what the problems were and list them:
MIDI USB: Some of my external MIDI gear wouldn’t show up on the Zynthian and, most frustratingly, it wouldn’t consistently be the same external gear missing. Like, I would try to plug in all the gear before turning the Zynthian on, and all the gear would show up except one. I’d try fiddling with it, like reseating the USB cable and power cycling everything to fix that, but on the next power cycle, that device would work but another one would drop. Of course, given my luck, this only happens when somebody else is here ready to practice and didn’t happen in my test the previous week when they weren’t here. I think part of what might be going on is that there might be too many devices plugged in for the Raspberry PI to handle power-wise, so I plan to supplement with a powered USB hub to fix that. However, that doesn’t let the Zynthian OS off the hook, because it was forgetting the MIDI in and out settings of my various chains every time anything was unplugged or replugged AND the MIDI device list wouldn’t stay in the same order. Of course, at the absolute minimum, the MIDI device list should always have a proper alphanumeric sort, obviously. What kind of crazyland does anyone live in where they would actually want to be guessing what order the list goes in, being different all the time!? That’s nuts! Fix it please. Not only should it remember what gear was selected when things get unplugged and replugged, but the list of options should all appear alphanumeric sorted every time all the time and I should be able to set the default for any/all new MIDI input devices to MULTI so I’m not left wondering what’s going on when I get other weird and unexpected behavior from their being set to something else.
Crashing: Even a few times when I got most of the other stuff working, the GUI and SFizz flat out crashed several times. I had two SFizz chains going, one with Salamander Piano and another with a bass guitar sound, along with four MIDI Thru chains, so a total of six chains. I had another guy playing the piano on my Casio keyboard on channel 1 while I tried to play bass guitar on my Vortex on channel 6. That seemed to work only for a few seconds at a time with both instruments going before a crash would happen, like the GUI would freeze but MIDI notes on one of the chains would still output sound, or the GUI would appear fine, showing the green line go up when we pressed keys, but the sound would stop. What!? I suppose you’ll want crash reports right? I’d need to know the right procedure to acquire and transmit those if they’d help and this isn’t already a known issue. (later edit: I realized after the first crash that I had accidentally left the VNC server on so that one’s on me, but subsequent crashes had it turned off)
Sustain pedal MIDI panic: When playing Salamander Piano, strange skips would happen, like notes suddenly going silent when it seemed like they shouldn’t. It is like as if letting up on the sustain pedal was sending a MIDI panic signal instead of just … letting up on sustain. This issue is a little more subtle than the others and I didn’t run into it as much because of the above earlier issues.
UI design madness: This UI is quite bad: like, the sort of thing that would make a really entertaining tantacrul video. OK, I thought of one positive: There is usually enough contrast between the grey background and the white text for the white text to be legible. I’ve seen worse color choices. So there’s that on the positive side. But why are we ever doing long presses on a device that has a metric crap ton of mostly unused physical buttons on it? Why, with so many buttons, is there not a dedicated DELETE button to delete things? If we must use long presses, (which is horrible when we have so many physical buttons available that we could use instead) why isn’t there at least visual feedback on the screen (like a bar filling up) when doing a long press so that I can tell how long I should press to get the desired effect? Why does the “Alt” button do nothing at all except change the LED light color? Why does selecting a snapshot with a short press seem to do nothing at all and going into the menu of the snapshot with a long press not have an obvious “Load” option to load the snapshot? And of course, like I’ve mentioned before, there’s the sideways text. The whole mixer screen just shouldn’t be vertical because sideways text is crazy. It looks like someone must have done a ton of extra work to make the mixer screen vertical even though a horizontal mixer screen would have been easier to use and easier to program. Zynthian isn’t Propellerhead’s Reason so it doesn’t need the mixer screen to imitate the layout of physical hardware mixers, which are confusing IRL anyway. There are just so many counterintuitive things going on with this UI, I can’t even list them all. Couldn’t we at least get a chart of the physical buttons on the device and how they map to keys I can press in the VNC session? I feel like the Zynthian UI is driving me mad.
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.
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.
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.