Re: Support articulations, slurs and breaths in MIDI (issue 26470047)

[dak]

On 2013/11/18 13:34:33, Devon Schudy wrote:
> mailto:address@hidden wrote:
> > If you say "overlap is the one synthesizers recognize": does that
> > mean that there needs to be a physical gap, or is it sufficient if
> > the note-on command of the next note comes before the note-off
> > command of the previous note in the MIDI data, without any
> > intervening time gap?

> I think the MIDI command just has to arrive later, but this is a
> slightly obscure feature, so actual synthesizers might do something
> else.

> However, this is probably irrelevant, because synthesizers recognize
> overlap only if legato/portamento mode is on — and it usually isn't on
> by default, because it misinterprets chords. So the slurry sound of
> overlapping notes is just due to overlapping sound, not to special
> synthesizer support. Maybe Lilypond could emit the command to turn on
> portamento mode when there are no chords; I haven't tried this.

I don't think LilyPond should do something like that unless very
specifically told so (and not sure it is a good idea then): the output
should be a good basis for further processing with MIDI tools.  Sound
synthesis is only the last step.

So the question is likely more how other notation programs view/produce
the MIDI (for better or worse, one of the more important formats for
getting LilyPond-produced music into other notation programs).  The most
important thing is to have a good understanding between us and other
tools manipulating MIDI.

> Slur overlap doesn't improve the sound nearly as much as
> articulations, and breaks midi roundtripping, and the current
> implementation is ad-hoc, so maybe it shouldn't be included.

If you call the current implementation ad-hoc, then it's probably at
least a good idea to move it to a different issue.

> How does the parser create slurs? They seem to be post-events, but I
> don't see where they're defined.

ly/declarations-init.ly:81:"(" =  #(make-span-event 'SlurEvent START)

They are no longer visible separately in the parser (see issue 3487).

The user can redefine them to anything else as if they were
\some-identifier

> It would be more flexible to do slurs
> with a perform-length property on the SlurEvent, and that would
> generalize to other spanners.

I don't think it makes sense to move LilyPond in that direction: we want
clearly recognizable output.  And even if we wanted to: at the current
point of time, the MIDI phase has no access to a property system
comparable to the grob property system.  That means that all such
finetuning data would need to get designed onto events or into generic
context properties.

So any _local_ specialization of execution would have to be done in a
dissimilar approach to the typesetting.  We would not be doing the
complexity of our user/programming interfaces any favors with that.

So "tweakable MIDI" where we are talking about local tweaks in my
opinion should only be tackled once we have moved to GUILE2 _and_ we
have reworked the context property system in a manner where \layout and
\midi work in comparable ways at least from the user interfaces.

Otherwise we'll get another large diversion of interfaces that will have
significant consolidation costs once the necessary facilities will
trickle in.

https://codereview.appspot.com/26470047/