| Age | Commit message (Collapse) | Author |
|---|
|
The live output goes to channel 0. This prevents the two from messing
with each other (cancelling each others' notes).
Simply hard-coding channel 1 is a bad idea long-term, though. We
actually could have input from more than one channel (if we pump a midi
file into the program with "aplaymidi", for example). I suppose we want
to map the entire range of channels based on the input source in order
to prevent input sources from affecting one another. Then generated
playback could be considered a separate input source.
All of this will have to be done in order to deal with simultaneous
looping of multiple tracks, anyway.
|
|
Currently, the "dump" command plays the entire database. Only the SQL
SELECT statement needs to be changed in order to play a specific
time-range.
|
|
Also whitespace, comments, & other non-functional changes.
|
|
This format is still inefficient -- because the time is still
represented as a string that is parsed as an Integer -- but it's
certainly much more efficient than before. And more importantly, it can
be both written and read.
|
|
|
|
My intent in doing this was to have a format suitable for reading
and writing to the database; the old format (using "show" on the
Sound.ALSA.Sequencer.Event.T) could not be read back.
Unfortunately, this new format cannot be read back _OR WRITTEN_!
At least not without more conversion (of my list of pairs into a
Thielemann's specialized event-list).
My new plan is to use HCodec's Codec.Midi.Message instead. But I'll
commit this before I get to that.
|
|
|
