Rethink lenses

[ryanlaws]

Summary

Reconsider lenses: why they're good, what they could be, what they are and how that could better serve the idea.

Why

The implementation of lenses is a hacky mess right now. It does not do justice to the idea.

Considerations

• The mode functionality was very much tacked-on. I literally added it because of the 1.40 Octatrack OS that dropped on 2020-12-04.
• Nesting or groups could be nice here, both to group parameters within code and to imbue lensed parameters with their parents' traits. For example, all parameters with a range of 1-8 could be grouped together, and then this range only needs to be expressed once.
• Machine-readable metadata could be very useful for UI features that take advantage of lenses. This would include things like parameter types/names, or the range that already exists in the Octatrack lens.

[ryanlaws]

Why not just really go all in on plisp and properly use that for lenses? Could identify "reversible" operators to trace the steps backwards. offset and range are a simple declarative form of this which might not be a bad approach, but limits expressiveness. Which tactic scales better is an important concern, but maybe less significant with e.g. DSLs.

[ryanlaws]

One easier fix would be better handling of n and v for MIDI types. For example, program_change doesn't have a v and e.g. clock doesn't have either. I think a simple lookup table, i.e. one for types with v and one for types with n, would be a pretty easy fix.

Longer-term, it's likely we need different lens strategies for different protocols. Like, a MIDI-specific one, and then one for e.g. grids, crow, whatever else comes down the pipe. These could surely be injected somehow.