It seems to me that this is a bit exaggerated… There is a fairly wide tolerance in these three types of pressure… but I am sure that soon the Zynthian will work with the power of thought given the developments it has had since I discovered it online… the problem will be when the instruments will also be played with the thought… without a minimum of study and effort to learn, everything loses its charm…
First of all, use complete sentences.
Second, if you really want charm and quirks, try controlling it using only your elbows.
This is a multinational community with many wonderful users whose first language may not be English. Please be courteous when commenting. I am detecting some animosity here and this will not be tolerated.
Good design has a lot of things to balance and it’s very hard to do while making things more awkward than they need to be is unfortunately very easy to do by accident.
It’s inevitably going to take some effort to learn how to use any new system but the fewer quirks and differences from how other similar systems work, the better so the interface can be as intuitive as possible.
About English: OK, don’t mean to criticize here but just for learning’s sake: the ellipsis indicates an incomplete sentence due to words being left out or interrupted. Just one terminal punctuation mark ends a complete sentence.
Just for learning sake, mate - and since here you’re inadvertently treading in waters where some in the forum have some modest skills to trade - I think that @Lanfranco is not resorting here to any metalogism, in order to possibly make his statement more obscure or enigmatic (which happens like in ellipsis by subtraction of syntactic elements to be reconstructed), but - if any - to the metataxis of isocolon (parallel delivery of repeated statements), whose objective is to mimic at syntactic level, in the written language, the flow of consciousness of associative thought, or the enumeration from memory of religious texts, thus providing the enunciation with a more open and less assertive semantic character.
Good point about the short press timing. The Morningstar MC6 handles this by having two modes for short presses that are assignable per-button - the standard one that behaves like you describe, with a bit of delay while it waits for a double-press, and a timing-critical one that has no delay but also disables double-press for that button. Works very well but definitely not a practical approach for something like the Zynthian. There would have to be an option to manually toggle every any parameter between normal and precision modes like the MC6 buttons, and that would either mean more hassle and room for error for the end user, or a lot more work for the devs building and maintaining default settings for every parameter of every engine. I can’t think of any other way that it would work for time-critical stuff, and it seems like it would just snowball into too much work and unnecessary complexity to be worth considering.
Getting used to the way it works now is a lot more practical and it comes pretty quickly, or at least it did for me. Zynthian users are musicians, internalizing the timing shouldn’t be that big a hurdle.
I’ve got no issue with the way it functions now, so I probably won’t submit a feature request myself. Just tossed it out as something that might satisfy everyone and didn’t think of the timing problem. If anyone else wants to run with the idea, go for it!
Maybe four small, three-state meters of some kind in the top bar that would show the length of up to four simultaneous presses? Perhaps something like this:
(blank/hidden) = no press
• (small, filled circle) = short press
o (medium, empty circle) = bold press (large, filled circle) = long press
It would be unobtrusive, color and language neutral, and could track up to four simultaneous presses (seems like plenty to me). The actual shapes could be left to the people with graphic design experience to figure out for maximum distinguishability and accessibility concerns. Putting them in the top bar would make them layout-agnostic and keep them from being covered up when using the touchscreen.
I considered this but, as you realised, there is the question of how many? There are 24 switches on a V5 and most of us have about 10 fingers (or elbows) to prod things with. The topbar does seem like a reasobable location although it is quite crowded and is precious space. One might argue that such a gui element may only require space whilst a button is being pressed which may decrease its impact on topbar occupation. (This adds another complexity - but let the programmer worry about that!)
I am not keen on 4 indications that get randomly assigned to the first 4 pressed buttons. Maybe a single indication that considers multiple controls? Maybe it uses the first control only or it has 4 states, each with an OR logic for any pressed buttons, e.g.
OFF - No buttons pressed.
Small circle - At least one button is short pressed.
Medium ring - At least one button is bold pressed.
Large ring - At least one button is long pressed.
The OFF state completely hides the indication and has (almost) no impact on CPU.
A button press would show the indication in its small cirlce state. There is CPU required to detect and GPU to show. (Not really GPU but I will use it to indicate some overhead required by the GUI.)
A button held for the bold duration would show a ring. There is additional CPU required for this because we currently do not actively detect this threshold but instead, react to the release action. There is some additional GPU.
A button held for long duration will trigger its operation. I don’t think we need a visual indication for this because the user feedback is the required action occuring, e.g. ALL NOTES OFF. This may already have a visual indication. There is a little GPU required to clear the ring indication. (Well, actually CPU to clear the bold flag for that switch and then GPU if all bold flags are clear.)
Another option could be to represent the push on the control most relevant to the push, e.g. the controller widget next to a rotary encoder (if it exists) or the LED within a button. This may be considered more intuitive in that the indication has physical registration with the action but has issues like, some actions don’t have associated gui elements and pressing a button or control may (probably) obscures the indication.
Anyway - I think this discussion has reached a conclusion that there is some desire for user feedback for the different button press states and that there is opinion on how that might be achieved. There has also been some prelimary consideration of implementation. This needs to move to the issue tracker. Nothing will happen if it stays here. When a feature request is rasied in the issue tracker, we will properly triage the request which includes considering whether we want to implmenet it, how it might impact the system and where in our priorities it sits.
@BenMcLean please add a feature request if you still feel this would be beneficial. You just need to have a GitHub acount then follow the link which will create a template for you to complete. (Hint: Use kind and positive language in the feature request. You want the developers to want to do this so don’t use language such as, “awful in the extreme”.)
Check the ticket for info but I have implemented this in dev. It awaits approval from our lord and master. It simply shows an indication when any button has been pressed longer than the short period and shorter than the long period. It currently replaces the health indicator in the top right with a “B” (but that might change). It retains the health colour, i.e. green when healthy, orange when getting a bit hot or low voltage and red when xrun or over temp / under voltage. I reckon this implementation works quite well. We don’t need to be told we have pressed the button (short) and are already notified when the long action occurs so we must need an indication during the bold period. Those really keen could test it by switching zynthian-ui to 1346/indicate_bold branch but you are probably mostly normal people so willing to wait until it hits a more stable branch.
That’s what I spent the most time thinking about before I posted and I couldn’t really think of anything that was totally satisfactory. A single indicator like you’re describing was what I was leanign toward but in the end I thought four was a good compromise since the UI is designed around the four encoders on the official hardware already, and four presses is the most you could comfortably do with one hand. I was thinking showing the four most recently pressed buttons, like how oldest-note voice stealing on synthesizers, would be the most meaningful because if more than four presses were active the state of the first/oldest indicator would also show the MINIMUM state of any older presses that were still active no longer displayed.
Here’s what I mean, using numbers for lit indicators to show which press each one is displaying (not their state). I’ll label the four indicator locations A, B, C, D. Hopefully it makes sense, I’ll describe it in a few different way.
One button pressed:
ABCD
1
A second button added:
ABCD
12
Two more added:
ABCD
1234
A fifth added:
ABCD
2345
The active indicators always show the most recently initiated presses, ordered oldest to newest. When held presses beyond four are added A is dropped, B-D are shifted left into A-C, and the newest press appears in D. So with 8 simultaneous presses, 5-8 will be displayed by indicators A-D. Because 5-8 are the most recent, we know that the state all presses not being displayed is at least equal to the state of the press displayed in location A. So in my example, if there are 8 presses active and location A contains a bold press indicator we know that presses 1-4 (which were initiated before 5) will always be either bold or long.
In terms of visual simplicity I definitely prefer a single indicator, but I have a feeling it wouldn’t quite show enough information to be a robust solution.
Or we could get tricky and make the number of indicators a user setting (only limited by the amount of free space available)
I really tip my head seeing so much effort in solving a problem which is presented in such an inadequate way. I also don’t see any problem in the current behaviour, because it’s configurable and the 2 second default for long press is really quite long. I mean like “I would not even think about pressing it so long if I didn’t know it” long. The bold press time is quite intuitive. The only thing I am missing in these V5 virtual buttons (which I really enjoy) is the long press action being displayed on the button.
For the record I’m totally fine with the way it works now, but I appreciate that some people could benefit from a visual indicator and it’s fun design challenge to think about. Maybe less fun if I was the one who would actually have to implement it, though.
It’s always good to chew over this sort of area. This is how systems develop.
It’s probably ANOTHER flag in admin to turn it all on and off, possibly as part of accessibility functionality.
What I would add is a debug mode that responds to every event that comes in over these various channels. It makes for a very useful functionality test when chasing down hardware faults in these areas particularly with respect to none official kits, in that it can be quickly ascertained if an expected response has been received, removing much of the did it didn’t sort of questions when first testing a new hardware addition.
Completely unrelated to the subject of this thread, but for some reason your debug mode suggestion made me think how handy it could be to have some kind of “chain mappings” matrix. I hate to drop another feature request, but the more I think about how useful it would be for the way I work (changing parameter mappings during performance the way a modular synthesist might patch modulation signals as part of their performance), I think I’m going to have to write something up and submit it later this week.
I sort of feel that something like this has been mentioned, by Riban, not so long ago. I dont know for sure that i’m right, and also dont know if it was just mentioned as a thought or upcoming feature or what.
I’ve got a couple paragraphs roughed out now, I’ll finish writing up my ideas about it this evening and maybe make some kind of visual mockup. Don’t want to derail this thread anymore, though!
(large, filled circle) = long press