Draft: Data Flow/Interrupt based implementation of PySwitch

[Tunetown]

PySwitch suffers from some limitations:

• RAM on the MC devices
• Flexibility: Functionality from one callback/action cannot be easily adapted to others when the base classes differ etc.

NEW IDEA: Rewrite based on block processing and Hardware interrupts. Provide more atomic/minimal building blocks instead of high level actions. Think of the RISC idea. The end goal would be:

• Probably huge RAM savings:
  • Because most of the code would be gone, the logic is pushed more into the preset, also processing could be done way more flat in terms of stack size which has also been a pain in the ass sometimes during development.
  • Object oriented style is superior in terms of software development in general, but costs lot of RAM too, and this implementation could be pretty low on classes because everything is in the blocks. After all, the approach might be better suited for this kind of embedded device.
  • The graph definitions can be translated into minimal data structures (using single bits perhaps), it is assumed this costs less memory than the loads of code we have now
• Complete flexibility! This could be used for anything as blocks could be user defined....
• Still possible to keep the Emulator UI similar to the current one by providing blocks
• Better suited for Python beginners as there is no OO knowledge needed to write a simple block which does something

DRAWBACKS:

• Complete incompatibility: No old configs can be taken over per se. However, all actions will be rewritten as blocks anyway, so there could be a simple converter option in the (old) emulator to convert to the new graph JSON format.

Outline:
Blocks:

• Building blocks should be interconnectable on the base of connection types similar to Max or Pure Data. There could be these types of interconnects:
  • MIDI messages
  • Internal messages (like the "bang" in Max/PD)
  • Boolean State
  • Number
  • String
• Replace all actions and callbacks with pre-made "circuits" the user can choose from (or build his own!)
• Instead of Inputs and Displays lists, just provide the IO (switches, labels etc., also MIDI over USB/DIN) as "inlets" and "outlets" like Max/PD
  • LEDs with individual addressing
  • LEDs in groups of three with automatic addressing like it is now
  • Switches including all modes (momentary, latch etc), sending messages or providing boolean state outlets, too
  • Display Labels (Inputs: Text, Color)
  • Encoders/Wheel etc.
• Provide a graphic "breadboard" for editing actions, similar to Max/PD
• Remove communication.py (MIDI routing can then be done freely using interconnects)
• Store as Net list
• Provide elementary building blocks, with defined/typed inlets and outlets, implemented in Python and extensible.
  • All kinds of triggers (MIDI -> bang, bool -> bang, number -> bang etc.)
  • Kemper Bidirectional Protocol
  • All kinds of logic blocks etc.
  • Code blocks: Python scripts embedded in JSON or referenced to a file and function (like pre-built blocks are)
  • Library of blocks is outside PySwitch: These are provided in a separate library, not loaded by PySwitch (but the emulator).
• Remove UI code, directly address hardware in the IO blocks

Graph Processing (full processing, done at the start only):

• Process from the source outlets (define in blocks which outlets are sources, for example in the IO modules) down the graph (width first!) and wait if parallel inputs are not finished yet
• raise error in case of roundtrips

Events:

• Main loop should only check for MIDI messages and analog IO. In case a message comes in or a value changes, the graph has to be recalculated from the corr. outlets
• Use countio to catch switches as hardware interrupts. In this case, just recalculate the graph from the corr. outlets.

Keep from the old implementation:

• hardware/devices
• Remove everything, put the hardware code directly to the blocks.

Emulator

• Use Rete.js and provide a blank screen, MC and everything can be added using a plus button.
• Keep Tab Subsystem for:
  • Node List editor
  • MIDI Monitor
  • Virtual Kemper
  • Editors for selected node
    • Properties
    • Sources