Re: Adds bar line section to LM (Issue 3408) (issue 12724043)
On 2013/08/16 08:59:36, Graham Percival wrote:
On Fri, Aug 16, 2013 at 08:53:44AM +, mailto:k-ohara5...@oco.net
wrote:
> On 2013/08/16 08:16:22, http://mail_philholmes.net wrote:
> >> Do we really need to explain how to do special bar lines before
> >> explaining accidentals?
>
> >According to mail to -user, yes. The only reason I did this was
> because of
> >a request there.
>
> The mail said it seemed strange that there was final bar-line in any
> examples in the Learning Manual.
I don't think we need to respond to every single doc suggestion;
often users are unaware of the trade-offs we've chosen or are
particularly focused on their application domain ("why bother with
stuff for singers? the LM should only be about monophonic music
which is used for strings").
You make a good point about trade-offs. However, i think that adding
this short explanation would be inappropriate.
cheers,
Janek
https://codereview.appspot.com/12724043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make several special characters with or without backslash "non-special" (issue 12432043)
2013/8/15 :
> "Keith OHara" writes:
>
>> '!' also looks like a staccatissimo,
>> is a stop character so conceptually related to the '.' for staccato,
>> conflicts less with the use of ''' in pitches:
>>e'4-! cs-! bf-! g-! e'-! cs-! \tuplet3/2{bf-> g-> e->}
>>e'4-' cs-' bf-' g-' e'-' cs-' \tuplet3/2{bf-> g-> e->}
>> indicates an exclamation which "Hey!" is conceptually similar to a
>> staccatissimo,
>> is easier to type on key layouts that use ''' for accents (like mine,
>> US deadkeys on Windows).
>> ''' would look ridiculous when using octave checks: e'='-'
>
> Well, we can have eis'!='-! or even eis!=-! as well, but then
> octave-less octave checks always look like an oddity. But forced
> accidentals are usually less frequent than octave marks.
>
> And I agree that in the non-contrived interlinear comparison above, the
> variant using ! is less of an overall distraction.
ok, i'm convinced. And my question was of the "musing-kind" anyway.
Jaenk
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: maintaining advanced power-user Scheme functions
Hi, 2013/8/14 Thomas Morley : > 2013/8/14 Janek Warchoł : >> Harm and David N. (and some other people) write lots of very advanced >> (and very helpful!) Scheme functions. These funcitons are improved >> over time, and there is a problem related to that: it's easy to get >> lost in all the email threads about them, and it's not always obvious >> where the most recent version is. >> >> I think that such functions should be tracked by version control, and >> i see two approaches: >> - include them in official LilyPond source as soon as they are >> created. Upside: there's bigger chance that they will be updated when >> there are some changes. Downside: one has to write documentation and >> go through official patch submitting channels. >> - use another repository. What about OpenLilyLib? >> http://www.openlilylib.org/ > > Hi Janek, > > well, if I think one of my functions, definitions etc is worth a > patch, I do so, but ofcourse there's the risk I'm distracted by other > tasks and forget about it or I've no time or ... sure, i understand. Actually, you said something very important: preparing an "official" patch is a non-trivial task - it requires thinking and focusing. We probably cannot make our patch-accepting policy simpler, so this means that we need to have a simpler means of handling such work. The situation "i have something useful, but i dont' have enough time/energy to get it submitted" should never happen. Submitting useful stuff should be a no-brainer. > The idea of version-control for such functions might be nice. But > because I'm still not very familiar with git I'm feeling kind of > ambivalent. I'd be happy to help you (and anyone else) with git. And as i'm a huge fan of git, i believe that it can solve many problems - probably also this one. > Otoh, it might be an idea to do so for the LSR. > > Though, a lot of my functions, definitions etc are too special-cased, > written to fit some users needs or they are workarounds not worth a > patch. They may not be worth a patch for the official LilyPond code base/documentation, but they are definitely worth being remembered. All of them. This means that we need some place to store such things - something like LSR. > The right place for them would be the LSR, _if_ the LSR would be able > to compile them and not use a LilyPond-version far too old for many of > my ideas. > > There were some insinuations on the list the last months (or was it a > year already?) to upgrade the LSR and yes, one should do so. > But I hesitate to volunteer again for this task. > I initiated the last ugrade and did perhaps the major work, supported > by several developers and the great David Nalesnik. > Though there was only one, I repeat _one_, other user who tried to help: > Philippe Hezaine > > @Philippe > Thanks a lot for trying to help. And let me say: You didn't waste my time! > > So I was annoyed by the lack of help/interest of others and I'm still > pissed off. I understand this. I think that this means that there is some design flaw about how LSR works. I'll think about it more. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How are stems created?
Hi Phil, 2013/8/14 Phil Holmes : > - Original Message - From: "Janek Warchoł" >> I'd like to change stem and flag code so that stems, flags and >> noteheads are attached to each other using generic functions from >> Self_alignment_interface instead of their own funcitons (if that's >> possible). >> >> Fiddling with metafont code can be interesting as well. > > > I'd concluded that they are attached because they have a common origin, so > if this is wrong I probably won't be able to help. Always willing to try, > though. I'm not sure what you mean. Maybe i didn't make myself clear? Here's what i'd like to do: X-offset of a Stem is currently calculated by a function Stem::offset_callback (from stem.cc). I suppose that it would be possible to use some function from Self_alignment_interface, for example align_on_parent (probably after making it more generic). best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Uses single algorithm for side-position spacing. (issue 6827072)
http://code.google.com/p/lilypond/issues/detail?id=3503 On 2012/11/16 20:32:54, mike7 wrote: On 14 nov. 2012, at 07:33, mailto:m...@mikesolomon.org wrote: http://codereview.appspot.com/6827072/diff/1/lily/axis-group-interface.cc#newcode403 >> >> lily/axis-group-interface.cc:403: Axis_group_interface::cross_staff (SCM >> smob) >> For what situation? Which object that supports axis-group-interface >> (PianoPedalSpanner, DynamicLineSpanner) should be potentially considered >> a cross-staff object? > > NoteColumn Hey all, One result of my approach is that grobs that were not previously cross staff are. This allows for better positioning with respect to a system, but results in collisions with other systems. Try the following on current master and this patch : [what is now input\regression\dynamics-avoid-cross-staff-stem-2.ly] This was a side-effect of marking the entire NoteColumn as cross-staff if it contains a cross-staff-stem. The DynamicLineSpanner responds by becoming cross-staff (as has been done for a long time, for spanners normally belonging to a Voice) and delays placement of the 'f' until after staff-spacing (thus possibly overwriting the next staff down the page). Grouping objects like NoteColumn, however, are not usually marked cross-staff if some contents of the group are cross-staff. Marking NoteColumn as cross-staff requires the marking to be ignored in few places https://codereview.appspot.com/6827072/diff/38003/lily/axis-group-interface.cc#newcode115 https://codereview.appspot.com/6827072/diff/38003/lily/axis-group-interface.cc#newcode257 https://codereview.appspot.com/6827072/diff/38003/lily/axis-group-interface.cc#newcode896 The 'f' would then avoid the stem, but tuck in alongside and cross beam, as the beam is not part of the NoteColumn. Another special case, though, replaces the skyline of the note and stem with a box https://codereview.appspot.com/6827072/diff/38003/lily/side-position-interface.cc#newcode326 These changes were all originally added for fingerings, but for fingerings we had to restore the old 'add-stem-support' mechanism to choose whether slide down alongside the stem. In current master, there is a dynamic-on-beam intersection, and w/ my patch there is a dynamic-on-system intersection. Both of them are bad, but in terms of future work on LilyPond, I think the dynamic-on-system is a better alternative. The long-term goal of this work is to get cross-staff grobs into vertical calculations, We can tell dynamics to acknowledge Stems and NoteHeads individually, and become cross-staff if the stem is, *after* you include cross-staff grobs into vertical calculations. Until that time, the old code does a better job of dynamics overall. https://codereview.appspot.com/6827072/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds bar line section to LM (Issue 3408) (issue 12724043)
- Original Message -
From: "Graham Percival"
To: ; ;
; ; ;
; ; ;
Sent: Friday, August 16, 2013 9:59 AM
Subject: Re: Adds bar line section to LM (Issue 3408) (issue 12724043)
On Fri, Aug 16, 2013 at 08:53:44AM +, k-ohara5...@oco.net wrote:
On 2013/08/16 08:16:22, mail_philholmes.net wrote:
>> Do we really need to explain how to do special bar lines before
>> explaining accidentals?
>According to mail to -user, yes. The only reason I did this was
because of
>a request there.
The mail said it seemed strange that there was final bar-line in any
examples in the Learning Manual.
I don't think we need to respond to every single doc suggestion;
often users are unaware of the trade-offs we've chosen or are
particularly focused on their application domain ("why bother with
stuff for singers? the LM should only be about monophonic music
which is used for strings").
I would be tempted to simply insert \bar "|." into the longer examples
in the LM, with no explanation, so it is there for curious people to
find, and shows them what to look up in the index to learn more.
Either that, or add "alternate bar lines" to 2.4 Final touches.
- Graham
I actually proposed adding a short section in 2.1.1 on July 6th and nobody
demurred, which is why I went ahead and did it. The section I've added also
clarifies how bar lines are created and the difference from bar checks,
which confuses no end of people. And yes, I do think that bars should come
before accidentals.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Windows tutorial updates (issue 12980044)
Reviewers: Trevor Daniels, Message: Please review. Description: As previously discussed, updates to the Windows tutorial to match the way LilyPond currently works and fit the images into the PDF better. Please review this at https://codereview.appspot.com/12980044/ Affected files: M Documentation/included/generating-output.itexi A Documentation/pictures/BadLog.png A Documentation/pictures/BadLog2.png A Documentation/pictures/DragDrop.png A Documentation/pictures/EditFile.png A Documentation/pictures/FileSave.png A Documentation/pictures/GenPDF.png D Documentation/pictures/Learning_Win7_All_Files_Created.png D Documentation/pictures/Learning_Win7_Log_File.png D Documentation/pictures/Learning_Win7_New_Menu.png D Documentation/pictures/Learning_Win7_Open_Context_Menu.png D Documentation/pictures/Learning_Win7_Open_Dragndrop.png D Documentation/pictures/Learning_Win7_Open_Menu.png D Documentation/pictures/Learning_Win7_Pdf_Output.png D Documentation/pictures/Learning_Win7_Save_File_With_Name.png D Documentation/pictures/Learning_Win7_Save_Menu.png D Documentation/pictures/Learning_Win7_Welcome_File_Whole.png A Documentation/pictures/LilyPad.png A Documentation/pictures/PDFRead.png A Documentation/pictures/SaveAs.png Index: Documentation/pictures/Learning_Win7_All_Files_Created.png diff --git a/Documentation/pictures/Learning_Win7_All_Files_Created.png b/Documentation/pictures/Learning_Win7_All_Files_Created.png deleted file mode 100644 index 5d608555c30afa1413cb00821266ed37aed8ef32.. Binary files a/Documentation/pictures/Learning_Win7_All_Files_Created.png and /dev/null differ Index: Documentation/pictures/Learning_Win7_Log_File.png diff --git a/Documentation/pictures/Learning_Win7_Log_File.png b/Documentation/pictures/Learning_Win7_Log_File.png deleted file mode 100644 index 4a68339d458d64c5269c5def063489526bca3abe.. Binary files a/Documentation/pictures/Learning_Win7_Log_File.png and /dev/null differ Index: Documentation/pictures/Learning_Win7_New_Menu.png diff --git a/Documentation/pictures/Learning_Win7_New_Menu.png b/Documentation/pictures/Learning_Win7_New_Menu.png deleted file mode 100644 index eebabd4eb570943d343bb735877a4238db0352ff.. Binary files a/Documentation/pictures/Learning_Win7_New_Menu.png and /dev/null differ Index: Documentation/pictures/Learning_Win7_Open_Context_Menu.png diff --git a/Documentation/pictures/Learning_Win7_Open_Context_Menu.png b/Documentation/pictures/Learning_Win7_Open_Context_Menu.png deleted file mode 100644 index 8e7d420ee6075af8611cf8b2353d7e9e1765668f.. Binary files a/Documentation/pictures/Learning_Win7_Open_Context_Menu.png and /dev/null differ Index: Documentation/pictures/Learning_Win7_Open_Dragndrop.png diff --git a/Documentation/pictures/Learning_Win7_Open_Dragndrop.png b/Documentation/pictures/Learning_Win7_Open_Dragndrop.png deleted file mode 100644 index 2df9b1714c0fc62cf8e864c3dc62c9d7a2ea6396.. Binary files a/Documentation/pictures/Learning_Win7_Open_Dragndrop.png and /dev/null differ Index: Documentation/pictures/Learning_Win7_Open_Menu.png diff --git a/Documentation/pictures/Learning_Win7_Open_Menu.png b/Documentation/pictures/Learning_Win7_Open_Menu.png deleted file mode 100644 index 68cdcb44c351a81481f6c67f9050163680e30b5d.. Binary files a/Documentation/pictures/Learning_Win7_Open_Menu.png and /dev/null differ Index: Documentation/pictures/Learning_Win7_Pdf_Output.png diff --git a/Documentation/pictures/Learning_Win7_Pdf_Output.png b/Documentation/pictures/Learning_Win7_Pdf_Output.png deleted file mode 100644 index 57190f3255468bbe3e77600b5f3a7a907bb55135.. Binary files a/Documentation/pictures/Learning_Win7_Pdf_Output.png and /dev/null differ Index: Documentation/pictures/Learning_Win7_Save_File_With_Name.png diff --git a/Documentation/pictures/Learning_Win7_Save_File_With_Name.png b/Documentation/pictures/Learning_Win7_Save_File_With_Name.png deleted file mode 100644 index ba605da09da076dc3badca672236185de29022fb.. Binary files a/Documentation/pictures/Learning_Win7_Save_File_With_Name.png and /dev/null differ Index: Documentation/pictures/Learning_Win7_Save_Menu.png diff --git a/Documentation/pictures/Learning_Win7_Save_Menu.png b/Documentation/pictures/Learning_Win7_Save_Menu.png deleted file mode 100644 index f9b3dd759bc98e407e746760f82768bbced728e7.. Binary files a/Documentation/pictures/Learning_Win7_Save_Menu.png and /dev/null differ Index: Documentation/pictures/Learning_Win7_Welcome_File_Whole.png diff --git a/Documentation/pictures/Learning_Win7_Welcome_File_Whole.png b
Re: Screenshots/PNG files in manuals
"Phil Holmes" writes: > - Original Message - > From: "Phil Holmes" > To: "Devel" > Sent: Thursday, August 15, 2013 4:31 PM > Subject: Screenshots/PNG files in manuals > > >> As I said earlier, I'm working on the tutorial in the LM. It uses >> screenshots to show what users will see on the screen. The versions >> on the web are (as expected from a pixel-based system) fine. >> However, the versions in the PDF docs are badly scaled and look >> ugly. It seems that this is generally tackled for images by making >> them large and then constraining the width in the tex version of the >> source (this is how it's done in the essay). I'm wondering if >> there's a better way - is there a recommended pixel-per-inch setting >> for image files that will end up in the PDFs? I've looked on the >> web and couldn't find anything, but am hoping someone will know. > > I resorted to generating a number of pixel-constrained grids at > different PPI to try to work this out, and this is what I've found. > > The main problem with screenshot-type images in the PDFs is that the > viewer program scales them badly on screen, and as a result they look > bad. Printed output is far better. However, if the resolution of a > screenshot is left at its default, then the image in the PDF is far > too big. In my experiments, it appears that a setting of 120 pixels > per inch gives a good compromise between having an image large enough > to be legible, and allowing images of a reasonable pixel count. I don't actually understand what you are trying to say here. A screen shot should always have one pixel per pixel, anything else does not make sense. You want to use PNG. > With 120 PPI, the maximum image size is just over 750 pixels. The main problem is that you'll ultimately want the output to be something like 100dpi or 150dpi in print. _Exactly_ so. So scaling to a certain width is likely to be problematic. You should figure out the typical available width, pick a resolution, and then resize your window to match the available width before doing the screen shot. Then it's best to specify the exact width when including the image, and center the image in the available line width whatever it may be. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Screenshots/PNG files in manuals
- Original Message - From: "Phil Holmes" To: "Devel" Sent: Thursday, August 15, 2013 4:31 PM Subject: Screenshots/PNG files in manuals As I said earlier, I'm working on the tutorial in the LM. It uses screenshots to show what users will see on the screen. The versions on the web are (as expected from a pixel-based system) fine. However, the versions in the PDF docs are badly scaled and look ugly. It seems that this is generally tackled for images by making them large and then constraining the width in the tex version of the source (this is how it's done in the essay). I'm wondering if there's a better way - is there a recommended pixel-per-inch setting for image files that will end up in the PDFs? I've looked on the web and couldn't find anything, but am hoping someone will know. -- Phil Holmes I resorted to generating a number of pixel-constrained grids at different PPI to try to work this out, and this is what I've found. The main problem with screenshot-type images in the PDFs is that the viewer program scales them badly on screen, and as a result they look bad. Printed output is far better. However, if the resolution of a screenshot is left at its default, then the image in the PDF is far too big. In my experiments, it appears that a setting of 120 pixels per inch gives a good compromise between having an image large enough to be legible, and allowing images of a reasonable pixel count. With 120 PPI, the maximum image size is just over 750 pixels. I think a small section in the docs section of the CG with this information might be worth it? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds bar line section to LM (Issue 3408) (issue 12724043)
On Fri, Aug 16, 2013 at 08:53:44AM +, k-ohara5...@oco.net wrote:
> On 2013/08/16 08:16:22, mail_philholmes.net wrote:
> >> Do we really need to explain how to do special bar lines before
> >> explaining accidentals?
>
> >According to mail to -user, yes. The only reason I did this was
> because of
> >a request there.
>
> The mail said it seemed strange that there was final bar-line in any
> examples in the Learning Manual.
I don't think we need to respond to every single doc suggestion;
often users are unaware of the trade-offs we've chosen or are
particularly focused on their application domain ("why bother with
stuff for singers? the LM should only be about monophonic music
which is used for strings").
> I would be tempted to simply insert \bar "|." into the longer examples
> in the LM, with no explanation, so it is there for curious people to
> find, and shows them what to look up in the index to learn more.
Either that, or add "alternate bar lines" to 2.4 Final touches.
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds bar line section to LM (Issue 3408) (issue 12724043)
On 2013/08/16 08:16:22, mail_philholmes.net wrote: > Do we really need to explain how to do special bar lines before > explaining accidentals? According to mail to -user, yes. The only reason I did this was because of a request there. The mail said it seemed strange that there was final bar-line in any examples in the Learning Manual. I would be tempted to simply insert \bar "|." into the longer examples in the LM, with no explanation, so it is there for curious people to find, and shows them what to look up in the index to learn more. I see how a digression on to \bar might be distracting here. For at least one person, confusion about how to indicate the end of a piece was also distracting. https://codereview.appspot.com/12724043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds bar line section to LM (Issue 3408) (issue 12724043)
- Original Message - From: To: ; ; ; ; ; Cc: ; Sent: Friday, August 16, 2013 5:48 AM Subject: Re: Adds bar line section to LM (Issue 3408) (issue 12724043) https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-notation.itely File Documentation/learning/common-notation.itely (right): https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-notation.itely#newcode64 Documentation/learning/common-notation.itely:64: @node Bar lines and bar checks Do we really need to explain how to do special bar lines before explaining accidentals? According to mail to -user, yes. The only reason I did this was because of a request there. The only reason we have bar checks here is that it helps the reader to see the | symbols in the input. I don't think it's useful to explain special bar lines here. Can't people find special bar lines in Notation? https://codereview.appspot.com/12724043/ -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3491: Add \displayMarkup command. (issue 12732043)
David Kastrup wrote: I vote to go ahead with adding \displayMarkup. Huh? Can you name a _single_ advantage that is gained by having \displayMarkup (which is only different from \displayScheme by refusing to accept a number of arguments) instead of \displayScheme? Of course not. I meant let's add \displayMarkup or \displayScheme as opposed to Harm's or Ian's more generic proposals. Also, what is the issue with my original wording? Seems clear and concise compared to the other suggestions: "To prevent the markup from printing on the page, use `\void \displayScheme markup'." I didn't add a @ref to where \void was previously explained because reading 13 words is easier than following a link and finding the paragraph containing the relevant material in a separate section, which in that specific case, was buried at the very end (Extending 1.3.1 "Displaying music expressions"). I *did* add a @ref to the "save to an external file" stuff because that's more involved. I've uploaded the latest incarnation. Thanks. - Mark https://codereview.appspot.com/12732043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
side-position-interface: use real positions of cross-staff grobs; issue 3363 (issue 9426044)
LGTM - just make sure to check this against the dynamics-avoid-cross-staff-stem regtests. https://codereview.appspot.com/9426044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
