newlandsvalley/purescript-midi

MIDI and Web MIDI support

purescript-midi

MIDI support in the browser.

This library allows you to both parse and generate MIDI event streams and MIDI recordings. It also allows you to connect to a MIDI instrument (such as a keyboard) via the Web MIDI API. For example, if you use Chrome and can plug in a MIDI keyboard you should to be able to play it using this demonstration.

To parse a MIDI string that represents a recording and thus generate a value of type Midi.Recording you can use:

(parse <<< normalise) midiString

On the other hand, you may merely need to parse MIDI events (such as note on or note off) that emanate from a Web MIDI connection. In other words, you are connecting directly to a MIDI device through the browser and need to parse the stream of event messages as the instrument is played. To do this, use:

parseMidiEvent midiEvent

This will attempt to parse an individual event.

To Build

npm run build 

To Test

npm run test

Web MIDI Permissions

It appears that browsers are becoming stricter about allowing Web MIDI to run from 'untrusted' servers after being notified of security exploits. At the time of writing, both Chrome (see details) and Mozilla require HTTPS connections.

Module documentation

Module documentation is published on Pursuit.

purescript-midi's Issues

Consider separating single and multi tracks within the ADT

elm-comidi now has:

type MidiRecording
    = SingleTrack Int Track
    | MultipleTracks TracksType Int (List Track)

I think this is clearer

File and event parsing is subtly different

In that SysEx messages appear to have a different format within a file from that in an event stream. From p135 in the MIDI spec:

For instance, the transmitted message F0 43 12 00 07 F7 would be stored in a MIDI file as F0 05 43 12 00 07 F7.

Again discovered by @rhofour against the Elm implementation. Unfortunately this means that it will require separate implementations of all event parsing.

Empty tracks not supported by the parser

A track is allowed to consist only of a track end meta-event. This was discovered by @rhofour in the Elm version.

Support serializing a Midi Recording

Rename Instruments.instruments

Probably best just to call this just names and rename the existing function that is called names (and is not exported) to namesMap.

Upgrade to Signal

The FFI interface (for Web-Midi) is completely new in the latest AFF

Check the Gleitzman instrument names against the different providers

I've just noticed that the Gleitzman MIDI instrument names differ across the different soundfont providers that he uses. If we want to allow the user to choose between these providers in the soundfonts module, we'll need first to sort this out.

Add support for web-midi output devices

This can be culled from elm-webmidi-ports with the PR kindly provided by @rhofour. Probably have to wait until I buy myself a suitable device.

Parsing messages from node-midi

Hi! I'm writing a library to talk with node-midi, and I'd like to integrate it with this library, i.e. possibly reuse the datatypes and the parser, etc.

I'm opening this issue because I'm not sure how to make the parser work on the events that I get from the Node library, which are JS arrays. E.g. a NoteOn would be something like [144, 89, 127].

Is this possible right now, or would it require a patch?

Upgrade to work with string-parsers 7.0.0

This package no longer compiles with string-parsers 7.0.0 and needs to be updated.
For this package it's only a matter changing all imports to import from StringParser.
See also purescript/package-sets#1077

Move InstrumentMap somewhere else

Amend the Playable typeclass

The definition is suitable for MIDI melodies but not for other sources which may need to look up MIDI note channels from instrument soundfonts that are in scope. (This is the case with PSoM melodies for example).

Generated code for Midi.Instruments is grossly inflated

This is because we have a very large enumerated type for the (128) MIDI instrument names. The problem comes if we want to automatically generate an Ord instance - the code bloat goes through the roof.

The answer seems to be to write an Ord instance by hand by just comparing the stringified version of the names.