MAIN GOAL: Figure out plans for [looper] bank switching algorithms and implementation
The main consideration is where the logic for switching banks is going to live. We want to be able to update the UI to keep its state accurate to reflect the backend. Our design has the UI being the root source of truth with changes getting committed to the backend.
Thinking about this, I think that having the switching algorithm get defined in the backend and triggering changes to the frontend is the way to go. We commit the change algorithm to the backend, the backend will process it whenever the currently playing bank ends, and fire a callback to the frontend. Frontend will push Redux action which will propagate the event to the backend.
On the backend, we currently store the index of the next bank to switch to once the current bank ends. We can swap this to a handle to a transition algorithm. We will probably have to evaluate the transition algorithm one step ahead so that it yields the next bank to switch to for each module. The transition algorithm should be per-module; if we want to define things at a higher level, that should happen at the UI level. So, whenever a bank finishes playing, we will ask the transition algorithm what the next active bank index should be and set it. Then, fire an event to the UI to set the active bank ix to it. I think that will work just fine.
As for the transition algorithms themselves, we can have one be constant which will never transition (default). Oh, we should think about what effect (if any) manually activating banks while an automated transition algorithm is enabled should have. I think it should be dependant on the transition algorithm; for constant, we will actually go ahead and switch the algorithm. For probabilistic state-machine based transition algorithms, we can manually set the next state it will switch to or something.
I think I want to write some code for this and let that give me a better feel for how this will look.
OK well I think the code for the back and middle end is wired up. Need to build the UI for actually defining these patterns though. What will that look like and where on the screen will we show it? I suppose the second question is somewhat determined by the first one.
We need to be able to switch between different transition algorithms. Each algorithm will probably have its own sub-UI to configure it. For constant, that will be pretty trivial - just a select box to pick which bank we want. Or maybe not even that, maybe just leave it blank and put a note that whichever bank is selected in the UI will be played over and over forever.
The only other transition algorithm that I've built is static pattern, and for that one I think that just allowing users to type the pattern out, parse it, and commit to backend will do.
I think that we want to retain the UI state for each of the different algorithms. That way, when users switch between them, they can have their state from where they left off. I'm seeing the Redux state have a sub-object for transition algorithm UI which has a selected algorithm index and child objects for each of the different transformation functions.
I will include a "commit" button on the bottom that will actually lock the new transition function into the backend. There may be some confusion if the UI state doesn't match up with the backend state, but when we refresh it will automatically get committed if it's valid. That's a good point though - if the state isn't valid, we will need to have something else to commit. We should store the last good applied transition function state as well to fall back to in that case.
Finally, I've decided that I want this to show up on the bottom of the screen, in a collapsible pane that will share the same horizontal space with the bank listing. It will collapse down to a short bar along the bottom of the screen when not visible, and it will expand up and shorten the height of the bank list when expanded. I quite like that idea.
Let's write some code for that.