Blend mode: blend between snapshots#150
Conversation
There was a problem hiding this comment.
Even without blend config defined, this is causing a regression for me. Changing the Snapshot via the Nav encoder, doesn't re-render the status for each plugin accordingly on the LCD.
It's possible that the code for this PR is in a weird state, but I have to say that I have reservations about this one.
It's cool, but I'm pretty sure less than 1% of users will ever use it. It's very advanced to set up and to understand.
If it didn't modify the regular/non-blend code path at all, I might be more keen on it, but it does. It adds code complexity, 7 new python files, and potential maintenance overhead.
For those who do use it, I'm imagining support calls (emails). There's a lot to get wrong in the config file.
So unless, you really think you need this. I'm suggesting against merging this.
UPDATE:
Actually... I was misunderstanding how this is configured (was thinking individual settings would need to get mapped, etc.) and didn't fully consider the power of this in a performance setting.
Forgive my skepticism above. If we can get this to work, I'm ok with the complexity hit. We need to figure out why it's messing with regular (non-blend) snapshot changes. My guess is that preset_change_plugin_update() isn't working like it used to.
28d6aea to
b38083e
Compare
# Conflicts: # modalapi/modhandler.py # tests/conftest.py # tests/integration/conftest.py # tests/test_websocket_bridge.py
…r/send_bpm return bool feat/blend-mode declares WebSocketBridgeProtocol.send_parameter() -> bool (blend/types.py) and uses the return value for dedup-tracking. feat/websocket-parameter-set implements AsyncWebSocketBridge with -> None. Neither leaf can own the signature alignment. Why: blend dedup needs to know when a parameter write was suppressed by backpressure; the protocol signature must match the implementation. How to apply: update AsyncWebSocketBridge.send_parameter / send_bpm to return bool with backpressure check; mirror in FakeWebSocketBridge; wire reset_tracking() into the blend fixture so dedup state is clean across tests. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
rreichenbach
left a comment
There was a problem hiding this comment.
Looks good. thanks.
This PR introduces "blend mode", which allows a single analog input (e.g. the expression pedal) to interpolate parameter values between multiple snapshots. This is essentially a workaround for the fact that MOD pedalboard does not let you map multiple MIDI CCs to control the same parameter, and also that it does not seem to let you change the extents easily (at least in the UI).
The workflow is such: create your pedalboard, attach footswitches for MIDI controls as usual, etc. Then, create one or more snapshots that make the board sound to your liking. We can then create a new "Blend Mode" preset by configuring the pedalboard.
Configuration
In
$HOME/.pedalboards/$PEDALBOARD/config.yml:Enabling and hooks
When we load a pedalboard with blend snapshots configured, we create a new snapshot for each . Whenever this snapshot is selected, we set it as the
active_blend_modein the handler. If we change / remove any of these blend snapshots, we automatically modify / delete them when we next switch to that pedalboard.When the pedalboard is saved (and
snapshots.jsonhas been written, which requires saving the pedalboard, not just the snapshot), the generated snapshots are re-generated to sync constant values.How blend mode works
We take over the chosen analog input by adding a callback to it that will override its default behaviour (e.g. sending a MIDI CC). We convert the value to a float (0..1) and use it to discover the stops that this value is contained within. Then, we discover which parameters differ between the two snapshots these stops are configured to use, and interpolate the parameters between them using websocket messages, e.g.
Review checklist