Re: A question of rendering multiple instances of \arpeggio in MIDI

[Flaming Hakama by Elaine]

>
> ---------- Forwarded message ----------
> From: "Petr Pařízek" <petrparizek2000@yahoo.com>
> To: lilypond-devel@gnu.org
> Cc:
> Bcc:
> Date: Fri, 16 Apr 2021 04:39:59 +0200
> Subject: A question of rendering multiple instances of \arpeggio in MIDI
> Hello,
>
> originally I wanted to ask two questions but I'll leave my second
> question for a different thread so that the two topics don't get mixed up.
> I currently use LilyPond 2.22 on my Windows machine.
> Via simple web search, I was trying to find some info on the possibility
> of rendering arpeggios in MIDI files. What I found was an older
> discussion (I don't remember the URL) from which it seemed to me that
> such a feature was actually not planned to be implemented, even though
> many other kinds of performance markings could be rendered in the MIDI
> file via the "articulate" script.
> My question is: Is my understanding correct that implementing such a
> feature would, in one way or another, be troublesome and that doing so
> is not considered a good idea? Or is the reason something else?
> I'm asking because I can name at least 4 different ways in which this
> feature would help me tremendously:
> - 1) I'm blind. Therefore, if I want to make sheet music available to
> other people, MIDI files are the one and only way I can locate typos in
> my .ly file (an invaluable feature, numerous times has it helped me spot
> really serious errors in my input text!). If I could render the
> arpeggios in the MIDI file similarly to rendering ornamentation or
> accents or other stuff, I could then easily check whether I have indeed
> used a \arpeggio at the particular spot or not.
> - 2) If this were possible, I wouldn't have to manually turn all the
> arpeggios into written-out notes while repeatedly switching
> \tieWaitForNote on and off. Doing something like this is time-consuming
> even for one single arpeggio because it can't easily be automated.
> Therefore if my score contains more than 30 of them, I don't even try to
> imagine how much time it would take. And I may easily forget to do that
> at one spot if there are so many of them. In contrast, introducing a
> dedicated feature might allow me to just enclose the whole portion into
> braces.
> - 3) If I ever wanted to turn my modified .ly file back to one that's
> more appropriate for printing, I would just remove the dedicated command
> and the braces and leave the music fragment unchanged.
> - 4) If I have good-quality samples available for playing back the MIDI
> file, then the MIDI file can serve as a handy tool not just for spotting
> errors but also for making serious recordings. For a blind person, this
> is an important point because currently there doesn't seem to be any
> other software that would A) run under Windows, B) use some syntax whose
> verbosity is minimal, and C) make meaningful MIDI files. I mean, well,
> there's Scala, but Scala's "sequence" format is much much more verbose
> than what LilyPond offers. And what's more, I think I've read somewhere
> in the documentation that LilyPond even allows me to include a series of
> controller messages in my MIDI file, which can definitely make the
> resulting performance sound a lot better still.
>
> Thank you in advance for your answers or comments.
>
> Petr
>
>
> --
> Tento e-mail byl zkontrolován na viry programem AVG.
> http://www.avg.cz



My initial thoughts on this is that, like many other things in lilypond, it
is generally necessary to have parallel PDF vs MIDI content, when they
diverge.

The most straightforward approach is to use tags, and to make sure that
everywhere you have content that diverges, you have tagged both a PDF and a
MIDI version of the content.

The PDF score keeps the PDF tags, and the MIDI score keeps the MIDI tags.

Note that the tag names "MIDI" and "PDF" are just arbitrary words,
there is no intrinsic significance to them.

This approach becomes handy when coding other differences for MIDI,
such as fermatas, breaths, rit/accel, trills.

Here is an example from some time ago that demos how to use PDF vs MIDI
tags to deal with non-trivial repeats.  Not the same use case, but you
would still use the \tag and \keepWithTag commands.

\version "2.19.81"

body = { c'4 c' c' c' }
voltaI = { d'4 d' d' d' }
voltaII = { e'4 e' e' e' }
voltaIII = { g'4 g' g' g' }

music = {
  \repeat volta 5 \body
  \set Score.repeatCommands = #'((volta "1."))
  \voltaI
  \tag #'MIDI { \body }

  \set Score.repeatCommands = #'((volta #f) (volta "2. 3. 4.") end-repeat)
  \voltaII
  \tag #'MIDI {
      \body \voltaII
      \body \voltaII
      \body }

  \set Score.repeatCommands = #'((volta #f) (volta "5.") end-repeat)
  \voltaIII
  \set Score.repeatCommands = #'((volta #f))
  \bar "|."
}

\score {
  \keepWithTag #'PDF \music
  \layout { }
}

\score {
  \keepWithTag #'MIDI \music
  \midi { }
}




Next, the question is how to produce the tags.

If the transformation of an chord that is marked with an arpeggio into a
performed arpeggio can be done in an automated way, then you could do
something like this, so your usage was reasonable:


myMusic = \relative c' {
    <d f aes c>1
    <d f aes b>1
    \arpeggiate <c ees g b>1
    <c ees g c>4
}



This proposed \arpeggiate function would end up producing, in this example,
something like:

\tag #'PDF { <c ees g b>1\arpeggio }
\tag #"MIDI << { c1 } { s4 ees 2. } { s2 g2 } { s2. b4 } >>


On the question of how best to represent a played-out arpeggio remains to
be determined.  Divide equally, as suggested here?  Or stagger entrances by
some duration like 16ths, then tie each note to completion?

You'd have to determine what that algorithm is, and then write a function
to turn a chord into a played out arpeggio,

then write the \arpeggio function to produce the tagged version with both.



HTH,


Elaine Alt
415 . 341 .4954                                           "*Confusion is
highly underrated*"
elaine@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-