newlandsvalley / elm-comidi Goto Github PK

I believe it's possible to have running status with something like Channel Aftertouch where you could get an odd number of data bytes.

from String to List Int

Nice library! Do you have any plans to re-release it to be compatible with the current version of Elm?

There is still a problem with multi-track files. Carolan's Receipt parses OK whereas the Galway Hornpipe does not - it reaches the end of the first track and expects the input to be at an end. Not entirely sure yet why this is - the files are pretty similar and I would have expected either both to pass or both to fail. I suspect the problem might be in midiMessage() - the parser has to consume the delta-time but then has to backtrack if in fact the message is TrackEnd. In which case, why would anything parse at all?

These are tricky because they depend on state. They can only be used (in a possible sequence) immediately after a channel voice or channel mode message and they inherit the status byte of that message. They only provide data (no status). I had to remove them because my naive parser accepted any input for this data and would have swallowed the TrackEnd messages.

Hi. Nice library! I really like how the midi message types nicely translate to Elm union types.

I'm working on a browser based step sequencer and I want some way to save the step sequencer phrases to disk. At first I was going to use Json.Decode, but that will be a headache to maintain as this is a work in process, and I'm likely to change the internal data format, rendering the saved files obsolete. I figure MIDI might be a better serialization format - I should be able to map it to my internal step sequencer note data, and if I abandon my project, any saved data will still be readable as a MIDI file in any another software that can read midi files.

Would it make sense to add this functionality to this package, or do you think it should be a separate one? The main thing that would be common between the two would be the types in MidiTypes.elm. I'm happy to have a go at building the generator in a fork of this repo - I'll let you know how I go! If I get somewhere with it, I'll submit a pull request.

Right now sysex messages are treated as MetaEvents which are prefixed by 0xFF, but it looks like SysEx events don't require this prefix either in realtime or in midi files.

I believe this can be fixed by just moving parseSysEx from metaEvent to midiEvent, but I'm not terribly familiar with this stuff so I figured I'd check before I submitted a PR.

Forgot to delete elm-stuff before recompiling and publishing.