Pirate-MIDI / Pirate-MIDI-BridgeOS

Documenting Bugs & Issues - Public Collaboration
10 stars 2 forks source link

Secondary Hold Toggle triggers inconsistently on hold vs hold-release #192

Closed TheGuacamoleXplosion closed 3 months ago

TheGuacamoleXplosion commented 1 year ago

BRIDGE4 Firmware 1.3.1 Hardware 1.0.1 Editor on Chrome/Win10

TL;DR: The SAME .json configuration file loaded into the BRIDGE4 can result in A. FS3 Secondary Toggle triggering on hold-release (desireable in my use case), or B. FS3 Secondary Toggle triggering on simple hold (undesireable in my use case). Also, behaviour seems to switch from A to B at some point; no idea why, yet.

Long version: I've built a bank to control the Strymon Timeline Looper. FS3 primary function is “Stop”; Switch Mode=Momentary, release messages are “send CC#85=127 to the Timeline” and “send FS1 to Sequential Step #1” (which is “STOP” state). FS3 secondary function is “Undo/Redo”. Switch Mode=Hold Toggle, Secondary Toggle On sends CC#90=127 to the Timeline (Redo = Unmute Overdub Layers), Secondary Toggle Off sends CC#89=127 (Undo = Mute Overdub Layers). There are no other messages in the FS3 stack. FS1 however, which is Sequential, controlling Record/Overdub/Overdub off, does send “Secondary Switch off for FS3” when entering RECORD (new recording, i.e. no overdubs to undo), and does send “Secondary Switch on for FS3” when entering OVERDUB (i.e. now there is something to undo).

When I first tested this, the Undo/Redo function triggered on FS3 hold-release. This was very convenient, since it allowed to take out/bring back in the overdubbed looper layers at exact rhythmic positions.

Some configuration versions later, I tested again: Now Undo/Redo would trigger on simple FS3 hold ... inconvenient, since no rhythmic control (unless you have perfect absolute timing). I was confused, not sure if had made any changes.

In my version 6+, Undo/Redo was back to triggering on hold-release. So it hadn’t been a fever dream ;-)

In version 7++, Undo/Redo was triggering in simple hold again. Bummer! So I compared the v6+ and v7++ config .json files, but couldn’t find any difference concerning FS3 Secondary Toggle functionality. Both had the code:

"secondaryToggleOnMessages":{"numMessages":1,"messages":[{"statusByte":"b0","dataByte1":"5a","dataByte2":"7f","outputs":{"midi0":true,"flexi1":false,"flexi2":false,"usb":false}}]}, "secondaryToggleOffMessages":{"numMessages":1,"messages":[{"statusByte":"b0","dataByte1":"59","dataByte2":"7f","outputs":{"midi0":true,"flexi1":false,"flexi2":false,"usb":false}}]}

So I loaded version 6+ back into the editor and sent it to the device: Voilà, desired behaviour “FS3 Secondary Toggle triggering on hold-release” was back.

Now I loaded version 7++ into the editor and sent it to the device: Now, v7++ would also do the desired behaviour “FS3 Secondary Toggle triggering on hold-release”. But after a while, it went back to triggering on simple hold, without any changes to the configuration. And I cannot figure out why.

Conclusion: It would be great, if the firmware would be fixed to have Secondary Toggle EITHER consequently always trigger on hold-release, OR make it switchable between simple hold and hold-release, and then consequently do what was selected :-)

Side note: Though FS3 Primary Switch Mode is Momentary, it happened twice in v7++ that the FS3 primary LED would stay on, and a second FS3 press was necessary to turn it off again.

Config file (renamed to .txt since github won’t allow .json): Bridge 4_2023-06-09_09-52-29_controlv7++.txt

simonaglover95 commented 3 months ago

Fixed in BridgeOS 2.0 Release