Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New option to inject MIDI instrumentation #3897

Open
musicog opened this issue Dec 18, 2024 · 1 comment
Open

New option to inject MIDI instrumentation #3897

musicog opened this issue Dec 18, 2024 · 1 comment

Comments

@musicog
Copy link
Contributor

musicog commented Dec 18, 2024

Is your feature request related to a problem? Please describe.
MEI allows the encoding of MIDI instrumentation preferences for individual staves using <instrDef>, with a controlled-vocabulary textual label as @midi.instrname or as a MIDI instrument number using @midi.instrnum. However, in interactive applications it is easy to imagine situations where a user might want to be able to choose instrumentation for playback without wanting or being able to modify the encoding.

Describe the solution you'd like
My proposal is to introduce a new Verovio option, e.g. midiInstrumentation. The option should accept either a single value or list of values:

  • Single value: use this value for all staves
  • List of values: use the list index to match each provided value to the corresponding staff, using empty values to fall back to default on individual staves, falling back to default on any staves where there are no values (i.e. if the provided list is shorter than the number of staves), and ignoring any values beyond the number of staves.

Use the provided value should be read as injecting a new <instrDef> in the appropriate place, replacing any previously encoded ones, prior to rendering to MIDI.

Fall back to default should be read as making use of any existing encoded <instrDef> information, or otherwise relying on system defaults (i.e., proceed without an encoded <instrDef>).

Of course, the client application could already perform this injection on behalf of the user prior to handing the MEI to Verovio for MIDI-rendering, but providing this facility vie Verovio itself would prevent each application from having to reinvent the wheel.

Additional context
In my limited testing it appears that @midi.instrname is not currently respected by Verovio. Ideally this would be fixed as part of this work, allowing the new option to accept either @midi.instrnum or @midi.instrname. If this presents an obstacle or if there is a reason to not support instrument names, the new option could be limited to supporting only instrument numbers instead.

@craigsapp
Copy link
Contributor

Implementation notes about MIDI channel assignments that would be necessary for this feature:

  • MIDI channels for each staff should be assigned automatically for this feature, if there are no MIDI channel assignments already in the file (or maybe reassign if there would be more than one instrument on a channel, which is not possible in MIDI). Or possibly require MIDI channels at the same time as the instruments are assigned.

  • If there are less than 15 staves, then staff@n="1" can be MIDI channel 1 (0x0), and so on. General MIDI uses channel 10 (0x9) for the drum track, so this channel should be skipped unless the staff is for a percussion instrument.

  • If there are more than 15 staves (excluding drum parts), then MIDI channels should be conserved: group all instruments with the same name/number into a common MIDI channel, such as violins 1/2. (or print an error saying there are too many staves/parts to map to MIDI channels).

  • Consideration for piano parts with two staves: the pedal is attached typically to the bottom staff but also applied to the top staff (i.e., the two piano parts staves form a grand staff, and the notes of both should be on the same channel to be affected by the pedal markings attached to the bottom staff). In certain cases, the user may want to use different instruments for the notes for each staff, in which case they could be placed in separate channels.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants