Re: Span_dynamic_performer
I forgot to say: The way LilyPond is designed today, you can only have
one MIDI instrument within each MIDI track, which means that the
solution I propose below will work for a PianoStaff but if you try the
same trick on a GrandStaff containing several staves with different
instruments, then your MIDI output will use the same instrument for
all of them.
/Mats
Mats Bengtsson wrote:
Stephen wrote:
Note also that these bugs have low priority among developers, since
there are
plans to rewrite the midi system from scratch.
My comments can be taken two ways, as suggestions for a rewrite of
span-dynamic-performer.cc or as a wish-list for the new
implementation. If I where to contribute to the new implementation, I
would need to start by analysing the drawbacks of the current
implementation of midi in Lilypond. When it comes to things like this,
I fail to see the distinction. We learn from each other, hopefully.
One thing I want to do in midi is to say:
\remove Voice.Span_dynamic_performer
\consists PianoStaff.Span_dynamic_performer
to controll the scope of the dynamic changes, whether they only affect
the voice, the staff, the piano part, of the entire score. I don't
know if that is possible yet.
That will give technical problem, since each Staff context in the .ly
file will translate into one MIDI track (I hope I remember the correct
terminology here) and as far as I know, the dynamics are set per track
in MIDI. One solution is to redefine the MIDI contexts so that the
full PianoStaff is typeset in the same track. Technically, this means
that the PianoStaff context should be changed to be of type
Staff_performer and that the ordinary Staff context should have type
Performer_group_performer. This is done with the following lines
in your .ly file:
\midi {
\tempo 4=60
\context {
\type Staff_performer
\name PianoStaff
\accepts Staff
\accepts DrumStaff
}
\context {
\type Performer_group_performer
\name Staff
\accepts Voice
\consists Key_performer
\consists Tempo_performer
\consists Time_signature_performer
}
Once you have done that, there's no need to move the Dynamic_performer
or Span_dynamic_performer, since any dynamic setting that will appear
within the same track will affect all the remaining notes in the track.
To see the original context definitions for the MIDI processing, see
the file ly/performer-init.ly
/Mats
--
=
Mats Bengtsson
Signal Processing
Signals, Sensors and Systems
Royal Institute of Technology
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Span_dynamic_performer
Stephen wrote:
Note also that these bugs have low priority among developers, since
there are
plans to rewrite the midi system from scratch.
My comments can be taken two ways, as suggestions for a rewrite of
span-dynamic-performer.cc or as a wish-list for the new implementation.
If I where to contribute to the new implementation, I would need to
start by analysing the drawbacks of the current implementation of midi
in Lilypond. When it comes to things like this, I fail to see the
distinction. We learn from each other, hopefully.
One thing I want to do in midi is to say:
\remove Voice.Span_dynamic_performer
\consists PianoStaff.Span_dynamic_performer
to controll the scope of the dynamic changes, whether they only affect
the voice, the staff, the piano part, of the entire score. I don't know
if that is possible yet.
That will give technical problem, since each Staff context in the .ly
file will translate into one MIDI track (I hope I remember the correct
terminology here) and as far as I know, the dynamics are set per track
in MIDI. One solution is to redefine the MIDI contexts so that the
full PianoStaff is typeset in the same track. Technically, this means
that the PianoStaff context should be changed to be of type
Staff_performer and that the ordinary Staff context should have type
Performer_group_performer. This is done with the following lines
in your .ly file:
\midi {
\tempo 4=60
\context {
\type Staff_performer
\name PianoStaff
\accepts Staff
\accepts DrumStaff
}
\context {
\type Performer_group_performer
\name Staff
\accepts Voice
\consists Key_performer
\consists Tempo_performer
\consists Time_signature_performer
}
Once you have done that, there's no need to move the Dynamic_performer
or Span_dynamic_performer, since any dynamic setting that will appear
within the same track will affect all the remaining notes in the track.
To see the original context definitions for the MIDI processing, see
the file ly/performer-init.ly
/Mats
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Span_dynamic_performer
IIRC, volume is controlled on per-note basis (attack and release; passed
as value parameter to each note on/off command), such that this approach
would not impose any problems. However, almost all other parameters, such
as pitch bend (important for tuning of micro tones), are channel messages,
such that restrictions apply when putting multiple voices into a single track.
Greetings,
Jrgen
On Fri, 15 Apr 2005, Mats Bengtsson wrote:
Stephen wrote:
Note also that these bugs have low priority among developers, since there
are
plans to rewrite the midi system from scratch.
My comments can be taken two ways, as suggestions for a rewrite of
span-dynamic-performer.cc or as a wish-list for the new implementation. If
I where to contribute to the new implementation, I would need to start by
analysing the drawbacks of the current implementation of midi in Lilypond.
When it comes to things like this, I fail to see the distinction. We learn
from each other, hopefully.
One thing I want to do in midi is to say:
\remove Voice.Span_dynamic_performer
\consists PianoStaff.Span_dynamic_performer
to controll the scope of the dynamic changes, whether they only affect the
voice, the staff, the piano part, of the entire score. I don't know if that
is possible yet.
That will give technical problem, since each Staff context in the .ly
file will translate into one MIDI track (I hope I remember the correct
terminology here) and as far as I know, the dynamics are set per track
in MIDI. One solution is to redefine the MIDI contexts so that the
full PianoStaff is typeset in the same track. Technically, this means
that the PianoStaff context should be changed to be of type
Staff_performer and that the ordinary Staff context should have type
Performer_group_performer. This is done with the following lines
in your .ly file:
\midi {
\tempo 4=60
\context {
\type Staff_performer
\name PianoStaff
\accepts Staff
\accepts DrumStaff
}
\context {
\type Performer_group_performer
\name Staff
\accepts Voice
\consists Key_performer
\consists Tempo_performer
\consists Time_signature_performer
}
Once you have done that, there's no need to move the Dynamic_performer
or Span_dynamic_performer, since any dynamic setting that will appear
within the same track will affect all the remaining notes in the track.
To see the original context definitions for the MIDI processing, see
the file ly/performer-init.ly
/Mats
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Span_dynamic_performer
Note also that these bugs have low priority among developers, since there
are
plans to rewrite the midi system from scratch.
My comments can be taken two ways, as suggestions for a rewrite of
span-dynamic-performer.cc or as a wish-list for the new implementation. If I
where to contribute to the new implementation, I would need to start by
analysing the drawbacks of the current implementation of midi in Lilypond.
When it comes to things like this, I fail to see the distinction. We learn
from each other, hopefully.
One thing I want to do in midi is to say:
\remove Voice.Span_dynamic_performer
\consists PianoStaff.Span_dynamic_performer
to controll the scope of the dynamic changes, whether they only affect the
voice, the staff, the piano part, of the entire score. I don't know if that
is possible yet.
Stephen
- Original Message -
From: Erik Sandberg [EMAIL PROTECTED]
To: Stephen [EMAIL PROTECTED]
Cc: Mats Bengtsson [EMAIL PROTECTED];
[EMAIL PROTECTED]; lilypond-devel@gnu.org
Sent: Monday, April 11, 2005 3:43 AM
Subject: Re: Span_dynamic_performer
On Sunday 10 April 2005 15.50, Stephen wrote:
Mats, the output went silent with this:
\tupletUp
\time 4/4
\tempo 4=50
\partial 4
g,8.\mf\ g,16 | c2.\fermata g,8. c16 | e2.\fermata g,8 c |
e4 g,8 c e4 g,8 c | e2.\fermata c8. e16 | g2\ff\ e4 c | g,2.\f
g,8. g,16 | c2.-\markup { \italic \bold morendo } \fermata \bar |.
Note the 'g,8.\mf\' beginning. An absolute dynamic did preceed the
hairpin, but on the same note.
On the same note means at the same time in lilypond; it is not
significant
in which order you write the commands. Due to a bug, the absolute dynamic
must happen _strictly_ before the hairpin, i.e. not at the same time.
Note also that these bugs have low priority among developers, since there
are
plans to rewrite the midi system from scratch. If you want to write a
workaround, I think span-dynamic-performer.cc might be a good file to hack
(no guarantees though).
Erik
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Span_dynamic_performer
I am not a lilypond hacker (just an user, bug admin and hacker wannabe). However, I could suggest you to start with a grep Span_dynamic_performer ly/* scm/* lily/* span-dynamic-performer.cc is the file I want to look at. the structure Audio_dynamic_tuple threw me off. I confused that with a regular tuple. I think if really means just the group of notes within the span. Stephen - Original Message - From: Erik Sandberg [EMAIL PROTECTED] To: Stephen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; lilypond-devel@gnu.org Sent: Sunday, April 10, 2005 3:19 AM Subject: Re: Span_dynamic_performer On Sunday 10 April 2005 05.18, Stephen wrote: It has been my experience that visually it looks better to connect absolute dynamics with a hairpin or to say it the other way around, to connect the hairpin to an absolute dynamic. I am not trying to be difficult. If what you say is true, what the hairpin engraver has been written to perform optimally the hairpin performer has a bug in. Yes, it is certainly a bug. midi-cresc-silence.ly in the bug repository. Usually a hairpin dynamic is placed between one or two absolute dynamics so that the performer of the music knows to gradually shift from one dynamic to the other. Usually in printed music the dynamics and hairpins are lined up with each other vertically in this case. I learned that an easy way to make a hairpin line up with an absolute dynamic is attach the start or end of the hairpin to the same note as the dynamic. So if this messes up the midi, it is very unfortunate, 'cause it is more important to makr it look good. There is one possible workaround: Create 2 scores, one for paper output and one for midi output. In the midi score, add an extra s64\mf before the beginning of each voice. (it's dirty but works) I am not angry, it just takes a lot of words to make clear what I mean. Often the purpose of a hairpin is to modulate the volume between two given dynamics. Clearly the problem is that the hairpin modulates the volume from its start to its endpoint, but really, it should never modulate at its endpoints anyway. When a performer sees a hairpin, he knows to bring it from the dynamic he is already playing at the start of the hairpin to another absolute dynamic at the end of the hairpin. So the modulation should never include, say, the first note of a hairpin. If there are only two notes, it should only change the dynamic of the second note. If the hairpin is attached to only one note, it should only change the dynamics of the notes following the hairpin. Etc. Again, I am curious to know which file this code is in in the sources. I am not a lilypond hacker (just an user, bug admin and hacker wannabe). However, I could suggest you to start with a grep Span_dynamic_performer ly/* scm/* lily/* Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Span_dynamic_performer
Again, I think some of the bugs would be solved by setting the first note in the span to the previous dynamic level or barring that to a default dynamic level and conceptually considering the dynamic change to fall between the notes rather than on the notes. Perhaps extending the last dynamic change past the last note in the tuple. Sort of offsetting the dynamic changes by a half of a note. Stephen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Span_dynamic_performer
On Sunday 10 April 2005 15.50, Stephen wrote:
Mats, the output went silent with this:
\tupletUp
\time 4/4
\tempo 4=50
\partial 4
g,8.\mf\ g,16 | c2.\fermata g,8. c16 | e2.\fermata g,8 c |
e4 g,8 c e4 g,8 c | e2.\fermata c8. e16 | g2\ff\ e4 c | g,2.\f
g,8. g,16 | c2.-\markup { \italic \bold morendo } \fermata \bar |.
Note the 'g,8.\mf\' beginning. An absolute dynamic did preceed the
hairpin, but on the same note.
On the same note means at the same time in lilypond; it is not significant
in which order you write the commands. Due to a bug, the absolute dynamic
must happen _strictly_ before the hairpin, i.e. not at the same time.
Note also that these bugs have low priority among developers, since there are
plans to rewrite the midi system from scratch. If you want to write a
workaround, I think span-dynamic-performer.cc might be a good file to hack
(no guarantees though).
Erik
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Span_dynamic_performer
That's true. I can't think of any solution other than to assume mf in the absence of any dynamic indication. Stephen - Original Message - From: David Rogers [EMAIL PROTECTED] To: lilypond-devel@gnu.org Sent: Sunday, April 10, 2005 11:55 AM Subject: Re: Span_dynamic_performer Stephen wrote: 2) We are talking about an impractical example here, cresc\decresc marks do not make any sense withtout an absolute dynamic preceeding it. I don't think this is necessarily the case. A score could easily have markup text Fairly quiet at the beginning, followed later by a crescendo. David ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Span_dynamic_performer
On Sunday 10 April 2005 05.18, Stephen wrote: It has been my experience that visually it looks better to connect absolute dynamics with a hairpin or to say it the other way around, to connect the hairpin to an absolute dynamic. I am not trying to be difficult. If what you say is true, what the hairpin engraver has been written to perform optimally the hairpin performer has a bug in. Yes, it is certainly a bug. midi-cresc-silence.ly in the bug repository. Usually a hairpin dynamic is placed between one or two absolute dynamics so that the performer of the music knows to gradually shift from one dynamic to the other. Usually in printed music the dynamics and hairpins are lined up with each other vertically in this case. I learned that an easy way to make a hairpin line up with an absolute dynamic is attach the start or end of the hairpin to the same note as the dynamic. So if this messes up the midi, it is very unfortunate, 'cause it is more important to makr it look good. There is one possible workaround: Create 2 scores, one for paper output and one for midi output. In the midi score, add an extra s64\mf before the beginning of each voice. (it's dirty but works) I am not angry, it just takes a lot of words to make clear what I mean. Often the purpose of a hairpin is to modulate the volume between two given dynamics. Clearly the problem is that the hairpin modulates the volume from its start to its endpoint, but really, it should never modulate at its endpoints anyway. When a performer sees a hairpin, he knows to bring it from the dynamic he is already playing at the start of the hairpin to another absolute dynamic at the end of the hairpin. So the modulation should never include, say, the first note of a hairpin. If there are only two notes, it should only change the dynamic of the second note. If the hairpin is attached to only one note, it should only change the dynamics of the notes following the hairpin. Etc. Again, I am curious to know which file this code is in in the sources. I am not a lilypond hacker (just an user, bug admin and hacker wannabe). However, I could suggest you to start with a grep Span_dynamic_performer ly/* scm/* lily/* Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Span_dynamic_performer
Just to clarify Erik's initial answer. The problem that the MIDI output goes silent after a (de)crescendo only happens for voices where there hasn't been any absolute dynamics at all before the hairpin. It doesn't matter if the absolute dynamics is 10 measures before or on the same note. However, it seems that you refer to another problem/feature, namely that in the printed output, the hairpin and the absolute dynamic will not be vertically aligned unless the start or end of the hairpin is on the same note as the absolute dynamics. Of course this is completely unrelated to the MIDI issue. /Mats Stephen wrote: It has been my experience that visually it looks better to connect absolute dynamics with a hairpin or to say it the other way around, to connect the hairpin to an absolute dynamic. I am not trying to be difficult. If what you say is true, what the hairpin engraver has been written to perform optimally the hairpin performer has a bug in. Usually a hairpin dynamic is placed between one or two absolute dynamics so that the performer of the music knows to gradually shift from one dynamic to the other. Usually in printed music the dynamics and hairpins are lined up with each other vertically in this case. I learned that an easy way to make a hairpin line up with an absolute dynamic is attach the start or end of the hairpin to the same note as the dynamic. So if this messes up the midi, it is very unfortunate, 'cause it is more important to makr it look good. I am not angry, it just takes a lot of words to make clear what I mean. Often the purpose of a hairpin is to modulate the volume between two given dynamics. Clearly the problem is that the hairpin modulates the volume from its start to its endpoint, but really, it should never modulate at its endpoints anyway. When a performer sees a hairpin, he knows to bring it from the dynamic he is already playing at the start of the hairpin to another absolute dynamic at the end of the hairpin. So the modulation should never include, say, the first note of a hairpin. If there are only two notes, it should only change the dynamic of the second note. If the hairpin is attached to only one note, it should only change the dynamics of the notes following the hairpin. Etc. Again, I am curious to know which file this code is in in the sources. Stephen - Original Message - From: Erik Sandberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Stephen [EMAIL PROTECTED]; lilypond-devel@gnu.org Sent: Saturday, April 09, 2005 4:50 PM Subject: Re: Span_dynamic_performer On Saturday 09 April 2005 23.10, Erik Sandberg wrote: On Saturday 09 April 2005 15.19, Stephen wrote: Known bug. You need to add an AbsoluteDynamicEvent (using e.g. \f) before any cresc or dim can be used. See scm/define-music-types.scm for ideas. Erik Actually, this is the piece that sent me looking for a solution. Perhaps because I am using Lilypond 2.4.3? No, it's the same problem with 2.5. The problem in your piece is another bug, midi-cresc-subp in cvs. Absolute dynamics don't work when they collide with start/end of cresc or dim. Oops, I was a bit wrong. The actual problem is that cresc.s create silence if there is no absolute dynamic _strictly_ before them. Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Span_dynamic_performer
Mats, the output went silent with this:
\tupletUp
\time 4/4
\tempo 4=50
\partial 4
g,8.\mf\ g,16 | c2.\fermata g,8. c16 | e2.\fermata g,8 c |
e4 g,8 c e4 g,8 c | e2.\fermata c8. e16 | g2\ff\ e4 c | g,2.\f
g,8. g,16 | c2.-\markup { \italic \bold morendo } \fermata \bar |.
Note the 'g,8.\mf\' beginning. An absolute dynamic did preceed the hairpin,
but on the same note.
Stephen
- Original Message -
From: Mats Bengtsson [EMAIL PROTECTED]
To: Stephen [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; lilypond-devel@gnu.org
Sent: Sunday, April 10, 2005 5:02 AM
Subject: Re: Span_dynamic_performer
Just to clarify Erik's initial answer. The problem that the MIDI output
goes silent after a
(de)crescendo only happens for voices where there hasn't been any absolute
dynamics at
all before the hairpin. It doesn't matter if the absolute dynamics is 10
measures before or
on the same note.
However, it seems that you refer to another problem/feature, namely that
in the printed
output, the hairpin and the absolute dynamic will not be vertically
aligned unless
the start or end of the hairpin is on the same note as the absolute
dynamics. Of course
this is completely unrelated to the MIDI issue.
/Mats
Stephen wrote:
It has been my experience that visually it looks better to connect
absolute dynamics with a hairpin or to say it the other way around, to
connect the hairpin to an absolute dynamic. I am not trying to be
difficult. If what you say is true, what the hairpin engraver has been
written to perform optimally the hairpin performer has a bug in.
Usually a hairpin dynamic is placed between one or two absolute dynamics
so that the performer of the music knows to gradually shift from one
dynamic to the other. Usually in printed music the dynamics and hairpins
are lined up with each other vertically in this case. I learned that an
easy way to make a hairpin line up with an absolute dynamic is attach the
start or end of the hairpin to the same note as the dynamic. So if this
messes up the midi, it is very unfortunate, 'cause it is more important
to makr it look good.
I am not angry, it just takes a lot of words to make clear what I mean.
Often the purpose of a hairpin is to modulate the volume between two
given dynamics. Clearly the problem is that the hairpin modulates the
volume from its start to its endpoint, but really, it should never
modulate at its endpoints anyway. When a performer sees a hairpin, he
knows to bring it from the dynamic he is already playing at the start of
the hairpin to another absolute dynamic at the end of the hairpin. So the
modulation should never include, say, the first note of a hairpin. If
there are only two notes, it should only change the dynamic of the second
note. If the hairpin is attached to only one note, it should only change
the dynamics of the notes following the hairpin. Etc.
Again, I am curious to know which file this code is in in the sources.
Stephen
- Original Message - From: Erik Sandberg
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Stephen [EMAIL PROTECTED]; lilypond-devel@gnu.org
Sent: Saturday, April 09, 2005 4:50 PM
Subject: Re: Span_dynamic_performer
On Saturday 09 April 2005 23.10, Erik Sandberg wrote:
On Saturday 09 April 2005 15.19, Stephen wrote:
Known bug. You need to add an AbsoluteDynamicEvent (using e.g. \f)
before any
cresc or dim can be used. See scm/define-music-types.scm for ideas.
Erik
Actually, this is the piece that sent me looking for a solution.
Perhaps
because I am using Lilypond 2.4.3?
No, it's the same problem with 2.5.
The problem in your piece is another bug, midi-cresc-subp in cvs.
Absolute
dynamics don't work when they collide with start/end of cresc or dim.
Oops, I was a bit wrong. The actual problem is that cresc.s create
silence if
there is no absolute dynamic _strictly_ before them.
Erik
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Span_dynamic_performer
Searching for the performers and engravers works for learning how to insert usable scheme code in the lilypond files, but the code that actually decides which midi volume levels to set where is not in the performer. For instance, absolute-volume-alist: #(set! absolute-volume-alist (append '( (sf . 1.00) (f . 0.95) ( . 0.90) (fff . 0.85) (ff . 0.80) (f . 0.75) (mf . 0.68) (mp . 0.61) (p . 0.55) (pp . 0.49) (ppp . 0.42) ( . 0.35) (p . 0.28) ) absolute-volume-alist)) can be set to determine the relative values of the absolute dynamic marks, but midi volume levels do not range from 0 to 1. There must be a place where the values are converted to midi volume values, but it is more difficult to trace which function is using the info in the absolute-volume-alist than it is to search for the engravers and performers in the sources. Stephen - Original Message - From: Erik Sandberg [EMAIL PROTECTED] To: Stephen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; lilypond-devel@gnu.org Sent: Sunday, April 10, 2005 3:19 AM Subject: Re: Span_dynamic_performer On Sunday 10 April 2005 05.18, Stephen wrote: It has been my experience that visually it looks better to connect absolute dynamics with a hairpin or to say it the other way around, to connect the hairpin to an absolute dynamic. I am not trying to be difficult. If what you say is true, what the hairpin engraver has been written to perform optimally the hairpin performer has a bug in. Yes, it is certainly a bug. midi-cresc-silence.ly in the bug repository. Usually a hairpin dynamic is placed between one or two absolute dynamics so that the performer of the music knows to gradually shift from one dynamic to the other. Usually in printed music the dynamics and hairpins are lined up with each other vertically in this case. I learned that an easy way to make a hairpin line up with an absolute dynamic is attach the start or end of the hairpin to the same note as the dynamic. So if this messes up the midi, it is very unfortunate, 'cause it is more important to makr it look good. There is one possible workaround: Create 2 scores, one for paper output and one for midi output. In the midi score, add an extra s64\mf before the beginning of each voice. (it's dirty but works) I am not angry, it just takes a lot of words to make clear what I mean. Often the purpose of a hairpin is to modulate the volume between two given dynamics. Clearly the problem is that the hairpin modulates the volume from its start to its endpoint, but really, it should never modulate at its endpoints anyway. When a performer sees a hairpin, he knows to bring it from the dynamic he is already playing at the start of the hairpin to another absolute dynamic at the end of the hairpin. So the modulation should never include, say, the first note of a hairpin. If there are only two notes, it should only change the dynamic of the second note. If the hairpin is attached to only one note, it should only change the dynamics of the notes following the hairpin. Etc. Again, I am curious to know which file this code is in in the sources. I am not a lilypond hacker (just an user, bug admin and hacker wannabe). However, I could suggest you to start with a grep Span_dynamic_performer ly/* scm/* lily/* Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Span_dynamic_performer
There is one possible workaround: Create 2 scores, one for paper output and one for midi output. In the midi score, add an extra s64\mf before the beginning of each voice. (it's dirty but works) I thought about it some more: 1) I would like to see the algorhythm that needs an absolute dynamic before the cresc\decresc mark. 2) We are talking about an impractical example here, cresc\decresc marks do not make any sense withtout an absolute dynamic preceeding it. None of my musical examples have that, so this cannot be the real problem. Again, I would like to see where in the code this is actually happening. (i.e., not where the error occurs, but where the midi volume values are determined.) Stephen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Span_dynamic_performer
Stephen wrote: 2) We are talking about an impractical example here, cresc\decresc marks do not make any sense withtout an absolute dynamic preceeding it. I don't think this is necessarily the case. A score could easily have markup text Fairly quiet at the beginning, followed later by a crescendo. David ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Span_dynamic_performer
Known bug. You need to add an AbsoluteDynamicEvent (using e.g. \f) before
any
cresc or dim can be used. See scm/define-music-types.scm for ideas.
Erik
Actually, this is the piece that sent me looking for a solution. Perhaps
because I am using Lilypond 2.4.3?
Stephen
attachment: taps-page1.pngtaps = {
#(define-public absolute-volume-alist '())
#(set! absolute-volume-alist
(append
'(
(sf . 1.00)
(f . 0.95)
( . 0.90)
(fff . 0.85)
(ff . 0.80)
(f . 0.75)
(mf . 0.68)
(mp . 0.61)
(p . 0.55)
(pp . 0.49)
(ppp . 0.42)
( . 0.35)
(p . 0.28)
)
absolute-volume-alist))
#(define-public (dynamic-absolute-volume s)
(let ((entry (assoc s absolute-volume-alist)))
(if entry
(cdr entry
\set Voice.dynamicAbsoluteVolumeFunction = #dynamic-absolute-volume
#(define-public instrument-equalizer-alist '())
#(set! instrument-equalizer-alist
(append
'(
(flute . (0 . 0.7))
(oboe . (0 . 0.7))
(clarinet . (0 . 0.7))
(bassoon . (0 . 0.6))
(french horn . (0.1 . 0.7))
(trumpet . (0.1 . 0.8))
(timpani . (0.2 . 0.9))
(violin . (0.2 . 1.0))
(viola . (0.1 . 0.7))
(cello . (0.2 . 0.8))
(contrabass . (0.2 . 0.8))
)
instrument-equalizer-alist))
#(define-public (instrument-equalizer s)
(let ((entry (assoc s instrument-equalizer-alist)))
(if entry
(cdr entry
\set Voice.instrumentEqualizer = #instrument-equalizer
\set midiMinimumVolume = #0.20
\set midiMaximumVolume = #1.00
\set Staff.midiInstrument = trumpet
#(override-auto-beam-setting '(end 1 16 4 4) 1 2 'Staff)
#(override-auto-beam-setting '(end 1 8 2 4) 1 2 'Staff)
\override TupletBracket #'bracket-visibility = ##f
\tupletUp
\time 4/4
\tempo 4=50
\partial 4
g,8.\mf\ g,16 | c2.\fermata g,8. c16 | e2.\fermata g,8 c |
e4 g,8 c e4 g,8 c | e2.\fermata c8. e16 | g2\ff\ e4 c | g,2.\f
g,8. g,16 | c2.-\markup { \italic \bold morendo } \fermata \bar |.
}
\paper {
#(set-paper-size letter 'landscape)
hsize = 139.7\mm
vsize = 215.9\mm
linewidth = 122\mm
indent = 0\mm
}
\score {
\header { piece = Taps }
\transpose c c'' { \taps }
\layout { }
\midi {
\context { \Voice \remove Span_dynamic_performer }
}
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Span_dynamic_performer
On Saturday 09 April 2005 15.19, Stephen wrote: Known bug. You need to add an AbsoluteDynamicEvent (using e.g. \f) before any cresc or dim can be used. See scm/define-music-types.scm for ideas. Erik Actually, this is the piece that sent me looking for a solution. Perhaps because I am using Lilypond 2.4.3? No, it's the same problem with 2.5. The problem in your piece is another bug, midi-cresc-subp in cvs. Absolute dynamics don't work when they collide with start/end of cresc or dim. Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Span_dynamic_performer
On Saturday 09 April 2005 23.10, Erik Sandberg wrote: On Saturday 09 April 2005 15.19, Stephen wrote: Known bug. You need to add an AbsoluteDynamicEvent (using e.g. \f) before any cresc or dim can be used. See scm/define-music-types.scm for ideas. Erik Actually, this is the piece that sent me looking for a solution. Perhaps because I am using Lilypond 2.4.3? No, it's the same problem with 2.5. The problem in your piece is another bug, midi-cresc-subp in cvs. Absolute dynamics don't work when they collide with start/end of cresc or dim. Oops, I was a bit wrong. The actual problem is that cresc.s create silence if there is no absolute dynamic _strictly_ before them. Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Span_dynamic_performer
It has been my experience that visually it looks better to connect absolute dynamics with a hairpin or to say it the other way around, to connect the hairpin to an absolute dynamic. I am not trying to be difficult. If what you say is true, what the hairpin engraver has been written to perform optimally the hairpin performer has a bug in. Usually a hairpin dynamic is placed between one or two absolute dynamics so that the performer of the music knows to gradually shift from one dynamic to the other. Usually in printed music the dynamics and hairpins are lined up with each other vertically in this case. I learned that an easy way to make a hairpin line up with an absolute dynamic is attach the start or end of the hairpin to the same note as the dynamic. So if this messes up the midi, it is very unfortunate, 'cause it is more important to makr it look good. I am not angry, it just takes a lot of words to make clear what I mean. Often the purpose of a hairpin is to modulate the volume between two given dynamics. Clearly the problem is that the hairpin modulates the volume from its start to its endpoint, but really, it should never modulate at its endpoints anyway. When a performer sees a hairpin, he knows to bring it from the dynamic he is already playing at the start of the hairpin to another absolute dynamic at the end of the hairpin. So the modulation should never include, say, the first note of a hairpin. If there are only two notes, it should only change the dynamic of the second note. If the hairpin is attached to only one note, it should only change the dynamics of the notes following the hairpin. Etc. Again, I am curious to know which file this code is in in the sources. Stephen - Original Message - From: Erik Sandberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Stephen [EMAIL PROTECTED]; lilypond-devel@gnu.org Sent: Saturday, April 09, 2005 4:50 PM Subject: Re: Span_dynamic_performer On Saturday 09 April 2005 23.10, Erik Sandberg wrote: On Saturday 09 April 2005 15.19, Stephen wrote: Known bug. You need to add an AbsoluteDynamicEvent (using e.g. \f) before any cresc or dim can be used. See scm/define-music-types.scm for ideas. Erik Actually, this is the piece that sent me looking for a solution. Perhaps because I am using Lilypond 2.4.3? No, it's the same problem with 2.5. The problem in your piece is another bug, midi-cresc-subp in cvs. Absolute dynamics don't work when they collide with start/end of cresc or dim. Oops, I was a bit wrong. The actual problem is that cresc.s create silence if there is no absolute dynamic _strictly_ before them. Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Span_dynamic_performer
On Friday 08 April 2005 16.09, Stephen wrote:
crescendos and decrescendos bring the dynamic level to near or below
audible in my midi files. This is a known bug in midi?
My solution for now is using the following line for the midi block:
\midi { \context { \Voice \remove Span_dynamic_performer } }
I am focusing on midi because Mutopia expects a the lilypond files
submitted there to produce midi files. Given the state of midi in lilypond,
it may be premature to make that a requirement, but it is.
Known bug. You need to add an AbsoluteDynamicEvent (using e.g. \f) before any
cresc or dim can be used. See scm/define-music-types.scm for ideas.
Erik
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
