About *alsa-midi-instrument-map*

[TatriX]

Hi!
Recently *alsa-midi-instrument-map* was added and it looks like a really nice idea!

I have some immediate thoughts on it, which are of course specific to my workflow, but I guess it is quite common among hardware users.

So, right now to use MIDI device you need to do something like this:

(pb :kick
  :backend :alsa-midi
  :channel (1- 1)
  :quant 1
  :dur 1)

Or with *alsa-midi-instrument-map*:

(setf (alsa-midi-instrument-program-number :nord-kick) 30)

(pb :kick
  :instrument :nord-kick
  :channel (1- 1)
  :quant 1
  :dur 1)

It would be really cool if I could set MIDI channel once for my setup, and make program change more explicit, perhaps like this:

(setf (alsa-midi-instrument :nord-kick) '(:chan (1- 3)))

(pb :kick
  :instrument :nord-kick
  :program '(:pc 32 :msb 13 :lsb 3)
  :quant 1
  :dur 1)

Typically having only program change is not enough, as every device has it's own scheme of switching banks, using all sort of combinations of program change, msb and lsb (http://www.andrelouis.com/qws/art/art009.htm)

[defaultxr]

This is a good idea! It'd definitely make the instrument map feature more flexible and useful. I'll see about implementing it soon, thanks!

[defaultxr]

Hmm, actually, thinking further, it seems like there might not even be any need to keep this specific to MIDI backends; it could probably be even more useful if implemented as a generalized event processing mechanism run as the last step of pattern processing, before events are sent to the clock. I'm thinking there could be a global list like *event-processing-functions* or similar, containing functions that are applied to the events yielded by patterns. The list could default to (list 'convert-midi-mapped-instruments-to-midi-parameters) for convenience, so that users don't have to manually implement MIDI instrument mapping themselves.

[defaultxr]

With commit 49f8dba I added instrument-mapping to map :instruments to arbitrary event parameters, and *post-pattern-output-processors* to process pattern outputs with arbitrary functions.

I'm planning on reworking backends in the future as well so that each enabled backend can have its own list of processor functions that will run on all events the backend receives too.