lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MIDI rendition of things like rall./acc./rit./fermata


From: David Kastrup
Subject: Re: MIDI rendition of things like rall./acc./rit./fermata
Date: Sun, 13 Jun 2021 11:46:44 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Dan Eble <dan@faithful.be> writes:

> On Jun 12, 2021, at 18:48, David Kastrup <dak@gnu.org> wrote:
>> 
>> So how robust (or not) would be the following approach?  Make it
>> possible to write in the timing track something like
>> 
>> \rit 2/3 { \skip 1*2 }
>> 
>> with the effect that some run-always translator keeps adjusting
>> tempoWholesPerMinute during the \skip (in proportion to where the time
>> is) until it is at 2/3 the speed at the end when it gets reset.
>
> As a user, I think I would rather specify the tempo at the endpoint.

That requires you to remember the tempo at the startpoint if you go for
a particular kind of slowdown.

> Is there any hope of handling tempo adjustments like dynamic
> adjustments?
>
>     \mf … \< … \f
>
>     \tempo 4 = 90 … \startLinearTempoChange … \tempo 4 = 60

Of course the question is what "linear" means with regard to a tempo
change.  MIDI files measure durations in terms of common-time (the basic
MIDI clock is 1/24th of a quarter note), so you actually are reduced to
writing tempo change events (which take the form of specifying µs/♩)
between note events.  They don't clog up the raw MIDI signal lines
(those running at 31250bps) since they are "meta events" and converted
into timing for the "real" events by whatever player/sequencer
translates the MIDI file into a timed sequence of commands.

> I don't remember very clearly how the dynamic performance looks ahead
> to manage as it does, but I think it might be that the MIDI generation
> occurs in a second pass, and a velocity value isn't actually needed
> until then.  It might be possible to record a piecewise function for
> the tempo during normal iteration, and then use that to stretch or
> compress MIDI time as the raw MIDI events are being generated.

We are not outputting a timed sequence of events but MIDI files, so we
just can intersperse tempo events: the actual timing in the MIDI file is
being expressed in terms of common-time quarternotes and is unimpressed
by rit/acc.

Of course that also begs the question of how often to output a tempo
change: it's conceivable that you run an arranger for accompanying music
that takes its timing from the generated MIDI file, and when it
accompanies long notes in a ritardando, the slowdown of the
accompaniment should likely occur more gradually than one tempo event
per long note.

> I would love to have this feature.  I'm glad you're considering it.

More thinking about what it would entail than considering it.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]