Re: Implements multiple-line non-cross-staff glissandi (issue4527086)
On Jun 13, 2011, at 1:03 PM, m...@apollinemike.com wrote: > On Jun 12, 2011, at 5:49 PM, n.putt...@gmail.com wrote: > >> On 2011/06/05 10:18:18, mike_apollinemike.com wrote: >>> On Jun 2, 2011, at 9:00 PM, mailto:n.putt...@gmail.com wrote: >> http://codereview.appspot.com/4527086/diff/7002/scm/output-lib.scm File scm/output-lib.scm (right): >> http://codereview.appspot.com/4527086/diff/7002/scm/output-lib.scm#newcode795 scm/output-lib.scm:795: (define-public >> (glissando::before-line-breaking grob) Possibly silly question: can't you fold this into callbacks for left-bound-info/right-bound-info instead? >> >>> Sorry - I don't get what you mean :( Could you please elaborate? >> >> You're calculating a value for 'Y which you add back into bound-details. >> This bypasses the default calculation in calc_bound_info (). Why not >> caculate 'Y when left-bound-info/right-bound-info is requested, either >> directly in C++ or as glissando-specific scheme versions? >> > > My goal is to bypass the default calculation and replace it with this one, > and it is easier to harvest the information about Y placement relative to the > staff before line breaking happens. Currently, there is no mechanism in > Line_spanner::calc_bound_info that can outsource the Y calculation to another > function, and I wouldn't want to code dup all of the parts of > Line_spanner::calc_bound_info that are worth keeping into a glissando > specific function. Taking that into account, does that seem like the right > approach? > Just touching base on this thread to see if the explanation above makes sense and, if so, if it is push-ready. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix for issue 1706. (issue4662047)
On 2011/06/23 17:48:23, hanwenn wrote: * Test missing. * Should print programming_error if dir == CENTER. * I'd use linear_combination on dir instead, so it is symmetric in up/down. Done, done, and done. Cheers, MS http://codereview.appspot.com/4662047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Replace Tab with 8 Spaces for .py files (issue4627062)
LGTM http://codereview.appspot.com/4627062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch meister
On 11-06-23 05:38 AM, Graham Percival wrote: Do either of you have 2-3 hours a week to spend shuffling patches? More directed at Colin than James, but I figured I'd include James in case he was getting sick of doc work and wanted a challenge. I'd like somebody else to be Patch Meister. The most important job is as described under "You can help" on this page: http://percival-music.ca/blog/2011-06-11-lilypond-2.14.html Yes, there's 6 steps. We might need to clarify some of them, but I'm certain that the final list will be less than 12 completely-robotic steps. Another job is to update the Patch-needs_work issues when a new draft is uploaded. I haven't written steps for this, but it would be a similarly robotic step-following process. Cheers, - Graham I could take it on, Graham. In some ways it's just a bit further and more formal than the "screening" I've been trying to do. I'd suggest a minor edit on your blog though: after the list of steps in "You can help", you might s/need/mind ;> A related question, though: how do we go about tying issues and patches closer together? It would be extremely valuable either to *require* that anything on reitveld have a formal issue number, even if it's a dev contributing a "hey, look what I wrote" enhancement, or to look for a different platform which combines issue tracking with patch management. As it sits, reitveld doesn't manage projects, only developers, and the issues on code.google.com don't reflect all the issues/patched needing attention. Should we start a GOP discussion, at least to get the views of the developer community on record? Colin -- The human race has one really effective weapon, and that is laughter. -- Mark Twain ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Replace Tab with 8 Spaces for .py files (issue4627062)
Reviewers: Keith, Message: Second go. Thanks Keith. Description: Replace Tab with 8 Spaces for .py files As per GOP Prop 1 - Python formatting. All files in /python/ and /scripts/ were checked. Please review this at http://codereview.appspot.com/4627062/ Affected files: M python/convertrules.py M python/fontextract.py M python/lilylib.py M python/musicxml.py M python/rational.py ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Replace Tab with 8 Spaces for .py files (issue4627062)
The bad news is, you replaced tabs by 4 columns when we needed 8 column. The good news is, so far as I can see, there were no un-wanted changes (no cases were we needed a literal tab). http://codereview.appspot.com/4627062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: question about mod dates in my git tree for resetted files
Keith, From: lilypond-devel-bounces+james.lowe=datacore@gnu.org [lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of Keith OHara [k-ohara5...@oco.net] Sent: 24 June 2011 03:31 To: lilypond-devel@gnu.org Subject: Re: question about mod dates in my git tree for resetted files James Lowe datacore.com> writes: > > I made the patch and then aborted my changes. > I noticed however that the mod dates were still the same as the time > I made the patch, even though the files themselves are the original files That is normal. The file system reports the last time the file changed, which is probably the moment you aborted the changes. Your patch for tab-conversion consistently shows the old versions removed, but no new versions put in their place --- it's not just the side-by-side view. I have no guesses about what might have gone wrong. If you are curious, maybe wade in to the command line just a bit and try `git status` just after re-committing your tab-expand changes (which might tell you the new versions are modified but not added or something; I don't know) --- Thanks for that. I went back and redid my edits (see other email I just sent out). I don't know what happened, but it's good to get some sanity check. I did a git status before committing and it showed all the .py files that were modified and after the commit they were gone. As opposed to git status showing files that need to be 'added' (a la binary files). Oh well, I seemed to have sorted this out. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: GOP-PROP 1: python formatting (accepted)
Hello (again) __ From: lilypond-devel-bounces+james.lowe=datacore@gnu.org [lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of Graham Percival [gra...@percival-music.ca] Sent: 23 June 2011 23:48 To: lilypond-devel@gnu.org Subject: GOP-PROP 1: python formatting (accepted) We have now accepted the final version of GOP-PROP 1. The unofficial page will remain online for the duration of GOP: http://lilypond.org/~graham/gop/gop_1.html but the offical version is now in the CG and was pushed as bde5d50a10ab68e864c161fb98478c3803b6d409 Are there any volunteers to do this reformatting? The GOP website link (above) has a few tips for tools which could make this a 5-minute job (plus testing). I don't anticipate it being a complicated process; if you have git access you can push the patch directly with no need for review. - I'll have a stab. http://codereview.appspot.com/4634090 - OK I closed the above reitveld issue. Actually I went back and did this again - I have no idea what was going on but I did some test edits on other tely files to see what was going on and for some reason any file I edited was seen as a complete change instead of just diffs. So I reverted back to an old 'snapshot' of Lilydev (hooray for Virtual Box!) and did a new git pull and redid this tab spacing thing with Geany (a nice text editor for this kind of stuff) after a quick google on what others use. Looks better now. http://codereview.appspot.com/4627062 James PS I guess the reitveld numbers don't increment...you can see my later post has a smaller number (4627062) than my earlier one (4634090). Odd. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: question about mod dates in my git tree for resetted files
James Lowe datacore.com> writes: > > I made the patch and then aborted my changes. > I noticed however that the mod dates were still the same as the time > I made the patch, even though the files themselves are the original files That is normal. The file system reports the last time the file changed, which is probably the moment you aborted the changes. Your patch for tab-conversion consistently shows the old versions removed, but no new versions put in their place --- it's not just the side-by-side view. I have no guesses about what might have gone wrong. If you are curious, maybe wade in to the command line just a bit and try `git status` just after re-committing your tab-expand changes (which might tell you the new versions are modified but not added or something; I don't know) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New breve rest with ledger lines (issue4650052)
On 2011/06/24 00:56:43, Bertrand Bordage wrote: You have to remove mf/out/feta* before compiling. That made everything work. Looks good to me. I was failing to find a glyph for rests.-1o , saw you were creating a new rests.M1o and thought "Oh, 'M' must mean mensural" but I see it really does mean 'minus'. http://codereview.appspot.com/4650052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
question about mod dates in my git tree for resetted files
Hello, Perhaps this is expected, but I wondered if someone could verify it. Usually when I make some patches and post on Rietveld, I make a .patch file, save it somewhere safe and then 'reset' my tree (abort in Lilygit.tcl). This means I can work on other stuff without having to do complicated stuff (for me) in gitk or git cli. My question is after making some mods to some .py files (converting tabs to spaces), I made the patch and then aborted my changes. I noticed however that the mod dates were still the same as the time I made the patch, even though the files themselves are the original files (i.e. the ones with the Tabs in still). I haven't paid much attention before, but shouldn't the mod dates revert back to what they were after I did the abort/reset? James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: GOP-PROP 1: python formatting (accepted)
Hello, From: lilypond-devel-bounces+james.lowe=datacore@gnu.org [lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of Graham Percival [gra...@percival-music.ca] Sent: 23 June 2011 23:48 To: lilypond-devel@gnu.org Subject: GOP-PROP 1: python formatting (accepted) We have now accepted the final version of GOP-PROP 1. The unofficial page will remain online for the duration of GOP: http://lilypond.org/~graham/gop/gop_1.html but the offical version is now in the CG and was pushed as bde5d50a10ab68e864c161fb98478c3803b6d409 Are there any volunteers to do this reformatting? The GOP website link (above) has a few tips for tools which could make this a 5-minute job (plus testing). I don't anticipate it being a complicated process; if you have git access you can push the patch directly with no need for review. - I'll have a stab. http://codereview.appspot.com/4634090 I know you said that it wasn't complicated - it wasn't - I used a text editor (on MacOS) that comes with a lot of snazzy functions including Tab to Space conversions on the fly. However, I had to move the files from one OS to another - the text editor keeps the formatting (I have used it before for LP stuff when hunting out invisibles that were added via copy/paste from email clients) so it shou be fine. When I uploaded it I don't see any 'side by side diff' instances, only the whole file. As if it were brand new. Is this expected or is it something special with .py files? I retried this again and saved it directly using gedit on Linux in case it was something odd with the OS formatting. But as I say this tool is designed to accommodate all the nuances of different formats of text so I'd expect this to be ok. Could someone look at the patch and see? James PS I did a search for Tabs on all py files in the /python/ and /scripts/ dir and only came up with these. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New breve rest with ledger lines (issue4650052)
Maybe I should have been more clear in the description. The glyph I added in feta-rests.mf is for the default style. You have to remove mf/out/feta* before compiling. There's no problem when I try this patch with your example. But again, maybe I don't understand what you mean. Thanks http://codereview.appspot.com/4650052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New breve rest with ledger lines (issue4650052)
On 2011/06/23 09:34:23, Bertrand Bordage wrote:
For the moment, the exception is handled by the next "if", line 100.
But don't forget to let /something/ print if the ledgered version is
missing in the chosen style -- especially default :
\relative c''' { \time 4/1
<< {
b\breve\rest g\breve
} \\ {
c,\breve b\breve
} >> }
I think you currently set is_ledgered = true for the b\breve\rest, and
then Lilypond looks for a glyph that does not exist.
http://codereview.appspot.com/4650052/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
GOP-PROP 1: python formatting (accepted)
We have now accepted the final version of GOP-PROP 1. The unofficial page will remain online for the duration of GOP: http://lilypond.org/~graham/gop/gop_1.html but the offical version is now in the CG and was pushed as bde5d50a10ab68e864c161fb98478c3803b6d409 Are there any volunteers to do this reformatting? The GOP website link (above) has a few tips for tools which could make this a 5-minute job (plus testing). I don't anticipate it being a complicated process; if you have git access you can push the patch directly with no need for review. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix for issue 1706. (issue4662047)
* Test missing. * Should print programming_error if dir == CENTER. * I'd use linear_combination on dir instead, so it is symmetric in up/down. On Thu, Jun 23, 2011 at 11:00 AM, wrote: > Reviewers: , > > Message: > I think this'll do it. > > Cheers, > MS > > Description: > Fix for issue 1706. > > Please review this at http://codereview.appspot.com/4662047/ > > Affected files: > M lily/beam.cc > > > Index: lily/beam.cc > diff --git a/lily/beam.cc b/lily/beam.cc > index > 8a30752c386eccd8294b181c5dd18159c2b492d2..e9ab3540b62318c1426f72bf36d2bdd008119482 > 100644 > --- a/lily/beam.cc > +++ b/lily/beam.cc > @@ -555,6 +555,8 @@ Beam::print (SCM grob) > Spanner *me = unsmob_spanner (grob); > Grob *commonx = 0; > vector segments = get_beam_segments (me, &commonx); > + if (!segments.size ()) > + return SCM_EOL; > > Interval span; > if (normal_stem_count (me)) > @@ -974,7 +976,7 @@ Beam::no_visible_stem_positions (Grob *me, Interval > default_value) > } > > Direction dir = get_grob_direction (me); > - Real y = head_positions[dir] > + Real y = head_positions[dir ? dir : UP] > * 0.5 * Staff_symbol_referencer::staff_space (me) > + dir * get_beam_translation (me) * (multiplicity.length () + 1); > > > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel > -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix for issue 1706. (issue4662047)
LGTM http://codereview.appspot.com/4662047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix for issue 1706. (issue4662047)
Reviewers: , Message: I think this'll do it. Cheers, MS Description: Fix for issue 1706. Please review this at http://codereview.appspot.com/4662047/ Affected files: M lily/beam.cc Index: lily/beam.cc diff --git a/lily/beam.cc b/lily/beam.cc index 8a30752c386eccd8294b181c5dd18159c2b492d2..e9ab3540b62318c1426f72bf36d2bdd008119482 100644 --- a/lily/beam.cc +++ b/lily/beam.cc @@ -555,6 +555,8 @@ Beam::print (SCM grob) Spanner *me = unsmob_spanner (grob); Grob *commonx = 0; vector segments = get_beam_segments (me, &commonx); + if (!segments.size ()) +return SCM_EOL; Interval span; if (normal_stem_count (me)) @@ -974,7 +976,7 @@ Beam::no_visible_stem_positions (Grob *me, Interval default_value) } Direction dir = get_grob_direction (me); - Real y = head_positions[dir] + Real y = head_positions[dir ? dir : UP] * 0.5 * Staff_symbol_referencer::staff_space (me) + dir * get_beam_translation (me) * (multiplicity.length () + 1); ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Patch meister
Hello )-Original Message- )From: Graham Percival [mailto:gra...@percival-music.ca] )Sent: 23 June 2011 12:38 )To: Colin Campbell; James Lowe )Cc: lilypond-devel@gnu.org )Subject: Patch meister ) )Do either of you have 2-3 hours a week to spend shuffling patches? )More directed at Colin than James, but I figured I'd include James in case )he was getting sick of doc work and wanted a challenge. [James' reply:] I'm always happy to help. Not getting sick of Doc work, I still enjoy it :) ) )I'd like somebody else to be Patch Meister. The most important job is as )described under "You can help" on this page: )http://percival-music.ca/blog/2011-06-11-lilypond-2.14.html ) )Yes, there's 6 steps. We might need to clarify some of them, but I'm )certain that the final list will be less than 12 completely-robotic steps. ) ) )Another job is to update the Patch-needs_work issues when a new draft )is uploaded. I haven't written steps for this, but it would be a similarly )robotic step-following process. ) [James' reply:] Well why not, one of us does 'needs review' and the other 'needs work'. Graham knows the limits of my 'sk177z' so perhaps he can decide which one I would be suited for. Failing that I can act as a backup to Colin along the lines of 'Hey James I only got to issue 123 today' can you check the rest?' assuming he starts from the lowest tracker number, I can play tag with him? I'm not around 'that much' from today until next weekend as I am on 'me hols' and have a concert at the end of next week plus some practices to do. but after Jul 4 it's back to normal. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: 48-hour countdown for new breve and bound-info
On Jun 23, 2011, at 1:40 PM, Graham Percival wrote: > Sat, 13:00 > > (not quit certain what this patch is doing now) > 1: Attaches bound info to beam for better normalized-endpoint > calculations > 2: Removes changing of beam extent and keeps bound-info > http://codereview.appspot.com/4605047 > It no longer fiddles with the X extent and just creates a bound-info property to be used in Spanner::normalized_endpoints. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dynamic + text aligned: BEST solution?
On Sun, Jun 19, 2011 at 11:30:25PM +0200, Xavier Scheuer wrote: > The following snippets are providing different solutions (some with > important drawbacks) to this issue/request (useful in many cases!): > http://lsr.dsi.unimi.it/LSR/Item?id=393 > http://lsr.dsi.unimi.it/LSR/Item?id=739 > > but there is also Graham's "make-dynamic-extra" (see below) I am fairly confident that at the time that I wrote make-dynamic-extra, it was the best way of doing it. I spent something like 10 hours working on it and reading mailing list archives. Issue 739 appears to have been written after that work, and at first glance it looks good. > and IIRC Valentin has a pending PATCH for implementing this. Please stop capitalizing "patch". If you're referring to issue 1264, the patch broke the build, and in any case it's postponed until GLISS. > I do not understand what means the Scheme code in each of these, could > someone have a look and tell me which one seems the best (i.e. with > the least possible drawbacks for an implementation)? It might be a good idea to learn some scheme, or at the very least do some more experimentation. I mean, ultimately what matters is the quality of the output. Try a few different commands in your scores, look at the output, and pick the one you like the best. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: 48-hour countdown for new breve and bound-info
Sat, 13:00 New breve rest with ledger lines http://codereview.appspot.com/4650052/ (not quit certain what this patch is doing now) 1: Attaches bound info to beam for better normalized-endpoint calculations 2: Removes changing of beam extent and keeps bound-info http://codereview.appspot.com/4605047 Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Patch meister
Do either of you have 2-3 hours a week to spend shuffling patches? More directed at Colin than James, but I figured I'd include James in case he was getting sick of doc work and wanted a challenge. I'd like somebody else to be Patch Meister. The most important job is as described under "You can help" on this page: http://percival-music.ca/blog/2011-06-11-lilypond-2.14.html Yes, there's 6 steps. We might need to clarify some of them, but I'm certain that the final list will be less than 12 completely-robotic steps. Another job is to update the Patch-needs_work issues when a new draft is uploaded. I haven't written steps for this, but it would be a similarly robotic step-following process. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch: small reduction in output from make doc
Carl Sorensen writes: >>> it should redirect non-error output to the file, and errors should appear >>> in the terminal. Stdout is used for valuable program output, stderr for any kind of message, including progress. The name stdERR is possibly somewhat unfortunate and comes from the days that unix commands would only print something (to stdERR) if there was an error. No news is good news. > There was some discussion on this in January. This seems to be coming back, yes. > David Kastrup feels pretty strongly that progress messages belong on stderr > along with warning/error messages, since ther are not the output of the > program. The output of lilypond is a music file of some sort. Right. For PDF that possibly does not make much sense, but more so for svg/html output. Here's the idea: foo.ly | lilypond -dbackend=svg - 2>foo.log | > foo.svg > Personally, since lilypond cannot produce the desired music files on stdout, yes, that seems to be broken [again?]. The above produces `-.svg' > I have no problem with putting progress messages on stdout, even though > that's not the standard for GNU utilities. But I can see where David K. is > coming from. Please, don't go there. Jan -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New breve rest with ledger lines (issue4650052)
thanks, added as http://code.google.com/p/lilypond/issues/detail?id=1705 http://codereview.appspot.com/4650052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes himidtom to highmidtom. (issue4633064)
On 2011/06/23 09:49:05, t.daniels_treda.co.uk wrote: mailto:m...@apollinemike.com wrote Thursday, June 23, 2011 9:56 AM The names in LilyPond should conform to those defined in General MIDI Level 1 - see http://www.midi.org/techspecs/gm1sound.php These are unfortunately inconsistent as you observe, but we should stay with them. I agree. Random other page which uses the same inconsistent naming: http://www.finalemusic.com/usermanuals/finale2011win/content/finale/General_MIDI_Percussion_Map_Table.htm 48 Hi-Mid Tom 50 High Tom I think we therefore cannot accept this patch, sorry Mike. http://codereview.appspot.com/4633064/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New breve rest with ledger lines (issue4650052)
Updated with the good bounds. The problem with mensural/neomensural/Petrucci styles is that they often have different ledger line thicknesses. The best solution is to get these ledger lines out of metafont. But this requires much more work. For the moment, the exception is handled by the next "if", line 100. Thanks! Bertrand http://codereview.appspot.com/4650052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes himidtom to highmidtom. (issue4633064)
m...@apollinemike.com wrote Thursday, June 23, 2011 9:56 AM On Jun 23, 2011, at 10:53 AM, k-ohara5...@oco.net wrote: On 2011/06/23 06:46:49, MikeSol wrote: Pretty self explanatory - it seems to be in keeping w/ the other tom names. That it is. Could you be persuaded to make a converting rule in python/convertrules.py ? I could. But before I do, I see a lot of inconsistencies between high/hi and low/lo. Do we want hi/lo or high/low? The names in LilyPond should conform to those defined in General MIDI Level 1 - see http://www.midi.org/techspecs/gm1sound.php These are unfortunately inconsistent as you observe, but we should stay with them. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes himidtom to highmidtom. (issue4633064)
On Jun 23, 2011, at 10:53 AM, k-ohara5...@oco.net wrote: > On 2011/06/23 06:46:49, MikeSol wrote: >> Pretty self explanatory - it seems to be in keeping w/ the other tom > names. > > That it is. > Could you be persuaded to make a converting rule in > python/convertrules.py ? > I could. But before I do, I see a lot of inconsistencies between high/hi and low/lo. Do we want hi/lo or high/low? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: enharmonic problem with \transpose - should we modify it?
>> well, it was nastier than I thought because of the current pitch
>> representation,
>> so I haven't done it as a patch but a standalone hack; there's also a
>> non-standard (E31) example.
>>
>> [...]
>>
> 2011/6/21 Felipe Gonçalves Assis :
>> Enharmonicity is just an equivalence relation respecting the abelian
>> group structure of intervals/transpositions. You can represent it by a
>> quotient map or by its kernel.
>>
>> Your approach is representing the kernel, via its generators. This
>> is complicated.
>>
>> A much simpler idea is to represent the quotient map, which is a
>> particularly simple kind of function.
>>
>> [...]
First of all, thank you, Felipe!
> Wow, thank you both!
> I don't think i would be able to write this at so high level of
> abstraction myself.
> I think i understand your explanation and i can roughly see what is
> going on in your code, except what the last argument(s) is (are) doing
> - why is it #(ly:make-pitch 0 1 -1) (which equals deses' IIUC)? Is
> this the "switch" which can be used to choose whether i want natural
> or double-accidentaled notes?
No, this tells what makes two notes enharmonic:
if their interval is a multiple of the enharmonic interval.
LilyPond represents intervals by pitches - a pitch represents
the interval from c' to the pitch, so deses' represents diminished second,
which is the standard E12 enharmonic interval.
> I hope to be able to modify this function so it would read scale from
> key signature. But before i'll do this, i'm afraid there is a problem:
> should double-sharped notes be transformed into themselves and not
> natural ones? Your examples contained the only one double-sharped note
> which is transformed to a enharmonic equivalent (aisis -> ces), all
> other double sharped notes remain the same - i.e. \enharmonizeMusic
> \esMinor { gisis' } #et12-class #et12-octaves outputs gisis' -
> shouldn't it output a'?
there's no equivalent in the es minor scale, so it's untouched.
The basic idea is to use a set and change those pitches that have
an enharmonic equivalent in this set to that element - other pitches
are left as is. you can enhance the set to be complete like
{ es f ges as bes ces des c d e g a },
and then all notes will be transformed to one of these.
I hope I'll find some time in the weekend to deal with all these.
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes himidtom to highmidtom. (issue4633064)
On 2011/06/23 06:46:49, MikeSol wrote: Pretty self explanatory - it seems to be in keeping w/ the other tom names. That it is. Could you be persuaded to make a converting rule in python/convertrules.py ? http://codereview.appspot.com/4633064/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
