Re: [Lilypond-auto] Issue 3878 in lilypond: MIDI lyrics start at 0 even when music doesn't

[lilypond]

Updates:
        Labels: -Patch-push Patch-needs_work

Comment #14 on issue 3878 by address@hidden: MIDI lyrics start at 0 even when  
music doesn't
http://code.google.com/p/lilypond/issues/detail?id=3878

I'm putting this on "Needs_work" for now since Devon and I am still  
actively considering alternatives.  Devon, I'll be sending the first_mom  
patch your way presently.  I think that's the right way to go.

Of course, there would also be the boorish way to tackle this, namely state  
that it cannot be LilyPond's business to allocate space for grace notes at  
the start of music since it means that multiple MIDI files (like when  
putting out parts, some of which with and some without grace notes) will  
not align.

In that case, one would provide a context property for midi time-shifting,  
or just suggest that people use
\score { { \skip 4 << whetever we had here before >> ... \midi { } }
But an explicit context property would allow for doing something like
\midi { midiOffset = #(ly:make-moment 0 3/8) }
in a central place.

I _think_ that the output definition is better accessible anyway.

Of course, that will by default result in a warning again.  In the case of  
before-zero timing, we could make that warning suggest the proposed remedy.

While I agree that an automatism would be fine whenever only one Midi is  
getting generated from the same source, or whenever any separate Midi files  
are never going to get recombined, but there are people who use external  
multiple track processing in order to make it easier to tell  
different "voices" apart and/or emphasize one.

I am not sure what the best mechanism is here.  I was going to suggest  
trying to use the same mechanism as \partial here, but \partial at the  
start of music actually does nothing at all to the Midi.  I am not sure  
there is a "timeline is zero here rather than at the start of the Midi" at  
all.  In the absence of it, I am slightly leaning towards a manual  
solution.  Or at least provide a midiDelay variable that will be  
authoritive when set.

Ok, proposed timeline:
a) revert the original issue 1412 patch.  It breaks more stuff than it  
fixes and it does not appear to be a suitable base for any followup work.   
That can basically be pushed now.
b) make a manual solution for setting the Midi starting time in the \midi  
block, letting it default to 0.  That puts us back to square one, but with  
a manually accessible, well-defined and consistent fix.
c) figure out the best behavior for _unsetting_ the Midi starting time in  
the \midi block (possibly indicated with ##f)
d) figure out whether it's a good idea to have that as default.

I think it's pretty clear that any possibility of letting the midi walkers  
of one compilation start at different points of time is a no-go.

But if a Performance has a notion of a starting time (possibly unset), and  
that notion is filled in from the output definition when available and  
otherwise by the first walker (probably quite similar to your first patch)  
then I think that we have the availability of well-defined behavior covered  
well enough that we don't really need to mess with the Global context and  
first_mom to be "more accurate" when the user says "I cannot actually be  
bothered of pinning a definite behavior down".

Devon, does that sound like something you could get behind?  It would  
likely avoid restructuring the code for a tighter interaction between  
Global and Performance.  It might be that we want that anyway at some point  
of time but I don't feel comfortable making a definite judgment about that,  
and I think the basic plan I outlined seems sound without it.

--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings