To Do

Bugs

The Be staff...went to see the movie "Men in Black." ...The movie makes a point that is somehow appropriate -- It is impossible to completely rid the universe of bugs, but at least you can drive something fast, arm yourself with powerful tools, and look good doing it.

-- [email protected]

Empty Patches

Need to be able to handle empty patches and empty songs for a few reasons. First, on create from the GUI it should be empty. Second, if there are no attached inputs or outputs we can't create a connection anyway.

Nomenclature: "All Notes Off" in menu, "panic" trigger action

Missing Features

Instrument Initialization/Editing

Problem: need to store device id because port names can be same for different versions of same device (for example, USB and non-USB Sledge outputs are both named "Sledge"). But what about disconnected / disabled devices?

On startup if no project is loaded, KeyMaster finds all attached MIDI instruments. When the project is saved, it saves those instruments. When a project is loaded, it loads those instruments and enables/disables them depending on if those instruments are currently attached. There's no reconciliation done --- it doesn't re-scan for all attached instruments, which means that any instruments that are attached but were not saved in the database won't be available.

So when a project is loaded, compare loaded to found instruments. If different,

• If found instrument missing, add it
• If loaded instrument missing, warn (it's disabled) and offer to map
  • Check to see if it's even used
  • Options: remap, ignore, delete
  • Should map add new instrument or replace?

Reaper seems to have four states for MIDI hardware: enabled, disabled, not present, and "!!! N/A Enabled", which means it's enabled but not attached. KeyMaster should probably do the same, so that instruments are in one of those four states.

Finally, should there be a way to edit the list of instruments? Without that, all old instruments will hang around forever.

"Changed" Flag

Add a "changed" flag to a project in memory so that the program can ask to save when quitting or opening a new project. https://docs.wxwidgets.org/trunk/classwx_close_event.html

• Ask to save when new project or open file
• Disable save and save as menu items if nothing changed

New Feature Ideas

Innovation is not about saying yes to everything. It's about saying NO to all but the most crucial features.

-- Steve Jobs

• Timing tests from input to output to make sure the connection code is fast enough.

• MIDI monitor. Split window/two windows showing incoming MIDI and outgoing MIDI. First col is instrument symbol then raw MIDI bytes. Use threads. (This code exists but is hidden because refresh is broken.)

• Let Named Messages send MIDI files or raw data files containing MIDI bytes.

• A DSL for byte messages

  • Symbolic names, default channels and perhaps velocities, note names, math (bitwise, addition)

• Info window could bold and italicize text according to markup (Org Mode or Markdown).

• A logo would be nice.

• Alternate display that only shows song and patch names and little else? This might be useful during performance.

• Do I need to handle running bytes in Connection#midi_in? I don't think so; I think PortMidi handles that.

• Add a "big patch name window" that shows current song and patch in big letters.

• MIDI to text; output file or text window

Ideas from Midihub (https://blokas.io/midihub/)

• MIDI generators that are not inputs, such as
  • CC LFO
    • rate, depth, center, waveform, trigger (always running, only when first note played in chord, retriggered for all notes)
  • CC ADSR envelope
    • trigger (always running, 1st note, retrigger every note)
  • main MIDI clock
• Arpeggiator (rate, direction, velocity changes?, other Hydrasynth options)
• Note scale remapper
• Note repeater (needs MIDI clock messages, division, num repeats, fade, octave)
• Delay (millisecs or tempo if clock)
• Randomizer
• Note to chord
• Velocity scale remapper
• Multi-CC controller from a single CC (map one CC to multiple ones)
• Fixed note length
• Tempo divider
• Sync delay

I have a feeling these would require something like a struct containing the current state of the channel (notes on, for example). Right now they are stored in the input. Does it make sense to move them to the connection?

Edit

Use Ctrl- (or Cmd-) -Z, -X, -C, -V, -D (undo, cut, copy, paste, duplicate), all for current type (except undo). Command pattern?

Ctrl/Cmd-N for new current obj? Shift Ctrl/Cmd-N for new project.

Connections

• Volume mapping for note ons and note offs (same one for both)
• Channel pressure mapping, poly pressure mapping

Controller Filters

• Map all values 0-127 (allow diff value for each input value)
• Different scaling/curves

Triggers

• Trigger on any program change from any source, which would require "wildcard" MIDI messages something like [0xcX, 0xXX]

Editor / GUI

• Drag and drop to reorder: patch, set list
  • Reordering connections doesn't matter, but no harm in allowing it

MIDI Monitor

Colorize inputs and outputs, different color per connection. Would have to send connection along with input and output message. But then if input had 2 conns we'd have send it to monitor twice.

Maybe input could have the monitor draw a line on both input and output side, or timestamp or something, to say "start of input".

Storage

Perhaps use https://www.sqlite.org/pragma.html#pragma_application_id and https://www.sqlite.org/pragma.html#pragma_user_version to store app id and db version. Could use user_version to do database migrations.

Documentation

• Document the GUI. Clicking on things to activate (messages send), double-click to edit.

• Connection start prog change/bank only sent if output channel is not "all"

• Zone note names.

• Song notes and reload features.