Add functionality to address specific use cases

[solidsnake745]

Want to simplify use of this library by including classes that encapsulate configuration and processing of MIDI events from different frameworks.

Thinking they will share two common methods, but with different parameters depending on case:

1. setup() - Configures controller for given use case and may have overloads specific to use case
2. process() - Processes MIDI data for given use case and may have overloads specific to use case

Use cases in mind currently:

1. USB MIDI Controller for up to 8 FDDs (Teensy + MIDI application to MIDI Device [MIDI Event Data])
2. Serial Moppy (Arduino/Teensy + Moppy application to Serial Device [Pin and Period Data])
3. Hairless MIDI [https://projectgus.github.io/hairless-midiserial/] (Arduino/Teensy + MIDI application to Hairless MIDI to Serial Device [MIDI Event Data])

[solidsnake745]

Refining - Separating out further to try and design a better mechanism

Setup devices Create setup type mechanism for: Teensy controller Create setup type mechanism for: Arduino controller

• Takes in a list (array) of devices? Where device ID relates to device controller slot?
• Why not just create a more flexible configuration mechanism instead of controller specific implementations?
• Then make an enum for controller types and possibly an enum for configuration type if specific defaults are necessary
• Create method: configureFromDevices which takes an array of devices
• Create method: configureForController which takes an enum for controller and possibly an enum for layout if different ones are desired

Processing different MIDI data sources Create process type mechanism for: Teensy MIDI Data Create process type mechanism for: Serial MIDI Data (Moppy) Create process type mechanism for: Serial MIDI Data (Hairless MIDI)

[solidsnake745]

After much thought, I think the best approach is to remember I need to separate specific use cases from implementation. Meaning I should make generic methods/things address those use cases rather than build something exactly for them.

In that spirit, I'm going to continue creating functionality like #13; I'll address those specific uses cases by adding example sketches to demonstrate using the library to accomplish them. I'll continue to reference them in this issue to track progress.