unexpected \unfoldRepeats behavior

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

unexpected \unfoldRepeats behavior

Mark Polesky

I tried to answer a question on -user but hit a brick wall.
\unfoldRepeats failed to work when the music block was funneled from 2
separate expressions. Can someone explain this to me? Why does the
following code work for voiceA but not for voiceB?

Thanks.
- Mark

_____________________________________


\version "2.13.1"

voiceA = \new Voice = "A" \relative {
  \time 1/4
  \repeat volta 2 { a' }
  \alternative { { b } { c } }
}


% voiceB is built from 2 separate expressions funneled into one voice,
% but otherwise ought to be identical to voiceA, it seems:
voiceBrepeats = {
  \time 1/4
  \repeat volta 2 { s }
  \alternative { { s } { s } }
}
voiceBnotes = \relative { \time 1/4 a' b c }
voiceB = \new Voice = "B" { << \voiceBrepeats \voiceBnotes >> }


% using \unfoldRepeats produces the expected MIDI output with voiceA,
% but not with voiceB. Why?
\score {
  \unfoldRepeats \voiceA % change to \voiceB to test.
  \midi { }
}


     


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: unexpected \unfoldRepeats behavior

Jay Anderson
On Sat, Jun 6, 2009 at 3:22 AM, Mark Polesky<[hidden email]> wrote:

>
> I tried to answer a question on -user but hit a brick wall.
> \unfoldRepeats failed to work when the music block was funneled from 2
> separate expressions. Can someone explain this to me? Why does the
> following code work for voiceA but not for voiceB?
>
> Thanks.
> - Mark
>
> _____________________________________
>
>
> \version "2.13.1"
>
> voiceA = \new Voice = "A" \relative {
>  \time 1/4
>  \repeat volta 2 { a' }
>  \alternative { { b } { c } }
> }
>
>
> % voiceB is built from 2 separate expressions funneled into one voice,
> % but otherwise ought to be identical to voiceA, it seems:
> voiceBrepeats = {
>  \time 1/4
>  \repeat volta 2 { s }
>  \alternative { { s } { s } }
> }
> voiceBnotes = \relative { \time 1/4 a' b c }
> voiceB = \new Voice = "B" { << \voiceBrepeats \voiceBnotes >> }
>
>
> % using \unfoldRepeats produces the expected MIDI output with voiceA,
> % but not with voiceB. Why?
> \score {
>  \unfoldRepeats \voiceA % change to \voiceB to test.
>  \midi { }
> }

This is the expected behavior. Only the spacers will be unfolded in
voiceB. The repeat needs to be around the actual notes. Use
\displayMusic and you'll see why.

If you really do want this to work you're going to need some sort of
flatten function: '\flatten << \voiceBrepeats \voiceBnotes >>' which
would recursively combine the contents of nested parallel sections
into one SequentialMusic section. This would be tricky. It's easiest
to just put the repeats in all voices.

------Jay


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: unexpected \unfoldRepeats behavior

Paul Scott-3
Jay Anderson wrote:

> On Sat, Jun 6, 2009 at 3:22 AM, Mark Polesky<[hidden email]> wrote:
>  
>> I tried to answer a question on -user but hit a brick wall.
>> \unfoldRepeats failed to work when the music block was funneled from 2
>> separate expressions. Can someone explain this to me? Why does the
>> following code work for voiceA but not for voiceB?
>>
>> Thanks.
>> - Mark
>>
>> _____________________________________
>>
>>
>> \version "2.13.1"
>>
>> voiceA = \new Voice = "A" \relative {
>>  \time 1/4
>>  \repeat volta 2 { a' }
>>  \alternative { { b } { c } }
>> }
>>
>>
>> % voiceB is built from 2 separate expressions funneled into one voice,
>> % but otherwise ought to be identical to voiceA, it seems:
>> voiceBrepeats = {
>>  \time 1/4
>>  \repeat volta 2 { s }
>>  \alternative { { s } { s } }
>> }
>> voiceBnotes = \relative { \time 1/4 a' b c }
>> voiceB = \new Voice = "B" { << \voiceBrepeats \voiceBnotes >> }
>>
>>
>> % using \unfoldRepeats produces the expected MIDI output with voiceA,
>> % but not with voiceB. Why?
>> \score {
>>  \unfoldRepeats \voiceA % change to \voiceB to test.
>>  \midi { }
>> }
>>    
>
> This is the expected behavior. Only the spacers will be unfolded in
> voiceB. The repeat needs to be around the actual notes. Use
> \displayMusic and you'll see why.
>
> If you really do want this to work you're going to need some sort of
> flatten function: '\flatten << \voiceBrepeats \voiceBnotes >>' which
> would recursively combine the contents of nested parallel sections
> into one SequentialMusic section. This would be tricky. It's easiest
> to just put the repeats in all voices.
>  

Which is kind of ridiculous if you're writing an ensemble piece with
many (even more than one) voices/parts.  How can a midi of a multi-voice
work with any repeats be done?  

I don't mind having a separate file for the midi output but not being
able to factor out the common timing and dynamics costs a lot of input
time and makes it a lot harder to make sure I haven't dropped a bar
somewhere.

Paul Scott





_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: unexpected \unfoldRepeats behavior

Jay Anderson
On Sat, Jun 6, 2009 at 4:53 PM, Paul Scott<[hidden email]> wrote:
> Which is kind of ridiculous if you're writing an ensemble piece with many
> (even more than one) voices/parts.  How can a midi of a multi-voice work
> with any repeats be done?

I was working on a large score and originally kept the repeat
structure separate from the individual parts and ran into the same
unfold-not-working problem. I thought about this a bit and decided it
was best just to have the repeats in each part. If you're going to
make a change to the repeat structure you're almost always going to
have to change each part/voice to match. Since this is the case it
makes sense to have the repeat structure in each part. If for nothing
else it makes it easy to find the beginnings and ends of repeats in
each part.

> I don't mind having a separate file for the midi output but not being able
> to factor out the common timing and dynamics costs a lot of input time and
> makes it a lot harder to make sure I haven't dropped a bar somewhere.

Actually I found that having the repeats in each part made it easier
to notice that bars were off. Lilypond throws errors where it thinks
the repeat timing problem is without having to look too much at the
pdf output.

-----Jay


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: unexpected \unfoldRepeats behavior

David Kastrup
Jay Anderson <[hidden email]> writes:

> On Sat, Jun 6, 2009 at 4:53 PM, Paul Scott<[hidden email]> wrote:
>
>> I don't mind having a separate file for the midi output but not being
>> able to factor out the common timing and dynamics costs a lot of
>> input time and makes it a lot harder to make sure I haven't dropped a
>> bar somewhere.
>
> Actually I found that having the repeats in each part made it easier
> to notice that bars were off. Lilypond throws errors where it thinks
> the repeat timing problem is without having to look too much at the
> pdf output.

There is no point in offering a half-broken feature and not fix it,
claiming that it was a bad idea in the first place.

So either the external repeat structure feature should be removed or
fixed.  Everything else is asking for trouble and problem reports and is
causing the users headaches for no good reason.

--
David Kastrup



_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: unexpected \unfoldRepeats behavior

Paul Scott-3
In reply to this post by Jay Anderson
Jay Anderson wrote:

> On Sat, Jun 6, 2009 at 4:53 PM, Paul Scott<[hidden email]> wrote:
>  
>> Which is kind of ridiculous if you're writing an ensemble piece with many
>> (even more than one) voices/parts.  How can a midi of a multi-voice work
>> with any repeats be done?
>>    
>
> I was working on a large score and originally kept the repeat
> structure separate from the individual parts and ran into the same
> unfold-not-working problem.

I don't need MIDIs that often.  Until it is established that this is a
bug or the intended result I can get any MIDIs that I need by defining
each section for each part as a separate definition that I can assemble
as needed for the two different purposes.
> I thought about this a bit and decided it
> was best just to have the repeats in each part. If you're going to
> make a change to the repeat structure you're almost always going to
> have to change each part/voice to match. Since this is the case it
> makes sense to have the repeat structure in each part.

*If* this is the case.  I am most often working with a structure already
determined by the composer who is not me.  I often create corrected or
easier to read ensemble parts or parts for people who don't do the
doubling that the original parts call for.
> If for nothing
> else it makes it easy to find the beginnings and ends of repeats in
> each part.
>  

I put bar numbers or other references when needed.

>  
>> I don't mind having a separate file for the midi output but not being able
>> to factor out the common timing and dynamics costs a lot of input time and
>> makes it a lot harder to make sure I haven't dropped a bar somewhere.
>>    
>
> Actually I found that having the repeats in each part made it easier
> to notice that bars were off. Lilypond throws errors where it thinks
> the repeat timing problem is without having to look too much at the
> pdf output.
>  

My first pass at most of what I do is to create the global timing
section.  I then know by the rehearsal marks, etc. whether I have
skipped some bars in the input of the music.

I will now reread the documentation on unfoldRepeats to see if I should
go any farther with this.

Thanks,

Paul




_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: unexpected \unfoldRepeats behavior

Trevor Daniels
In reply to this post by David Kastrup

David Kastrup wrote Sunday, June 07, 2009 8:22 AM


> Jay Anderson <[hidden email]> writes:
>
>> On Sat, Jun 6, 2009 at 4:53 PM, Paul Scott<[hidden email]>
>> wrote:
>>
>>> I don't mind having a separate file for the midi output but not
>>> being
>>> able to factor out the common timing and dynamics costs a lot of
>>> input time and makes it a lot harder to make sure I haven't
>>> dropped a
>>> bar somewhere.
>>
>> Actually I found that having the repeats in each part made it
>> easier
>> to notice that bars were off. Lilypond throws errors where it
>> thinks
>> the repeat timing problem is without having to look too much at
>> the
>> pdf output.
>
> There is no point in offering a half-broken feature and not fix
> it,
> claiming that it was a bad idea in the first place.

It's not really broken.  \unfoldRepeats simply
changes all repeats to \unfoldRepeats.  If no
repeat appears in a section of music clearly it
can't be changed.  Perhaps the Reference Manual
should be clearer on this point, although it is
stated in section 3.5.4 Repeats in MIDI.

> So either the external repeat structure feature should be removed
> or
> fixed.  Everything else is asking for trouble and problem reports
> and is
> causing the users headaches for no good reason.

No.  The extra functionality you're requesting
may be useful, but it's lack not a case for
removing a perfectly good and useful feature.

Trevor



_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel