Re: Map voices to channels in MIDI output
1) re-balancing the instruments (because the new implementation messed up the equalizer) Do you have a test file for that? As far as I can see, the velocity still comes through the equalizer. 2) implementing (de)crescendi on held notes (which sometimes works accidentally in 2.12, due I think to notes in other voices creating volume changes on the held note) Right. In fact, this should do it Segfaults during midi generation. Do you have a .ly file? Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Map voices to channels in MIDI output
Keith OHara schreef op ma 14-03-2011 om 13:50 [-0700]: On Mon, 14 Mar 2011 02:14:14 -0700, Jan Nieuwenhuizen jann...@gnu.org wrote: Midi tracks (from a Staff with midiInstrument) sometimes contain a program change event, sometimes not, depending on the path taken through Staff_performer::acknowledge_audio_element() on the way to new_audio_staff(). Temporary voices create tracks without the program change. If we use the new midiChannelMapping=#'voice, the notes in such voices sound as default piano. A temporary voice, creating a new track, sounds as a piano? The original voice and new temporary voice are in different tracks, but have the same channel number. So, it /is/ possible after all to have two channels 0 that sound as different instruments, in different tracks? Is this without even using ports? That would be great! (Unfortunately for me, the player I formerly used, NotationPlayer, gets confused by Tracks with no program change containing notes directed to a Channel that had an earlier program change.) What exactly do you mean by `confused'? Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regtests crashing?
Keith OHara schreef op di 15-03-2011 om 03:26 [+]: Neil Puttock n.puttock at gmail.com writes: The obvious fix allows make test-baseline to succeed, and could only affect midi, so I pushed it. cc: to Jan in case the 'obvious' was not the intent. That's the right fix, thanks! Greetings, Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
2.13.54 regtests
I've checked both the official page and using my pixel comparator. Both picked up Keith's changes to keep-inside-line settings for the 2 changed tests; a couple of oddities on fret diagrams that I'll detail when I have time later; but no problems that I can see. -- Phil Holmes Bug Squad ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Potential fix for issue 1504. (issue4237057)
On Mon, Mar 14, 2011 at 9:16 AM, m...@apollinemike.com wrote: I've sketched this out using your suggestion above (calculating it once and returning the fraction for the called beam) - nevermind my previous question about redoing calculations. A new patch set is on-line. I still need to do the math for the longer slopes - I'll have time to do that later today or tomorrow. In the spirit of the one-change-per-push idea, I'd like to push the fix to 1504 first before I push the change to feather-direction. Does this seem like a good idea? Do you mean: push an earlier version of this patch first? I think it's not a good idea, because you would rewrite it directly after pushing, cluttering up the history of what is happening. The idea of one-change-per-push is that all the individual changes are independent. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Small doc patch for woodwinds
Could one of the docs people reply w/ LGTM or w/ changes? Thanks! http://codereview.appspot.com/4291047 Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Potential fix for issue 1504. (issue4237057)
http://codereview.appspot.com/4237057/diff/14002/lily/beam.cc File lily/beam.cc (right): http://codereview.appspot.com/4237057/diff/14002/lily/beam.cc#newcode176 lily/beam.cc:176: Beam::calc_feather_widths (SCM smob) actually, you could just call this length-fraction; what's calculated over here is something generic to spanners. You could even move it there. http://codereview.appspot.com/4237057/diff/14002/lily/beam.cc#newcode204 lily/beam.cc:204: SCM temp = scm_cons (scm_from_double (feather_fractions[i][LEFT] / total_width), scm_from_double (feather_fractions[i][RIGHT] / total_width)); can you use a meaningful name? Even a 1 letter name than 'temp' http://codereview.appspot.com/4237057/diff/14002/lily/beam.cc#newcode672 lily/beam.cc:672: to the total length. ? should the total feathering dy be proportional to that? http://codereview.appspot.com/4237057/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Adds woodwind diagrams to changes.tely (issue4291047)
LGTM, go ahead and push. http://codereview.appspot.com/4291047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Potential fix for issue 1504. (issue4237057)
On Mar 15, 2011, at 9:18 AM, Han-Wen Nienhuys wrote: On Tue, Mar 15, 2011 at 10:08 AM, m...@apollinemike.com m...@apollinemike.com wrote: On Mar 15, 2011, at 9:03 AM, Han-Wen Nienhuys wrote: On Mon, Mar 14, 2011 at 9:16 AM, m...@apollinemike.com wrote: I've sketched this out using your suggestion above (calculating it once and returning the fraction for the called beam) - nevermind my previous question about redoing calculations. A new patch set is on-line. I still need to do the math for the longer slopes - I'll have time to do that later today or tomorrow. In the spirit of the one-change-per-push idea, I'd like to push the fix to 1504 first before I push the change to feather-direction. Does this seem like a good idea? Do you mean: push an earlier version of this patch first? I think it's not a good idea, because you would rewrite it directly after pushing, cluttering up the history of what is happening. The idea of one-change-per-push is that all the individual changes are independent. No, I mean that changing the feather-dir property from ly:dir to a pair seems like a different problem than fixing issue 1504. It effectively adds a new feature to lilypond, and thus seems like it should be the object of its own patch/push. However, if you think I Ah right. My proposal was for feather-dir to be used to init feather-fractions (or whatever they're called.) - please do what you think is best, but if you are pushing 2 commits where the 2nd mostly rewrites the 1st, you might as well skip the 1st. I'm going to push the first commit after people sign off on it and then work on the feather-dir bit (w/ the appropriate convert-ly rule). It won't require many rewrites: it'll just require some more math in the calc_feather_fractions function. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Small doc patch for woodwinds
Well, )-Original Message- )From: lilypond-devel-bounces+james.lowe=datacore@gnu.org )[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On )Behalf Of m...@apollinemike.com )Sent: 15 March 2011 13:01 )To: Lily devel )Subject: Small doc patch for woodwinds ) )Could one of the docs people reply w/ LGTM or w/ changes? ) )Thanks! ) )http://codereview.appspot.com/4291047 ) I don't have a problem in theory it all looks ok, unless we want to keep this section as 'text only' - but I'll leave that to Graham to have final say One thing I would probably say is can we make sure that the resulting image isn't too big/tall on the page. Otherwise LGTM James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.13.54 regtests
Phil Holmes m...@philholmes.net wrote in message news:ilnkda$k83$1...@dough.gmane.org... I've checked both the official page and using my pixel comparator. Both picked up Keith's changes to keep-inside-line settings for the 2 changed tests; a couple of oddities on fret diagrams that I'll detail when I have time later; but no problems that I can see. Slightly longer version. There have been extra fret diagrams added to fret-diagrams-fingering and fret-diagrams-fret-label, which I've seen at http://git.savannah.gnu.org/cgit/lilypond.git/ so no problems there. fret-diagrams-landscape is slightly different, because a slightly larger X on the one of the diagrams has pushed the others across a bit. That's it. -- Phil Holmes Bug Squad ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Persistent error on 'make': [Python] ordinal not in range(128)
Hello. This happens on _fresh_ repositories in one of my systems. Clues suggest that my python installation is misconfigured. make[1]: Entering directory `/home/fravd/source/lilypond/Documentation' LILYPOND_VERSION=2.13.54 /usr/bin/python ../scripts/lilypond-book.py -I ./ (...) usage.tely ... UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 24: ordinal not in range(128) So lilypond-book has problems with usage.tely. I have seen this problem sometimes exposed in users list, also related to lilypond-book, and a solution is never given. If somebody has any ideas, I'll thank to hear them. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Added @knownissue to NR for fingering (issue4248081)
Pushed as f93bc90b3ee5e5de96b59c8e81b4ea354d5b1927 Only @knownissue added. Solving issue. http://codereview.appspot.com/4248081/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Map voices to channels in MIDI output
On Tue, 15 Mar 2011 01:50:32 -0700, Jan Nieuwenhuizen jann...@gnu.org wrote: 1) re-balancing the instruments Do you have a test file for that? We have input\regression\midi-volume-equaliser.ly; the equalizer is still effective, but the values will probably need re-balancing if you implemnt dynamics differently. In fact, this should do it Segfaults during midi generation. Do you have a .ly file? Nevermind. I got confused somehow other bug; it looks like what I tested was announce_element (Audio_element_info (audio_staff, 0)); + if (!instrument_string_.empty ()) +set_instrument (channel_, voice); staff_map_[voice] = audio_staff; return audio_staff; Sorry. Using set_instrument() /after/ adding audio_staff to staff_map_[] does work. NotationPlayer is re-assured and plays the midi correctly. If we use the new midiChannelMapping=#'voice, the notes in such voices sound as default piano. A temporary voice, creating a new track, sounds as a piano? The original voice and new temporary voice are in different tracks, but have the same channel number. No no. If we let the temporary Voice use the channel of its Staff then midi players give it the sound already set on that channel (unless the player is 'confused'). If we map new Voices to new channels, midi players sound the new channel as piano, and in the current design there is not yet any means to change the instrument, so there seems no point in having midiChannelMapping=#'voice. What exactly do you mean by `confused'? My 'confused' midi-player would revert the channel Piano sound if a temporary Voice created a new track sharing the channel with existing Voices. This player would sound all Voices on that channel as Piano. Your suggestion to put program changes on these new tracks removes the 'confusion'. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Map voices to channels in MIDI output
Keith OHara schreef op di 15-03-2011 om 13:24 [-0700]: On Tue, 15 Mar 2011 01:50:32 -0700, Jan Nieuwenhuizen jann...@gnu.org wrote: We have input\regression\midi-volume-equaliser.ly; the equalizer is still effective, but the values will probably need re-balancing if you implemnt dynamics differently. Ah, okay. Using set_instrument() /after/ adding audio_staff to staff_map_[] does work. NotationPlayer is re-assured and plays the midi correctly. Good, pushed. No no. If we let the temporary Voice use the channel of its Staff then midi players give it the sound already set on that channel (unless the player is 'confused'). If we map new Voices to new channels, midi players sound the new channel as piano, and in the current design there is not yet any means to change the instrument, so there seems no point in having midiChannelMapping=#'voice. Well, other than that it's the easiest for midi2ly to recreate the ly, and using ports looks like a thing that could be easily supported in midi players like timidity. To create a new track for each voice as we do now, still seems a bit like a kludge to fix MIDI's brokenness. What exactly do you mean by `confused'? My 'confused' midi-player would revert the channel Piano sound if a temporary Voice created a new track sharing the channel with existing Voices. This player would sound all Voices on that channel as Piano. Your suggestion to put program changes on these new tracks removes the 'confusion' Ah, okay. Too bad. Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Potential fix for issue 1504. (issue4237057)
New patch set uploaded. Thanks for the comments, Han-Wen! http://codereview.appspot.com/4237057/diff/14002/lily/beam.cc File lily/beam.cc (right): http://codereview.appspot.com/4237057/diff/14002/lily/beam.cc#newcode176 lily/beam.cc:176: Beam::calc_feather_widths (SCM smob) On 2011/03/15 13:03:36, hanwenn wrote: actually, you could just call this length-fraction; what's calculated over here is something generic to spanners. You could even move it there. Done. http://codereview.appspot.com/4237057/diff/14002/lily/beam.cc#newcode204 lily/beam.cc:204: SCM temp = scm_cons (scm_from_double (feather_fractions[i][LEFT] / total_width), scm_from_double (feather_fractions[i][RIGHT] / total_width)); On 2011/03/15 13:04:39, hanwenn wrote: do you mean interval2scm(feather_factions[i] / total_width) ? Done, but for some reason, the division operator does not work, so I had to separate it out into LEFT and RIGHT. http://codereview.appspot.com/4237057/diff/14002/lily/beam.cc#newcode204 lily/beam.cc:204: SCM temp = scm_cons (scm_from_double (feather_fractions[i][LEFT] / total_width), scm_from_double (feather_fractions[i][RIGHT] / total_width)); On 2011/03/15 13:03:36, hanwenn wrote: can you use a meaningful name? Even a 1 letter name than 'temp' Done. http://codereview.appspot.com/4237057/diff/14002/lily/beam.cc#newcode672 lily/beam.cc:672: to the total length. On 2011/03/15 13:03:36, hanwenn wrote: ? should the total feathering dy be proportional to that? Yes (I think...). http://codereview.appspot.com/4237057/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dot-notehead collision
On Mar 15, 2011, at 6:51 PM, Carl Sorensen wrote:
On 3/15/11 2:59 PM, m...@apollinemike.com m...@apollinemike.com wrote:
On Mar 15, 2011, at 5:04 PM, Phil Holmes wrote:
- Original Message - From: Trevor Daniels t.dani...@treda.co.uk
To: m...@apollinemike.com; lilypond-user lilypond-u...@gnu.org
Sent: Tuesday, March 15, 2011 6:24 PM
Subject: Re: Dot-notehead collision
m...@apollinemike.com wrote Tuesday, March 15, 2011 5:00 PM
\relative c' { \time 3/4 { cis a'4 b fis'2 } \\ { d2. } }
Produces the attached output. Is there a way to get it so that the dot
does not collide with the notehead (w/o resorting to extra offsets and the
like)?
I don't think so. You'll need 'force-hshift.
Trevor
Agreed. I tried a number of other things, but h-shift worked out of the box.
Perhaps a stupid question - in traditional engraving, is there ever an
instance where, in 2 voice polyphony, the note column w/ a downward pointing
stem is placed to the right of note column with an upward pointing stem? I
hacked a solution that does this and it looks much clearer than moving in the
other direction (see attached). However, if it is not Kosher, I'll scrub it.
\relative c' { \time 3/4 { cis a'4 b fis'2 }
\\ { \once \override Voice . NoteColumn #'force-hshift = #1.25 d2. } }
\relative c' { \time 3/4 { cis a'4 b fis'2 }
\\ { \once \override Voice . NoteColumn #'force-hshift = #-1.25 d2. } }
In the words of Read (p. 68) When two separate note-heads are required for
a unison, it is important to differentiate the voices clearly. The note
having its stem *up* (almost invariably the upper voice) is positioned
first, to the left, while the note with the *downward* stem (lower voice,
ususally, goes to the right -- as shown in the previous two lower examples.
The validity of this principle is especially apparent when when the
down-stemmed note is dotted (left-hand example belos). Whe, however, the
upward-stemmed note is dotted, it is positioned to the right so that the dot
will not be obscured (right, below).
So, in my reading of his words, the downward stem is normally to the right
of the upward stem. But if there's a dot, the upward stem will be to the
right of the downward stem to avoid collisions.
So in your example, the first snippet is right, the second snippet is wrong.
This almost exactly matches Read's examples.
HTH,
Carl
[moved to devel from user]
It seems that this should be default output, then. I imagine that it'd be a
4-5 line fix tops (checking for dots durlog, then the shift). Any takers?
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: shortened flags affair, part 7 - downstem full-length 64th and 128th flags
On 3/15/11 3:24 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Hi, there is quite a lot of space between flag and the notehead in case of downstem 64th and 128th notes (at least compared to 16th and 32nd flags). I *suppose* these flags were made this way because they were intended for use with both shortened stems and full-length stems, and if the gaps were smaller, the flags would look bad on shortened stems. However, we are going to have dedicated flags for shorter stems soon, so maybe we want to tweak the design of 64th and 128th downstem flags to something roughly like suggestion.png? I prefer the new ones to the old ones, but I think that all of them need further adjustment. In the words of Read (p. 80) For each additional flag beyond two, the stem is extended by two staff degrees [1 staff space -- my addition], and the new flag is drawn parallel to the previous one(s), with the additional curved line joining the curved line of the first flag. In the 64th and 128th flags currently in the Feta font, the lines are not parallel at all, and I think that makes the flags look unbalanced. Thanks, Carl P.S. Janek, Amazon has used copies of Read in paperback for $9.97. At that price it may be worth purchasing. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Potential fix for issue 1504. (issue4237057)
lgtm
http://codereview.appspot.com/4237057/diff/13002/lily/beam.cc
File lily/beam.cc (right):
http://codereview.appspot.com/4237057/diff/13002/lily/beam.cc#newcode593
lily/beam.cc:593: Interval placements = robust_scm2interval
(me-get_property (normalized-endpoints), Interval (0.0,0.0));
space after ,
http://codereview.appspot.com/4237057/diff/13002/lily/beam.cc#newcode624
lily/beam.cc:624: weights[RIGHT] = 1 - multiplier;
weights.swap() ?
http://codereview.appspot.com/4237057/diff/13002/lily/beam.cc#newcode636
lily/beam.cc:636: + beam_dy * segments[extreme].vertical_count_;
how about
int idx = {i, extreme}
int translations[2]
for (j = 0;j2;j++)
translations[i] = slope * (segments[idx[j]] .. etc)
http://codereview.appspot.com/4237057/diff/13002/lily/spanner.cc
File lily/spanner.cc (right):
http://codereview.appspot.com/4237057/diff/13002/lily/spanner.cc#newcode406
lily/spanner.cc:406: SCM ret = scm_cons (scm_from_double (0.0),
scm_from_double (0.0));
i personally like 'result' better, almost as short, and a full word.
You could init to SCM_EOL instead?
http://codereview.appspot.com/4237057/diff/13002/lily/spanner.cc#newcode433
lily/spanner.cc:433: SCM t = ly_interval2scm (Interval
(unnormalized_endpoints[i][LEFT] / total_width,
unnormalized_endpoints[i][RIGHT] / total_width));
try using interval * 1/width (or 1/width * interval). The operator
overloading for interval is hit and miss. You can add a operator/ if
you want (separate commit)
http://codereview.appspot.com/4237057/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
