Re: New issue: Add StaffAxis context type
tisimst tisimst.lilyp...@gmail.com writes: I'm not necessarily against it being called StaffAxis, but I wonder if something like MixedStaff is more appropriate? Just thinking out loud. I love this idea, btw. StaffAxis is as appropriate as it gets. MixedStaff, however, might be more suggestive of the typical use case. I'm a bit skeptical because it is _not_ a Staff. But then neither are ChoirStaff or GrandStaff. Other ideas would be Squashed (we use that in Pitch_squash_engraver), Collapsed, CollapsedStaff. That brings the behavior of the axis into the name again. \new CollapsedStaff \new Staff ... \new Lyrics ... \new ChordNames ... seems pretty descriptive, more so than MixedStaff. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: [ISSUE 4577] Add StaffAxis context type
Simon Albrecht simon.albre...@mail.de writes: Am 26.08.2015 um 18:52 schrieb David Kastrup: New issue 4577 Status: Started Summary: Add StaffAxis context type Tags: Type-Enhancement Patch-new Rietveld issue: 265730043 (https://codereview.appspot.com/265730043) Issue description: Add StaffAxis context type See the regression test for more info. Another naming suggestion: MixedLine (or SystemLine? LineContainer?). IMO ‘line’ gives a better impression of the ‘container’ character than ‘axis’. And after all, it might be used for contexts without a Staff. So may be a StaffGroup, a GrandStaff, a ChoirStaff. And all of those are containers of Staff contexts. I'm not married to the Axis bit, but the common trait _is_ every stafflike entity inside sharing a common axis, whether simultaneously or sequentially. Eventually, this should be documented within a new subsection to NR 1.6.1 http://lilypond.org/doc/v2.19/Documentation/notation/displaying-staves. Definitely. I wanted to change the existing example (part of which made it into the regtest) but found that it was gone, with the exception of some outdated translations. Good idea! Well, it arose in some user list discussion: instead of adding somewhat strange \accepts to Staff, it may be better to have one enclosing context. That's more of a stock tool rather than having to tweak contexts yourself. In addition, in that way the Staff context does not get to see events it is not suited for. Having a ChordNames context inside of a Staff context, for example, works almost more by chance than by design since the Staff context gets to see all the same events. But since at least the NoteHeadEngraver (?) sits at Voice level, one does not get to see much from this problem. But an independent context is nicer. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New issue: Add StaffAxis context type
David Kastrup d...@gnu.org writes: David Kastrup d...@gnu.org writes: tisimst tisimst.lilyp...@gmail.com writes: I'm not necessarily against it being called StaffAxis, but I wonder if something like MixedStaff is more appropriate? Just thinking out loud. I love this idea, btw. StaffAxis is as appropriate as it gets. MixedStaff, however, might be more suggestive of the typical use case. I'm a bit skeptical because it is _not_ a Staff. But then neither are ChoirStaff or GrandStaff. Other ideas would be Squashed (we use that in Pitch_squash_engraver), Collapsed, CollapsedStaff. That brings the behavior of the axis into the name again. \new CollapsedStaff \new Staff ... \new Lyrics ... \new ChordNames ... seems pretty descriptive, more so than MixedStaff. Perhaps OneStaff? OneStaff to rule them all, OneStaff to find them, OneStaff to bring them all and in the \layout bind them in the scope of \paper where the note heads lie. \oneVoice _is_ sort of the name for not separating voices vertically. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
[ISSUE 4577] Add StaffAxis context type (was: New issue: Add StaffAxis context type)
Am 26.08.2015 um 18:52 schrieb David Kastrup: New issue 4577 Status: Started Summary: Add StaffAxis context type Tags: Type-Enhancement Patch-new Rietveld issue: 265730043 (https://codereview.appspot.com/265730043) Issue description: Add StaffAxis context type See the regression test for more info. Another naming suggestion: MixedLine (or SystemLine? LineContainer?). IMO ‘line’ gives a better impression of the ‘container’ character than ‘axis’. And after all, it might be used for contexts without a Staff. Eventually, this should be documented within a new subsection to NR 1.6.1 http://lilypond.org/doc/v2.19/Documentation/notation/displaying-staves. Good idea! Yours, Simon ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New issue: Add StaffAxis context type
This is a nice addition! I'm not opposed to StaffAxis either, but here's another suggestion to consider: StaffRow. -Paul ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New issue: Add StaffAxis context type
David Kastrup d...@gnu.org writes: tisimst tisimst.lilyp...@gmail.com writes: I'm not necessarily against it being called StaffAxis, but I wonder if something like MixedStaff is more appropriate? Just thinking out loud. I love this idea, btw. StaffAxis is as appropriate as it gets. MixedStaff, however, might be more suggestive of the typical use case. I'm a bit skeptical because it is _not_ a Staff. But then neither are ChoirStaff or GrandStaff. Other ideas would be Squashed (we use that in Pitch_squash_engraver), Collapsed, CollapsedStaff. That brings the behavior of the axis into the name again. \new CollapsedStaff \new Staff ... \new Lyrics ... \new ChordNames ... seems pretty descriptive, more so than MixedStaff. Perhaps OneStaff? OneStaff to rule them all, OneStaff to find them, OneStaff to bring them all and in the \layout bind them in the scope of \paper where the note heads lie. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New issue: Add StaffAxis context type
I'm not necessarily against it being called StaffAxis, but I wonder if something like MixedStaff is more appropriate? Just thinking out loud. I love this idea, btw. - Abraham On 8/26/2015 10:52 AM, David Kastrup [via Lilypond] wrote: New issue Status: Started Summary: Add StaffAxis context type Tags: Type-Enhancement Patch-new Rietveld issue: 265730043 (https://codereview.appspot.com/265730043) Issue description: Add StaffAxis context type See the regression test for more info. -- David Kastrup ___ bug-lilypond mailing list [hidden email] /user/SendEmail.jtp?type=nodenode=180204i=0 https://lists.gnu.org/mailman/listinfo/bug-lilypond If you reply to this email, your message will be added to the discussion below: http://lilypond.1069038.n5.nabble.com/New-issue-Add-StaffAxis-context-type-tp180204.html To start a new topic under Bugs, email ml-node+s1069038n58488...@n5.nabble.com To unsubscribe from Lilypond, click here http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=2code=dGlzaW1zdC5saWx5cG9uZEBnbWFpbC5jb218Mnw4MzU3Njg3MDU=. NAML http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://lilypond.1069038.n5.nabble.com/New-issue-Add-StaffAxis-context-type-tp180204p180207.html Sent from the Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
New issue: Add StaffAxis context type
New issue Status: Started Summary: Add StaffAxis context type Tags: Type-Enhancement Patch-new Rietveld issue: 265730043 (https://codereview.appspot.com/265730043) Issue description: Add StaffAxis context type See the regression test for more info. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New issue: Add StaffAxis context type
On 8/26/2015 4:23 PM, David Kastrup [via Lilypond] wrote:
tisimst [hidden email]
/user/SendEmail.jtp?type=nodenode=180227i=0 writes:
On 8/26/2015 1:14 PM, David Kastrup [via Lilypond] wrote:
David Kastrup [hidden email]
Perhaps OneStaff?
\oneVoice _is_ sort of the name for not separating voices vertically.
I can see that, but it still doesn't seem quite right to me. As I've
thought about this more, I'm having a hard time understanding what is
different about this proposed StaffAxis vs. the already defined
StaffGroup? It already accepts most other staff contexts, so can we
just
further add to its capabilities? It seems like all it's really lacking
is the Axis_group_engraver. I haven't tested what you've added to
engraver-init.ly, etc., but does it look like this:
\layout {
\context {
\StaffGroup
\consists Axis_group_engraver
}
}
\new StaffGroup {
\new Staff {
c' d' e' f'
\chords \with { \override ChordName.Y-offset = -1 } {
d1:m7 b1:min7.5-
}
}
\chords \with { \override ChordName.Y-offset = -1 } {
d1:m7 b1:min7.5-
}
}
StaffGroup has a Vertical_align_engraver. It accepts contexts with a
vertical alignment, like StaffGroup itself or GrandStaff. As a vertical
grouper, it has a Span_bar_engraver. It has an Instrument_name_engraver
and a System_start_delimiter_engraver. It's quite a different kettle of
fish.
I realize that the StaffAxis \accepts more contexts than StaffGroup
does,
That is probably a shortcoming of StaffGroup. More important are the
contexts that StaffGroup _does_ accept and StaffAxis doesn't. And the
multitude of different engravers.
Got it. How about one of these:
- AlignmentStaff
- StaffAligner
- ContextAligner
- CompositeStaff
- HybridStaff
- StaffBlend
- AssortedStaff
Maybe StaffAxis is the best one. Is the purpose just to fix the
vertical alignment issue?
- Abraham
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/New-issue-Add-StaffAxis-context-type-tp180204p180229.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New issue: Add StaffAxis context type
On 8/26/2015 4:45 PM, David Kastrup [via Lilypond] wrote: tisimst [hidden email] /user/SendEmail.jtp?type=nodenode=180230i=0 writes: - CompositeStaff - HybridStaff - StaffBlend - AssortedStaff Maybe StaffAxis is the best one. Of those? Probably. Not that it's all that good. I like OneStaff better. I think I'll put my vote is in for that, too, unless a more descriptive one comes up. I think that's what I feel is missing, more description in the name to make it more obvious to a new user. StaffContainer? Is the purpose just to fix the vertical alignment issue? Uh, it's not a bug workaround. It's a feature. It's sole purpose is to use common Y coordinates for all contained staves. There are a number of uses for that, for both parallel and immediately successive contexts. Poor word choice on my part. I didn't mean to suggest it was a bug. I'm pretty sure I understand what it does for successive contexts, but I'm not sure what it does for parallel ones. Can you show an example? Thanks, Abraham -- View this message in context: http://lilypond.1069038.n5.nabble.com/New-issue-Add-StaffAxis-context-type-tp180204p180231.html Sent from the Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New issue: Add StaffAxis context type
2015-08-27 0:45 GMT+02:00 David Kastrup d...@gnu.org: tisimst tisimst.lilyp...@gmail.com writes: Got it. How about one of these: - AlignmentStaff - StaffAligner - ContextAligner Bad because StaffAxis does _not_ constitute a vertical alignment (quite a few other Staff containers do). - CompositeStaff - HybridStaff - StaffBlend - AssortedStaff Maybe StaffAxis is the best one. Of those? Probably. Not that it's all that good. I like OneStaff better. +1 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New issue: Add StaffAxis context type
tisimst tisimst.lilyp...@gmail.com writes:
On 8/26/2015 1:14 PM, David Kastrup [via Lilypond] wrote:
David Kastrup [hidden email]
Perhaps OneStaff?
\oneVoice _is_ sort of the name for not separating voices vertically.
I can see that, but it still doesn't seem quite right to me. As I've
thought about this more, I'm having a hard time understanding what is
different about this proposed StaffAxis vs. the already defined
StaffGroup? It already accepts most other staff contexts, so can we just
further add to its capabilities? It seems like all it's really lacking
is the Axis_group_engraver. I haven't tested what you've added to
engraver-init.ly, etc., but does it look like this:
\layout {
\context {
\StaffGroup
\consists Axis_group_engraver
}
}
\new StaffGroup {
\new Staff {
c' d' e' f'
\chords \with { \override ChordName.Y-offset = -1 } {
d1:m7 b1:min7.5-
}
}
\chords \with { \override ChordName.Y-offset = -1 } {
d1:m7 b1:min7.5-
}
}
StaffGroup has a Vertical_align_engraver. It accepts contexts with a
vertical alignment, like StaffGroup itself or GrandStaff. As a vertical
grouper, it has a Span_bar_engraver. It has an Instrument_name_engraver
and a System_start_delimiter_engraver. It's quite a different kettle of
fish.
I realize that the StaffAxis \accepts more contexts than StaffGroup
does,
That is probably a shortcoming of StaffGroup. More important are the
contexts that StaffGroup _does_ accept and StaffAxis doesn't. And the
multitude of different engravers.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New issue: Add StaffAxis context type
tisimst tisimst.lilyp...@gmail.com writes: Got it. How about one of these: - AlignmentStaff - StaffAligner - ContextAligner Bad because StaffAxis does _not_ constitute a vertical alignment (quite a few other Staff containers do). - CompositeStaff - HybridStaff - StaffBlend - AssortedStaff Maybe StaffAxis is the best one. Of those? Probably. Not that it's all that good. I like OneStaff better. Is the purpose just to fix the vertical alignment issue? Uh, it's not a bug workaround. It's a feature. It's sole purpose is to use common Y coordinates for all contained staves. There are a number of uses for that, for both parallel and immediately successive contexts. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
[ISSUE 4576] Immediately subsequent DynamicTextSpanners collide at line break
ID: 4576
STATUS: New
SUMMARY: Immediately subsequent DynamicTextSpanners collide at line break
TYPE: Ugly
LABELS:
OWNER:
%%% start message body %%
Hello,
if two DynamicTextSpanners immediately follow one another and the second
one starts at a line break,
– the first will get repeated at the beginning of the new line, although
it doesn’t span any time there
– and the texts will collide:
4576.ly %%%
\version 2.19.25
\paper { ragged-right = ##t #(set-paper-size a8) }
\header { tagline = ##f }
#(ly:set-option 'point-and-click #f)
cres = -\tweak bound-details.left.text cres \cresc
cen = -\tweak bound-details.left.text cen \cresc
do = -\tweak bound-details.left.text do \cresc
{
c'1\cres
\break
d'\cen
\break
e'\do
f\f
}
% output attached %%%
Best regards, Simon
P.S. This is how I’d suggest making entries for the tracker during the
interim. Comments would be added as replies to the thread, keeping the
‘metadata block’ at the beginning. This first block is still only to be
edited by project members.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
*.eps and *.svg .gitignore patterns match files in repo
On Aug 25, 2015; 5:05pm James Lowe wrote: On 25/08/15 18:48, markdblackwell wrote: Per https://www.kernel.org/pub/software/scm/git/docs/gitignore.html A gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected Aug 23, 2015; 6:21am, James Lowe wrote: I had similar problems when trying to add snippets in the doc for midi, i.e. any snippet ending in -midi.ly Mark D. Blackwell wrote: Because of these patterns in the .gitignore's, Git will ignore changes to those files. I misspoke. More accurately: If a file is *already* in the repository, then its name matching a .gitignore pattern won't cause Git to ignore changes to it; Git still will commit its changes easily. Only *new* files which match a .gitignore pattern will be ignored, silently. If these particular new files have names (or extensions, or path fragments, depending on the particular .gitignore pattern) similar to files present in the repository, then this is confusing. Aug 23, 2015; 6:35am David Kastrup wrote: Basically, having files both in the repository and in .gitignore is a recipe for trouble. The patterns should likely be made more discriminatory. In order to make the relevant patterns more accurately discriminatory, we might identify the programs (that we use) which generate noise files (i.e., files we want to exclude from the repository) of these kinds, and in which directories. Does anybody know? Otherwise, we should try removing these particular .gitignore patterns, and see whether our procedures still generate any of these unwanted files—and in which directories. Then (obviously) we can reinstate the patterns, and make them more discriminatory. Here's what Git blame says is the latest commit which changed the relevant lines in /.gitignore: $ git blame .gitignore 915e0d52 (Jan Nieuwenhuizen 2006-12-05 14:54:32 +0100 2) *-midi.ly 915e0d52 (Jan Nieuwenhuizen 2006-12-05 14:54:32 +0100 9) *.eps 915e0d52 (Jan Nieuwenhuizen 2006-12-05 14:54:32 +0100 26) *.svg Well I am not sure exactly what we're looking for but when I removed these entries in my .gitignore and then ran both an out of and in tree make doc, make test-baseline and a make check, I didn't get any files showing up when I then did a 'git status'. Is that good enough? Now, I'm unsure exactly what you mean. Just to clear up one possibility first, I suppose you might be asking whether this is a good enough test to establish that these current lines in .gitignore are no problem. With that I would disagree, for the reason David Kastrup stated. Let me admit that I'm not expert on (all) the various tools used by (all the) people who now, or in future, might work on LilyPond, and who might submit patches for Rietveld review, or who might commit changes to the master branch of LilyPond's repository on Savannah. Therefore, regarding the question whether yours is a good enough *test* of the safety of removing those two lines (*.eps and *.svg), I don't know. Why are those lines in there? Usually people add patterns to .gitignore to cover problematic files which arise in practice. Perhaps indeed those patterns should be removed now, as you did in your test. This would simplify .gitignore. A more conservative approach would be to change them so that they ignore files of those extensions, but only in the top-level directory. That might cover such noise files as actually do arise naturally (maybe; I don't know). So, the lines would be: /*.eps /*.svg Have you seen this similar thread?: http://lilypond.1069038.n5.nabble.com/build-gitignore-pattern-matches-files-in-repo-tt179867.html Based on it, the pattern build/ in .gitignore should be changed perhaps to: /build/ These three (3) changes to lines in .gitignore, if committed to the LilyPond master branch on Savannah, would cover absolutely all the files of the current repository (as of August 21, 2015, anyway), so that no file matches a pattern in .gitignore. I believe this is what David Kastrup desires (see above). -- View this message in context: http://lilypond.1069038.n5.nabble.com/eps-and-svg-gitignore-patterns-match-files-in-repo-tp179828p180196.html Sent from the Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New issue: Add StaffAxis context type
On 8/26/2015 1:14 PM, David Kastrup [via Lilypond] wrote:
David Kastrup [hidden email]
/user/SendEmail.jtp?type=nodenode=180216i=0 writes:
David Kastrup [hidden email]
/user/SendEmail.jtp?type=nodenode=180216i=1 writes:
tisimst [hidden email]
/user/SendEmail.jtp?type=nodenode=180216i=2 writes:
I'm not necessarily against it being called StaffAxis, but I wonder
if something like MixedStaff is more appropriate? Just thinking out
loud. I love this idea, btw.
StaffAxis is as appropriate as it gets. MixedStaff, however,
might
be more suggestive of the typical use case. I'm a bit skeptical
because
it is _not_ a Staff. But then neither are ChoirStaff or GrandStaff.
Other ideas would be Squashed (we use that in Pitch_squash_engraver),
Collapsed, CollapsedStaff. That brings the behavior of the axis into
the name again.
\new CollapsedStaff
\new Staff ...
\new Lyrics ...
\new ChordNames ...
seems pretty descriptive, more so than MixedStaff.
Perhaps OneStaff?
OneStaff to rule them all, OneStaff to find them,
OneStaff to bring them all and in the \layout bind them
in the scope of \paper where the note heads lie.
Dude! That's awesome! 10 Tolkien points for you!
\oneVoice _is_ sort of the name for not separating voices vertically.
I can see that, but it still doesn't seem quite right to me. As I've
thought about this more, I'm having a hard time understanding what is
different about this proposed StaffAxis vs. the already defined
StaffGroup? It already accepts most other staff contexts, so can we just
further add to its capabilities? It seems like all it's really lacking
is the Axis_group_engraver. I haven't tested what you've added to
engraver-init.ly, etc., but does it look like this:
\layout {
\context {
\StaffGroup
\consists Axis_group_engraver
}
}
\new StaffGroup {
\new Staff {
c' d' e' f'
\chords \with { \override ChordName.Y-offset = -1 } {
d1:m7 b1:min7.5-
}
}
\chords \with { \override ChordName.Y-offset = -1 } {
d1:m7 b1:min7.5-
}
}
I realize that the StaffAxis \accepts more contexts than StaffGroup
does, but what do you think?
- Abraham
iibafihh.png (8K)
http://lilypond.1069038.n5.nabble.com/attachment/180221/0/iibafihh.png
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/New-issue-Add-StaffAxis-context-type-tp180204p180221.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Out of town, out of contact
Greetings - I will be out of town, and pretty much out of internet capability, for the next three Fridays. In other words, I shall not be able to cover August 28, September 4, or September 11. I apologize for any inconvenience this may cause. In gratitude for such a wonderful program and community, Ralph ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
