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
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
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?
When you examine the snapshot,you will see that subsnapshots are inside a snapshot. ZS3 saves part of the state, but not all state. ZS3 doesn’t include chain layout nor sequences, but it includes routing, engine parameters and mixer status.
You can have many ZS3 inside a snapshot.
BTW, could you confirm the issues when restoring midi output routing only? I mean, is midi input device config restored ok? I’ve some idea …
Regatds
It wasn’t just output being scrambled: it was input also.
Maybe this convoluted idea of snapshots vs subsnapshots might be why things aren’t saving and loading the way I expect. It seems really unnecessary to separate out saving the state into categories the end user can’t actually see or understand.
How do I just save and load the entire state? Exact button presses and knobs to just save and load the entire state from the main mixer screen please.
@BenMcLean have you read all of the user guides on the wiki? Read both the V4 & V5 guides because V5 documentation is not yet complete. Snapshots (full state) and ZS3 (like patches) are described in those documents. There is a substantial difference between these two and it is documented so you don’t need to be a developer of delve into configuration to find out this information.
It sounds like you are one of the few that @jofemodo mentioned who will actually benefit from the USB port device mapping feature in the next version, i.e. you have many of the same device connected. Previously you stated your sceptism of having USB devices identified by their port number but how else is Zynthian going to know which of your many Reface devices is which? Its like talking to a pair of identical twins. You may remember which is which during a conversation but the next time you meet them you need to identify them again.
Also, I amy be repeating myself here but remember that if you want to live on the bleeding edge of development then expect to bleed. Users who need a consistent behaviour elect to use the stable version and accept they must wait until the next update for the new goodness. We continue to warn users who use a development branch (like testing) that this comes with a risk of unexpected or undesirable behaviour and we always recommend using a different microSD card for stable and testing to keep the two isolated / protected. We are really pleased to have users willing to try out the new features and give critical and constructive feedback but they do so with the understanding that these versions are not production ready. If you want a stable platform then use the stable release. Users who use the stable release and find issues are quite justified to feel agrieved if they find an issue that is substantial (to the core workflows) and not resolved promptly.
Save a snapshot. This is the full state of the machine.
There are many musicians using Zynthian for production. I feel this comment may be a bit harsh.
It is possible to power off the unit with a long press of the top right encoder (on V5). This behaviour is configurable in webconf HARDWARE->Wiring (enable Advanced view).
Its great to hear you have the skills to delve in and understand / help resolve issues. Everything here is open so there are few barriers and there is a lot written in documentation on the wiki, in the source code on GitHub and here in the forum that can help in such endevours.
Indeed we are blessed / cursed by the ubiquity of USB and its perceived simplicity of plug-and-play. (Yeah! Try getting that plug in the right way before the third attemp… Clue - the split in the metal goes on the bottom - except on Zynthian because we mount the board upside down!!! 
) This means that we expect to be able to plug any USB device into any USB port and it magiacally works! As Ben is finding out, there can be challenges in making this happen but as you say, we did agree that we would have default behaviour to not be physical port specific, i.e. use name matching only which will result in Ben’s problem if you don’t switch scheme. (I may have been hoping you had forgotten that 
.) So it is back in my todo-list to add a switch between the modes of operation.
BTW - physical port mapping is not implemented in stable or testing, only in chain manager branch hence why Ben is probably suffering (apparently) random allocation of device mapping. I believe Ben has several of the same USB device connected and with name matching only (as implemented in stable / testing) these devices are being detected differently each time. So ironically it is the very thing that Ben and Jofe have identified as the enemy actually being the saviour to his problem. 
I fancy that the next version will provide substantial improvement to the issues mentioned here.
Zynthian works solidly for my gigs …
Hi @BenMcLean !
Please, i kindly ask you to moderate your tone and reshape your frustration into something productive.
First, i would like to apologize because you are probably right and perhaps stable is not being really stable when managing complex MIDI routing cases. And it’s my fault, but it has an explanation.
When you firstly explained your use case to the community, i felt really excited because i perceived it as a the perfect challenge for the new routing capabilities we are developing for zynthian.
Although we are focused in the next “chain_manager”, i decided to “move” some of this new capabilities to testing, and later to stable, so YOU could play with them. I decided to do so because i thought it would improve things and it wouldn’t affect normal behaviour or “standard use-cases”. And indeed, nobody (excepting you) is complaining too much about it. Also, i hoped to get useful feedback, what we are getting too, except for the “tone”.
The problem is that the implementation of this new MIDI routing capabilities in the current testing/stable branches is “quite tricky” and it’s probably flawed in different ways. I didn’t explain this before and it’s my fault.
So this is my advice:
If you want to help us to improve and fix the issues in current stable/testing branches, please, be kind and empathic. Don’t throw us your frustration because it’s unpleasant and don’t encourage us to help you. We love what we do and we love to love. Be empathic, my friend.
If you don’t, i would recommend you wait until the “chain_manager” branch is in production, hopefully in the next stable release.
Thanks for your understanding,
A certain degree of testing of this premise in chain_manager went on with a couple of DUO Pianos’ when last I visited @riban.
I don’t have four of the same keyboard model connected: I have four different models with different features from the same brand name. So while their names all start with “reface” this would be followed by the specific model on each one. (“reface cp”, “reface cs”, “reface dx”, “reface yc”) Identifying devices by name instead of by port should work for that setup – and probably for the vast majority of use cases out there since connecting more than one of the exact same device is probably going to be an extremely rare use case. I really do think it should be going by device name and should show a warning popup when loading a snapshot that expects a device to be there and doesn’t find it.
When it comes to the documentation, what the wiki says on the v5 page about stage and multitimbral modes is no longer accurate and the v5 documentation doesn’t actually describe snapshots or the difference between a snapshot and a subsnapshot. (something I’m still not convinced even makes sense) It does mention them a few times in passing in other sections but doesn’t actually explain them. If you say the older v1-v4 page actually explains this then I’ll read that next.
When I said “This is unusable” I meant I can’t depend on it to route my MIDI traffic for band practice for the time being. I’m going to be pursuing some other solution for our next band practice on Sunday and for future band practices for now. Doesn’t mean I won’t also still participate in trying to make this thing better but I am thinking I’m going to have to make that a much lower priority with no expectation of it actually doing anything for me in the near future.
@jofemodo Sorry about my tone in some of this but that experience of setting it up, seeing it seem to work during my test, then having it fail when I try to use it for band practice even though I tested ahead of time was more than a little draining to my mental health.
If I was really thinking of myself as a tester on the Zynthian OS rather than as just a user then I really shouldn’t have been depending on it to do anything. I should have at least had some kind of backup plan: like that Raspberry Pi Zero I was using before I bought a Zynthian kit. For now, I think that Pi Zero is going to be my production machine, while the Zynthian’s something I can sort of fiddle around with but not consider ready to actually produce anything with for now.
Okay - I misunderstood. In that case a mode that identifies by device name will work fine. FYI: I have already implemented a configuration (in our dev branch) that switches between mapping by name alone and by MIDI port + name. I have also sorted the USB MIDI devices alphabetically. So - in the future when we move to this version, everyone will be happy 
(well, hopefully a little happier).
Great! That sounds like exactly what I need here and I can help test it: just not depend on it for now at least.
That is great! We should be moving our testing branch to this soon so you may not need to wait too long.
Also I have an ammendment to some info I gave before. The shutdown command for the V5 is actually long hold of the OPT/ADMIN button but this does not give a confirmation dialog (like it does on the V4) - it just turns off the machine. I try to avoid it but we can also just throw the power switch. The way Zynthian works it avoids writing to internal storage as much as possible so we tend to avoid corrupted filesystems that other RPi OS suffer - although it is still a possibility.
I hate to nitpick here but I had posted a recommendation on the sorting algorithm on the Github issue:
Seems like that’d be good to get that kind of more advanced comparison function used for the sort because simple alphabetical sort is usually going by unicode (or ascii) character value, which results in “ABCabc” where what we’d actually want is “AaBbCc”.
But I don’t want to make the perfect the enemy of the good here. Just a suggestion. 
If you let me know which programming language then I could find out what to use in it.
This was a quick-ish implementation and uses Python3’s sorted function that - as you fear - sorts poorly, but it is better than nothing - maybe!
If you want to provide a better sort algorithm that would be good. I create a list of tuples. Each tuple consists of (name, id). I then iterate through sorted(tuple_name) to add the USB devices to the view. I currently only do this with USB devices as they are the most likely to be dynamic. Internal devices have a fixed (non-alphabetical) order that puts the most used at the top. Network connections are also in a fixed order (I could make this alphabetical because they are probably equally likely to be used and there are only three of them - although I anticpate each protocol supporting multipe connections in the future). BLE are also not yet sorted but that is because it looked more challenging, no one uses it yet and I was supposed to be doing other stuff… It should probably be sorted the same as the USB devices. The devices are spearated into groups in the list under titles:
I am sure there will be a better sort algorithm. I leave it as homework for the class…
On the sorting algorithm to use, it appears that this Stack Overflow answer is the best one for Python 3: sorting - How to sort text strings in Python case-insensitively AND deterministically - Stack Overflow
So you’d replace sorted(tuple_name) with sorted(sorted(tuple_name), key=str.casefold). Yes, it sorts twice, but that appears to be faster than using a more advanced key function would be.
It doesn’t treat groups of digits as numbers like would be ideal but it’s probably the best without importing some other Python library just for this.
Separating out the list by device type is probably fine.
Thanks for working on this!
I posted another Github issue based on my experience from Tuesday: