Re: fine-tuning new flags - feedback needed
I have created new [PATCH] issue for this: http://code.google.com/p/lilypond/issues/detail?id=1538 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
2011/2/24 Marek Klein ma...@gregoriana.sk I have created new [PATCH] issue for this: http://code.google.com/p/lilypond/issues/detail?id=1538 Thanks for remembering! However, i'm afraid this issue is invalid. We decided to divide this problem and the first part is discussed in http://lists.gnu.org/archive/html/lilypond-devel/2011-02/msg00391.html (i hope to upload a patch for that within a few hours). cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
2011/2/12 Han-Wen Nienhuys hanw...@gmail.com:
2011/2/11 Janek Warchoł lemniskata.bernoull...@gmail.com:
Don't take 32nds as a standard for comparing beams and stems. Due to
its configuration, the 32nd beam has very little room to move
vertically. See for example
\relative {
g32 g[g] a32 a[ a] b32 b32[ b] c32 c32[ c] d32 d[ d] e e[ e] f f[ f]
}
as you can see, there is a discrepancy that goes the other way too.
No, that's a bad example! I mean, to me there's a whole another
problem in what you posted above. The problem is that the stem of
unbeamed notes is lenghtened differently than in case of beamed notes.
Correct; but this is inevitable. The beams has much less ability to
move, since the staffline may not come into the blank space between
the beams.
Yes, the movement is limited. However, in the following example:
{ c64[ c] }
beams span over the upper four lines of the staff, while they could
span over the lower four lines of the staff also (i mean, they could
be moved exactly a staff space lower and it wouldn't cause any
problems). Maybe this should be changed too.
Look at this, it's a more pronounced example: { c32 c[ c] c64 c[ c] }
- the unbeamed stems are lenghtened to middle staff line, while beamed
stems are lenghtened more than that. That's not the case with 8ths and
16ths: { c8 c[ c] c16 c[ c] } looks fine.
In fact, i wondered if this behaviour is correct. My personal opinion
is that it isn't correct, but i have no idea what engraving books say.
In my opinion it should look like attached unbeamedVsBeamed.png .
Can you (or someone else) check this in music engraving books?
good question. I'm not sure I have any of those, but I'll try to look.
In my suggested output shortened 32nd notes with flags are a bit
longer than beamed ones, 8ths are a bit longer or equal, and all other
are equal. No flagged note is shorter than corresponding beamed one.
Are you sure that you haven't switched the files when comparing?
I am sure; the version number is on the bottom. I am looking at the
flag test proofsheet. Compare for example, a'' 8th upstem (3rd line).
The old version pops out, the new version is as long as the beam.
That's true, however compare my proposed output with old output in
case of the notes marked in red here:
http://imagehosting.nu/images/flagtestin.png
What's most interesting is that it's the beamed stems length that
changed (which i didn't touch at all).
I have been messing with the beam scoring; the regtest came out clean,
but we may miss some coverage. Probably it's best to always compare
the same versions (ie. origin/master vs.origin/master + your patch).
Agreed. I have an impression that i did it at least once and the
differencies in beamed notes were present, but i'll check it to make
sure.
I'll have a look to see what changed wrt beaming.
Especially the 8th up flag in shortened position (f'' and higher)
looks stocky rather than elegant and slender. If you let the flag
length overall be longer, it will be easier to maintain the slender
look.
Ah, you mean upstem 8th flag. I thought you were referring to the
downstem 8th flag.
Yes, i agree that upstem 8th flag is shortened quite aggresively.
On one hand, this makes it look more similar to all other shortened
upstem flags. Also, it was easy to code it this way.
On the other hand, it's very different from the old look, and, as you
say, quite stocky.
I don't insist on keeping it this short.
Awesome. Look forward to the new shapes.
The flags would be basically the same, they'll just be assigned to
stems differently.
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
2011/2/5 Janek Warchoł lemniskata.bernoull...@gmail.com:
Overall comments:
* There is no question that this is better for the 32nd and shorter in
forced directions, especially for the head-facing part of the flag.
* It seems to shorten the flags at the tip end too. I'm not sure if
that is desired.
Do you mean the difference marked in attachment (tip difference.png)?
Yes.
If so, its desired. Reasons for the change were:
- old stem length was so big that the unbeamed 32nd note was reaching
a lot higher (half staffspace) than beamed 32nds lying higher on the
staff (see lower note higher stem.png)
Don't take 32nds as a standard for comparing beams and stems. Due to
its configuration, the 32nd beam has very little room to move
vertically. See for example
\relative {
g32 g[g] a32 a[ a] b32 b32[ b] c32 c32[ c] d32 d[ d] e e[ e] f f[ f]
}
as you can see, there is a discrepancy that goes the other way too.
- the stem length and flag characteristic points didn't correspond
nicely to 16th and 64th flags (see red lines in upstem flags
old.png)
Right. While you are talking about the 32nd flag only, my impression
is that after your change, the flags overall are at smaller or at
equal height relative to the corresponding beam. I would like them to
pop out a bit to give a visual balance against the (much heavier)
beam.
In normal non-forced positions, the flags are a little bit taller than
the beamed notes from the same position, and the old version maintains
that for the forced positions too (of course, the beaming quants
sometimes make it less obvious). This effect is gone in your verison
example, it seems all forced stems are getting shorter than the beams.
I cannot say what will happen in real-life situations, but in my
example (flag testing.ly) it's not quite as you say. 2.13.47 output
was like that:
- stems of shortened 8ths, 32nds and 128th with flags were longer than
beamed ones,
- stems of shortened 16ths and 64ths with flags were equal or
*shorter* than beamed ones.
In my suggested output shortened 32nd notes with flags are a bit
longer than beamed ones, 8ths are a bit longer or equal, and all other
are equal. No flagged note is shorter than corresponding beamed one.
Are you sure that you haven't switched the files when comparing?
I am sure; the version number is on the bottom. I am looking at the
flag test proofsheet. Compare for example, a'' 8th upstem (3rd line).
The old version pops out, the new version is as long as the beam. It's
best to look at the beams outside the staff, as the ones inside the
staff are more restricted in allowed positions due to interference
from the stafflines
Of course, it may be that the beaming is not perfect, and should be
adjusted in some situations, but maybe we could solve one problem at a
time? Ie. fix the discrepancy of the 32nd, and improve the shape for
the shortened flags at the note head end? We could try to treat the
tip lengths in a separate patch; possibly beam scoring should be tuned
too.
Is there a way to main
..?
sorry - brainfart. I was going to write maintain the lengths of the old flags
* For the longer (8th, 16th), it trades some voloptuousness for
practicality. I think the overall feel of feta is more on the
exuberant side, so I think we could lessen the effect there, and
lengthen the hooks a bit more.
I'm not sure if i understand what effect you want to achieve. From my
experiments it looks like it won't work well, though. I'll post some
examples tomorrow.
Especially the 8th up flag in shortened position (f'' and higher)
looks stocky rather than elegant and slender. If you let the flag
length overall be longer, it will be easier to maintain the slender
look.
The 16th has the same problem, but much less space to make it still
look slender, so I understand it may not be possible.
* I'm not sure, but it looks like the outer flag of the 64th and 128th
upstem flag seems to pop out a bit. There is a correction for this,
perhaps you uptune that correction for the shorter up flags.
I don't see what you mean.
And by 'outer' do you mean topmost or bottommost?
I mean that the hip_wid_multiplier for the last hook of the flag is
smaller (0.95 vs. 1.0)
% Because of optical illusion, the utmost flag (bottom for
% down-pointing, top for up-pointing) should be smaller than the other
% flags. Adobe Sonata doesn't do this correctly. (Instead they have
% an extension flag, which looks less elegant.)
I have the feeling that the new 64th and 128th upflags have their
utmost hooks be too large.
hope this helps,
--
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
Re: fine-tuning new flags - feedback needed
2011/2/11 Han-Wen Nienhuys hanw...@gmail.com:
2011/2/5 Janek Warchoł lemniskata.bernoull...@gmail.com:
* It seems to shorten the flags at the tip end too. I'm not sure if
that is desired.
Do you mean the difference marked in attachment (tip difference.png)?
Yes.
If so, its desired. Reasons for the change were:
- old stem length was so big that the unbeamed 32nd note was reaching
a lot higher (half staffspace) than beamed 32nds lying higher on the
staff (see lower note higher stem.png)
Don't take 32nds as a standard for comparing beams and stems. Due to
its configuration, the 32nd beam has very little room to move
vertically. See for example
\relative {
g32 g[g] a32 a[ a] b32 b32[ b] c32 c32[ c] d32 d[ d] e e[ e] f f[ f]
}
as you can see, there is a discrepancy that goes the other way too.
No, that's a bad example! I mean, to me there's a whole another
problem in what you posted above. The problem is that the stem of
unbeamed notes is lenghtened differently than in case of beamed notes.
Look at this, it's a more pronounced example: { c32 c[ c] c64 c[ c] }
- the unbeamed stems are lenghtened to middle staff line, while beamed
stems are lenghtened more than that. That's not the case with 8ths and
16ths: { c8 c[ c] c16 c[ c] } looks fine.
In fact, i wondered if this behaviour is correct. My personal opinion
is that it isn't correct, but i have no idea what engraving books say.
In my opinion it should look like attached unbeamedVsBeamed.png .
Can you (or someone else) check this in music engraving books?
- the stem length and flag characteristic points didn't correspond
nicely to 16th and 64th flags (see red lines in upstem flags
old.png)
Right. While you are talking about the 32nd flag only, my impression
is that after your change, the flags overall are at smaller or at
equal height relative to the corresponding beam.
They are at equal height or taller relative to the corresponding beam.
However, there might be an optical illusion going on here and that's
why some unbeamed stems appear shorter than they really are.
It may be necessary to adjust for that.
I would like them to
pop out a bit to give a visual balance against the (much heavier)
beam.
This might be the right thing to do.
In normal non-forced positions, the flags are a little bit taller than
the beamed notes from the same position, and the old version maintains
that for the forced positions too (of course, the beaming quants
sometimes make it less obvious). This effect is gone in your verison
example, it seems all forced stems are getting shorter than the beams.
I cannot say what will happen in real-life situations, but in my
example (flag testing.ly) it's not quite as you say. 2.13.47 output
was like that:
- stems of shortened 8ths, 32nds and 128th with flags were longer than
beamed ones,
- stems of shortened 16ths and 64ths with flags were equal or
*shorter* than beamed ones.
In my suggested output shortened 32nd notes with flags are a bit
longer than beamed ones, 8ths are a bit longer or equal, and all other
are equal. No flagged note is shorter than corresponding beamed one.
Are you sure that you haven't switched the files when comparing?
I am sure; the version number is on the bottom. I am looking at the
flag test proofsheet. Compare for example, a'' 8th upstem (3rd line).
The old version pops out, the new version is as long as the beam.
That's true, however compare my proposed output with old output in
case of the notes marked in red here:
http://imagehosting.nu/images/flagtestin.png
What's most interesting is that it's the beamed stems length that
changed (which i didn't touch at all).
It's best to look at the beams outside the staff, as the ones inside the
staff are more restricted in allowed positions due to interference
from the stafflines
Of course, it may be that the beaming is not perfect, and should be
adjusted in some situations, but maybe we could solve one problem at a
time? Ie. fix the discrepancy of the 32nd, and improve the shape for
the shortened flags at the note head end? We could try to treat the
tip lengths in a separate patch; possibly beam scoring should be tuned
too.
Yes, i agree. We should do one thing at a time. I even see another
issue that can be separated here - the transition in length of
unbeamed notes (the thing illustrated by the second part of the first
system in flag testing).
I'll divide my patch as soon as i resolve some problems that i have
with my git repository (hopefully this will happen tomorrow), and i
think we shall discuss these issues in separate threads.
Is there a way to main
..?
sorry - brainfart. I was going to write maintain the lengths of the old
flags
Ah, ok.
* For the longer (8th, 16th), it trades some voloptuousness for
practicality. I think the overall feel of feta is more on the
exuberant side, so I think we could lessen the effect there, and
lengthen the hooks a bit more.
I'm not sure if i
Re: fine-tuning new flags - feedback needed
2011/2/11 Janek Warchoł lemniskata.bernoull...@gmail.com:
Don't take 32nds as a standard for comparing beams and stems. Due to
its configuration, the 32nd beam has very little room to move
vertically. See for example
\relative {
g32 g[g] a32 a[ a] b32 b32[ b] c32 c32[ c] d32 d[ d] e e[ e] f f[ f]
}
as you can see, there is a discrepancy that goes the other way too.
No, that's a bad example! I mean, to me there's a whole another
problem in what you posted above. The problem is that the stem of
unbeamed notes is lenghtened differently than in case of beamed notes.
Correct; but this is inevitable. The beams has much less ability to
move, since the staffline may not come into the blank space between
the beams.
Look at this, it's a more pronounced example: { c32 c[ c] c64 c[ c] }
- the unbeamed stems are lenghtened to middle staff line, while beamed
stems are lenghtened more than that. That's not the case with 8ths and
16ths: { c8 c[ c] c16 c[ c] } looks fine.
In fact, i wondered if this behaviour is correct. My personal opinion
is that it isn't correct, but i have no idea what engraving books say.
In my opinion it should look like attached unbeamedVsBeamed.png .
Can you (or someone else) check this in music engraving books?
good question. I'm not sure I have any of those, but I'll try to look.
In my suggested output shortened 32nd notes with flags are a bit
longer than beamed ones, 8ths are a bit longer or equal, and all other
are equal. No flagged note is shorter than corresponding beamed one.
Are you sure that you haven't switched the files when comparing?
I am sure; the version number is on the bottom. I am looking at the
flag test proofsheet. Compare for example, a'' 8th upstem (3rd line).
The old version pops out, the new version is as long as the beam.
That's true, however compare my proposed output with old output in
case of the notes marked in red here:
http://imagehosting.nu/images/flagtestin.png
What's most interesting is that it's the beamed stems length that
changed (which i didn't touch at all).
I have been messing with the beam scoring; the regtest came out clean,
but we may miss some coverage. Probably it's best to always compare
the same versions (ie. origin/master vs.origin/master + your patch).
I'll have a look to see what changed wrt beaming.
It's best to look at the beams outside the staff, as the ones inside the
staff are more restricted in allowed positions due to interference
from the stafflines
Of course, it may be that the beaming is not perfect, and should be
adjusted in some situations, but maybe we could solve one problem at a
time? Ie. fix the discrepancy of the 32nd, and improve the shape for
the shortened flags at the note head end? We could try to treat the
tip lengths in a separate patch; possibly beam scoring should be tuned
too.
Yes, i agree. We should do one thing at a time. I even see another
issue that can be separated here - the transition in length of
unbeamed notes (the thing illustrated by the second part of the first
system in flag testing).
I'll divide my patch as soon as i resolve some problems that i have
with my git repository (hopefully this will happen tomorrow), and i
think we shall discuss these issues in separate threads.
Great!
Especially the 8th up flag in shortened position (f'' and higher)
looks stocky rather than elegant and slender. If you let the flag
length overall be longer, it will be easier to maintain the slender
look.
Ah, you mean upstem 8th flag. I thought you were referring to the
downstem 8th flag.
Yes, i agree that upstem 8th flag is shortened quite aggresively.
On one hand, this makes it look more similar to all other shortened
upstem flags. Also, it was easy to code it this way.
On the other hand, it's very different from the old look, and, as you
say, quite stocky.
I don't insist on keeping it this short.
Awesome. Look forward to the new shapes.
--
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
Re: fine-tuning new flags - feedback needed
On Mon, Feb 07, 2011 at 04:16:42PM +0100, Reinhold Kainhofer wrote: My workflow is that I make several commits (i.e. I don't amend) in each feature branch. But before actually merging back to master (or pushing to the server), I do a git rebase -i origin/master +1 My personal workflow (on my PhD stuff) is full of commits like asdf or stop crashing the thing or even just save point. But I (almost) always do a git rebase -i before pushing it to my backup repository. Sadly, git grep rebase -i Documentation/contributor Could somebody add this tip to a new subsection inside Contributor 3.4 Advanced Git procedures ? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
On Sun, Feb 06, 2011 at 05:05:37PM -0700, Carl Sorensen wrote: On 2/6/11 4:44 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: git status (everything looks fine, 3 files i've changed are listed) git diff HEAD (i see something resembling patch file) git commit -a (it asked me for message - i'm not sure if it's needed since it will be an update of existing commit, but i wrote something there and answered yes to questions that shown up...) There's no such thing as an update of an existing commit. Every time you do git commit, it's a new commit, even though it's an existing patch set. If you want to make it part of the previous commit, you can do so with git commit -a --amend Um. I agree that on a technical note, clicking amend previous commit is *not* an update of the previous commit. Technically, it (probably) removes the first commit, then creates a new commit with the same old material plus some new material. But from a user's perspective, I definitely _would_ call that an update of an existing commit. and i see the changes now in http://codereview.appspot.com/4134041, but i don't see any notification e-mail send to-devel... Is everything right? Yes, everything is right. Notification emails are never sent to -devel when a new patch set is uploaded. Just click on Publish and mail comments with a comment that says New patch set uploaded. I've added a @warning to the paragraph that explains doing this. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
On Sun, Feb 06, 2011 at 03:54:17PM -0700, Carl Sorensen wrote: On 2/6/11 7:10 AM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Now i see that there is a warning about vim, only it's somewhere else (CG 3.3.4 commit messages), not in uploading patch for review. Sorry for whining. No problem. You've identified another place where we should have something in the docs. Were it not for the fact that I use vim regularly, I would have had no clue the first time I did git-cl upload. Good point. Long-term, it would be nice to set VISUAL=gedit or something like that in lilydev. Failing that, we should have something in the docs, either setting this up manually, or (ick) explaining how to use vim. (wait -- doesn't ubuntu use nano for $VISUAL by default?) Does anybody want to investigate this and make whatever patch for the CG that's requierd? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
On 2/8/11 3:00 PM, Graham Percival gra...@percival-music.ca wrote: On Sun, Feb 06, 2011 at 05:05:37PM -0700, Carl Sorensen wrote: On 2/6/11 4:44 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: git status (everything looks fine, 3 files i've changed are listed) git diff HEAD (i see something resembling patch file) git commit -a (it asked me for message - i'm not sure if it's needed since it will be an update of existing commit, but i wrote something there and answered yes to questions that shown up...) There's no such thing as an update of an existing commit. Every time you do git commit, it's a new commit, even though it's an existing patch set. If you want to make it part of the previous commit, you can do so with git commit -a --amend Um. I agree that on a technical note, clicking amend previous commit is *not* an update of the previous commit. Technically, it (probably) removes the first commit, then creates a new commit with the same old material plus some new material. But from a user's perspective, I definitely _would_ call that an update of an existing commit. That's true, if you're using lily-git.tcl. But in this case, Janek was using the command line to do his git work. That's why he even had to deal with it asking for a message. My answer was intended to be in git space, not lily-git.tcl space. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
On 2/6/11 7:10 AM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: 2011/2/6 Janek Warchoł lemniskata.bernoull...@gmail.com: Now i see that there is a warning about vim, only it's somewhere else (CG 3.3.4 commit messages), not in uploading patch for review. Sorry for whining. No problem. You've identified another place where we should have something in the docs. Were it not for the fact that I use vim regularly, I would have had no clue the first time I did git-cl upload. You're most of the way there, and you're a strong contributor. But if you'd prefer, I'll be happy to post the patch for you. I've succeded thanks to your help :) Here is the link: http://codereview.appspot.com/4134041 Oops, looks like i forgot to announce the patch... I'm doing it now. Great! I got the announcement. Looks i've managed to fix this. Now i have to deal with updating my commit... When i run lily-git.tcl and Update Source, it says Command returned an error: child process exited abnormally. Check output text for details and the text in lily-git window says Updating LilyPond... |git --git-dir=/home/janek/lilypond-git/.git fetch origin 2@1 |git --git-dir=/home/janek/lilypond-git/.git rebase origin/master 2@1 cannot rebase: you have unstaged changes M lily/stem.cc M scm/define-grobs.scm Done. Strange... I've tried doing this woithout lily-git (in command-line), but calling git pull -r returned lily/stem.cc: needs update scm/define-grobs.scm: needs update refusing to pull with rebase: your working tree is not up-to-date What shall i do now? I can copy modified files, delete whole lilypond-git directory, download source again and make changes again, but is there some better way? Why is it not working? Is it because i didn't do it before making changes in source files? Yes. That's exactly the problem. You solve it just by making a commit, then do the Update Source. Because stem.cc and define-grobs.cc have uncommitted changes, if you overwrite them you will lose the changes. So it won't update unless you commit first (or you can deliberately thrown them away with the Abort Changes -- Reset to Origin button). HTH, Carl cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
Janek Warchoł lemniskata.bernoull...@gmail.com writes: 2011/2/7 Carl Sorensen c_soren...@byu.edu: On 2/6/11 4:44 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: As for now, i've already reset my git repository (that is i clicked Abort changes - reset to origin in lily-git) and made the changes again. So now i call git status (everything looks fine, 3 files i've changed are listed) git diff HEAD (i see something resembling patch file) git commit -a (it asked me for message - i'm not sure if it's needed since it will be an update of existing commit, but i wrote something there and answered yes to questions that shown up...) There's no such thing as an update of an existing commit. Every time you do git commit, it's a new commit, even though it's an existing patch set. If you want to make it part of the previous commit, you can do so with git commit -a --amend But I don't recommend doing that. Aha. Ok. Rule of thumb: --amend is fine as long as long as the original commit never got into any repository other than the one being amended. A patchset on Rietveld does not count I should think since commit here means a complete unit including author, committer, commit message, diff and parent commit. Applying a patchset from Rietveld does not result in a reliable reproduction of the commit as identified by git since Rietveld is fundamentally Subversion. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
On 2/6/11 4:44 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: 2011/2/6 Carl Sorensen c_soren...@byu.edu: What shall i do now? I can copy modified files, delete whole lilypond-git directory, download source again and make changes again, but is there some better way? Why is it not working? Is it because i didn't do it before making changes in source files? Yes. That's exactly the problem. You solve it just by making a commit, then do the Update Source. Because stem.cc and define-grobs.cc have uncommitted changes, if you overwrite them you will lose the changes. So it won't update unless you commit first (or you can deliberately thrown them away with the Abort Changes -- Reset to Origin button). Ok. Thanks for explanation, i'll remember it. As for now, i've already reset my git repository (that is i clicked Abort changes - reset to origin in lily-git) and made the changes again. So now i call git status (everything looks fine, 3 files i've changed are listed) git diff HEAD (i see something resembling patch file) git commit -a (it asked me for message - i'm not sure if it's needed since it will be an update of existing commit, but i wrote something there and answered yes to questions that shown up...) There's no such thing as an update of an existing commit. Every time you do git commit, it's a new commit, even though it's an existing patch set. If you want to make it part of the previous commit, you can do so with git commit -a --amend But I don't recommend doing that. git pull -r (it said that Current branch master is up to date.) git cl issue 4134041 (that's number of my first patch sent to Rietveld) git cl upload origin/master (and wrote some description) and i see the changes now in http://codereview.appspot.com/4134041, but i don't see any notification e-mail send to-devel... Is everything right? Yes, everything is right. Notification emails are never sent to -devel when a new patch set is uploaded. Just click on Publish and mail comments with a comment that says New patch set uploaded. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
2011/2/7 Carl Sorensen c_soren...@byu.edu: On 2/6/11 4:44 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: As for now, i've already reset my git repository (that is i clicked Abort changes - reset to origin in lily-git) and made the changes again. So now i call git status (everything looks fine, 3 files i've changed are listed) git diff HEAD (i see something resembling patch file) git commit -a (it asked me for message - i'm not sure if it's needed since it will be an update of existing commit, but i wrote something there and answered yes to questions that shown up...) There's no such thing as an update of an existing commit. Every time you do git commit, it's a new commit, even though it's an existing patch set. If you want to make it part of the previous commit, you can do so with git commit -a --amend But I don't recommend doing that. Aha. Ok. git pull -r (it said that Current branch master is up to date.) git cl issue 4134041 (that's number of my first patch sent to Rietveld) git cl upload origin/master (and wrote some description) and i see the changes now in http://codereview.appspot.com/4134041, but i don't see any notification e-mail send to-devel... Is everything right? Yes, everything is right. Notification emails are never sent to -devel when a new patch set is uploaded. Just click on Publish and mail comments with a comment that says New patch set uploaded. Silly me. I forgot that i wasn't automatically logged in, and that's why i didn't see Publish and mail comments... Too bad i wen't to sleep immediately after sending previous mail... Well, i've uploaded yet another patch now (that uses some arrays instead of switches and if..elses). I suppose that if only one file changed then i'm not supposed to include all files in patch. Thanks for help, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
On 2/7/11 6:07 AM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Well, i've uploaded yet another patch now (that uses some arrays instead of switches and if..elses). I suppose that if only one file changed then i'm not supposed to include all files in patch. No, you will always do a git-cl upload master git-cl does exactly the right thing. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
2011/2/6 Janek Warchoł lemniskata.bernoull...@gmail.com: Carl Sorensen wrote: Once you get to that point, just hit the escape key, then type :wq. You are in vim, or some equivalent editor. I heard about vim... Yeah, so now i've experienced the Vim Joke and i have to admit that i fulfill the Vim hypothesis: i've generated random string trying to exit the program. :P Frankly, i'd prefer some sort of warning there... Beware! For thou hath stepped on the quicksands of Vim or something like that :) Now i see that there is a warning about vim, only it's somewhere else (CG 3.3.4 commit messages), not in uploading patch for review. Sorry for whining. You're most of the way there, and you're a strong contributor. But if you'd prefer, I'll be happy to post the patch for you. I've succeded thanks to your help :) Here is the link: http://codereview.appspot.com/4134041 Oops, looks like i forgot to announce the patch... I'm doing it now. 2011/2/5 Han-Wen Nienhuys hanw...@gmail.com: * For the longer (8th, 16th), it trades some voloptuousness for practicality. I think the overall feel of feta is more on the exuberant side, so I think we could lessen the effect there, and lengthen the hooks a bit more. I'm not sure if i understand what effect you want to achieve. From my experiments it looks like it won't work well, though. I'll post some examples tomorrow. Do you mean something like this? http://www.sendspace.com/file/42zwg7 I'd say that 8th and 16th hooks are too pronounced now (i think that's what Carl called squat and blocky 8th flag). In my opinion the previous version was optimal, however a compromise between previous version and this one may be acceptable. (as for the c++ code - i'm totally aware that it needs improvement. Can you look in define-grobs.scm ? I didn't look closely, but I suspect a lot of the things you are hard-coding in C++ are actually soft-coded in the details property; if not, we should work to softcode them; it will make your experiments easier as well. Yes, i'll fix that. Looks i've managed to fix this. Now i have to deal with updating my commit... When i run lily-git.tcl and Update Source, it says Command returned an error: child process exited abnormally. Check output text for details and the text in lily-git window says Updating LilyPond... |git --git-dir=/home/janek/lilypond-git/.git fetch origin 2@1 |git --git-dir=/home/janek/lilypond-git/.git rebase origin/master 2@1 cannot rebase: you have unstaged changes M lily/stem.cc M scm/define-grobs.scm Done. Strange... I've tried doing this woithout lily-git (in command-line), but calling git pull -r returned lily/stem.cc: needs update scm/define-grobs.scm: needs update refusing to pull with rebase: your working tree is not up-to-date What shall i do now? I can copy modified files, delete whole lilypond-git directory, download source again and make changes again, but is there some better way? Why is it not working? Is it because i didn't do it before making changes in source files? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
2011/2/4 Janek Warchoł lemniskata.bernoull...@gmail.com: Hi, this is (hopefully) the final version of the new flags; it's a mix of previous two propositions and some new modifications. I must admit that i'm proud of it :) Some differencies between this version and the compromise version (from my previous mail): - 32nd stems are a bit shorter (but not as short as i suggested before), 128th stems are a bit shorter too. This makes the stem length transition smoother (see the coloured lines in the attachments), - the downstem flags are modified in such a way that the gap between notehead and flag is smaller; this makes 64th and especially 128th notes more balanced (at least in my opinion), see the dots in the attachment, - the downstem 8th flag is a bit shorter. This is to make sure that there will be a visible gap between notehead and the end of the flag. See attachment, - the shortened upstem 8th flags are shorter (now the dots don't collide with them!). Here are the .ly files used for testing: http://www.sendspace.com/file/gjh6ng Here are the pdfs: http://www.sendspace.com/file/j9dq5t Here are pdfs made with current dev release (2.13.47) for comparison: http://www.sendspace.com/file/ogl8rk Here is the patch file (i hope i got this right...): http://www.sendspace.com/file/2dx8wa Please tell me what you think. Graham, Han-Wen, Reinhold, Keith - may i ask for your opinion too? After all, this changes will affect virtually all scores (all notes on middle line of the staff will have longer stems, not mentioning other changes). Also it's my first contribution, and i've spent many hours fine-tuning the new flags, so i'd like to know how this turned out. Hey Janek, thanks for looking into this, and welcome to the world of font-design aka. endless fiddling :) Overall comments: * There is no question that this is better for the 32nd and shorter in forced directions, especially for the head-facing part of the flag. * It seems to shorten the flags at the tip end too. I'm not sure if that is desired. In normal non-forced positions, the flags are a little bit taller than the beamed notes from the same position, and the old version maintains that for the forced positions too (of course, the beaming quants sometimes make it less obvious). This effect is gone in your verison example, it seems all forced stems are getting shorter than the beams. Is there a way to main * For the longer (8th, 16th), it trades some voloptuousness for practicality. I think the overall feel of feta is more on the exuberant side, so I think we could lessen the effect there, and lengthen the hooks a bit more. * I'm not sure, but it looks like the outer flag of the 64th and 128th upstem flag seems to pop out a bit. There is a correction for this, perhaps you uptune that correction for the shorter up flags. (as for the c++ code - i'm totally aware that it needs improvement. Can you look in define-grobs.scm ? I didn't look closely, but I suspect a lot of the things you are hard-coding in C++ are actually soft-coded in the details property; if not, we should work to softcode them; it will make your experiments easier as well. -- 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
Re: fine-tuning new flags - feedback needed
On 2/4/11 12:01 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Hi, this is (hopefully) the final version of the new flags; it's a mix of previous two propositions and some new modifications. I must admit that i'm proud of it :) Some differencies between this version and the compromise version (from my previous mail): - 32nd stems are a bit shorter (but not as short as i suggested before), 128th stems are a bit shorter too. This makes the stem length transition smoother (see the coloured lines in the attachments), - the downstem flags are modified in such a way that the gap between notehead and flag is smaller; this makes 64th and especially 128th notes more balanced (at least in my opinion), see the dots in the attachment, Read shows a larger gap on 64th and 128th flags than on the longer note duration flags. - the downstem 8th flag is a bit shorter. This is to make sure that there will be a visible gap between notehead and the end of the flag. See attachment, The downstem flags shown by Read have no gap between the flag and the head for eighth, sixteenth, and 32nd notes. I have not looked into beautifully-engraved music to see what the publishers' practice is. - the shortened upstem 8th flags are shorter (now the dots don't collide with them!). Here are the .ly files used for testing: http://www.sendspace.com/file/gjh6ng Here are the pdfs: http://www.sendspace.com/file/j9dq5t Here are pdfs made with current dev release (2.13.47) for comparison: http://www.sendspace.com/file/ogl8rk Here is the patch file (i hope i got this right...): http://www.sendspace.com/file/2dx8wa Since you have made a patch, it appears that you have git available. Is there a reason you haven't uploaded the patch to Rietveld for review? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
On 2/4/11 3:59 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: W dniu 4 lutego 2011 20:13 użytkownik Carl Sorensen c_soren...@byu.edu wrote: On 2/4/11 12:01 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Hi, this is (hopefully) the final version of the new flags; it's a mix of previous two propositions and some new modifications. I must admit that i'm proud of it :) Some differencies between this version and the compromise version (from my previous mail): - 32nd stems are a bit shorter (but not as short as i suggested before), 128th stems are a bit shorter too. This makes the stem length transition smoother (see the coloured lines in the attachments), - the downstem flags are modified in such a way that the gap between notehead and flag is smaller; this makes 64th and especially 128th notes more balanced (at least in my opinion), see the dots in the attachment, Read shows a larger gap on 64th and 128th flags than on the longer note duration flags. The downstem flags shown by Read have no gap between the flag and the head for eighth, sixteenth, and 32nd notes. I have not looked into beautifully-engraved music to see what the publishers' practice is. Isn't all this a matter of the font design exclusively? We have our own font and we design it the way we like it. Absolutely. But the way we like it should be informed by the best engraving practice. I changed downstem 64th and 128th flags because they looked like their design was limited by previous code. I mean that until now LilyPond used one flag for standard and shortened stems, and therefore this flag had to be some sort of a compromise (if the flag with smaller gap (like the one i made now) was used in old code, it would look good on standard length stems, but horrible on shortened stems; therefore the old flag had to have wide gap). Now i've changed the code, allowing different versions of flags being used on stems of different length, so the need for compromise is gone. Maybe the need for compromise was the reason why flags in Read have wide gaps, too? I don't think so, but it's possible. As for the downstem 8th flag, it's current look is simply inconsistent with other flags (and with itself - it looks different when notehead lies on the staff line insted of between the lines). Look at the attachment. Read's downstem flag is actually inconsistent in different locations, which is probably consistent with a hand-engraved look. - the shortened upstem 8th flags are shorter (now the dots don't collide with them!). Great! That's one of the items Read mentions that should happen -- avoiding the dots (although he says he does it by having different flags when the dot is present). Here are the .ly files used for testing: http://www.sendspace.com/file/gjh6ng Here are the pdfs: http://www.sendspace.com/file/j9dq5t Here are pdfs made with current dev release (2.13.47) for comparison: http://www.sendspace.com/file/ogl8rk Here is the patch file (i hope i got this right...): http://www.sendspace.com/file/2dx8wa Since you have made a patch, it appears that you have git available. Probably... :) I did the following: - modified the files - called lily-git.tcl - clicked New local commit - clicked Make patch set - send you the file that appeared. I don't know if using lily-git GUI instead of git (from terminal) makes any difference here... Is there a reason you haven't uploaded the patch to Rietveld for review? CG 2.2 says More experienced contributors should upload the patch for web-based review. This requires additional software and use of the command-line; see Uploading a patch for review. and i felt like a not-so-experienced-contributor. Fair enough. But your work is significant, so I see you much less like a not-so-experienced contributor. Perhaps i should have send all this to frog mailing list, but i wanted to know developers' opinion about the output too (not only the code itself)... sorry for the mess. No apology needed. This isn't a mess. It's just that the next step for review is having a patch on Rietveld. And I can post it for you, or you can post it yourself. I'm just asking how you'd like to proceed. I tried doing things described in CG 3.3.4 Uploading a patch for review now, but i'm stuck after calling git cl upload origin/master below is what the terminal showed me (i entered that description earlier, when i was using lily-git): # Enter a description of the change. # This will displayed on the codereview site. # The first line will also be used as the subject of the review. shortened stems and flags This improves the way that stems in forced directions are shortened and adds loads of new flags to be used with these shortened stems. I cannot do anything with this, only move cursor. pressing Return does nothing and i cannot scroll this too. Spooky... Once you get to that point, just hit the
Re: fine-tuning new flags - feedback needed
On Fri, 04 Feb 2011 11:01:02 -0800, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Please tell me what you think. Graham, Han-Wen, Reinhold, Keith - may i ask for your opinion too? After all, this changes will affect virtually all scores (all notes on middle line of the staff will have longer stems, not mentioning other changes). Also it's my first contribution, and i've spent many hours fine-tuning the new flags, so i'd like to know how this turned out. (as for the c++ code - i'm totally aware that it needs improvement. metafont is much easier ;P). Janek, I am not going to have an aesthetic opinion. I read and write mostly piano music, which is crowded enough that I don't notice changes on the scale you are proposing. You should use the properties defined in scm/define-grobs.scm under Stem, 'lengths' and 'stem-shorten', to hold your adjusted values. Other parts of the code might need to access these values, in order to know how much to lengthen a stem to avoid other note-heads, for example. -- Keith ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
this is (hopefully) the final version of the new flags; it's a mix of previous two propositions and some new modifications. I must admit that i'm proud of it :) I like the new shapes. However, only tests and comparisons with various documents will show where and when the new flags can be used. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
Nice work! My preference is the compromise solution too, for both stems up and stems down Trevor - Original Message - From: Janek Warchoł lemniskata.bernoull...@gmail.com To: lilypond-devel@gnu.org; Carl Sorensen c_soren...@byu.edu; Werner LEMBERG w...@gnu.org; Xavier Scheuer x.sche...@gmail.com Sent: Saturday, January 29, 2011 11:14 PM Subject: fine-tuning new flags - feedback needed Hi, After some discussion in flags, beams and stem length in forced directions - output improvement thread, i've created new flags for shorter-stemmed notes and new rules for shortening stems. Please look at pdfs linked below and tell me what you think. Changes: - stem length transition between regular stems and shortened stems is now smooth (it's especially visible with unflagged notes), - the difference in length between regular stems and shortened stems depends on the duration of notes (that's because notes with different amount of flags need different treatment), - regular stems of 32nd and 128th notes are shorter. I felt they were too long, especially compared to the beamed notes - for example the stem of the unbeamed e 32nd reaches higher than the beamed f's following it, - 64th and 128th basic flag shape now matches stem length better (i think). I hope that .zip archives are appropriate here... Each archive is about 400 KB. output from 2.13.45: http://www.sendspace.com/file/6cwf2q proposed new output: http://www.sendspace.com/file/52bbz6 If you don't like the last two changes (shorter regular stems and modified basic flags), try this: http://www.sendspace.com/file/gglzoh (shortened stems of 8th and 16th notes are also a little bit longer here than in previous one) I attach .ly files used for testing. You may send me more files if you want to see how they would look like. I will send a patch with the code changes when i resolve some problems i've encountered; as for now i'd like to know your opinions about the output itself. I see that there is a problem with dots and single flags... I'd gladly help with solving this one, i have some idea what the solution may look like. cheers, Janek PS you may forward this to -user if you find this appropriate. ___ 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
fine-tuning new flags - feedback needed
Hi, After some discussion in flags, beams and stem length in forced directions - output improvement thread, i've created new flags for shorter-stemmed notes and new rules for shortening stems. Please look at pdfs linked below and tell me what you think. Changes: - stem length transition between regular stems and shortened stems is now smooth (it's especially visible with unflagged notes), - the difference in length between regular stems and shortened stems depends on the duration of notes (that's because notes with different amount of flags need different treatment), - regular stems of 32nd and 128th notes are shorter. I felt they were too long, especially compared to the beamed notes - for example the stem of the unbeamed e 32nd reaches higher than the beamed f's following it, - 64th and 128th basic flag shape now matches stem length better (i think). I hope that .zip archives are appropriate here... Each archive is about 400 KB. output from 2.13.45: http://www.sendspace.com/file/6cwf2q proposed new output: http://www.sendspace.com/file/52bbz6 If you don't like the last two changes (shorter regular stems and modified basic flags), try this: http://www.sendspace.com/file/gglzoh (shortened stems of 8th and 16th notes are also a little bit longer here than in previous one) I attach .ly files used for testing. You may send me more files if you want to see how they would look like. I will send a patch with the code changes when i resolve some problems i've encountered; as for now i'd like to know your opinions about the output itself. I see that there is a problem with dots and single flags... I'd gladly help with solving this one, i have some idea what the solution may look like. cheers, Janek PS you may forward this to -user if you find this appropriate. 01-HomeSweetHome.ly Description: Binary data 02-BlueBells.ly Description: Binary data 03-TheLastRoseOfSummer.ly Description: Binary data Abschied.ly Description: Binary data flag testing.ly Description: Binary data Lyngham.ly Description: Binary data Uxbridge.ly Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
On 1/29/11 4:14 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Hi, After some discussion in flags, beams and stem length in forced directions - output improvement thread, i've created new flags for shorter-stemmed notes and new rules for shortening stems. Please look at pdfs linked below and tell me what you think. Very interesting work, indeed. Thanks! Changes: - stem length transition between regular stems and shortened stems is now smooth (it's especially visible with unflagged notes), - the difference in length between regular stems and shortened stems depends on the duration of notes (that's because notes with different amount of flags need different treatment), - regular stems of 32nd and 128th notes are shorter. I felt they were too long, especially compared to the beamed notes - for example the stem of the unbeamed e 32nd reaches higher than the beamed f's following it, - 64th and 128th basic flag shape now matches stem length better (i think). I hope that .zip archives are appropriate here... Each archive is about 400 KB. output from 2.13.45: http://www.sendspace.com/file/6cwf2q proposed new output: http://www.sendspace.com/file/52bbz6 If you don't like the last two changes (shorter regular stems and modified basic flags), try this: http://www.sendspace.com/file/gglzoh (shortened stems of 8th and 16th notes are also a little bit longer here than in previous one) I attach .ly files used for testing. You may send me more files if you want to see how they would look like. I will send a patch with the code changes when i resolve some problems i've encountered; as for now i'd like to know your opinions about the output itself. I see that there is a problem with dots and single flags... I'd gladly help with solving this one, i have some idea what the solution may look like. I prefer the compromise flags to the new flags. I think that the new flags are a little bit too short. I prefer the old stem-down single flags to the new. The shorter flags seem to me to be too squat and blocky. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
Nice job! And I have to second Carl's comment: The `compromise' stuff is the best one $(Q#|(B and perhaps you can make a compromise between the `orig' stuff and `compromise' w.r.t. the shape of the down-flags... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
