lilypond-devel
[Top][All Lists]
Advanced

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

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


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

Hi,

I am currently working on creating MIDI tracks for percussion (for many
accordion orchestra scores, there is sort of a discretionary percussion
part), sort of a glorified metronome substitute (considerably more fun).

What the articulate script does with rit/rall/a tempo is a disgrace (it
switches the tempo down at the point of rit/rall and picks it up again
at a tempo) and only moderately robust because it works on music input
rather than at the translation stage.  I presume that the relation of
all voices according to their notated time should stay the same even in
polyrhythmic situations; this makes the problem boil down to one of
translating common-time to MIDI time.

\tempo changes that translation but only for increments, and with a
constant factor.

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.  That's
somewhat sloppy since the tempo is not adjusted during long notes, so in
particular a long first note would not get slowed down at all.

If I get the run-always semantics right.  But if I don't (and if one
does not care about the inconsistency of long notes), one can always
write

\rit 2/3 { \repeat unfold 32 \skip 32 }

It would not really need to be written in a separate timing track, you
could just write ordinary music inside.

Does this sound feasible?

In a similar vein, one could do a fermata by just switching
tempoWholesPerMinute to 2/3 of its value for a single note.  Though this
does not necessarily need to be the same mechanism, though it likely
could.

-- 
David Kastrup



reply via email to

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