More questions about footswitches

[jkrafft]

I have more questions regarding footswitches configuration:
- Would it be possible to send midi CC (or preset change) when longpressing a footswitch (like for bypass)
- would it be possible to send midi CC (or bypass or preset change) on dual footswitch (pressing footswitch 1+2 send midi cc or does a preset change or save current pedalboard/snapshot)

The goal here would be to have a configuration like that:
 footswitches:
  - id: 0
    debounce_input: 0
    midi_CC: 60
    bypass: LEFT
    preset: UP
  - id: 1
    debounce_input: 1
    midi_CC: 61
    preset: DOWN
  - id: 2
    debounce_input: 2
    midi_CC: 62
    longpress: 72
  - id: 3
    debounce_input: 3
    midi_CC: 63
    longpress: 73
  - id: 4
    debounce_input: 4
    midi_CC: 64
    longpress: 74
  - id: 5
    debounce_input: 2+3
    midi_CC: 85
    longpress: 95
  - id: 6
    debounce_input: 3+4
    midi_CC: 86
    longpress: 96
  - id: 7
    debounce_input: 0+4
    midi_CC: 87
    longpress: do_a_barrel_roll

You get the idea.
Would that be possible ?

[Randall (Admin)]

Another good one!

Longpress, yes.  I've long thought about adding something like that for my own purposes.  Footswitch-Chords, maybe.  Simultaneous, asynchronous event handling can be somewhat harry, and specification gets sticky too.  But it does allow for a few footswitches to go a long way, so it's worth considering.

Also considering these:
- MIDI Program Change messages
- toggle between midi-CC values other than the default 0 and 127
- multiple midi msgs per click (CC61 + CC62)

To be most flexible, any action (CC, PC, bypass, preset, etc.) could be triggered by any event (click, longpress or chord).  So I'm thinking additional yaml levels might be needed.


footswitches:
- id: 0
  debounce_input: 0
  on_click:
    # toggle CC60 between 45 and 46 (instead of the default 0 and 127)
    midi_CC:
      CC: 60
      value_off: 45
      value_on: 46
    preset: UP
  on_longpress:
    bypass: LEFT
- id: 1
  debounce_input: 1
  on_click:
    midi_PC: 4
  on_longpress:
    # multiple CC's, same press, toggle between default 0 and 127
    - midi_CC: 61
    - midi_CC: 62
# For backward compatibility, still need to support this which assumes the click event
- id: 2
  debounce_input: 2
  midi_CC: 70
  bypass: LEFT
  preset: DOWN


The syntax/indention is more finicky, and backward compatibility somewhat trickier, but probably best to define it broadly now instead of bolting on one use case at a time.  I suppose adding "on_click" maybe isn't needed if backward compatibility already assumes on-click, but it does make things more symmetrical when on_longpress is added.   

I understand your intent behind the chord definition (eg. 2+3) but I'm not so fond of there being footswitch objects which are more like virtual footswitches.  The count doesn't match the number of physical footswitches.  I'd be more likely to create a new object type.  But again, chords make a lot of code a lot more complex.  Would require some deep thought, code analysis and trials.

Would the above allow you to do most of what you're wanting to do?

[jkrafft]

Another good one!

I'm delighted that you don't mind being flooded with my forum's messages.

Longpress, yes.  I've long thought about adding something like that for my own purposes.  Footswitch-Chords, maybe.  Simultaneous, asynchronous event handling can be somewhat harry, and specification gets sticky too.  But it does allow for a few footswitches to go a long way, so it's worth considering.

Also considering these:
- MIDI Program Change messages
- toggle between midi-CC values other than the default 0 and 127
- multiple midi msgs per click (CC61 + CC62)

To be most flexible, any action (CC, PC, bypass, preset, etc.) could be triggered by any event (click, longpress or chord).  So I'm thinking additional yaml levels might be needed.

Footswitch-chords is something more complicated to handle for sure, and many people are not that fond of tap dancing, even more when you have to tap several switches at once. However, I have a Mooer preamp live that make a pretty good use of those making it really user friendly with only 4 footswitches.
About midi ccs, that's great, I didn't think about multiple midi msgs, but it would definatly be very useful as you can't assign the same midi cc to multiple objects in MODEP. Toggle is also a good improvement.

I understand your intent behind the chord definition (eg. 2+3) but I'm not so fond of there being footswitch objects which are more like virtual footswitches.  The count doesn't match the number of physical footswitches.  I'd be more likely to create a new object type.  But again, chords make a lot of code a lot more complex.  Would require some deep thought, code analysis and trials.

Yes it would probably be more like:

Code: [Select]

- virtual_debounce_input: 5
    debounce_input: 2
    debounce_input: 3
- id: 5
    debounce_input: 5
    midi_CC: 85

Would the above allow you to do most of what you're wanting to do?

Yes that would cover most of it and expanded greatly the possibilities, especially with fewer footswitches.
As always, I see that you already had some thoughts on that matter, that's really fantastic.

Keep up the awesome job!

[ReneMadeira]

Hello there,
Thanks Randall for the awesome project!
The forum is great as there many doubts already solved.
This particular is one that I had when reading the wiki, but I am not sure what is implemented since it is not in the docs.
For what I understand the Randall's answer has already been implemented, right?
What about dual footswitch press, is it implemented too?
I have another question that I couldn't understand very well: In the code below, will the footswitch trigger all 3 actions at the same time? If so, wouldn't that be confusing?

Code: [Select]

- id: 2
  debounce_input: 2
  midi_CC: 70
  bypass: LEFT
  preset: DOWN

[Randall (Admin)]

The YML proposed in this thread has not been finalized or implemented yet.

What is available today is shown in the Wiki:
https://www.treefallsound.com/wiki/doku.php?id=configuration_file_guide#objects

So no switch "chords" (dual press), PC messages, value specification, etc.

MIDI and control features seem to be the most requested lately, so such enhancements will likely become available eventually, but not yet.  The next revision needs to be well planned to accommodate a wide variety of use cases.  I'll try to set up a wiki page for discussion and specification soon.  I'll post a link to this thread.

In the meantime, to answer your question about that YML footwitch definition: The bypass action is currently hardcoded to be on longpress (more than a half second).  Preset and midi_CC functions would be on short click.  A new YML specification should allow the end user to assign any action (CC, PC, bypass, preset, etc.) to any event (click, longpress, chord, etc.)

[benh]

From an implementation perspective, I wonder if it's worth splitting the footswitch object which sends internal "events" (up/down) from the object that translates these into actions/MIDI. This would allow to have such action objects source multiple footswitches or example.

There's a bit of a trick here. To handle chords, we would need the action/policy object to receive both foot down and foot up events. Those aren't really synchronized so we would need to keep track that a given pair are both down for at least a minimum amount of time.

However, currently, we only really send events on "up" due to how we do the long vs short handling.

The leads to a couple of question:

 - What should be the behaviour of "chords" if one of the two switches does a short press and the other one a long press.
 - Is the current behaviour that great ? ie, the user might expect an action to happen as soon as a switch is pressed, not when it's released, though that would make dealing with long press difficult

The least disruptive way I can think of right now to implement chords would be to move the MIDI message logic out of the footswitch to the handler (or a separate object), and have the footswitch send event tuples (event, timestamp) to it, including "down" events.

That way, on an "up" event on a switch that is part of a chord, the handler can check if the other switch is down, and treat that as a chord. Otherwise, treat that as a normal singleton event.

We could move that to a separate object "event mapper", as well rather than the handler.

[timothyd4y]

Thanks for posting your experiences with getting buttons configured. These posts helped me get my PiStomp customized to fit better into my pedalboard.