[Feature Suggestion]


Sure. Bloating up GUI as complexity increases is a dead end street and opting for "programming language" is so much better. I believe that offering simple basic operation but also complex abilities behind the scene is beneficial for all parties. In a way that's what MIDI is for most devices with a simple limited UI/UX. With a programming language, the complex software abilities can create a free secondary market in which specialists expand functionality by offering free or paid presets/scripts/libraries which increases the appeal of the product thus growing the economy to support it. So the basic user will have basic functionality and if he wants more he can go through the learning curve or get professional expansions from the secondary market. The FCB1010 is certainly not an open architecture device but having it here for decades and still growing strong is basically case in point as it is a cheap robust simple fully functional hardware device and then vastly expandable with the UnO that keeps it up to date thus creating a flourishing community.

As for the suggested features. I see what you mean with the unblocking wait. I wasn't thinking about actions queues and frankly this was an offshoot of another user post that described activating a smoke machine  so I don't think there are many use cases that need it.

However, as for the Long Press, as you said the Up Down having a long press to scroll. It is of use to page around few banks with short presses, but long press Up/Down scrolling is not that useful in navigating a 0-199 banks space. I believe this is why a long press on Up / Down to enable 10 direct banks (instead of just one that also requires sacrificing footswitch #10), and being able to directly go to each of banks 0-199 will be of much more use. Also having an ability to define long press triggers for stomps so that they have short and long press actions opens up a lot of possibilities and those I think are not complicated to implement.

[Sorry for the misplacing. I just realized that this reply was posted as a new subject so I move it here and delete the wrong one :-)]


Oh, I didn't think of a non blocking use for myself but I saw that another user defined a footswitch on his FCB1010 UnO2 to turn on the relay Switch1 for 10 seconds (with a wait of course) in order to activate a smoke machine. However if he presses this smoke machine footswitch he can't do anything until the 10 seconds pass so he has to coordinate his act around this limitation.
I don't know if there are a lot of such use cases but code wise it should be only a small modification.

Jack Fenton

For users that don't want a programming language I think UNO 1.0.4 and the editor are super!  I guess you will never please everyone, but I'm happy !


It seems like most feature requests are things which were available in our earlier Gordius Little Giant controllers, and deliberately left out to keep the complexity down
For the delay command in the Little Giant you had the choice between a blocking delay, non-blocking delay, long-press delay, long-release delay, (absolute or clock-synced delay) ... 
I remember it was quite complex for the user to get it all programmed correctly. Same for UnO2: everything which can be linked to a switch (preset, effect or trigger) already has a "short press" action, so you would have to do special tricks to combine that with a long-press action.
The up/down switches in UnO2 already have a long press action, which is too obvious to abandon (start auto-scrolling banks up or down)
Implementing a non-blocking wait is easy, but of course the complexity is that you want to do other things during a non-blocking wait. At the end of the wait the controller needs to process the rest of the original preset contents, while you might already have activated another preset in the mean time, so which one is active then? and so on... 

I did introduce this "programming language" concept, because it allowed adding more features without making the editor more bloated (I remember the hundreds of checkboxes and dropdownboxes in the LittleGiant editor, growing after each firmware release) , but now I'm convinced that an ever growing command set might be as bad. I already get plenty of complaints about the learning curve and stuff like "this sucks, when will you release a graphical editor"... (never!)  


I can see a good use for long press detection - the one you mentioned would be very nice to have.  But I don't see any use for a non-blocking Wait.  Could you give an example where it would be useful?


[Long Press] Thanks so much. As a guitar player I was considering other devices and frustrated by their limitations and high price. I was not decisive about the FCB1010 but as I came across UnO, as a programmer I was immediately sold. It hasn't arrived yet but I already read the manual. Therefore I was wondering in case there will be versions releases, if I may put forward few suggestions which I think would not be complicated to implement and will expand the functionality considerably. So here is for all its worth:
  1. Long press - as I understand the UnO2 identifies switch press and switch release. I think it would be quite easy to be able to identify a long press too. This would enable reacting to long pressing a footswitch and thus having all the footswitches that are not assigned as triggers free to make an additional action. e.g. this can enable a mode where a long press on say the Down goes to the direct bank and long press Up expects the next presses to be a bank number. Or a long press on any of the 1 to 10 footswitches can go to a matching direct bank (direct bank 1, direct bank 2...) or fire an extended desired action or whatever.
  2. I noticed the Wait command is blocking. I believe it would be better if it is made asynchronous by moving the timestamp check to the main loop with a variable so it wouldn't block other actions. I think that this limitation is also in the "While".