search

newlandsvalley / elm-comidi

MIDI parser in pure elm
BSD 3-Clause "New" or "Revised" License
9 stars 3 forks source link

Generate Midi data from Elm data #4

Open mbylstra opened 7 years ago

mbylstra commented 7 years ago

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.

newlandsvalley commented 7 years ago

Hi, @mbylstra - many thanks!

I think using MidiTypes.elm as a serialization format makes sense.

At the moment, I'd prefer it to be a separate package and have it dedicated to being a MIDI parser. However, I have something of the same problem, given that my midi-player and abc-player packages also depend on MidiTypes.elm.

Perhaps there are two ways to go with this. One way would be to publish MidiTypes.elm as a separate package - I'd be happy to do this. Another might be for you to go ahead with your generator and then see if there is enough coherence between our various projects in order somehow to combine them into some sort of uber-MIDI library. At the moment I think I prefer the former, but I'd be very interested to see what direction your project will take.

rhofour commented 6 years ago

I'm also interested in this and I agree that splitting MidiTypes.elm into a separate package seems like a good way to go about it.

I might even have time to write the generator. I'll take a look at it today.

newlandsvalley commented 6 years ago

My preferred option would be to be able to live in an Elm world where there was a single place to go in http://package.elm-lang.org/ for comprehensive MIDI support. This would require Elm to have a straightforward story to tell on binary data and also for it to climb down from its position on the publication of native modules which only wrap a browser API such as web-midi. Unfortunately, I can't see this happening.

This probably being the case, I'd be prepared to have a separate MidiTypes package.

I'd be interested to hear @mbylstra's thoughts.

rhofour commented 6 years ago

Yeah, I was pretty surprised to learn Elm didn't have any kind of real support for binary data. Splitting things is just the best of the options I realistically see available.

newlandsvalley commented 6 years ago

Agreed. (sigh).

rhofour commented 6 years ago

I've gotten far enough along on a project that I could really use a library to generate "binary" MIDI data from MidiTypes and I like the idea of MIDI support existing in one place. How would you feel about a PR that restructured it like this?

Midi.Types (MidiTypes) Midi.Parse (CoMidi) Midi.Generate (what I'll write)

newlandsvalley commented 6 years ago

I'd be happy with this now, I think. Would you be able to liaise with @mbylstra to see whether he is still interested in the idea and whether your requirements match his?

rhofour commented 6 years ago

I was assuming @mbylstra wasn't interested anymore given the lack of response to this thread. Either ways, my plan was to add two functions.

Midi.Generate.event: Midi.Types.MidiEvent -> List Int Midi.Generate.recording: Midi.Types.MidiRecording -> List Int

I think the latter should handle pretty much all cases where you want to serialize MIDI data, including @mbylstra 's case. My own application also has a sequencer which will probably make use of this too (though I'm primarily more interested in sending MidiEvents).

newlandsvalley commented 6 years ago

I think you're probably right. I seem to remember he created the audio-music-synth channel on elm-slack but he doesn't seem to have been very active on it recently. Just go ahead.

rhofour commented 6 years ago

You can check out my progress over at: https://github.com/rhofour/elm-comidi/tree/generate

So far it's moving along pretty well. I'm going to wait to send a PR until it's all done.

newlandsvalley commented 6 years ago

It's looking good, and a natural fit with the parser in that we have its inverse operation. I like the fact that you are round-tripping and using QuickCheck style checks. I'm very tempted eventually to port this over (with acknowledgement) to my PureScript version if you have no objections.

rhofour commented 6 years ago

No objections at all. I'll be happy to see the code have more impact.

I love how amenable this kind of code is to QuickCheck style tests. It feels almost like it belong in a textbook with how well it works out.