I’m somewhat “relieved” of reading your thoughts and reports on arches because it moves the discussion on another territory, that is not ‘bug report and fixing’ but usability and ‘feeling’ with the instruments. I know that there are also more ‘technical’ issues (partly solved AFAIK) but It’s important for us to draw a line.
Nonetheless this is as important as the ‘robustness’ of the product and so it’s important for me to discuss a little more about this:
I’ve done two or three fair trades in the first part of the year (esp. following v1.0.0) and found that the first two sentiments that I’ve had from people looking at and testing the arches were: WOW Awesome!! (1st) and then Fright! (2nd). The second one was appearing as I recounted the many things that (arches) can do, and the fact that those are concurrent. The persons whom I spoke with were curious about ‘configurabiity’ of the product and as I was entering the tiny details they asked me about configuration interface needed for this task. Obviously it’s complicated. Not buchla-complicated (use of ‘mnemonic codes’ instead of funtion names etc..) but complex nonetheless. In the end a 1 inch OLED screen and a map of the surface is a limited set of elements to play with…
Trying to put all those functions into a stand alone unit called for two main compromises: The first was to avoid total configurability, especially introducing the concept of a limited set of keyboards. The second one was UI limitations.
So, to start with, the user have only a finite set of keyboards to instantiate, each of those well described in the manual.
You cannot ‘move’ an element between keyboards, for example putting a slider of KB4 as a 9th button of KB1. As far as I understood this is one of your requests in the message posted above. This is not a technical limitation but it serves the purpose to maintain ‘configurability’ on a “complex but not impossible” task. As you may have seen, the third preset have the entire arches working as single elements. Every slider, button and pads output their CV and gates (and also midi CC) independently.
The keyboard exists as long as none of the elements involved is set to ‘FREE’ type. For us it won’t make sense to have a three-elements keyboard and then single free elements embedded into that keyboard. This will augment the perceptive chaos of the surface, as you won’t have NO WAY in recalling what element does what.
Regarding the configuration flow I’m interested in having an in-depth discussion. I don’t really understand the ‘sequence’ you have in mind so I really would like to have a chat about this, It’s much more direct and I will have a system at hand to simulate (and obviously Samuele, the firmware guy, at hand!)
Or, if your time-schedule is limited, I will also appreciate a small description of the ‘scenario’ that for you is more critical with respect to ‘quickly setup’ the machine. It’s totally possible that the way you intended to use (arches) at the beginning was considered marginal by the dev team (me first!!!).
As a last point, we can program the modification to the naming of preset files but it would take a bit so I really would like to schedule this after we have worked on the other points!
Awaiting your feedback!!