Re: Frecobaldi 2 Mac OS X install guide
flup2 wrote > Here is a step by step guide to install Frescobaldi on a Mac OS X system. > > I hope to have some time to make this easier to read (and, why not, > include it to Frescobaldi website) Philippe, Thanks for this guide! It would definitely be good to have it on the Frescobaldi website. I have a question: When *upgrading* to a new version of Frescobaldi, should you do the whole process over again to upgrade all dependencies, or do you just re-install the new version of Frescobaldi? I have seen on the Frescobaldi list that sometimes there is trouble when upgrading dependencies and keeping them all working together. Thanks again, -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/Frecobaldi-2-Mac-OS-X-install-guide-tp145898p145913.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ANN: Frescobaldi 2.0.10
On May 12, 2013, at 10:24 PM, Tim McNamara wrote: > Struggling through with installing this on a Mac, how the heck does one get > Poppler to work? Jeez, after installing nearly a GB of dependencies, > everything seems to work but Poppler. Hi Tim, Glad you've got Frescobaldi working except for Poppler. I haven't tackled upgrading to 2.0.10 yet, but I previously got Poppler to work with 2.0.8 by installing it through MacPorts. Here's my current version info, if that's helpful: Frescobaldi: 2.0.8 Python: 2.7.3 Qt: 4.8.4 PyQt4: 4.9.6 sip: 4.14.2 Operating System: Darwin-12.3.0-x86_64-i386-64bit And here are some notes I made for myself, FWIW: Use macports to install: - poppler (using +qt4 variant (also added +quartz variant, but that's probably not necessary)) - use terminal to install poppler-qt from their site as described on frescobaldi site (note: I had to add "sudo" before python "setup.py install" to get it to work) -- -Paul Morris ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML project platform
On Apr 26, 2013, at 4:31 PM, Curt wrote: > My own sense after reviewing the discussions I've been able to find: > > I suspect that focusing on music-stream export first is too "half-a-loaf" and > would require major rework once we add positioning. And, that re-parsing the > input file for positioning information is not as good an option as figuring > out how to hook export logic into the lilypond positioning logic itself. It > seems the right way is to make the positioning logic maintain knowledge of > music-stream. I hear your concern, but as I understand it the music stream is the closest that the music data in LilyPond gets to the structure and level of abstraction of a MusicXML file. (MusicXML 1.0 included no positioning/layout info, which was then added at 2.0, so in a sense we could follow that progression as well, targeting 1.0 first.) So that is why people who know the internals of LilyPond are recommending this approach. Especially, Han-Wen: "you would probably have to use some sort of dual approach, where you store the stream, label each event, and then you trace back the grobs during output stage to their originating events. You can use the ordering from the stream to output the XML elements in the correct order." I take it that the music stream has the order that is needed for the XML file, and that order is no longer present once the stream is converted to grobs and their positioning is determined. So use the stream's order as the framework, and then trace the grobs to their originating events in the stream in order to add positioning after it is determined.[1] This approach has the big advantage that you can do a first iteration without the positioning info and get a lot more benefit for a lot less effort. And one of the biggest constraints here is the volunteer labor force when there are a lot of other areas that are being worked on by only a few people. One of the key variables is how important is having the positioning data? In my mind it is not really that important relative to having an export of the basic musical data. Positioning is icing on the cake. In some cases it may not be used at all, as with a publisher who will do their own custom positioning anyway, or in Braille notation. That's my understanding at least, but I'm no expert. At any rate, I imagine that your insights in organizing, identifying dependencies, tasks, etc, might help. Cheers, -Paul [1] After the music stream data goes to the various engravers and is converted into graphics (grobs). So a note from the input file that has a pitch and duration is converted into separate grobs of a notehead, a stem, a flag, etc, and only at that point is the positioning determined in relation to other grobs. Hence as Mike Solomon said: "there is not a one-to-one correspondence between events in the music stream and musical objects created." ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML project platform
On Apr 26, 2013, at 8:59 AM, Urs Liska wrote: > in order not to let this discussion go asleep again, I set up a GitHub project Hi Urs, Good idea. I added the following which I dug up. As well as the link to SXML support in Guile 2.0. -Paul ___ This discussion on LilyPond's issue tracker gives a lot of insights: http://code.google.com/p/lilypond/issues/detail?id=665 Including comment #15 from Jan Nieuwenhuizen: "You may want to look at input/regression/to-xml.ly and scm/to-xml.scm, some old and preliminary work there." Searcing for "to-xml.ly" in the lilypond-devel archive only brings up 5 results, but the file has existed since September 2002 at least: http://lists.gnu.org/archive/html/lilypond-devel/2002-09/msg00199.html ___ One possibility is to follow the example of MIDI file creation/export. This would apparently require working in C++ rather than Scheme or Python. On 10 Jul 2011 Reinhold Kainhofer (who coded the musicxml2ly python script) wrote: "I have rather been thinking about adding MusicXML export like the MIDI export: Create some translator (e.g. a base class Exporter or Xporter to indicate XML, like Performer or Engraver) and subclasses to listen to all the different music events/grobs. That would probably be the most native and probably also easiest implementation of MusicXML export. For example, MIDI creation is relatively simple code-wise (just look at the performer.cc and the audio.cc and midi*.cc files)." >From the following lilypond-devel thread: >http://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg00398.html ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML
On Apr 24, 2013, at 12:52 AM, m...@mikesolomon.org wrote: > Python is a great tool for XML creation. There is also > http://okmij.org/ftp/Scheme/xml.html. The advantage of doing it in Scheme is > that you are building it directly into LilyPond. Doing it in scheme does seem to offer some nice advantages. I looked into it and found that there's SXML, a scheme version of XML: SXML: '(doc (title "Hello world")) XML: Hello world And there is existing scheme code that converts SXML to an XML file.[1] So if all went well (ha ha) it would "just" be a matter of rearranging the scheme data from the music stream into SXML format, following the MusicXML specification. Though I'm sure that's harder than it sounds. Having all the moving parts in scheme would be nice and having an internal scheme version of the XML file might make it easier to (eventually, maybe) add in additional data that is not part of the music stream. Is the music stream what you see when you use \displayMusic as described here? http://lilypond.org/doc/v2.16/Documentation/extending/displaying-music-expressions [1] http://modis.ispras.ru/Lizorkin/sxml-tutorial.html#hevea:serializ [2] https://en.wikipedia.org/wiki/SXML [3] http://www.ibm.com/developerworks/library/x-matters31.html Quoting: "XML is semantically almost identical to the nested list-oriented data structures native to Lisp-like languages. Anything you can represent in XML can be straightforwardly represented as SXML -- Scheme lists nesting the same data as the original XML. Moreover, Scheme comes with a rich library of list and tree manipulation functions, and a history of contemplating manipulation of those very structures. A natural fit, perhaps." Cheers, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML
On Apr 23, 2013, at 2:21 PM, "Christopher R. Maden" wrote: > Can someone please summarize (or point me to a summary of) the current > state of MusicXML support, what needs to be done, and the > infrastructure? E.g., is a standalone XSLT conversion acceptable, or > should MusicXML import/export be integrated into the core LilyPond code? I don't know enough to give an adequate summary, but here are some starting points. Import documentation: http://www.lilypond.org/doc/v2.16/Documentation/usage/invoking-musicxml2ly Export feature tracker: http://code.google.com/p/lilypond/issues/detail?id=665&q=musicxml&colspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary Work done on musicxml2ly for Philomelos.net that has not yet been incorporated back into the version shipped with LilyPond: (the low hanging fruit?) http://lists.gnu.org/archive/html/lilypond-user/2013-03/msg00919.html Cheers, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Newbie problems
On Apr 15, 2013, at 10:48 AM, Peter Toye wrote: > One problem I'm having is that it's not easy to find things in the > documentation. As with all language systems,. you spend an awful lot of time > searching. I have had good luck searching the Notation Reference index page (using your browser's "find" command"): http://www.lilypond.org/doc/v2.16/Documentation/notation/lilypond-index -Paul___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Frescobaldi install (was: final score)
On Mar 10, 2013, at 4:08 PM, flup2 wrote: > The "opt/" etc. path and the frescobaldi command must be on the same line. > They seem to be on 2 different lines in your command. Ah, right. The email formatting made it seem like they were on separate lines. I also realized that the cd /Library/... line needed to be pointing at the directory containing the UNIX executable file "frescobaldi". Which was here for me: cd /Library/Frameworks/Python.framework/Versions/2.7/bin/ Those two changes have got it working for me. Thanks again! -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Frescobaldi install (was: final score)
On Mar 10, 2013, at 1:23 PM, flup2 wrote: > #!/bin/sh > > cd /Applications/frescobaldi > /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 > frescobaldi Thank you for the instructions! When I installed frescobaldi, I just did the default install from the command line, and it looks like it is located here: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/frescobaldi_app so I tried using the following in Platypus: #!/bin/sh cd /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/frescobaldi_app /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 frescobaldi But I get this error: line 5: frescobaldi: command not found Any ideas? Thanks again, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Frescobaldi install (was: final score)
On Mar 10, 2013, at 3:39 AM, flup2 wrote: > But as soon as the macports installation is done (between 1 and 4 hours > depending the computer age), anyone can create an .app bundle (I posted the > way to do it) that only includes a launch script. Hi Philippe, Can you point me to where you posted how to do this? Was it on the lilypond-user list? Thanks, -Paul PS. I used macports to install Frescobaldi. It did take awhile, and several steps, but ultimately worked. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Proposed new available and recommended behavior of \relative
On Mar 10, 2013, at 10:22 AM, David Kastrup wrote: > The proposed convert-ly rule of issue 2329 converts everything it can > interpret (which is the majority) to argumentless \relative. This > conversion is needed for converting the LilyPond code base, and it > should be available to the user as well. It should likely not be > applied without notice as it affects work style. Ah, "code base" includes the docs. I missed that before. Giving the user the option of whether to convert to argument-less \relative or not would be ideal. Not sure if convert-ly can do that. Also, looks like you meant issues 3229 and 3231 (not 2329 or 2331). > There was one other major convert-ly rule doing an actually optional > conversion: >\override Context.Grob #'property #'sub = #5 > into >\override Context.Grob.property.sub = #5 > I think that doing this without asking was ok since it did not really > affect meaningful choices taken by the user. That makes sense. > For better or worse, the choice of a reference pitch, even though it was > a choice forced on the user, will likely have been taken with some > deliberation, likely reflecting personal style and/or preferences. > Throwing it away without asking would likely be impolite. Agreed. > Issue 2331 only converts \relative without reference pitch to \relative c'. Sounds good, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Proposed new available and recommended behavior of \relative
On Mar 9, 2013, at 10:05 PM, Jim Long wrote: > I would rather not have convert-ly change any use of \relative with an > explicit reference pitch. That was my thought too. Of course it would be possible, but since there would be no change to the usage of explicit reference pitches, I don't see a reason for convert-ly to change anything if people are using that approach. -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Bar lines
On Mar 8, 2013, at 1:21 AM, Janek Warchoł wrote: > To be absolutely clear: i want both an 'end-bar' property and the > thing mentioned above. > To put it differently: i suggest to have an 'end-bar' property and set > its default value to a function which returns "|." for longer music > and "|" for shorter, while allowing user to set the value to something > else he wants. > An example of very similar design that is currently implemented: there > is a property ragged-right, which default value is ##t for music that > is 1 system long, and ##f for longer music. The idea is precisely the > same as mine: normally all music should have systems justified to fit > the page width, but for the sake of snippets in music theory works > (e.g. Lily docs) this shouldn't be done when the score is really > short. > > Is my explanation clear? This makes sense to me, and I like your idea. Have an end-bar property and just as with ragged-right, when there is more than one line/system (or whatever measure makes sense) default to the standard thicker closing bar. And of course all of this can be overridden by the user. -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Proposed new available and recommended behavior of \relative
On Mar 9, 2013, at 4:47 AM, David Kastrup wrote:
> So that's the next step: opening the door on \relative { } again, or rather a
> different door with the same door handle.
Interesting discussion. I like the new/proposed behavior for \relative { ... }
(without reference pitch), and would probably use it myself.
As someone mentioned, it might be helpful to explain things in the docs
something like the following: If there is no explicit reference pitch, the
first note defaults to being relative to f (or else the middle note of the
current scale if the scale has been changed). And also say that this happens
to correspond with seeing the first pitch as written in absolute notation (as a
quick way of determining the pitch of the first note). So both ways of looking
at it work. (Am I understanding this right?)
That would address concerns about the perception of mixing absolute and
relative notation inside the { ... }.
OTOH, it is pretty straightforward to say that the first note after \relative
is interpreted in absolute terms as a starting point / reference pitch for
subsequent notes, whether it is inside or outside of the { ... }.
> Then there are two more questions:
>
> a) should the LilyPond codebase walk through that door?
I would say yes. But seems like there is another question:
a2) should \relative { ... } be the default/recommended approach as presented
in the docs?
I'm leaning slightly towards yes on this, but it's probably worth sitting with
it for a bit.
> b) should convert-ly make user code walk through that door once?
Hmmm... If people have been using an explicit reference pitch, nothing changes
in that case. So it's just if they have *not* been using one (which has been
deprecated, right?) that convert-ly will need to either
1) possibly change the octave of the first pitch inside { ... }
2) possibly add an explicit reference pitch.
I'm not sure which is better, and maybe this is getting ahead of ourselves.
On Mar 9, 2013, at 5:40 AM, David Kastrup wrote:
> a) stop any further use of the current \relative { ... }
> That's issue 3231.
> b) Implement new proposed behavior for \relative { ... }.
> That's the ly/music-functions-init.ly part of issue 3229.
> c) give this proposed behavior equal coverage in the passages talking
> about absolute and relative pitches in Learning and Notation.
> Impact: a handful of paragraphs.
> d) wait and see.
Sounds good.
-Paul
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: final score
On Mar 4, 2013, at 10:39 AM, flup2 wrote: > The best would be to create a "Macport's port for Frescobaldi. I'll try to > see if it's easy or not. I agree that this would really help and is a smart "low-hanging-fruit" approach. Thanks for looking into it. -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: final score
On Mar 4, 2013, at 10:28 AM, Francisco Vila wrote: > What I really meant is that a monolithic, windows-style installer for > Frescoaldi on MacOs is more important than one for GNU/Linux because > GNU/Linux users are more likely to be able to face the rather > challenging compiling/installing process of Frescobaldi. > > Important for Frescobaldi and indirectly also for LilyPond, IMO, > because I find Frescobaldi very user friendly and thus it lowers the > entry threshold to LilyPond. +1 from someone who recently went through his first command-line-build-dependencies-from-source ordeal to get Frescobaldi running on a mac. It was no picnic, with lots of gotchas. I think most would not have the patience for it, since they are used to simple installations. That's too bad because Frescobaldi is wonderful and really improves the experience of working with LilyPond. Also, would it be worth adding line numbers to the default binary LilyPad apps? That by itself would go a long way by making it easy to find errors. -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: CPU usage and barchecks
On Feb 25, 2013, at 2:48 PM, Antonio Gervasoni wrote: > I wonder if a future version of Lilypond would be able to compile only > the parts that change. Maybe with some kind of version control management > incorporated into the software. Don't know why it wasn't included from the > beginning but guess it's because it's not as easy as it sounds. LOL Hi Antonio, You might find this interesting: http://lilypond.org/schikkers-list/ "The basic idea is to have LilyPond render only a small bit of the music: the bit that changed." -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Mutopia
"New contributions will not be added until such a new team is in place, although I will try to continue to process updates to existing contributions where possible." This is from Chris Sawyer's message (copied below) to the Mutopia discussion list on November 25, 2012, in the thread "Mutopia must live!" Cheers, -Paul ___ All, Thanks for the various messages during today. As has become rather obvious, Mutopia activity has been almost non-existant for the last few months and the time has come for me to hand over leadership to someone new with the energy and enthusiasm to take the project forward. I have been leading the project since 1999 but unfortunately no longer have the time to put in the hours required to bring the site up to modern standards and co-ordinate the addition and updating of contributions. We attempted to set up a new system for handling contributions around a year ago but unfortunately that wasn't completed for various reasons. I do not want to see Mutopia die due to lack of interest on my part, and am willing to work for several months with a new team to get things going again. However someone needs to volunteer to co-ordinate that team. New contributions will not be added until such a new team is in place, although I will try to continue to process updates to existing contributions where possible. Thanks to all who have supported Mutopia since 1999 and if you are interested in co-ordinating the project from now onwards please contact me by e-mail. If you want to see how things work at present, the source code for the website, scripts and all LilyPond files can be found in github. Of course I will give admin rights to the new co-ordinator so the project can be taken forward. I still believe Mutopia is unique in offering "open source" sheet music that can be edited, transposed, arranged, etc. all using free software. I really hope that a new team can be found to continue the work. Best regards, Chris ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Changing the "midpoint" of a custom staff for stem direction purposes
On Feb 10, 2013, at 6:09 PM, Eluze wrote:
> I never used such transformations, but in
>
> /NR 1.6.2 Modifying single staves /(2.17.11) I found:
>
> "The clef position and the position of middle C may need to be adjusted
> accordingly to fit
> the new lines."
Thanks Eluze. I had actually tried this, as follows:
1. Set the custom staff line-positions so that they are centered on the default
staff midpoint (0). This means the direction of stems are automatically
correct. No Scheme needed.
2. Set middleCPosition and clefPosition for the staff to adjust the notes and
clef so they appear at the correct vertical positions on the staff.
(See example code below.)
The only trouble is that any time there's a clef change, you have to manually
re-do the custom middleCPosition and clefPosition that you had set, since each
new clef overwrites these staff settings with the default values (not your
custom values).
I guess ideally the midpoint of the staff would be a customizable Staff
property (so that stem directions could be correct when using custom staff line
positions).
And/or it would be handy if there were a way to set what the middleCPosition(s)
and clefPosition(s) should be for clefs on a given staff once, without having
to manually reset them with each clef change. So basically if there were a way
to customize the values that are set for middleCPosition and clefPosition for
each type of clef, within a given staff.
I'm not sure if there's a way to use Scheme to override the clef setting
operation to apply custom values instead of the defaults, maybe with a custom
clef engraver?
I realize we're pretty far into non-standard customization territory here...
Cheers,
-Paul
BEGIN
\version "2.16.1"
theMusic = \relative c' {
% adjustments to middleCPosition and clefPosition
% overwritten by new clef signs
c4 e g c
\clef bass
c,, e g c
\clef treble
c e g c
\break
% manual re-setting required to restore correct positions
\set Staff.middleCPosition = #-5
\set Staff.clefPosition = #-1
c,4 e g c
\clef bass
\set Staff.middleCPosition = #-2
\set Staff.clefPosition = #1
c, e g c
\clef treble
\set Staff.middleCPosition = #-5
\set Staff.clefPosition = #-1
c, e g c
}
\score {
\new Staff \with {
\override StaffSymbol #'line-positions = #'( -3 -1 1 3)
middleCPosition = #-5
clefPosition = #-1
}
{\theMusic }
\layout {}
}
END
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: No time signature or bar lines
On Feb 10, 2013, at 12:22 AM, SoundsFromSound wrote:
> Hmm, I think I maybe figured it out. Not 100% sure if it's the most lean,
> efficient code but this seems to work great for what I want:
>
> A solo piano piece with no barlines and no time signature.
Looks fine to me. As Xavier and David mentioned, probably better to override
the stencil instead of removing the engraver:
\layout {
\context {
\Staff
\override TimeSignature #'stencil = #point-stencil% = ##f also works
}
}
Cheers,
-Paul
>
>
> \version "2.17.10"
>
> \header {
> % Remove default LilyPond tagline
> tagline = ##f
> }
>
> global = {
> \key c \major
> \numericTimeSignature
> \time 4/4
> }
>
> right = \relative c'' {
> \global
> \cadenzaOn
> c4 \times 4/5 {fis8[ g e' g,, a'] } bes16[ c c c c]
>
> }
>
> left = \relative c' {
> \global
> c,8[ g a bes,] f[ g] g f'es
>
> }
>
> \score {
> \new PianoStaff \with {
>instrumentName = "Piano"
> } <<
>\new Staff = "right" \right
>\new Staff = "left" { \clef bass \left }
>>>
> \layout {
>%% insert these lines within the
>%% layout block after your music:
>\context {
> \Staff
> \remove Time_signature_engraver
>
>}
>
> }
> }
>
>
>
>
> -
> composer | sound designer
> --
> View this message in context:
> http://lilypond.1069038.n5.nabble.com/No-time-signature-or-bar-lines-tp140688p140695.html
> Sent from the User mailing list archive at Nabble.com.
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: No time signature or bar lines
On Feb 9, 2013, at 6:53 PM, ivan.k.kuznet...@gmail.com wrote:
> (1) the example below is pretty much what I want expect
> that there is space where the time signature would normally go
> (I erase the time signature with
> "\override TimeSignature #'transparent = ##t" but the space
> is still there).
>
> How can I get rid of this space?
I don't know why this does not work:
%%
\version "2.16.0"
\score { % score
\new Staff \with {
\override TimeSignature #'break-visibility = #'#(#f #f #f) } % <--- ADDED
{
\time 4/4
\key c \major
\clef "treble"
\cadenzaOn
a1b1
c'1 d'1 e'1 f'1 g'1 a'1 b'1
c''1 d''1 e''1 f''1 g''1 a''1 b''1
\cadenzaOff
}
\layout {
\context {
\Score
%
}
}
} % score
%%
...as described here:
http://lilypond.org/doc/v2.16/Documentation/notation/visibility-of-objects#using-break_002dvisibility
But the following works.
HTH,
-Paul
%%
\version "2.16.0"
\score { % score
\new Staff \with { \remove "Time_signature_engraver" } % <--- ADDED
{
\time 4/4
\key c \major
\clef "treble"
\cadenzaOn
a1b1
c'1 d'1 e'1 f'1 g'1 a'1 b'1
c''1 d''1 e''1 f''1 g''1 a''1 b''1
\cadenzaOff
}
\layout {
\context {
\Score
% \override TimeSignature #'transparent = ##t
}
}
} % score
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Changing the "midpoint" of a custom staff for stem direction purposes
Hello everyone,Here's another obscure question. If you change the line-positions to create a custom staff, for example to have a 4-line staff, what is the best way to also change the "midpoint" of the staff, so that the stem directions are correct for the altered staff? (Notes should get upwards stems in the bottom half of the staff, and downward stems in the top half.)I've gotten pretty far with the approach below. It seems to work, but then it does not work for beamed 8th notes. (I started by setting the stem's "direction" instead of "default-direction", but that works "too well" and results in beaming problems -- see attached image.)Internals Reference for Stem:http://www.lilypond.org/doc/v2.16/Documentation/internals/stemAny suggestions appreciated,-Paul%%% BEGIN \version "2.16.1"#(define (stemDirectionHandler midpoint) (lambda (grob) (let* ( (notecol (ly:grob-parent grob X)) (stm (ly:grob-object notecol 'stem)) (ypos (ly:grob-staff-position grob))) (if (< ypos midpoint) (set! (ly:grob-property stm 'default-direction) 1) (set! (ly:grob-property stm 'default-direction) -1)theMusic = \relative c' { c4 d e f g a b c d e f g a b \time 2/4 r8 c,,8 d e f g a b c d e f g a b}\score { \new Staff \with { \override StaffSymbol #'line-positions = #'( 1 3 5 7 ) \override NoteHead #'before-line-breaking = #(stemDirectionHandler 4) \override Stem #'no-stem-extend = ##t \remove "Clef_engraver" \remove "Time_signature_engraver" } {\theMusic } \layout {}}%%% END___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Space between Piano Staves
On Feb 3, 2013, at 8:13 PM, Mark Stephen Mrotek wrote: > For what term/command do I search the online manual for directions to control > the distance from one Piano staff to the next Piano staff? Hi Mark, I think you are looking for this: http://www.lilypond.org/doc/v2.16/Documentation/notation/flexible-vertical-spacing-within-systems#spacing-of-grouped-staves Notation Reference --> Spacing Issues --> Vertical Spacing --> Spacing of Grouped Staves Cheers, -Paul___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ledger line crash with very high notes in first chord of system
On Jan 30, 2013, at 5:32 PM, Jeffrey Trevino wrote:
> A great trick! It looks like beaming and slurring across staffs works well
> with this technique, which is marvelous.
Hi Jeff, Glad this may prove useful to you.
> Is there a way to attach a "treble^8" clef at the beginning of the additional
> staff?
I figured this out, using this doc page:
http://www.lilypond.org/doc/v2.16/Documentation/notation/displaying-pitches#clef
See below...
> Is there a way to display a chord with a stem across both staffs, which notes
> on both staffs?
This already Just Works, nothing special needed!
\version "2.16.1"
\relative c'' {
c a' c
% begin extended staff
\stopStaff \startStaff
\override Staff.StaffSymbol #'line-positions = #'( 18 16 14 12 10 4 2 0 -2 -4
)
\override Stem #'no-stem-extend = ##t
% print the clef on the extended staff:
% \set Staff.clefGlyph = #"clefs.G"
\set Staff.clefPosition = #12
\set Staff.clefOctavation = #7
a' g
% restore normal staff
\stopStaff \startStaff
\override Staff.StaffSymbol #'line-positions = #'( 4 2 0 -2 -4 )
\override Stem #'no-stem-extend = ##f
a c
}
I commented out the line that sets the clefGlyph, since it is not needed for
this use case (it is already set as a treble clef). It might be useful for
other applications, so I didn't take it out entirely.
There are still some spacing tweaks to work out, like maybe pushing the clef to
the right a bit so that the staff extends beyond it on the left.
Cheers,
-Paul
> On Mon, Jan 28, 2013 at 11:27 AM, Paul Morris wrote:
> On Jan 28, 2013, at 11:24 AM, Eluze wrote:
>
> > adding
> >
> > \stopStaff \startStaff
> >
> > works
>
> Thanks! I also added an override to keep the stems from being extended all
> the way down. Not sure if this is the best approach, but good to know how to
> use it.
>
> -Paul
>
>
> \version "2.16.1"
>
> \relative c'' {
> c a' c
> \stopStaff \startStaff
> \override Staff.StaffSymbol #'line-positions = #'( 18 16 14 12 10 4 2 0 -2
> -4 )
> \override Stem #'no-stem-extend = ##t
> a' c a cis
> \stopStaff \startStaff
> \override Staff.StaffSymbol #'line-positions = #'( 4 2 0 -2 -4 )
> \override Stem #'no-stem-extend = ##f
> a,, c
> }
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ledger line crash with very high notes in first chord of system
On Jan 30, 2013, at 11:36 PM, Paul Morris wrote: > \set Staff.clefOctavation = #7 Actually, this should be: \set Staff.clefOctavation = #14 since the clef is two octaves higher, not one, right? -Paul___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \bar"|:" & \bar":|"
On Jan 28, 2013, at 10:25 PM, MING TSANG wrote: > I try tools menu update with convert-ly & I got the following error from > frescobaldi. Hi Ming, Hmmm... it works for me. I do not know how to troubleshoot that error you got. I would try the Frescobaldi mailing list as Federico suggested. Cheers, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \bar"|:" & \bar":|"
On Jan 28, 2013, at 8:47 PM, MING TSANG wrote: > how do I run convert-ly using frescobaldi? Hi Ming, try: Tools menu --> Update with convert-ly... HTH, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ledger line crash with very high notes in first chord of system
On Jan 28, 2013, at 11:24 AM, Eluze wrote:
> adding
>
> \stopStaff \startStaff
>
> works
Thanks! I also added an override to keep the stems from being extended all the
way down. Not sure if this is the best approach, but good to know how to use
it.
-Paul
\version "2.16.1"
\relative c'' {
c a' c
\stopStaff \startStaff
\override Staff.StaffSymbol #'line-positions = #'( 18 16 14 12 10 4 2 0 -2
-4 )
\override Stem #'no-stem-extend = ##t
a' c a cis
\stopStaff \startStaff
\override Staff.StaffSymbol #'line-positions = #'( 4 2 0 -2 -4 )
\override Stem #'no-stem-extend = ##f
a,, c
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ledger line crash with very high notes in first chord of system
On Jan 28, 2013, at 5:32 AM, m...@mikesolomon.org wrote:
> I haven't completely wrapped my head around the best way to implement it, but
> it seems like one solution is overriding the stencil function of the
> LedgerLineSpanner to be continuous across notes.
Hmmm... I tried overriding the line positions of the staff:
\version "2.16.1"
\relative c'' {
a c
\override Staff.StaffSymbol #'line-positions = #'( 18 16 14 12 10 4 2 0 -2
-4 )
a' c a' c
}
\relative c'' {
\override Staff.StaffSymbol #'line-positions = #'( 18 16 14 12 104 2 0 -2
-4 )
a c a' c a' c
}
It looks like this only works to change the whole staff, by putting it at the
beginning of the music (or in the Staff's \with block), and does not work for a
temporary staff extension occurring in the middle of the music.
-Paul
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Writing markup in lisp
On Jan 26, 2013, at 12:42 PM, David Kastrup wrote:
> Not quite: you'll need
>
> \addInstrumentDefinition #"contrabassoon"
> #`((shortInstrumentName . ,#{ \markup { ... } #} ))
>
> or you'll have the quoted equivalent of \markup in your definition.
Thanks David!
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Writing markup in lisp
Please disregard my last message. I now see that you wanted to use \markup in
the following scheme code:
\addInstrumentDefinition #"contrabassoon"
#`((shortInstrumentName . "Cbsn."))
So I think something like this should work:
\addInstrumentDefinition #"contrabassoon"
#`((shortInstrumentName . #{ \markup { ... } #} ))
Apologies for the noise.
-Paul
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Writing markup in lisp
Hello Alberto,
Looks like you've already figured it out, but you can also wrap lilypond code
in #{ ... #} to embed it in scheme code. This is particularly helpful for
use with \markup. So I think the following should also work (although I
haven't tried it):
\set Staff.instrumentName = #{ \markup {
\column { "Clarinetti"
\line { "in B" \smaller \flat } } } #}
See:
http://www.lilypond.org/doc/v2.16/Documentation/extending/markup-construction-in-scheme
HTH,
-Paul
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Mac MIDI synthesizer (was frescobaldi on mac)
On Jan 15, 2013, at 4:47 AM, flup2 wrote: > Each time Qsynth is launched, it uses a different port, obvisously; if you > had to restart it, you need to click "Refresh MIDI ports" and choose another > Fluidsynth occurrence (the port number is shown between parenthesis). Thank you. That's got it working for me again. (I had tried clicking "refresh MIDI ports" before, but did not click the pull-down menu to realize that another option had been added to it that needed to be chosen. If it was not a pull down menu, but an always-visible list of options, then I wouldn't have missed it. I think I assumed that the refresh button would remove the old no-longer-working instance and go ahead and replace it with a new one, but that was not the case.) -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Mac MIDI synthesizer (was frescobaldi on mac)
On Jan 14, 2013, at 7:13 PM, james wrote: > what do those of you here who have osx 10.7+ use for MIDI playback? I've just been using Quicktime Player 7, and haven't looked into other options. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: frescobaldi on mac
I spoke too soon. MIDI was working, but now it's not. Under Frescobaldi's MIDI Settings "FluidSynth virtual port" shows up just fine, and midi files load fine in the player. But when I click play it gives a "No output found!" message and there is no audio. (It appears that qsynth needs to be open for the MIDI player to work in Frescobaldi. When it is not open, under MIDI settings it says "There are no MIDI output ports available on your system..." Things stopped working when I closed qsynth while Frescobaldi was still working. Now I can't get it working again.) I guess I should move this over to the Frescobaldi discussion forum... -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: frescobaldi on mac
On Jan 14, 2013, at 6:36 PM, Tim McNamara wrote: > I'm still not able to get this to work. Frescobaldi complains about not > having SIP even though SIP is installed and activated, and therefore won't > launch. Which means of course that I am not yet able to try to get it to > find Lilypond... Wish I knew how to troubleshoot this. Was this when using MacPorts to install everything? For what it's worth, before I started using MacPorts, when attempting to install python-poppler-qt4, it failed because it said it couldn't find SIP. However, opening Frescobaldi and going to About > Version showed that SIP was installed. -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: frescobaldi on mac
On Jan 14, 2013, at 4:00 PM, flup2 wrote: > Here's the way I made MIDI work within Frescobaldi on a Mac: Thanks Philippe! I followed your steps and Frescobaldi's MIDI player is now working for me. This is especially nice because I was never able to get it to work with the older 2.0.4 pre-packaged-for-mac version of Frescobaldi that I was using before. I'll post these instructions to the Frescobaldi mailing list so that this is documented there (at least). -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: frescobaldi on mac
Philippe's message inspired me to try again using Macports. It was *much* easier going than without Macports. "python-poppler-qt" is now working for me for PDF functionality, but I still have not been able to get the midi part (portmidi) to work. Jim, below are my notes on what I did, in case they might help. -Paul ___ Installing Frescobaldi using MacPorts (Mac OS 10.8.2, Frescobaldi 2.0.8) Logged in to admin user account on Mac OS X INSTALLING MACPORTS - installed Xcode, downloaded from apple dev center (copying Xcode.app from .dmg file to applications folder) - open Xcode and agree to EULA agreement - go into Xcode's preferences/downloads and install command line tools - installed XQuartz for X11 environment (I already had this installed) - download and install macports from macports.org using their easy Package (.pkg) installer INSTALLING FRESCOBALDI Use macports to install: - python27 - py27-pyqt4 - install frescobaldi after downloading from frescobaldi site (not using macports) Use macports to install: - poppler (with +qt4 variant (also added +quartz variant, but that's probably not necessary)) - install poppler-qt from their site as described on frescobaldi site (not using macports) (I had to add "sudo" before "python setup.py install" to get it to work, though this wasn't mentioned in their installation guide) MIDI FUNCTIONALITY ATTEMPTS: Use macports to install - portmidi (installed fine in the terminal/macports, but frescobaldi still did not recognize portmidi) Use macports to install - py27-game (with +portmidi variant) (this includes portmidi for python, according to the frescobaldi site, installed fine, but again, frescobaldi still not recognizing portmidi) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: frescobaldi on mac
On Jan 12, 2013, at 2:53 PM, Jim Tisdall wrote: > In trying to compile frescobaldi on my mac pro osx10.7.5, I have the > program running but I've run into the following problem with trying > to get the python-poppler-qt4-0.16.3 extension to work: Hi Jim, I got as far as trying to installing the poppler pdf part about a month or so ago and ran out of steam. (I am not very fluent with the command line.) So I've just been using an older 2.0.4 version that I installed with this pre-packaged mac installer that Rodolfo Zitellini made: https://groups.google.com/d/msg/frescobaldi/Of51097BeqA/7F3geR2gPd4J Here's a link to the installer file: http://www.xhero.org/frescobaldi.zip It would be great to have an easy installer like this for the more recent 2.0.8 version (and future versions). Frescobaldi really takes working with LilyPond to another level compared with the default LilyPond.app for mac. I've found the text highlighting, point-and-click functionality, and having everything in one window to be really helpful. Good luck with it! -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Getting the name of the context a scheme function was called from
On Jan 12, 2013, at 10:42 AM, Marc Hohl wrote: > Would the use of tags be helpful here? > > http://lilypond.org/doc/v2.16/Documentation/notation/different-editions-from-one-source#using-tags Thanks Marc! Tags are just the tool for the job, and I wasn't aware of them before. I can tag the overridden bits of music for use with my custom staff, and tag non-overridden bits for use with the standard staff. Once again, it is hard to come up with something that LilyPond can't handle! Thanks, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Getting the name of the context a scheme function was called from
On Jan 12, 2013, at 2:47 AM, David Kastrup wrote:
> Uh, if you have a _custom_ staff context for which you want particular
> overrides, you just do
>
> \layout {
> \context {
>\Staff
>\name "MyStaff"
>\alias "Staff"
>\override ...
>\override ...
> }
> }
>
> at the bottom, and then in the music you use
>
> \new MyStaff { ... }
>
> and, of course, the overrides will be in every staff of that type, and
> not anywhere else.
Right, I have been using this custom staff approach and it works great for
"global" overrides that should _always_ happen on the custom staff. (I omitted
those overrides in my previous tiny example to make it tiny, with a comment
saying so, but in the process I may not have communicated clearly enough that I
was trying to achieve something else.)
My question now is about when say, a particular chord needs a manual
("non-global") override added _within_ the music (using \once), for it to look
right on the custom staff (as a by-product of the global overrides of the
custom staff). However, these same manual one-time overrides are not needed on
a standard staff, and look wrong there. (For example, needing to move note
heads to a different side of the stem to avoid collisions with other note heads
on the custom staff, but not on the standard staff.)
So once you've added these one-time overrides within the music you can only use
the music for the custom staff and not a standard staff. (Unless... there's
some way for a function that's called to do these one-time overrides to know
whether its being called from the custom staff context or a standard staff
context.)
So this is a _really_ marginal use-case that fortunately has an easy
workaround: I can just copy and paste the music into a 2nd variable and add
the one-time overrides to the new copy, then use the two copies of the music
with their respective staves. And/or write a "global" override function for
the custom staff that's smart enough so that I do not need to do the one-time
tweaks in the music at all. (Which is what I'm working on now.)
Cheers,
-Paul
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Getting the name of the context a scheme function was called from
On Jan 11, 2013, at 12:40 PM, David Kastrup wrote:
>> But to do that I need the "translator object" (which seems to be an
>> engraver?), and I'm not sure how to do that. Maybe there is a way to
>> get to it from the grob?
>
> A grob can be announced in multiple contexts, so no.
Ok, thanks.
>> displaceHeads =
>> #(define-music-function (parser location offsets) (list?)
>> "
>> Moves the NoteHeads, using (shift offsets)
>> "
>> #{
>> \once \override NoteColumn #'before-line-breaking = #(shift offsets)
>> #})
>
> At the time this is called, there are no live contexts. You might want
> to try fiddling with the context grob properties (huh, do we even have
> functions for that?) directly in a function called via \applyContext.
Ok, good to know about \applyContext. After looking into it a bit, I'm not
sure whether it will do what I need it to do, but that's fine since this is not
essential. It's just something that would be nice to have. I can always just
copy and paste the music and then add or remove the overrides that go in it
(one version of the music for each of the two staff types).
(I also should be able to write some code to automatically do the overrides in
my custom staff context instead of having to enter them manually. That would
be the ideal solution, and a better place to put the effort.)
Thanks,
-Paul
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Getting the name of the context a scheme function was called from
Hello everyone,
Here's an obscure scheme function question: how do you get the name of the
context that a scheme function was called from, from within that function?
Assuming this is possible...
I would like to write a scheme function that will do something (override
horizontal placement of noteheads) when it is called from a given custom staff
context, but do nothing when it is called from a standard staff context. Then
I could put the music, with calls to the function, into a variable, and use
that variable in both custom and standard staves. When called from the custom
staff the function would make changes, but when called from the standard staff
it would do nothing.
I've tried to do this by using ly:context-name:
Function: ly:context-name context
Return the name of context, i.e., for \context Voice = "one" … return the
symbol Voice.
and maybe getting the "context" argument by using ly:translator-context:
Function: ly:translator-context trans
Return the context of the translator object trans.
http://www.lilypond.org/doc/v2.16/Documentation/internals/scheme-functions
But to do that I need the "translator object" (which seems to be an engraver?),
and I'm not sure how to do that. Maybe there is a way to get to it from the
grob?
Also, it seems like I might be able to get the name of the voice context since
the note head engraver lives in the voice context, but what I really want is
the staff context. So that might be another hurdle.
See example below for where I'm stuck.
(It now occurs to me that it would probably be better to put the context-lookup
logic in displaceHeads rather than in #(define ((shift offsets)...)
Thanks for any advice or pointers,
-Paul
BEGIN TINY EXAMPLE
\version "2.16.1"
\layout {
\context {
\Staff
\name TwinNoteStaff
\alias Staff
% omitting customizations that go here (\consists, \override etc.)
}
\context { \Score \accepts TwinNoteStaff }
\context { \ChoirStaff \accepts TwinNoteStaff }
\context { \GrandStaff \accepts TwinNoteStaff }
\context { \PianoStaff \accepts TwinNoteStaff }
\context { \StaffGroup \accepts TwinNoteStaff }
}
#(define ((shift offsets) grob)
"Defines how NoteHeads should be moved according to the given list of offsets."
(let* (
(trans "how to get a Translator? from the grob?")
(context (ly:translator-context trans))
(name (ly:context-name context))
;; (name "TwinNoteStaff")
)
(display name)
(newline)
(if (equal? name "TwinNoteStaff")
(display "Yes, TwinNote staff")
(display "No, standard staff")
)
(newline)
))
% shift note heads
displaceHeads =
#(define-music-function (parser location offsets) (list?)
"
Moves the NoteHeads, using (shift offsets)
"
#{
\once \override NoteColumn #'before-line-breaking = #(shift offsets)
#})
music = \relative c' { \displaceHeads #'(-1 0) }
<<
\new Staff {
\music
}
\new TwinNoteStaff {
\music
}
>>
END TINY EXAMPLE
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tweaking notehead direction in chords
Hi Harm, On Jan 6, 2013, at 7:38 AM, Thomas Morley wrote: > The problem is that \displaceHeads uses 'before-line-breaking. > In case of beamed stems it tries to call the 'stencil before it is calculated. > > Changing the property to 'after-line-breaking seems to solve this issue. > > Drawback: The spacing of the NoteColumns is affected. > See the example with "my crazy NoteHead" > Will think about it. Thanks for the reminder about 'before-line-breaking. For my own use I think I will just revise the code so it checks the stem 'thickness property rather than the stencil width. That will work for me since I don't plan on overriding the stem stencil. But I'm not sure what the best approach for the snippet would be. Maybe there's a way to try checking the stencil width, and if that fails, fall back to the 'thickness property. (I realize this is how it currently should work, by using "ly:stencil?" but since that doesn't get around this error...?) Maybe "catch" would help? https://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Catch.html#Catch Cheers, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tweaking notehead direction in chords
On Jan 4, 2013, at 11:10 PM, Paul Morris wrote: > Without looking into it any further, my best guess is that calculating the > stem width does not work because the stem grob has not been generated before > the ] is reached, or something like that? By commenting things out, I identified the following as the first line that causes the error: (stem-stil (ly:grob-property stem 'stencil)) So it seems like the stem grob's stencil may not have been created yet, at the point where we are trying to get its width? I tried the following, which moves the attempt to access the stencil behind the "ly:stencil?" check, but it returned the same error anyway. (stem (ly:grob-object grob 'stem)) (stem-thick (ly:grob-property stem 'thickness 1.3)) ;; (stem-stil (ly:grob-property stem 'stencil)) (stem-x-width (if (ly:stencil? (ly:grob-property stem 'stencil)) (interval-length (ly:stencil-extent (ly:grob-property stem 'stencil) X)) ;; if no stem-stencil use 'thickness-property (/ stem-thick 10))) (stem-dir (ly:grob-property stem 'direction)) ;; Calculate a value to compensate the stem-extension (stem-x-corr (map (lambda (q) (+ 1 1) ) nh-duration-log))) Cheers, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tweaking notehead direction in chords
On Dec 27, 2012, at 9:38 AM, Thomas Morley wrote: > Hi Paul, > > approved as > http://lsr.dsi.unimi.it/LSR/Item?id=861 > > I added some small changes. > Could take them back, if you want. > > Many thanks for contributing, > Harm Hi Harm, That's great, thanks! Unfortunately, I ran into a problem when using this snippet with beams set with square brackets. Here's a tiny example (see attached file for full tiny example): 16[ \displaceHeads #'(-1 0) ] This leads to the following error (without the square brackets there is no error): __ Parsing... Interpreting music... Preprocessing graphical objects.../Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/output-lib.scm:133:10: In procedure - in expression (- (ly:stem::pure-calc-stem-end-position grob 0 ...) beg): /Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/output-lib.scm:133:10: Wrong type: calculation-in-progress Exited with return code 1. ___ Without looking into it any further, my best guess is that calculating the stem width does not work because the stem grob has not been generated before the ] is reached, or something like that? Any thoughts on how to best work around this? Thanks, -Paul shift-note-heads-problem.ly Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tweaking notehead direction in chords
Hi Harm, On Dec 26, 2012, at 7:13 AM, Thomas Morley wrote: > was a matter of $-signs again. > I uploaded a 2.14.2-version with some small changes. Ah, I should have known. :-) Thanks for making the needed changes. > Ofcourse the description and the prefatory comments in the code should > be altered. > May I ask you to change them? Could do it myself, but a native speaker > would be faster and the wording would be surely much better. Glad to do it. I've edited the description and comments and uploaded the revisions to the LSR. http://lsr.dsi.unimi.it/LSR/Item?u=1&id=861 I changed "tweaked" to "altered" to avoid any confusion with LilyPond's specific use of "\tweak". I also included an instance of using the "setOtherScriptParent" function in the LSR example (and not just the commented-out development examples). Any further revisions are welcome, but I think we can call this one done (for now). :-) Thanks for all your help! -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tweaking notehead direction in chords
On Dec 23, 2012, at 1:33 PM, Thomas Morley wrote: > that's all true and _much_ better explained than I could have done it. > I agree to all of it. Hi Harm, ok, thanks. > Thanks. > And I promise to approve it asap. I tried to upload the most recent code to the LSR, with some edits to the examples: http://lsr.dsi.unimi.it/LSR/Item?u=1&id=861 But it did not work since it is throwing errors in 2.14.2. I now have 2.14.2 running via Frescobaldi and it is returning things like the following: ___ Parsing... :2:63: error: GUILE signaled an error for the expression beginning here \once \override NoteColumn #(quote before-line-breaking) = # (shift offsets) Interpreting music... warning: type check for `before-line-breaking' failed; value `#' must be of type `boolean' Preprocessing graphical objects...Unbound variable: offsets Unbound variable: offsets ERROR: Unbound variable: val Exited with return code 1. The code I tried to upload to the LSR is attached. Should it work in 2.14.2 or will it need to wait for the LSR to run 2.16? I can try to get it working for 2.14.2 if that should work. Thanks, -Paul offset-note-heads-05.ly Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tweaking notehead direction in chords
On Dec 20, 2012, at 7:51 PM, Thomas Morley wrote: > I think there is no way to align moved noteheads left and right from > the stem _and_ to keep a correct 'stem-attachment in x-axis-direction > in all thinkable cases. > The y-value of 'stem-attachment has to be modified in several situations > anyway. Hi Harm, I had some more time to look at this, and I think I may be catching up with you now. :-) I now see that using (/ stem-x-width 2) nicely handles all four possibilities correctly in terms of positioning note heads relative to the stem on the X-axis (upwards or downwards stem, moving a note head to the default or to the opposite-of-default side of the stem). So this is all that is needed to correctly align notes vertically on either side of the stem. But I also see how this means the stem may not attach properly in some cases. The main (or only?) instance of this seems to be when a note head that is at the end of a stem has been offset to the non-default side of the stem. It overlaps only half of the stem width, and this does not look right. (I can't think of another case where this would be a problem.) It might be possible to handle this case automatically in the code (at least for the X-axis of 'stem-attachment), but I'm not sure it would be worth it since it can be tweaked manually using your adjustStem function. (But just for example...) if note head is the lowest one on an upwards stem or if note head is the highest one on a downwards stem and it has been moved to the non-default side of the stem then adjust the 'stem-attachment accordingly Also, it seems that changing the 'stem-attachment property moves the stem and not the note. This preserves the vertical alignment of the notes which is a good thing, but it basically reverses the usual pattern of how note heads overlap the stem. (Notes on the non-default side of the stem will now overlap the full width of the stem, and notes on the default side will now overlap half the width of the stem -- the opposite of the usual pattern.) There is no way around this, since offsetting a note at the end of the stem means you either get the stem attachment right, or keep the usual pattern of how note heads overlap the stem. And clearly it's better to get the stem attachment right. So I don't have any further suggestions for the code. I will try to find some time to come up with a good concise example for the LSR, and put the default notes on a separate staff above the offset notes. Best, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Macro function for changing the size of a single staff
On Dec 22, 2012, at 6:52 AM, Thomas Morley wrote: > nice function! Thanks! > But making it work with "2.14.2" is not a matter of correct usage of "$" > "2.14.2" doesn't accept music-functions in \with or \layout. Ok, I thought something like that might be the case, so thanks for letting me know. > In this case I'd wait for the LSR-upgrade. Will do. Best, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Macro function for changing the size of a single staff
On Dec 22, 2012, at 12:49 AM, Jeffrey Trevino wrote: > Doesn't set-global-staff-size do this already? > > http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Setting-the-staff-size Yes, but the difference is that set-global-staff-size sets the size _globally_ for all staves in a file (or book block), and this macro function only changes the size of an individual staff. You would use it if you wanted different size staves within the same score, for example. But you're right, in many cases set-global-staff-size is what you would use. Cheers, -Paul___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Macro function for changing the size of a single staff
Hi all, To resize a single staff you have to change three different settings,
using the same value for each[1]. This felt redundant and complex, so I wrote
a little macro function that sets all three at once, simplifying the process.
Maybe others will find it useful too.
See the snippet below for how to use it. I added it to the LSR[2], but it
needs LilyPond 2.16.1 -- unless I can get it to work with 2.14.2 by figuring
out how to use the "$" with \set Staff.fontSize = #new-size
Cheers,
-Paul
[1] http://www.lilypond.org/doc/v2.16/Documentation/learning/size-of-objects
and
http://www.lilypond.org/doc/v2.16/Documentation/learning/length-and-thickness-of-objects
[2] http://lsr.dsi.unimi.it/LSR/Item?u=1&id=862
BEGIN SNIPPET
\version "2.16.1"
staffSize = #(define-music-function (parser location new-size) (number?)
#{
\set Staff.fontSize = #new-size
\override Staff.StaffSymbol #'staff-space = #(magstep new-size)
\override Staff.StaffSymbol #'thickness = #(magstep new-size)
#})
theMusic = \relative c' {
a'8 a a a a \ff a a a
}
\score {
<<
\new Staff
{ \theMusic }
% the usual way to change a staff's size
\new Staff \with {
fontSize = #-3
\override StaffSymbol #'staff-space = #(magstep -3)
\override StaffSymbol #'thickness = #(magstep -3)
}
{ \theMusic }
% simplified with staffSize function
\new Staff \with {
\staffSize #-3
}
{ \theMusic }
>>
}
END SNIPPET
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tweaking notehead direction in chords
On Dec 20, 2012, at 7:51 PM, Thomas Morley wrote: > We should provide a shorter example than my last. > I used the custom-note-heads only for advanced testings. > I'd prefer a double-line, though, above the original, below the tweaked > version. Sounds good to me. I can work on that. > (2) LilyPond > So far so good and LilyPond _does_ it quite good. > Though, the amount of covering the stem-width isn't the same for left > and right printed noteheads. > For up-stems a left-printed notehead covers the whole stem-width but a > right-printed one only about the half (or two-thirds?). > Not sure about the reasoning. Looking at your example with the colored note heads, it seems like (1) note heads on the default side of the stem will overlap the whole stem width, and (2) any notes on the opposite, non-default side will overlap about half of the stem width. So: Upwards stem Notes on the left (default): overlap full stem width Notes on the right: overlap about half the stem width Downwards stem Notes on the right (default): overlap full stem width Notes on the left: overlap about half the stem width It seems that we could achieve the same result for manually shifted note heads. We could just adjust how far to shift them based on whether the note was being moved in the default direction or non-default direction (left or right) for the given stem direction (up or down). Is that right? > I think there is no way to align moved noteheads left and right from > the stem _and_ to keep a correct 'stem-attachment in x-axis-direction > in all thinkable cases. If what I wrote above is correct, then it seems that we could achieve both of these, at least in most cases, as a default. But maybe I'm missing something about why we can't have both, at least not in all cases? Sorry if you are already a few steps ahead of me here. I don't have time at the moment to try to put any of this into code, but maybe it's better to see what you think first anyway? > (3) Solution > Apart from correcting the above mentioned wrong expression, I changed > \adjustStem. > It now requiers a pair as argument. > The car of it adds multiples of the stem-width to the x-default. > The cdr multiplies with the y-default (as before). This seems like a good change in any case, allowing for more flexibility. > Would be very nice if you could have a look again. :) Sure thing. Thanks again, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dashed staff lines
My apologies for my email program screwing up the image attachment on that last message. I tried to attach an svg image with unexpected results. Here's a png version instead.-Paul___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: zigzag staffline
On Dec 19, 2012, at 8:14 PM, Thomas Morley wrote: > the code below constructs a new StaffSymbol with zigzag-lines at specified > positions. Very nice! I agree with Marc that it would be good to add it to the LSR. I will see if I can adapt it to make a "dashed staff line" version... (Does anyone know what kind of music notation this is that uses a zig-zag line? I haven't seen it before.) Cheers, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: zigzag staffline
On Dec 18, 2012, at 10:25 AM, David Kastrup wrote: > Dashed lines can be done using something like > > \markup \pattern #60 #X #1 \draw-line #'(0.5 . 0) Thanks! This is good to know. -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tweaking notehead direction in chords
On Dec 17, 2012, at 6:13 PM, Thomas Morley wrote: > I had a closer look at this snippet. > Attached you'll find my version of it. Hi Harm, I had a chance to take a closer look at your improved version of this snippet. Very nice work, thank you! The changes and additions all make sense to me. It will be much harder to break it now. It's nice having the stemAdjust function to make that simpler, and I liked your crazy NoteHeads. :-) I started work on editing it for the LSR (see attachment). Having the comments explaining the steps is really nice. I thought it would probably be good to comment out the test section and the music examples that go with it to keep things focused and simple for people browsing the LSR. I do like keeping these tests in there since they will help people understand the code and the problems that it solves. What do you think? Also, I noticed a small fine-tuning issue. In the four note chords in the last measure of the attached LSR example, the two offset E flat notes are not exactly aligned with the A and C notes above them in either chord, if you zoom in. In the previous version they were fully aligned. I haven't had a chance to try and fix this yet. Any thoughts on what needs to be adjusted there? > BTW, 'stem-begin-position doesn't exist in 2.14.2, but overriding > 'stem-attachment will work, if it is placed correctly. Huh, that's odd, as overriding 'stem-begin-position is working in the current LSR version (2.14.2 - http://lsr.dsi.unimi.it/LSR/Item?id=861). Maybe you meant it doesn't exist in 2.16? Good to know that stem-attachment will work for chords. I'll just need to figure out the proper placement. Regards and thanks again, -Paul offset-note-heads-04.ly Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: zigzag staffline
Hi Gagi, On Dec 18, 2012, at 5:35 AM, Gagi Petrovic wrote: > Dear Ponders, i'm working on a composition where i'm in need of a custom > 3-lined-staff with a zigzagged (like the glissando style, see attachment) > middle line. Is it possible to make a small adjustement to the code below, or > should i start doing some serious tweaking? Any pointers are well > appreciated. Thank you very much in advance! I don't have any suggestions beyond the colored line snippet that David already mentioned (see below). I once got this advice about dashed lines: "It may be possible to get dashed lines by writing a stencil in Scheme and overriding it in. But you'd have to locate which stencil draws the lines, study the C++ code, and write Scheme to do the same thing with some extra options." I would be curious to see how you achieve this, so please share your solution if you create one. Cheers, -Paul On Dec 18, 2012, at 2:48 AM, Werner LEMBERG wrote: > Gagi, > >> On 15 December 2012 10:39, Gagi Petrovic wrote: >>> >>> Dear Ponders, i'm working on a composition where i'm in need of a custom >>> 3-lined-staff with a zigzagged (like the glissando style, see attachment) >>> middle line. Is it possible to make a small adjustement to the code below, >>> or should i start doing some serious tweaking? > > So the middle line of the 3-line staff will actually be replaced with > a zigzag line? I'm not aware of doing something like that with a > simple override. I would imagine that you'd have to build up a new > StaffSymbol from the ground up. There's a snippet in the LSR which > colors individual lines, and that might be something to look at and > adapt to your needs. Unfortunately, I don't have time right now to > work on it. > > http://lsr.dsi.unimi.it/LSR/Item?id=700 > > HTH, > David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: A question of list etiquette and images.
Hi David and Helge, You both make good points (copied below) about the drawbacks of using links to images instead of attaching images to an email. I actually don't mind inline images, but was just suggesting links as another possibility. Cheers, -Paul On Dec 18, 2012, at 3:00 AM, Helge Kruse wrote: > When you upload the images somewhere you will lose the relation between mail > text and images when the poster thinks it's not required as the question has > been answered. I already found some good ideas from the mailing list archive. > The archive will be less useful without the inline (or attached) images. On Dec 18, 2012, at 3:21 AM, David Kastrup wrote: > Huh. For me (small) inline images are quite fine in GNUS. External > downloads, in contrast, would be quite more of a nuisance. Perhaps > using both? Though to be honest, having to use an http download link > over an inline image in reasonably standard format does not strike me > like much of a security advantage. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: A question of list etiquette and images. (Was Re: Short stems)
On Dec 18, 2012, at 1:03 AM, Arle Lommel wrote: > Given that, does anyone have any suggestions to how behave nicely for list > members like Harm when images are involved? Hi Arle, Hmmm... one possible solution is to post your images in flickr, dropbox, or your online storage provider of choice, and then include links to them in your messages. (I saw where Thunderbird now has this feature where it will upload a file to online storage and insert the link into your message. I'm not suggesting you change your email app -- it's just what made me think of this.) Just a thought, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: please direct to removing page numbers
On Dec 17, 2012, at 9:12 PM, i...@soundand.com wrote: > I'm sure it's possible to remove page numbers from a score but I can't find > it in the snippets or manual > > I've been assuming that it's something like \remove page number in \context > in \Score but I can't find it > > Thanks > > jay > Hi Jay, http://www.lilypond.org/doc/v2.16/Documentation/notation/other-_005cpaper-variables#index-page-numbers_002c-suppress I find things like this by going to the index page: http://www.lilypond.org/doc/v2.16/Documentation/notation/lilypond-index and searching the index page, in this case for "page number". Cheers, -Paul___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tweaking notehead direction in chords
On Dec 17, 2012, at 6:13 PM, Thomas Morley wrote: > 2012/12/15 Paul Morris : > [...] >> Looks like the most recent version of the snippet is now appearing in the >> LSR: >> http://lsr.dsi.unimi.it/LSR/Item?u=1&id=861 > > Hi Paul, > > I had a closer look at this snippet. > Attached you'll find my version of it. Hi Harm, Wow! I gave this a quick glance and it looks great -- much more robust, and harder to break. When I get a chance I'll look at it more closely and give a longer reply. Regards, and many thanks! -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Moving accidentals above or below notes
Hi Dominique,
Apparently I cannot resist a challenge. The following is a scheme function
that will move accidentals above or below notes, depending on the stem
direction. You can adjust the numbers following "ly:grob-translate-axis!" to
fine-tune the positioning.
If you want it to automatically move all accidentals, you can put the override
in the \with block of a staff, like I've shown below.
HTH,
-Paul
\version "2.16"
accidentalShifter =
#(lambda (grob)
(let* (
(notehead (ly:grob-parent grob 1))
(notecol (ly:grob-parent notehead 0))
(stm (ly:grob-object notecol 'stem))
(stmdir (ly:grob-property stm 'direction))
)
;; just for testing
;; (display stmdir) (newline)
(ly:grob-translate-axis! grob 0.2 X)
(if (= stmdir -1)
(ly:grob-translate-axis! grob 2.5 Y)
(ly:grob-translate-axis! grob -2.5 Y)
)
))
accShift = {
\once \override Score.Accidental #'before-line-breaking = \accidentalShifter
}
\relative c'' {
a16 b \accShift cis \accShift bes
g a \accShift b \accShift c
}
\relative c'' {
a b c b
g a b c
}
\new Staff \with {
\override Accidental #'before-line-breaking = \accidentalShifter
} {
\relative c'' {
a16 b cis bes
g a b c
}
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Moving accidentals above or below notes
On Dec 17, 2012, at 2:58 PM, Dominique Faure wrote:
> Using the following code, I'd like to move accidentals above or below notes.
>
> --8<- - - - - - - - - -
> \version "2.16"
>
> accidentalBelow = {
> \once \override Score.Accidental #'extra-offset = #'(1.5 . -2.5)
> }
>
> accidentalAbove = {
> \once \override Score.Accidental #'extra-offset = #'(1.5 . 2.5)
> }
>
> \relative c'' {
> a16 b \accidentalAbove cis \accidentalAbove bes
> g a \accidentalBelow b \accidentalBelow c
> }
>
> \relative c'' {
> a b c b
> g a b c
> }
> --8<- - - - - - - - - -
>
> This almost works, but I was wondering how I could:
>
> 1) eliminate the extra horizontal space kept in front of notes where
> the accidental was originally drawn.
I think the following will work, use:
\override Score.Accidental #'before-line-breaking =
which performs the override before the spacing is calculated. You would set it
to your own scheme function that changes the position of the accidental grob.
In your function you could use the internal scheme function
ly:grob-translate-axis! (once for the X axis and once for Y axis) to do the
repositioning.
> 2) have it working without the need to know in advance how the stems
> are oriented.
In your scheme function you should be able to access the stem grob from the
accidental (via the note head grob) and check the stem direction property of
the stem grob. This will probably involve ly:grob-parent or something like it.
Then you can adjust the accidental above or below based on the stem direction
property.
These snippets may be helpful:
http://lsr.dsi.unimi.it/LSR/Item?id=621
http://lsr.dsi.unimi.it/LSR/Item?id=622
Searching for "grob" may find other relevant examples:
http://lsr.dsi.unimi.it/LSR/Search?q=grob
I don't have the time at the moment to offer more, but that should get you
started.
HTH,
-Paul
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tweaking notehead direction in chords
On Dec 14, 2012, at 4:07 AM, David Kastrup wrote: > David Nalesnik writes: > >> On Thu, Dec 13, 2012 at 9:30 PM, David Nalesnik >> wrote: >>> >>> I notice that you haven't added the $ sign before offsets in the LSR >>> snippet as Harm and I advised. Try that and I see no reason the >>> snippet shouldn't work.. >>> >> >> Ah, no, I see. You did add it, but not in the right place. > > Good thing it is no longer needed in current versions. Indeed, such simplifications make things easier, thanks! Looks like the most recent version of the snippet is now appearing in the LSR: http://lsr.dsi.unimi.it/LSR/Item?u=1&id=861 Anyone know why there is so much unnecessary white-space? -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond in Mac OS X Terminal
On Dec 12, 2012, at 11:03 AM, Paul Morris wrote: > I tried to follow those instructions recently (to try the png output) but was > not able to get it to run. For future command-line beginners like myself, I figured out the problem: I needed to change the shell I was using from tcsh to bash. Bash is now the default shell for OSX, but at one point it was tcsh (10.2 Jaguar or earlier). If you upgrade from those earlier tcsh versions, it does not automatically change the default shell to bash, but keeps using tcsh unless you manually change it. More details and how to change the shell: http://macdevcenter.com/pub/a/mac/2004/02/24/bash.html -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tweaking notehead direction in chords
Hi David,
On Dec 13, 2012, at 10:36 PM, David Nalesnik wrote:
> Hi again,
>
> On Thu, Dec 13, 2012 at 9:30 PM, David Nalesnik
> wrote:
>> Hi Paul,
>>
>> Somehow your response has gotten associated with the wrong thread.
>>
>> On Thu, Dec 13, 2012 at 9:12 PM, Paul Morris wrote:
>>
>>> I came up with the following using "inf?" to check for an infinite value
>>> and use 0 if so. It works on my machine. Blank > screen after uploading
>>> to the LSR again, but maybe it is just taking time to update? So I left it
>>> up this time.
>>
>>
>> I notice that you haven't added the $ sign before offsets in the LSR
>> snippet as Harm and I advised. Try that and I see no reason the
>> snippet shouldn't work..
>>
>
> Ah, no, I see. You did add it, but not in the right place.
Thanks for catching that. I was sure I had added it!
> Here's how
> the music function should look:
>
> displaceHeads =
> #(define-music-function (parser location offsets) (list?)
> #{
> \once \override NoteColumn #'before-line-breaking = #(shift $offsets)
> #})
Yep, I've fixed it now. Just got in too much of a hurry I guess.
And we're back on the right thread.
Cheers,
-Paul
On Dec 13, 2012, at 10:12 PM, Paul Morris wrote:
> On Dec 13, 2012, at 6:50 AM, Thomas Morley
> wrote:
>
>> 2012/12/13 Paul Morris :
>> [...]
>>> I found a good way to break it. If you try it with whole notes the stem's
>>> X-extent is (+inf.0 . -inf.0) and you get this error: "programming error:
>>> Infinity or NaN encountered"
>>
>> Likely, a check for
>> grob::is-live?
>> should be helpful.
>
> Thanks, I gave that a try tonight, but
> grob:is-live?
> returned #t for the stem grob for whole notes. It appears their stem is live
> but with a width of negative infinity.
>
>
>>> So I tried to work around this with the code below, but when I uploaded it
>>> to the LSR something went wrong, no error messages or anything but the
>>> preview page was just blank.[1] I put the previous version back but it was
>>> still blank, so I must have broken something.
>>>
>>> [1] http://lsr.dsi.unimi.it/LSR/Item?u=1&id=861
>>
>> Today I can't see any problems. Sometimes the LSR seems to need a
>> little more time.
>
> I came up with the following using "inf?" to check for an infinite value and
> use 0 if so. It works on my machine. Blank screen after uploading to the
> LSR again, but maybe it is just taking time to update? So I left it up this
> time.
>
> http://lsr.dsi.unimi.it/LSR/Item?u=1&id=862
>
> Regards,
> -Paul
>
>
> #(define ((shift offsets) grob)
> (let* ((note-heads (ly:grob-array->list (ly:grob-object grob 'note-heads)))
> (stem (ly:grob-object grob 'stem))
> (stem-ext (ly:grob-property stem 'X-extent))
> (half-stem-ext (if (inf? (cdr stem-ext)) 0 (cdr stem-ext
> (display stem-ext) (newline)
> (for-each
>(lambda (p q)
> (let ((head-ext (interval-length (ly:grob-property p 'X-extent
>(ly:grob-translate-axis! p (* q (- head-ext half-stem-ext)) X)))
>note-heads offsets)))
>
>
> displaceHeads =
> #(define-music-function (parser location offsets) (list?)
> #{
> \once \override NoteColumn #'before-line-breaking = #(shift offsets)
> #}
> )
>
> EXAMPLE
>
> theMusic = \relative c' {
> e4
>
> \displaceHeads #'(1)
> \once \override Staff.NoteHead #'stem-attachment = #'(1.09 . -0.34)
> e
>
> d'
>
> \displaceHeads #'(-1)
> \once \override Staff.NoteHead #'stem-attachment = #'(1.11 . -0.34)
> d
>
>
>
> \displaceHeads #'(0 1)
>
>
>
> \displaceHeads #'(-1 0)
>
>
>
> \displaceHeads #'(1 0 0)
> \once \override Staff.Stem #'stem-begin-position = #-3.3
>
>
>
>
> \displaceHeads #'(-1 -1 0)
>
>
>
> \displaceHeads #'(0 -1 0 0)
>
>
>
> \displaceHeads #'(1 0 0 0)
> \once \override Staff.Stem #'stem-begin-position = #-4.3
>
> }
>
> \new Staff {
> \theMusic
> }
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Forced double accidental
On Dec 13, 2012, at 6:50 AM, Thomas Morley
wrote:
> 2012/12/13 Paul Morris :
> [...]
>> I found a good way to break it. If you try it with whole notes the stem's
>> X-extent is (+inf.0 . -inf.0) and you get this error: "programming error:
>> Infinity or NaN encountered"
>
> Likely, a check for
> grob::is-live?
> should be helpful.
Thanks, I gave that a try tonight, but
grob:is-live?
returned #t for the stem grob for whole notes. It appears their stem is live
but with a width of negative infinity.
>> So I tried to work around this with the code below, but when I uploaded it
>> to the LSR something went wrong, no error messages or anything but the
>> preview page was just blank.[1] I put the previous version back but it was
>> still blank, so I must have broken something.
>>
>> [1] http://lsr.dsi.unimi.it/LSR/Item?u=1&id=861
>
> Today I can't see any problems. Sometimes the LSR seems to need a
> little more time.
I came up with the following using "inf?" to check for an infinite value and
use 0 if so. It works on my machine. Blank screen after uploading to the LSR
again, but maybe it is just taking time to update? So I left it up this time.
http://lsr.dsi.unimi.it/LSR/Item?u=1&id=862
Regards,
-Paul
#(define ((shift offsets) grob)
(let* ((note-heads (ly:grob-array->list (ly:grob-object grob 'note-heads)))
(stem (ly:grob-object grob 'stem))
(stem-ext (ly:grob-property stem 'X-extent))
(half-stem-ext (if (inf? (cdr stem-ext)) 0 (cdr stem-ext
(display stem-ext) (newline)
(for-each
(lambda (p q)
(let ((head-ext (interval-length (ly:grob-property p 'X-extent
(ly:grob-translate-axis! p (* q (- head-ext half-stem-ext)) X)))
note-heads offsets)))
displaceHeads =
#(define-music-function (parser location offsets) (list?)
#{
\once \override NoteColumn #'before-line-breaking = #(shift offsets)
#}
)
EXAMPLE
theMusic = \relative c' {
e4
\displaceHeads #'(1)
\once \override Staff.NoteHead #'stem-attachment = #'(1.09 . -0.34)
e
d'
\displaceHeads #'(-1)
\once \override Staff.NoteHead #'stem-attachment = #'(1.11 . -0.34)
d
\displaceHeads #'(0 1)
\displaceHeads #'(-1 0)
\displaceHeads #'(1 0 0)
\once \override Staff.Stem #'stem-begin-position = #-3.3
\displaceHeads #'(-1 -1 0)
\displaceHeads #'(0 -1 0 0)
\displaceHeads #'(1 0 0 0)
\once \override Staff.Stem #'stem-begin-position = #-4.3
}
\new Staff {
\theMusic
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tweaking notehead direction in chords
Hi Harm,
On Dec 12, 2012, at 9:03 PM, Thomas Morley
wrote:
> I've seen the updated version in the LSR already and tend to approve it as is.
> I doubt it could be possible to create an automatism for 'stem-attachment.
Ok, I went ahead and added examples of manual overrides for fixing stem
attachment problems. I used the stem-attachment property for single notes, but
I couldn't get it to work with chords, so I used the Stem's stem-begin-position
property instead.
> I tried to break the code, though.
I found a good way to break it. If you try it with whole notes the stem's
X-extent is (+inf.0 . -inf.0) and you get this error: "programming error:
Infinity or NaN encountered"
So I tried to work around this with the code below, but when I uploaded it to
the LSR something went wrong, no error messages or anything but the preview
page was just blank.[1] I put the previous version back but it was still
blank, so I must have broken something.
[1] http://lsr.dsi.unimi.it/LSR/Item?u=1&id=861
#(define ((shift offsets) grob)
(let* ((note-heads (ly:grob-array->list (ly:grob-object grob 'note-heads)))
(stem (ly:grob-object grob 'stem))
(stem-ext (ly:grob-property stem 'X-extent))
(half-stem-ext (if (= -inf.0 (cdr stem-ext)) 0 (cdr stem-ext
(for-each
(lambda (p q)
(let ((head-ext (interval-length (ly:grob-property p 'X-extent
(ly:grob-translate-axis! p (* q (- head-ext half-stem-ext)) X)))
note-heads offsets)))
displaceHeads =
#(define-music-function (parser location offsets) (list?)
#{
\once \override NoteColumn #'before-line-breaking = #(shift offsets)
#}
)
EXAMPLE
theMusic = \relative c' {
e4
\displaceHeads #'(1)
\once \override Staff.NoteHead #'stem-attachment = #'(1.09 . -0.34)
e
d'
\displaceHeads #'(-1)
\once \override Staff.NoteHead #'stem-attachment = #'(1.11 . -0.34)
d
\displaceHeads #'(0 1)
\displaceHeads #'(-1 0)
\displaceHeads #'(1 0 0)
\once \override Staff.Stem #'stem-begin-position = #-3.3
\displaceHeads #'(-1 -1 0)
4
\displaceHeads #'(0 -1 0 0) 4
4
\displaceHeads #'(1 0 0 0)
\once \override Staff.Stem #'stem-begin-position = #-4.3
4
}
\new Staff {
\theMusic
}
> And noticed that adding Fingering, StringNumber and Script will result
> in some strange not aligned output.
Huh, that's weird.
> Adding a stencil-tweak switches it to funny.
> ->png
>
> \version "2.16.1"
>
> % displaceHeads is omitted
>
> #(define rhomb-note
> (lambda (grob)
>(let* ((stencil (ly:note-head::print grob))
> (new-stil
> (grob-interpret-markup grob
> (markup #:rotate -45 #:box #:rotate 45 #:stencil stencil
>new-stil)))
>
> \relative c' {
> \displaceHeads #'(1 0 1 1)
> <\tweak #'stencil #rhomb-note b\1 cis-1\2 eis-2\3 gis-3\4 >4-.---|
> }
>
> It is much easier to break code than to create it.
So true!
Cheers,
-Paul
> I should do more review-work.
> :D
>
>
> -Harm
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tweaking notehead direction in chords
On Dec 12, 2012, at 7:24 PM, Thomas Morley
wrote:
> Hi Paul,
>
> I had a look at the LSR-snippet
> http://lsr.dsi.unimi.it/LSR/Item?id=861
>
> It's no problem to make it work with 2.14.2 just adding a $-sign
> before offsets in the music-function.
>
> But you will have noticed that after applying the function an
> additional override for 'stem-attachment is necessary in many cases.
> You should show how to do this. At least for some examples.
>
> In general I'd prefer to have a more automated way for offsetting the
> NoteHeads.
> The hardcoded value of 1.251178 will change for different NoteHeads and
> styles.
>
> I'll continue to think about it. ;)
>
>
> Regards,
> Harm
Hi Harm,
Thanks for taking a look at it and for the tip on using a $-sign for 2.14.2. I
was also thinking about the best way to correct the 'stem-attachment values.
It would be nice if that could be automatic.
I had emailed David Nalesnik to ask about posting his code to the LSR, and he
also had the concern about the hard-coded 1.251178. He sent me the following
which automatically calculates the offset amount based on the width of the
NoteHead, so I will update the snippet with this revision.
#(define ((shift offsets) grob)
(let* ((note-heads (ly:grob-array->list (ly:grob-object grob 'note-heads)))
(stem (ly:grob-object grob 'stem))
(stem-ext (ly:grob-property stem 'X-extent)))
(for-each
(lambda (p q)
(let ((head-ext (interval-length (ly:grob-property p 'X-extent
(ly:grob-translate-axis! p (* q (- head-ext (cdr stem-ext))) X)))
note-heads offsets)))
displaceHeads =
#(define-music-function (parser location offsets) (list?)
#{
\once \override NoteColumn #'before-line-breaking = #(shift offsets)
#}
)
Regards,
-Paul
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond in Mac OS X Terminal
On Dec 12, 2012, at 6:13 PM, Parham Fazelzadeh wrote: > I have tried searching for the answer online [...] > thank you so much. I feel stupid now, can't believe I missed that. I guess my > eyes were looking for the word "terminal". Also, I would have maybe expected > that information to also exist under the Manual link and not Downloads! Hmmm... it might be good to include the word "Terminal" (the default OS X command-line app) somewhere on the following page, since it is a term that many mac users would use when searching the web search for this information. http://www.lilypond.org/doc/v2.16/Documentation/web/macos-x Just a thought, -Paul___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond in Mac OS X Terminal
On Dec 12, 2012, at 10:32 AM, David Kastrup wrote: > Paul Morris writes: > >> On Dec 12, 2012, at 9:31 AM, Parham FH wrote: >> >>> I am curious if it is possible to run lilypond from the Mac OS X >>> (my case: 10.6.8) terminal >> >> Instructions are here: >> http://www.lilypond.org/doc/v2.16/Documentation/web/macos-x >> >> "Running on the command-line" > > Stupid question: why would one create executable shims to something like > DIR/LilyPond.app/Contents/Resources/bin/* in ~/bin and then add ~/bin to > one's PATH when one can just add > DIR/LilyPond.app/Contents/Resources/bin/ instead? Is DIR expected to > contain stuff that is bad for PATH? I have no idea, as I am pretty unfamiliar with using the command-line. I tried to follow those instructions recently (to try the png output) but was not able to get it to run. There did seem to be more steps than I would have thought. I'm hoping to get together with a friend of mine who is experienced with unix on the mac to help me get it working. -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond in Mac OS X Terminal
On Dec 12, 2012, at 9:31 AM, Parham FH wrote: > I am curious if it is possible to run lilypond from the Mac OS X > (my case: 10.6.8) terminal Instructions are here: http://www.lilypond.org/doc/v2.16/Documentation/web/macos-x "Running on the command-line" Cheers, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tweaking notehead direction in chords
Hi Arle,
Below is a revised version that lets you just enter 1 and -1 to indicate your
offsets. It then multiplies that by 1.251178 to get the precise offset amount.
You could enter a slightly larger amount (like 1.1) for whole notes and adjust
to taste. This basically lets you work in units of "one standard note head
width".
It also uses ly:grob-translate-axis! rather than setting the X-offset property
of the NoteHead grob. This accomplishes the same thing and avoids potential
problems where setting the X-offset for NoteHead grobs in chords may not work
in certain cases. Thanks to Harm/Thomas Morley for this tip.[1]
Cheers,
-Paul
[1] http://lists.gnu.org/archive/html/bug-lilypond/2012-12/msg00017.html
%% BEGIN SNIPPET
#(define ((shift offsets) grob)
(let ((note-heads (ly:grob-array->list (ly:grob-object grob 'note-heads
(for-each
(lambda (p q) (ly:grob-translate-axis! p (* q 1.251178) X))
note-heads offsets)))
displaceHeads =
#(define-music-function (parser location offsets) (list?)
#{
\once \override NoteColumn #'before-line-breaking = #(shift offsets)
#}
)
theMusic = {
\displaceHeads #'(0 0 1)
4
\displaceHeads #'(0 1 1)
\displaceHeads #'(0 1 1)
\displaceHeads #'(0 0 1)
< c' e' g'>
\displaceHeads #'(-1 -1 0)
< c'' e'' g''>
\displaceHeads #'(-1 -1 0)
< c''' e''' g'''>
\displaceHeads #'(0 0 1)
< c e g>
\displaceHeads #'(0 -1 0)
< c'' e'' g''>
\displaceHeads #'(0 0 -1)
< c'' e'' g''>
}
\new Staff {
\theMusic
}
On Dec 11, 2012, at 3:15 PM, Arle Lommel wrote:
> Brilliant, Paul. It isn't as easy as I'd hoped, but this works and is really
> minimally difficult for me to use. I used 1.25 and -1.25 as values and it is
> certainly close enough that I can't complain. This helps a *lot*.
>
> Best regards,
>
> Arle
>
> On 2012 Dec 11, at 21:05 , Paul Morris wrote:
>
>> Hi Arle,
>>
>> On Dec 11, 2012, at 2:37 PM, Arle Lommel wrote:
>>
>>> I've been looking for how to tweak the direction of noteheads within
>>> chords. I've got a few instances where Lilypond’s default isn't as clear as
>>> when I flip the direction of some of the noteheads. I've searched the
>>> repository and tried various tweaks using direction, but nothing seems to
>>> matter. I'm sure it's easy, but I can't find it.
>>>
>>> As a minimal example, consider this chord:
>>>
>>> 4
>>>
>>> The default is to have the e face left and the other heads face right, but
>>> in the piece I am reproducing the e faces right and the fis faces left.
>>> Doing it this way, as per the old engraver, increases the white space
>>> between the noteheads and increases legibility.
>>>
>>> Any guidance on how to achieve this? If there is an easy way, I would
>>> suggest adding it to the LSR as well, since this is a basic sort of tweak
>>> that others must surely need, but which doesn't seem to be easy to find.
>>
>> I had trouble figuring this out earlier this year and David Nalesnik helped
>> me out with the code below.[1] I have had it on my list to add it to the
>> LSR (while giving proper credit to David N.), as it is something that is not
>> easy to figure out on your own.
>>
>> (I think the fully accurate horizontal offsets should be 1.251178 and
>> -1.251178 rather than 1.3 or -1.3 for regular sized noteheads. They would
>> be a little larger for whole note note heads, but I don't know those values
>> at the moment.)
>>
>> Let me know if you have questions about how it works.
>>
>> HTH,
>> -Paul
>>
>>
>> #(define ((shift offsets) grob)
>> (let ((note-heads (ly:grob-array->list (ly:grob-object grob 'note-heads
>> (for-each
>> (lambda (p q) (set! (ly:grob-property p 'X-offset) q))
>> note-heads offsets)))
>>
>> displaceHeads =
>> #(define-music-function (parser location offsets) (list?)
>> #{
>> \once \override NoteColumn #'before-line-breaking = #(shift offsets)
>> #}
>> )
>>
>> theMusic = {
>> \displaceHeads #'(0 0 1.3)
>> 4
>>
>> \displaceHeads #'(0 1.3 1.3)
>>
>>
>> \displaceHeads #'(0 1.3 1.3)
>>
>>
>> \displaceHeads #'(0 0 1.3)
>> < c' e' g'>
>>
>> \displaceHeads #'(-1.3 -1.3 0)
>> < c'' e'' g''>
>>
>> \displaceHeads #'(-1.3 -1.3 0)
>> < c''' e''' g'''>
>>
>> \displaceHeads #'(0 0 1.3)
>> < c e g>
>>
>> \displaceHeads #'(0 -1.3 0)
>> < c'' e'' g''>
>>
>> \displaceHeads #'(0 0 -1.3)
>> < c'' e'' g''>
>> }
>>
>> \new Staff {
>> \theMusic
>> }
>>
>> [1] http://lists.gnu.org/archive/html/lilypond-user/2012-12/msg00186.html
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: NoteHead X-offset, conflict with ly:grob-relative-coordinate?
Hi David,
On Dec 8, 2012, at 2:03 PM, David Nalesnik wrote:
> Hi Paul,
>
> On Sat, Dec 8, 2012 at 12:00 PM, Paul Morris wrote:
>
> [snip]
>
>>>
>>> In this case you can make use of the 'stem-attachment property:
>>>
>>> \override NoteHead #'stem-attachment = #'(-0.8 . 0)
>>
>> Thanks David, I hadn't thought of using stem-attachment. It works for
>> single notes, but unfortunately does not seem to work for repositioning
>> individual noteheads within chords, which is what I want to do.
>>
>> For example, the snippet below changes stem-attachment to try to reposition
>> every other note (colored green as well just for purposes of illustration).
>> But the notes in a given chord all end up on the same side of the stem
>> rather than some on one side and some on the other.
>>
>> (I tried using the extra-offset property, and it worked, but it is applied
>> after the spacing has been set, and so could lead to collisions or bad
>> horizontal spacing. The X-offset property, on the other hand, is applied
>> before spacing is determined.)
>>
>> -Paul
>>
>> \version "2.16.1"
>>
>> note-counter = 1
>>
>> CustomNoteHeads =
>> #(lambda (grob)
>> (let*
>>(
>> (notecol (ly:grob-parent grob 0))
>> (rel-coord (ly:grob-relative-coordinate grob notecol 0))
>>)
>>(cond ((= 0 (modulo note-counter 2))
>> (set! (ly:grob-property grob 'stem-attachment) '(-0.8 . 0))
>> (set! (ly:grob-property grob 'color) green)
>>))
>>(set! note-counter (+ 1 note-counter))
>> ))
>>
>> \score {
>> \new Staff
>>\with {
>> \override NoteHead #'before-line-breaking = \CustomNoteHeads
>>}
>>{
>>
>>
>>}
>> \layout { }
>> }
>
> You posted this question awhile back
> (http://www.mail-archive.com/lilypond-user@gnu.org/msg70733.html). Is
> the solution I provided there no longer working for you?
Yes, your solution still works well (thanks again!).
I think by using tiny examples that focus on how X-offset is not working, it
hasn't been clear that I'm working on a more automated approach. I have
written some code to automatically apply certain offsets in certain cases[1],
so I do not have to manually apply them.
I use ly:grob-relative-coordinate to find out which side of the stem a note
head is on (in order to know which side I need to place the next note head),
but then for some reason that prevents changing the X-offset of the NoteHead
from having any effect.
My current approach is to override the NoteHead rather than the NoteColumn as
in your solution. I could override the NoteColumn instead (and this might even
be a better way to go...), but I will still need to determine which side of the
stem a note is on, so might still need to use ly:grob-relative-coordinate to do
that and would run into the same problem.
But maybe there is another way to tell which side of the stem a note head is
on, without using ly:grob-relative-coordinate?
Anyway, thanks again for your help.
-Paul
[1] Notes that are 3 semitones apart are placed on opposite sides of the stem.
This is for use with an alternative notation system (http://twinnote.org)
> I needed to change some values to deal with normal note-shapes, but
> this seems to work just fine:
>
> #(define ((shift offsets) grob)
> (let ((note-heads (ly:grob-array->list (ly:grob-object grob 'note-heads
>(for-each
> (lambda (p q) (set! (ly:grob-property p 'X-offset) q))
> note-heads offsets)))
>
> displaceHeads =
> #(define-music-function (parser location offsets) (list?)
> #{
>\once \override NoteColumn #'before-line-breaking = #(shift offsets)
> #}
> )
>
> theMusic = {
> \displaceHeads #'(0 0 1.3)
> 4
>
> \displaceHeads #'(0 1.3 1.3)
>
>
> \displaceHeads #'(0 1.3 1.3)
>
>
> \displaceHeads #'(0 0 1.3)
> < c' e' g'>
>
> \displaceHeads #'(-1.3 -1.3 0)
> < c'' e'' g''>
>
> \displaceHeads #'(-1.3 -1.3 0)
> < c''' e''' g'''>
>
> \displaceHeads #'(0 0 1.3)
> < c e g>
>
> \displaceHeads #'(0 -1.3 0)
> < c'' e'' g''>
>
> \displaceHeads #'(0 0 -1.3)
> < c'' e'' g''>
> }
>
> \new Staff {
> \theMusic
> }
>
> -David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
NoteHead X-offset, conflict with ly:grob-relative-coordinate?
Hello everyone, I'm writing a scheme function to override the usual horizontal
placement of noteheads relative to the stem (in certain instances). The only
thing that is not working is the final step of setting the X-offset property of
the NoteHead grob.
I tracked down the problem, as shown in the tiny example below. All the notes
should be moved to the right-hand side of the stem, but the "rel-coord"
variable that is set by "ly:grob-relative-coordinate" is preventing it from
working. After commenting out that variable it works fine. This seems very
odd. Maybe a bug? Any ideas on what's going on or how to get this to work?
-Paul
\version "2.16.1"
CustomNoteHeads =
#(lambda (grob)
(let*
(
(note-col (ly:grob-parent grob 0))
;; This...
(rel-coord (ly:grob-relative-coordinate grob notecol 0))
)
;; ...mysteriously prevents this from working.
(set! (ly:grob-property grob 'X-offset) 1.251178 )
)
)
\score {
\new Staff
\with {
\override NoteHead #'before-line-breaking = \CustomNoteHeads
}
{ c' d' e' f' }
\layout { }
}
PS. Here's what the internals reference says about this function:
Function: ly:grob-relative-coordinate grob refp axis
Get the coordinate in axis direction of grob relative to the grob refp.
PPS. I tried it in LilyPond 2.17.8-1 but I got this error: Unbound variable:
notecol
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Custom key signature stencils, differentiating major and minor keys
On Dec 5, 2012, at 5:58 PM, Thomas Morley wrote:
> Sorry to send this again, forgot to cc the list.
>
> 2012/12/5 Thomas Morley :
>> 2012/12/5 Paul Morris :
>>> On Dec 4, 2012, at 7:27 PM, Thomas Morley
>>> wrote:
>> [...]
>>>> May I ask, if you could add a commented 2.16-version of it?
>>>> Although your code will work for 2.16.1 up to 2.17.6 (so far I
>>>> tested), it would be nice to show the new make-engraver-macro and the
>>>> possibility of #{ #} in scheme-code, once the LSR is updated.
>>>
>>> Ok, I just uploaded a new version with the 2.16 code commented out. The
>>> make-engraver-macro is quite nice.
>>
>> Thanks for doing this!
Glad to help!
>>> It was a little tricky figuring out the #{ \markup ... #} syntax after
>>> getting used to the scheme version. If it were not for the need to
>>> demonstrate the new syntax (which I'm happy to help with) I'd probably just
>>> stick with the scheme version at this point.
>>
>> I know what you mean. :)
>> I tend to use only scheme-syntax in longer scheme-expressions.
>> It's nice to show #{ #}, though.
>>
>>> I eventually got it working in all cases, but had to move the accidental
>>> markups into variables
>>
>> Well, I do like variables. :)
Yeah, in this case they were only used once each, so it seemed like overkill to
assign them to variables. Maybe it's clearer that way though.
>>> to avoid too much nesting, which wasn't working. Namely this part:
>>>
>>> (if (pair? tonic-acc)
>>>(set! key-name (markup key-name (if (= acc-type 0.5 )
>>> (markup #:translate (cons (* mult -0.3) (* mult 0.8))
>>> #:magnify (* mult 0.9) #:sharp)
>>> (markup #:translate (cons (* mult -0.2) (* mult 0.4))
>>> #:magnify (* mult 0.9) #:flat)
>>>
>>> % > the following doesn't work:
>>>
>>> (if (pair? tonic-acc)
>>>(set! key-name #{ \markup #key-name #(if (= acc-type 0.5 )
>>> #{ \markup { \translate #(cons (* mult -0.3) (* mult 0.8))
>>> \magnify #(* mult 0.9) \sharp } #}
>>> #{ \markup { \translate #(cons (* mult -0.2) (* mult 0.4))
>>> \magnify #(* mult 0.9) \flat } #} ) #} ))
>>
>> It will work, while adding two braces:
>>
>> (if (pair? tonic-acc)
>> (set! key-name
>> #{ \markup { % <==
>> #key-name
>> #(if (= acc-type 0.5 )
>> #{
>> \markup {
>> \translate #(cons (* mult -0.3) (* mult 0.8))
>> \magnify #(* mult 0.9)
>> \sharp
>> }
>> #}
>> #{
>> \markup {
>> \translate #(cons (* mult -0.2) (* mult 0.4))
>> \magnify #(* mult 0.9)
>> \flat
>> }
>> #})
>> } % <=
>>#}))
Argh! The missing braces strike again. I should have caught that. Your
reformatting makes it much easier to follow.
>>> %> but this does:
>>>
>>> (if (pair? tonic-acc)
>>>(set! key-name #{ \markup { #key-name #(if (= acc-type 0.5 )
>>> txt-sharp txt-flat ) } #} ))
>>>
>>>
>>> Regards,
>>> -Paul
>>
>>
>> Now approved:
>> http://lsr.dsi.unimi.it/LSR/Item?id=856
>>
>> Regards,
>> Harm
>>
>> P.S.
>> I cc-ed the list, because I think it might be of interest for all.
Thanks again!
-Paul
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Custom key signature stencils, differentiating major and minor keys
I've uploaded a revised version of my snippet: Automatically display key names above key signatures http://lsr.dsi.unimi.it/LSR/Item?u=1&id=856 What's new? - handles modes (dorian, phrygian, lydian, etc.) - never prints key names above key cancellations (this was inconsistent before) - better code Cheers and enjoy! -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: printKeyCancellation, a way to never show key cancellations?
On Dec 2, 2012, at 6:49 PM, Thomas Morley wrote:
> You can distinguish KeySignature and KeyCancellation by 'name:
>
> \version "2.16.1"
>
> #(define Custom_key_engraver
> (make-engraver
>(acknowledgers
> ((key-signature-interface engraver grob source-engraver)
>(let ((grob-name (lambda (x) (assq-ref (ly:grob-property x
> 'meta) 'name
>
>;; For testing:
>;; (newline)(write (grob-name grob))
>;; (if (eq? 'KeySignature (grob-name grob))
>;; (ly:grob-set-property! grob 'color red)
>;; (ly:grob-set-property! grob 'color green))
>
>(if (eq? 'KeySignature (grob-name grob))
> (ly:grob-set-property! grob 'stencil (make-circle-stencil .7 .3 #f))
> (ly:grob-set-property! grob 'stencil #f)))
>
> music = \relative c' {
> \time 1/4
> \key a \major
> d4
> \key f \major
> d
> \key a \major
> d
> \key f \major
> d
> \key a \major
> d
> \break
> \key c \major
> d
> \key a \major
> d
> \key c \major
> d
> }
>
> \score
> {
> <<
> \new Staff { \music }
> \new Staff \with { \consists \Custom_key_engraver }
> { \music }
> >>
> \layout { }
> }
>
> HTH,
> Harm
Thanks Harm! Now it seems kind of obvious that the 'name of the grob
differentiates them. (Although I would not have known exactly how to access the
'name without help, even if I'd known that was what was needed).
Thanks again,
-Paul
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: printKeyCancellation, a way to never show key cancellations?
On Dec 2, 2012, at 3:01 PM, Keith OHara wrote: > Paul Morris paulwmorris.com> writes: > >> For greater flexibility, would it make sense for PrintKeyCancellation to >> have 3 options instead of 2? >> 1. show key cancellations >> 2. hide key cancellations, except C major / A minor >> 3. hide all key cancellations >> > Maybe it would have, but we have gotten used to the simple true/false, which > does the right thing for most situations. > > Option number 3 can be had most simply with > >> \override Staff.KeyCancellation #'stencil = ##f > > but it looks like you wrote code that restores the 'stencil for > anything that answers to the "key-signature-interface" > >> ((key-signature-interface engraver grob source-engraver) >> (ly:grob-set-property! grob 'stencil >> (make-circle-stencil .7 .3 #f)) > > You can stop the key cancellation by some other means as Harm suggested, > or change your code to stencil KeySignatures only. That makes sense. Reading through the docs I haven't been able to figure out how to do this. If anyone has suggestions or pointers, I would appreciate it. >From what I could tell the Key_engraver engraves both signatures and their >cancellations, and I couldn't see how (or whether) it knows which one it's >engraving, or how one might replicate that with custom Scheme code. Maybe one >would need to hook into the code at a higher step in the order of operations, >where the difference between signatures and cancellations was still accessible? In any case I can use \override Staff.KeyCancellation #'break-visibility = ##(#f #f #f) but it would be nice to know the better way to do it. Thanks again, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: printKeyCancellation, a way to never show key cancellations?
On Dec 2, 2012, at 1:16 PM, Thomas Morley wrote:
> 2012/12/2 Paul Morris :
>> Hi everyone, I am using
>> \set Staff.printKeyCancellation = ##f
>> to not show the key cancellation when you change keys[1]. But I found that
>> this does not hide the key cancellation when you change back to C major or A
>> minor[2] (presumably since that would leave no indication of a key change at
>> all).
>>
>> But I am using non-standard key signatures that make all key cancellations
>> unnecessary, so I want to never show them, even when changing to C major / A
>> minor.
>>
>>
>> JUST A THOUGHT
>> For greater flexibility, would it make sense for PrintKeyCancellation to
>> have 3 options instead of 2?
>>
>> 1. show key cancellations
>> 2. hide key cancellations, except C major / A minor
>> 3. hide all key cancellations
>>
>>
>> OR A DOCUMENTATION SUGGESTION
>> In any case it would be helpful to mention this C major / A minor exception
>> on the page documenting this option.[1] Something like:
>>
>> "(Note that setting the Staff context property printKeyCancellation to #f
>> does _not_ remove cautionary accidentals when changing to a key with no
>> sharps or flats (C major / A minor), since that would leave no indication of
>> a key change.)"
>>
>> Also, the example on that page concludes with: "With these overrides only
>> the accidentals before the notes remain to indicate the change of key."
>> ...which is not completely true, unless you add something like "(unless you
>> have just changed to C major / A minor)".
>>
>>
>> A WORKAROUND FROM THE ARCHIVES (ALMOST)
>> So I searched the lilypond-user archives and found a few instances where
>> this has come up, and a suggested workaround[3]:
>>
>> \once \override Staff.KeyCancellation #'stencil = ##f
>>
>> This works! ...except it does not seem to work when using a custom key
>> signature engraver. Here is a tiny example that just shows a circle as a
>> custom key signature (of course, this is not what I actually use).
>>
>> \version "2.16.1"
>>
>> #(define Custom_key_engraver
>> (make-engraver
>>(acknowledgers
>> ((key-signature-interface engraver grob source-engraver)
>>(ly:grob-set-property! grob 'stencil (make-circle-stencil .7 .3
>> #f))
>>
>> music = \relative c' {
>> \time 1/4
>> \key a \major
>> d4
>> \key f \major
>> d
>>
>> \set Staff.printKeyCancellation = ##f
>> \key a \major
>> d
>> \key f \major
>> d
>> \key a \major
>> d
>> \key c \major
>> d
>>
>> \override Staff.KeyCancellation #'stencil = ##f
>> \override CustomStaff.KeyCancellation #'stencil = ##f
>> \key a \major
>> d
>> \key c \major
>> d
>> }
>>
>> \score
>> {
>> <<
>> \new Staff { \music }
>> \new Staff \with { \consists \Custom_key_engraver } { \music }
>>>>
>> \layout { }
>> }
>>
>> The problem can be seen in the last measure where two circles are printed,
>> one for the key cancellation and one for the key of C, whereas no key
>> cancellation is printed on the standard staff.
>>
>> I realize I am off in the land of non-standard customizations, but does
>> anyone have any suggestions? Is there a way to get such a custom key
>> signature engraver to recognize and follow this override?
>>
>> Cheers,
>> -Paul
>>
>> [1] See "Visibility of cautionary accidentals" section:
>> http://www.lilypond.org/doc/v2.16/Documentation/notation/visibility-of-objects#special-considerations
>>
>> [2]
>> \version "2.16.1"
>> \relative c' {
>> \time 1/4
>> \key a \major
>> d4
>> \key f \major
>> d
>> \set Staff.printKeyCancellation = ##f
>> \key a \major
>> d
>> \key f \major
>> d
>> \key a \major
>> d
>> \key c \major
>> d
>> }
>>
>> [3] http://lists.gnu.org/archive/html/lilypond-user/2012-05/msg00749.html
>> ___
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
> How about adding
> \override Staff.KeyCancellation #'break-visibility = #'#(#f #f #f)
> to your score?
> Seems to work.
Thanks Harm! That looks like it does the trick! And thanks David for the tip.
Hmmm... maybe it would make sense to add "KeyCancellation" to the list of
layout objects that are affected by break-visibility in the documentation here:
http://www.lilypond.org/doc/v2.16/Documentation/notation/visibility-of-objects#using-break_002dvisibility
Cheers,
-Paul
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
printKeyCancellation, a way to never show key cancellations?
Hi everyone, I am using
\set Staff.printKeyCancellation = ##f
to not show the key cancellation when you change keys[1]. But I found that
this does not hide the key cancellation when you change back to C major or A
minor[2] (presumably since that would leave no indication of a key change at
all).
But I am using non-standard key signatures that make all key cancellations
unnecessary, so I want to never show them, even when changing to C major / A
minor.
JUST A THOUGHT
For greater flexibility, would it make sense for PrintKeyCancellation to have 3
options instead of 2?
1. show key cancellations
2. hide key cancellations, except C major / A minor
3. hide all key cancellations
OR A DOCUMENTATION SUGGESTION
In any case it would be helpful to mention this C major / A minor exception on
the page documenting this option.[1] Something like:
"(Note that setting the Staff context property printKeyCancellation to #f does
_not_ remove cautionary accidentals when changing to a key with no sharps or
flats (C major / A minor), since that would leave no indication of a key
change.)"
Also, the example on that page concludes with: "With these overrides only the
accidentals before the notes remain to indicate the change of key." ...which
is not completely true, unless you add something like "(unless you have just
changed to C major / A minor)".
A WORKAROUND FROM THE ARCHIVES (ALMOST)
So I searched the lilypond-user archives and found a few instances where this
has come up, and a suggested workaround[3]:
\once \override Staff.KeyCancellation #'stencil = ##f
This works! ...except it does not seem to work when using a custom key
signature engraver. Here is a tiny example that just shows a circle as a
custom key signature (of course, this is not what I actually use).
\version "2.16.1"
#(define Custom_key_engraver
(make-engraver
(acknowledgers
((key-signature-interface engraver grob source-engraver)
(ly:grob-set-property! grob 'stencil (make-circle-stencil .7 .3 #f))
music = \relative c' {
\time 1/4
\key a \major
d4
\key f \major
d
\set Staff.printKeyCancellation = ##f
\key a \major
d
\key f \major
d
\key a \major
d
\key c \major
d
\override Staff.KeyCancellation #'stencil = ##f
\override CustomStaff.KeyCancellation #'stencil = ##f
\key a \major
d
\key c \major
d
}
\score
{
<<
\new Staff { \music }
\new Staff \with { \consists \Custom_key_engraver } { \music }
>>
\layout { }
}
The problem can be seen in the last measure where two circles are printed, one
for the key cancellation and one for the key of C, whereas no key cancellation
is printed on the standard staff.
I realize I am off in the land of non-standard customizations, but does anyone
have any suggestions? Is there a way to get such a custom key signature
engraver to recognize and follow this override?
Cheers,
-Paul
[1] See "Visibility of cautionary accidentals" section:
http://www.lilypond.org/doc/v2.16/Documentation/notation/visibility-of-objects#special-considerations
[2]
\version "2.16.1"
\relative c' {
\time 1/4
\key a \major
d4
\key f \major
d
\set Staff.printKeyCancellation = ##f
\key a \major
d
\key f \major
d
\key a \major
d
\key c \major
d
}
[3] http://lists.gnu.org/archive/html/lilypond-user/2012-05/msg00749.html
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Note duration line (contemporary)
On Nov 28, 2012, at 7:02 PM, Jeffrey Trevino wrote: > It's a long-term goal of mine to learn enough about the Scheme side of > Lilypond to be able to design stencils, and custom notational constructs more > broadly, like you've just done. It seems like graphic flexibility with > \markup is documented really well, but I've yet to get the basics of how I > can use Scheme to control Lilypond at a low-level graphically as you've just > done. Do you -- or anyone else reading -- have a suggestion about which > source code or documentation I should take a look at to start learning how? Hi Jeffrey, I have found that the LSR is really your friend here. I have been able to learn a *lot* by following (reverse-engineering) the way certain examples are done there (with help from the LilyPond documentation and online scheme tutorials). Try a search for "stencil" to look at relevant snippets: http://lsr.dsi.unimi.it/LSR/Search?q=stencil LilyPond's Scheme tutorial helped me get started with Scheme (if you haven't seen it): http://www.lilypond.org/doc/v2.16/Documentation/extending/scheme-tutorial Here's a great snippet on creating custom stencils: http://lsr.dsi.unimi.it/LSR/Item?id=623 And here's a good site for making sense of cubic bezier curves: http://cubic-bezier.com Harm's advice about following the user list is good too. It is really impressive how far you can go with customizing LilyPond with Scheme. -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Custom key signature stencils, differentiating major and minor keys
On Nov 18, 2012, at 7:26 AM, Thomas Morley wrote: > 2012/11/18 Paul Morris : > [...] >> I do have some small changes I made to my local copy that I'd like to add. >> They are for the accidental signs in the text -- better spacing and putting >> them into a LilyPond variable for less repetition. I won't be able to get >> to this until Wednesday at the earliest. > > No problem. I'll wait. Hi Harm, I incorporated your 2.14 "downgrades" into my most current version, and uploaded it to the LSR: http://lsr.dsi.unimi.it/LSR/Item?u=1&id=856 I kept the commented-out 2.16 version in the snippet, for easy future migration. But I am fine with removing it if that's preferred for the LSR. The most current code for use in 2.16 is pasted below. Thanks again, -Paul % Begin snippet \version "2.16.0" % tonic-semi: semitone of the tonic note, 0-11, 0=C, 2=D, etc % psn: vertical staff position of the last accidental sign in key signature % accsign: the accidental sign type, 1/2=sharp, -1/2=flat % (These 3 things let us identify the key and if it is major or minor.) % txt-size: size of key name text % padd: padding between key signature and key name % C Major, F Major, A Minor, and D Minor all get extra padding % so the name is above the staff % This snippet does not work with modal keys (dorian, lydian, etc.) % Key cancellations usually get no name above them, % unless they have the same tonic note, like G major to G minor. #(define Custom_key_signature_engraver (make-engraver (acknowledgers ((key-signature-interface engraver grob source-engraver) (let* ( (context (ly:translator-context engraver)) (tonic-pitch (ly:context-property context 'tonic)) (tonic-semi (modulo (ly:pitch-semitones tonic-pitch) 12)) (acclist (ly:grob-property grob 'alteration-alist)) (accsign (if (null? acclist) 0 (cdr (list-ref acclist 0 (psn (if (null? acclist) 0 (car (list-ref acclist 0 (key-name (markup #:null)) (txt-size .7) (padd .5) (sharptxt (markup #:translate (cons -0.3 0.8) #:magnify .9 #:sharp)) (flattxt (markup #:translate (cons -0.2 0.4) #:magnify .9 #:flat)) ) (cond ((= accsign 0) (cond ((= tonic-semi 0) (set! key-name (markup "C Major" )) (set! padd 3.2)) ((= tonic-semi 9) (set! key-name (markup "A Minor" )) (set! padd 3.2)) (else (set! key-name (markup #:null))) )) ((= accsign 1/2) (cond ((= psn 3) (cond ((= tonic-semi 7) (set! key-name (markup "G Major" ))) ((= tonic-semi 4) (set! key-name (markup "E Minor" ))) (else (set! key-name (markup #:null))) )) ((= psn 0) (cond ((= tonic-semi 2) (set! key-name (markup "D Major" ))) ((= tonic-semi 11) (set! key-name (markup "B Minor" ))) (else (set! key-name (markup #:null))) )) ((= psn 4) (cond ((= tonic-semi 9) (set! key-name (markup "A Major" ))) ((= tonic-semi 6) (set! key-name (markup "F" sharptxt "Minor" ))) (else (set! key-name (markup #:null))) )) ((= psn 1) (cond ((= tonic-semi 4) (set! key-name (markup "E Major" ))) ((= tonic-semi 1) (set! key-name (markup "C" sharptxt "Minor" ))) (else (set! key-name (markup #:null))) )) ((= psn 5) (cond ((= tonic-semi 11) (set! key-name (markup "B Major" ))) ((= tonic-semi 8) (set! key-name (markup "G" sharptxt "Minor" ))) (else (set! key-name (markup #:null))) )) ((= psn 2) (cond ((= tonic-semi 6) (set! key-name (markup "F" sharptxt "Major" ))) ((= tonic-semi 3) (set! key-name (markup "D" sharptxt "Minor" ))) (else (set! key-name (markup #:null))) )) ((= psn 6) (cond ((= tonic-semi 1) (set! key-name (markup "C" sharptxt "Major" ))) ((= tonic-semi 10) (set! key-name (markup "A" sharptxt "Minor" ))) (else (set! key-name (markup #:null))) )) ) ) ((= accsign -1/2) (cond ((= psn 6) (cond ((= tonic-semi 5) (set! key-name (markup "F Major" )) (set! padd 1.4)) ((= tonic-semi 2) (set! key-name (markup "D Minor" )) (set! padd 1.7)) (else (set! key-name (markup #:null))) )) ((= psn 2) (cond ((= tonic-semi 10) (set! key-name (markup "B" flattxt "Major" ))) ((= tonic-semi 7) (set! key-name (markup "G Minor" )))
Re: Custom key signature stencils, differentiating major and minor keys
On Nov 16, 2012, at 8:55 PM, MING TSANG wrote:
> Dear Paul,
>
> I tested your latest version, the C Major, A Minor the alternative key
> signature does not print on the second system. G major, E minor & D Major, B
> Minor seems ok - that is - alternative key singature displayed on the second
> system.
Hi Ming, Yes, I do not know how to work around this. It seems that in the
keys of C Major or A Minor, LilyPond does not print a key signature at all at
the beginning of the 2nd, 3rd, etc... lines of music (not even an "empty" or
"invisible" key signature). So the custom key signature engraver does not get
called and so it does not print the name of the key there.
-Paul
>
> Please see the .pdf
>
>
> Blessing in+,
> Ming.
> From: Thomas Morley
> To: Paul Morris
> Cc: MING TSANG ; lilypond-usermailinglist
>
> Sent: Friday, November 16, 2012 7:50:17 PM
> Subject: Re: Custom key signature stencils, differentiating major and minor
> keys
>
> 2012/11/14 Paul Morris :
> > Hi Ming, I took another look at this and since there's only one key
> > signature where the accidentals do not extend above the staff (F major / D
> > minor) I just added extra padding for those keys. Now the key names always
> > appear above the staff, regardless of the clef.
> >
> > The sizing of the accidental signs in the key names is better in this
> > version as well.
> >
> > Cheers,
> > -Paul
>
> Hi Paul,
>
> am I right you've added your engraver to LSR with a [needs upgrade]-label?
> http://lsr.dsi.unimi.it/LSR/Item?u=1&id=856
>
> If so:
> I downgraded your code to make it work with 2.14.2:
> changing the make-engraver-macro (created by David Kastrup) to the old
> syntax and changing the #{ #}-syntax (also made possible by David) to
> scheme-syntax.
> The 2.16.0-code is untouched and commented.
>
> Note that I didn't have a closer look at the code. ;)
> Also note, since there is something strange with the displayed
> LSR-output I added a markup to get the spacing correct.
>
> If you agree, I could approve it now.
> Currently, I let it unapproved, in case you may want to add or change sth.
>
>
> Best,
> Harm
>
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Custom key signature stencils, differentiating major and minor keys
On Nov 16, 2012, at 7:50 PM, Thomas Morley
wrote:
> 2012/11/14 Paul Morris :
>> Hi Ming, I took another look at this and since there's only one key
>> signature where the accidentals do not extend above the staff (F major / D
>> minor) I just added extra padding for those keys. Now the key names always
>> appear above the staff, regardless of the clef.
>>
>> The sizing of the accidental signs in the key names is better in this
>> version as well.
>>
>> Cheers,
>> -Paul
>
> Hi Paul,
>
> am I right you've added your engraver to LSR with a [needs upgrade]-label?
> http://lsr.dsi.unimi.it/LSR/Item?u=1&id=856
Hi Harm, Yes, that was me.
> If so:
> I downgraded your code to make it work with 2.14.2:
> changing the make-engraver-macro (created by David Kastrup) to the old
> syntax and changing the #{ #}-syntax (also made possible by David) to
> scheme-syntax.
> The 2.16.0-code is untouched and commented.
Thanks! I didn't know that that was what was needed, or what changes to make.
> Note that I didn't have a closer look at the code. ;)
Ok. :) I realize there may be better ways of doing it.
> Also note, since there is something strange with the displayed
> LSR-output I added a markup to get the spacing correct.
Hmmm, ok.
> If you agree, I could approve it now.
> Currently, I let it unapproved, in case you may want to add or change sth.
I do have some small changes I made to my local copy that I'd like to add.
They are for the accidental signs in the text -- better spacing and putting
them into a LilyPond variable for less repetition. I won't be able to get to
this until Wednesday at the earliest.
Thanks for your help getting it to run with 2.14.2!
-Paul
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Custom key signature stencils, differentiating major and minor keys
Hi Ming, I took another look at this and since there's only one key signature
where the accidentals do not extend above the staff (F major / D minor) I just
added extra padding for those keys. Now the key names always appear above the
staff, regardless of the clef.
The sizing of the accidental signs in the key names is better in this version
as well.
Cheers,
-Paul
\version "2.16.0"
% tonic-semi: semitone of tonic note, 0-11, 0=C, 2=D, etc
% psn: vertical staff position of the last accidental sign in key signature
% accsign: the accidental sign type, 1/2=sharp, -1/2=flat
% Knowing these 3 things is enough to identify the key and whether it is
major/minor
% txt-size: size of key name text
% padd: padding between key signature and key name
% F Major and D Minor get extra padding to clear the staff
% It does not handle modal keys correctly (dorian, lydian, etc.)
#(define Custom_key_sig_engraver
(make-engraver
(acknowledgers
((key-signature-interface engraver grob source-engraver)
(let* (
(context (ly:translator-context engraver))
(tonic-pitch (ly:context-property context 'tonic))
(tonic-semi (modulo (ly:pitch-semitones tonic-pitch) 12))
(acclist (ly:grob-property grob 'alteration-alist))
(accsign (if (null? acclist) 0 (cdr (list-ref acclist
0
(psn (if (null? acclist) 0 (car (list-ref acclist
0
(key-name #{ \markup {} #})
(txt-size .7)
(padd .5)
)
(cond
((= accsign 0) (cond
((= tonic-semi 0) (set! key-name #{ \markup {C Major}
#}) (set! padd 3.2))
((= tonic-semi 9) (set! key-name #{ \markup {A Minor}
#}) (set! padd 3.2))
(else (set! key-name #{\markup{}#}))
))
((= accsign 1/2)
(cond
((= psn 3) (cond
((= tonic-semi 7) (set! key-name #{ \markup {G Major}
#}))
((= tonic-semi 4) (set! key-name #{ \markup {E Minor}
#}))
(else (set! key-name #{\markup{}#}))
))
((= psn 0) (cond
((= tonic-semi 2) (set! key-name #{ \markup {D Major}
#}))
((= tonic-semi 11) (set! key-name #{ \markup {B Minor}
#}))
(else (set! key-name #{\markup{}#}))
))
((= psn 4) (cond
((= tonic-semi 9) (set! key-name #{ \markup {A Major}
#}))
((= tonic-semi 6) (set! key-name #{ \markup {F\raise
#.8 \magnify #.8 {\sharp} Minor} #}))
(else (set! key-name #{\markup{}#}))
))
((= psn 1) (cond
((= tonic-semi 4) (set! key-name #{ \markup {E Major}
#}))
((= tonic-semi 1) (set! key-name #{ \markup {C\raise
#.8 \magnify #.8 {\sharp} Minor} #}))
(else (set! key-name #{\markup{}#}))
))
((= psn 5) (cond
((= tonic-semi 11) (set! key-name #{ \markup {B Major}
#}))
((= tonic-semi 8) (set! key-name #{ \markup {G\raise
#.8 \magnify #.8 {\sharp} Minor} #}))
(else (set! key-name #{\markup{}#}))
))
((= psn 2) (cond
((= tonic-semi 6) (set! key-name #{ \markup {F\raise
#.8 \magnify #.8 {\sharp} Major} #}))
((= tonic-semi 3) (set! key-name #{ \markup {D\raise
#.8 \magnify #.8 {\sharp} Minor} #}))
(else (set! key-name #{\markup{}#}))
))
((= psn 6) (cond
((= tonic-semi 1) (set! key-name #{ \markup {C\raise
#.8 \magnify #.8 {\sharp} Major} #}))
((= tonic-semi 10) (set! key-name #{ \markup {A\raise
#.8 \magnify #.8 {\sharp} Minor} #}))
(else (set! key-name #{\markup{}#}))
))
)
)
((= accsign -1/2)
(cond
((= psn 6) (cond
((= tonic-semi 5) (set! key-name #{ \markup {F Major}
#}) (set! padd 1.4))
((= tonic-semi 2) (set! key-name #{ \markup {D Minor}
#}) (set! padd 1.7))
(else (set! key-name #{\markup{}#}))
))
((= psn 2) (cond
((= tonic-semi 10) (set! key-name #{ \markup {B\raise
#.4 \magnify #.8 {\flat} Major} #}))
((= tonic-semi 7) (set! key-name #{ \markup {G Minor}
#}))
(else (set! key-name #{\markup{}#}))
))
((= psn 5) (cond
((= tonic-semi 3
Re: Custom key signature stencils, differentiating major and minor keys
On Nov 13, 2012, at 7:26 AM, MING TSANG wrote:
> Hi, Paul: I apply the change, it pushes the display above the staff. However
> I notice (1) that the distance is not constant from system to system - it
> diminishes;
That is expected. It sets the padding (distance) between the top of the
highest accidental in the key signature and the bottom of the text. So that is
constant. But when the top of the highest accidental falls below the top of
the staff, and at different vertical positions below the top of the staff, then
the distance between the text and the top of the _staff_ will be different.
Ideally it would set the padding from the top of the staff _or_ the top of the
highest accidental. A better approach to achieve this would be: instead of
combining the text and the key signature symbol into one graphical stencil /
grob, add the text as a rehearsal mark centered on the key signature. Then it
would inherit all of the usual smart spacing for rehearsal marks.
Here's how you can do that by hand:
\version "2.16.0"
\new Staff {
\clef bass
\once \override Score.RehearsalMark #'break-align-symbols = #'(key-signature)
\key f \major
\mark \markup \magnify #.7 {F Major}
c1
\clef treble
\once \override Score.RehearsalMark #'break-align-symbols = #'(key-signature)
\key cis \major
\mark \markup \magnify #.7 {C\raise #.4 {\sharp} Major}
c'1
}
As described here:
http://lilypond.org/doc/v2.16/Documentation/notation/writing-text#text-marks
Under: Selected Snippets > Aligning marks with various notation objects
So there should be a way to get my custom key signature script to automatically
add such rehearsal marks to the key signature. But this would require
reworking it.
> (2) that after key change from F Major to C Major, it display at the point
> where it changes, but disappear on the next system onward.
Hmmm... it looks like if the key is C Major or A Minor then no key signature
is printed, not even an "empty" one, and so the name does not get printed
either. Not sure how to work around that.
-Paul
>
> Here is the .png and .ly file.
>
> Thank you again.
>
> Blessing in+,
> Ming.
> From: Paul Morris
> To: MING TSANG
> Sent: Monday, November 12, 2012 10:54:56 PM
> Subject: Re: Custom key signature stencils, differentiating major and minor
> keys
>
> Hi Ming,
> Yes, I saw that too... There is a padding setting that sets the distance
> between the top of the key signature and the name above it. So you could
> increase this until it no longer overlapped in the bass clef, but this might
> create too much space in other places?
>
> For example change the .5 in this:
>
> (ly:stencil-scale (grob-interpret-markup grob key-name) .7 .7)
> .5 ))
>
> To 1.1 like so:
>
> (ly:stencil-scale (grob-interpret-markup grob key-name) .7 .7)
> 1.1 ))
>
> That pushes the name up above the bass staff, but it also increases the
> distance in all the other places as well.
>
> Cheers,
> -Paul
>
> PS. Sorry for resending my previous message. I realized I did not send it to
> the lily-user list before.
>
>
> On Nov 12, 2012, at 10:33 PM, MING TSANG wrote:
>
>> Hi, Paul:
>>
>> Thank you for the sample placement of the "\consists
>> \Custom_key_sig_engraver".
>>
>> One minor drawback: The alternative key signature on Bass is on the staff
>> line, not above the staff. How can I adjust it?
>>
>>
>> Blessing in+,
>> Ming.
>> From: Paul Morris
>> To: MING TSANG
>> Sent: Monday, November 12, 2012 9:53:31 PM
>> Subject: Re: Custom key signature stencils, differentiating major and minor
>> keys
>>
>>
>> On Nov 12, 2012, at 2:42 PM, MING TSANG wrote:
>>
>>> Hi, Paul:
>>>
>>> I try to use custon-key-signature in my lilypond score and I did not get
>>> the alternative key printed above the traditional key signature. What is
>>> missing in the code below? I have "\Staff \consists
>>> \Custom_key_sig_engraver" in \layout as seen in your sample.
>>
>> Hi Ming, It looks like you need to just put \consists
>> \Custom_key_sig_engraver in the \with block for each of the three staves in
>> your score as shown below. Then you don't need it in the layout block. The
>> following changes below got it to work for me.
>>
>> Cheers,
>> -Paul
>>
>> [...]
>>
>> sopranoVoicePart = \new Staff \with { \consists #numbr
>> \consists \Custom_key_sig_engraver
>> instrumentName = "Soprano"
>> %midiInstrument = "choir aahs"
>> } { \sopranoVoiceI }
>>
Re: Custom key signature stencils, differentiating major and minor keys
On Nov 12, 2012, at 2:42 PM, MING TSANG wrote:
> Hi, Paul:
>
> I try to use custon-key-signature in my lilypond score and I did not get the
> alternative key printed above the traditional key signature. What is missing
> in the code below? I have "\Staff \consists \Custom_key_sig_engraver" in
> \layout as seen in your sample.
Hi Ming, It looks like you need to just put \consists \Custom_key_sig_engraver
in the \with block for each of the three staves in your score as shown below.
Then you don't need it in the layout block. The following changes below got it
to work for me.
Cheers,
-Paul
[...]
sopranoVoicePart = \new Staff \with { \consists #numbr
\consists \Custom_key_sig_engraver
instrumentName = "Soprano"
%midiInstrument = "choir aahs"
} { \sopranoVoiceI }
\addlyrics { \verseSopranoVoiceI }
pianoPart = \new PianoStaff \with {
instrumentName = "Piano"
} <<
\new Staff = "right" \with {
\consists \Custom_key_sig_engraver
midiInstrument = "acoustic grand"
} \right
\new Staff = "left" \with {
\consists \Custom_key_sig_engraver
midiInstrument = "acoustic grand"
} { \clef bass \left }
>>
\score {
<<
\sopranoVoicePart
\pianoPart
>>
\layout {
\context {
\RemoveEmptyStaffContext
\override VerticalAxisGroup #'remove-first = ##t
}
}
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Custom key signature stencils, differentiating major and minor keys
Here is another revision (hopefully the last?!). The previous version would
include the key name over a key cancellation[1], but it would often be an
incorrect/unrelated key name (!).
This version does not include the name of the key above a key-cancellation,
unless the tonic note is the same in both keys, like a switch from G major to G
minor. (This is a glitch I haven't been able to work around. It always gives
the correct key name now at least. I tried checking for natural signs as the
type of accidental used in key cancellations, but this does not work.)
Cheers,
-Paul
[1] http://www.lilypond.org/doc/v2.16/Documentation/internals/keycancellation
\version "2.16.0"
% tonic-semi: semitone of tonic note, 0-11
% psn: vertical staff position of the last accidental sign in key signature
% accsign: the accidental sign type, 1/2=sharp, -1/2=flat
% Knowing these 3 things is enough to identify the key and whether it is
major/minor
#(define Custom_key_sig_engraver
(make-engraver
(acknowledgers
((key-signature-interface engraver grob source-engraver)
(let* (
(context (ly:translator-context engraver))
(tonic-pitch (ly:context-property context 'tonic))
(tonic-semi (modulo (ly:pitch-semitones tonic-pitch) 12))
(acclist (ly:grob-property grob 'alteration-alist))
(accsign (if (null? acclist) 0 (cdr (list-ref acclist 0
(psn (if (null? acclist) 0 (car (list-ref acclist
0
(key-name #{ \markup {} #})
)
(cond
((= accsign 0) (cond
((= tonic-semi 0) (set! key-name #{ \markup \raise #3.4
{C Major} #}))
((= tonic-semi 9) (set! key-name #{ \markup \raise #3.4
{A Minor} #}))
(else (set! key-name #{\markup{}#}))
))
((= accsign 1/2)
(cond
((= psn 3) (cond
((= tonic-semi 7) (set! key-name #{ \markup {G Major}
#}))
((= tonic-semi 4) (set! key-name #{ \markup {E Minor}
#}))
(else (set! key-name #{\markup{}#}))
))
((= psn 0) (cond
((= tonic-semi 2) (set! key-name #{ \markup {D Major}
#}))
((= tonic-semi 11) (set! key-name #{ \markup {B Minor}
#}))
(else (set! key-name #{\markup{}#}))
))
((= psn 4) (cond
((= tonic-semi 9) (set! key-name #{ \markup {A Major}
#}))
((= tonic-semi 6) (set! key-name #{ \markup {F\raise
#.6 {\sharp} Minor} #}))
(else (set! key-name #{\markup{}#}))
))
((= psn 1) (cond
((= tonic-semi 4) (set! key-name #{ \markup {E Major}
#}))
((= tonic-semi 1) (set! key-name #{ \markup {C\raise
#.6 {\sharp} Minor} #}))
(else (set! key-name #{\markup{}#}))
))
((= psn 5) (cond
((= tonic-semi 11) (set! key-name #{ \markup {B Major}
#}))
((= tonic-semi 8) (set! key-name #{ \markup {G\raise
#.6 {\sharp} Minor} #}))
(else (set! key-name #{\markup{}#}))
))
((= psn 2) (cond
((= tonic-semi 6) (set! key-name #{ \markup {F\raise
#.6 {\sharp} Major} #}))
((= tonic-semi 3) (set! key-name #{ \markup {D\raise
#.6 {\sharp} Minor} #}))
(else (set! key-name #{\markup{}#}))
))
((= psn 6) (cond
((= tonic-semi 1) (set! key-name #{ \markup {C\raise
#.6 {\sharp} Major} #}))
((= tonic-semi 10) (set! key-name #{ \markup {A\raise
#.6 {\sharp} Minor} #}))
(else (set! key-name #{\markup{}#}))
))
)
)
((= accsign -1/2)
(cond
((= psn 6) (cond
((= tonic-semi 5) (set! key-name #{ \markup {F Major}
#}))
((= tonic-semi 2) (set! key-name #{ \markup {D Minor}
#}))
(else (set! key-name #{\markup{}#}))
))
((= psn 2) (cond
((= tonic-semi 10) (set! key-name #{ \markup {B\raise
#.4 {\flat} Major} #}))
((= tonic-semi 7) (set! key-name #{ \markup {G Minor}
#}))
(else (set! key-name #{\markup{}#}))
))
((= psn 5) (cond
((= tonic-semi 3) (set! key-name #{ \markup {E\raise
#.4 {\flat} Major} #}))
((= tonic-semi 0) (set! key-name #{ \markup {C Minor}
#}))
Re: Custom key signature stencils, differentiating major and minor keys
Here is an improved version. It works the same as the last,
but with much more streamlined and concise code.
-Paul
\version "2.16.0"
#(define Custom_key_sig_engraver
(make-engraver
(acknowledgers
((key-signature-interface engraver grob source-engraver)
(let* (
(context (ly:translator-context engraver))
(tonic-pitch (ly:context-property context 'tonic))
(tonic-semi (modulo (ly:pitch-semitones tonic-pitch) 12)) ;;
semitone of tonic note, 0-11
(acclist (ly:grob-property grob 'alteration-alist))
(accsign (if (null? acclist) 0 (cdr (list-ref acclist 0
;; accidental sign type, 1/2=sharp, -1/2=flat
(psn (if (null? acclist) 0 (car (list-ref acclist
0 ;; vertical position of last accidental sign
(key-name #{ \markup {} #})
)
(cond
((= accsign 0)
(if (= tonic-semi 0)
(set! key-name #{ \markup \raise #3.4 {C Major} #})
(set! key-name #{ \markup \raise #3.4 {A Minor} #})
))
((= accsign 1/2) ;; SHARP KEYS
(cond
((= psn 3)
(if (= tonic-semi 7)
(set! key-name #{ \markup {G Major} #})
(set! key-name #{ \markup {E Minor} #})
))
((= psn 0)
(if (= tonic-semi 2)
(set! key-name #{ \markup {D Major} #})
(set! key-name #{ \markup {B Minor} #})
))
((= psn 4)
(if (= tonic-semi 9)
(set! key-name #{ \markup {A Major} #})
(set! key-name #{ \markup {F\raise #.6 {\sharp}
Minor} #})
))
((= psn 1)
(if (= tonic-semi 4)
(set! key-name #{ \markup {E Major} #})
(set! key-name #{ \markup {C\raise #.6 {\sharp}
Minor} #})
))
((= psn 5)
(if (= tonic-semi 11)
(set! key-name #{ \markup {B Major} #})
(set! key-name #{ \markup {G\raise #.6 {\sharp}
Minor} #})
))
((= psn 2)
(if (= tonic-semi 6)
(set! key-name #{ \markup {F\raise #.6 {\sharp}
Major} #})
(set! key-name #{ \markup {D\raise #.6 {\sharp}
Minor} #})
))
((= psn 6)
(if (= tonic-semi 1)
(set! key-name #{ \markup {C\raise #.6 {\sharp}
Major} #})
(set! key-name #{ \markup {A\raise #.6 {\sharp}
Minor} #})
))
)
)
((= accsign -1/2) ;; FLAT KEYS
(cond
((= psn 6)
(if (= tonic-semi 5)
(set! key-name #{ \markup {F Major} #})
(set! key-name #{ \markup {D Minor} #})
))
((= psn 2)
(if (= tonic-semi 10)
(set! key-name #{ \markup {B\raise #.4 {\flat}
Major} #})
(set! key-name #{ \markup {G Minor} #})
))
((= psn 5)
(if (= tonic-semi 3)
(set! key-name #{ \markup {E\raise #.4 {\flat}
Major} #})
(set! key-name #{ \markup {C Minor} #})
))
((= psn 1)
(if (= tonic-semi 8)
(set! key-name #{ \markup {A\raise #.4 {\flat}
Major} #})
(set! key-name #{ \markup {F Minor} #})
))
((= psn 4)
(if (= tonic-semi 1)
(set! key-name #{ \markup {D\raise #.4 {\flat}
Major} #})
(set! key-name #{ \markup {B\raise #.4 {\flat}
Minor} #})
))
((= psn 0)
(if (= tonic-semi 6)
(set! key-name #{ \markup {G\raise #.4 {\flat}
Major} #})
(set! key-name #{ \markup {E\raise #.4 {\flat}
Minor} #})
))
((= psn 3)
(if (= tonic-semi 11)
(set! key-name #{ \markup {C\raise #.4 {\flat}
Major} #})
(set! key-name #{ \markup {A\raise #.4 {\flat}
Minor} #})
))
Re: Custom key signature stencils, differentiating major and minor keys
On Nov 11, 2012, at 7:38 AM, MING TSANG wrote:
> Hi, Paul: Thank you for the custom key signature. I have been dreaming this
> for sometime, but hesitate to ask lilypond user community. I have been using
> circle of fifths to identify the key signature.
Hi Ming, I'm glad you find it useful.
> You mention this custom key signature can be adapted to print above the clef
> sign. I am not a programmer, so not able to change (adapt).
>
> Questions:
> 1. Print the custom key signature above the clef sign
> 2. Is it possible to retain the traditional key signature then print the
> custom key signature above
> 3. Can this custom key signature use with \include "english.ly" or \language
> english?
> 4. Can ais (as in english) print as A# Major & f# Minor; same for flat as
> well?
The new code below will print the name of the key above the standard key
signature. It now uses actual sharp and flat signs in the key names ("Fb"
rather than "Fes"), and the text is smaller.
It should work fine with \include "english.ly" or \language english, but I have
not tried it. You can edit the names of the keys by changing the relevant text
in the following parts of the code. For example change:
#{ \markup \magnify #0.7 {B Major} #
#{ \markup \magnify #0.7 {G\raise #.6 {\sharp} Minor} #
to
#{ \markup \magnify #0.7 {B M} #
#{ \markup \magnify #0.7 {G\raise #.6 {\sharp} m} #
for an abbreviated text ("B M" and "G# m" instead of "B Major" and "G Minor").
I think this has reached the "potentially useful" stage, for anyone who is
still learning the key signatures or wants to know explicitly whether keys are
major or minor.
(Ideally it would be better if it did not print the name of the key signature
above a key cancellation, as with the transition from A# Minor to F Major in
the code below. I would have to figure out how to somehow access whether it
was engraving a key-cancellation or a key-signature.)
Any suggestions for improvement are welcome. I am an amateur hack at this and
stand on the shoulders of giant snippets. :-)
(Like this one http://lsr.dsi.unimi.it/LSR/Item?id=233 for this most recent
version).
Cheers,
-Paul
%% Begin snippet
\version "2.16.0"
#(define Custom_key_sig_engraver
(make-engraver
(acknowledgers
((key-signature-interface engraver grob source-engraver)
(let* (
(context (ly:translator-context engraver))
(tonic-pitch (ly:context-property context 'tonic))
(tonic-semi (modulo (ly:pitch-semitones tonic-pitch)
12))
(acclist (ly:grob-property grob 'alteration-alist))
(accsign (if (null? acclist) 0 (cdr (list-ref
acclist 0
(psn (if (null? acclist) 0 (car (list-ref
acclist 0
(sig-stencil (ly:key-signature-interface::print
grob))
)
(cond
((= accsign 0)
(if (= tonic-semi 0)
(ly:grob-set-property! grob
'stencil
(ly:stencil-combine-at-edge sig-stencil 1 1
(grob-interpret-markup grob #{ \markup \raise #2.3 \magnify #0.7 {C Major} #})
.5 ))
(ly:grob-set-property! grob
'stencil
(ly:stencil-combine-at-edge sig-stencil 1 1
(grob-interpret-markup grob #{ \markup \raise #2.3 \magnify #0.7 {A Minor} #})
.5 ))
))
((= accsign 1/2);; SHARP KEYS
(cond
((= psn 3)
(if (= tonic-semi 7)
(ly:grob-set-property! grob
'stencil
(ly:stencil-combine-at-edge sig-stencil 1 1
(grob-interpret-markup grob #{ \markup \magnify #0.7 {G Major} #}) .5 ))
(ly:grob-set-property! grob
'stencil
(ly:stencil-combine-at-edge sig-stencil 1 1
(grob-interpret-markup grob #{ \markup \magnify #0.7 {E Minor} #}) .5 ))
))
((= psn 0)
(if (= tonic-semi 2)
(ly:grob-set-property! grob
'stencil
(ly:stencil-combine-at-edge sig-stencil 1 1
Re: Custom key signature stencils, differentiating major and minor keys
Ok, I figured out a way to differentiate between major and minor keys. I
followed the example of this snippet which shows how to access the tonic note
of the current key:
http://lsr.dsi.unimi.it/LSR/Item?id=818
By combining the tonic note with the type and position of the right-most
accidental sign in the key signature, I could determine both the current key
and whether it was major or minor. (I guess I should allow for other modes as
well, hmmm...)
See the code below which also now handles C Major / A Minor, and (for now)
replaces the key signature stencil with the name of the key, as described here:
http://lilypond.org/doc/v2.16/Documentation/notation/modifying-stencils
A variation on this could come in handy if you wanted to automatically print
the textual name of the key above the key signature.
Any advice or comments welcome. There are probably ways to improve this or do
it better.
Cheers,
-Paul
%%% Begin snippet
\version "2.16.0"
#(define Custom_key_sig_engraver
(make-engraver
(acknowledgers
((key-signature-interface engraver grob source-engraver)
(let* (
(context (ly:translator-context engraver))
(tonic-pitch (ly:context-property context 'tonic))
(tonic-semi (modulo (ly:pitch-semitones tonic-pitch) 12))
(acclist (ly:grob-property grob 'alteration-alist))
(accsign (if (null? acclist) 0 (cdr (list-ref acclist 0
(psn (if (null? acclist) 0 (car (list-ref acclist
0
)
(cond
((= accsign 0)
(if (= tonic-semi 0)
(ly:grob-set-property! grob
'text #{ \markup {C Major} #}) ;; C Major
(ly:grob-set-property! grob
'text #{ \markup {A Minor} #}) ;; A Minor
))
((= accsign 1/2);; SHARP KEYS
(cond
((= psn 3)
(if (= tonic-semi 7)
(ly:grob-set-property! grob
'text #{ \markup {G Major} #}) ;; G Major
(ly:grob-set-property! grob
'text #{ \markup {E Minor} #}) ;; E Minor
))
((= psn 0)
(if (= tonic-semi 2)
(ly:grob-set-property! grob
'text #{ \markup {D Major} #}) ;; D Major
(ly:grob-set-property! grob
'text #{ \markup {B Minor} #}) ;; B Minor
))
((= psn 4)
(if (= tonic-semi 9)
(ly:grob-set-property! grob
'text #{ \markup {A Major} #}) ;; A Major
(ly:grob-set-property! grob
'text #{ \markup {Fis Minor} #}) ;; Fis Minor
))
((= psn 1)
(if (= tonic-semi 4)
(ly:grob-set-property! grob
'text #{ \markup {E Major} #}) ;; E Major
(ly:grob-set-property! grob
'text #{ \markup {Cis Minor} #}) ;; Cis Minor
))
((= psn 5)
(if (= tonic-semi 11)
(ly:grob-set-property! grob
'text #{ \markup {B Major} #}) ;; B Major
(ly:grob-set-property! grob
'text #{ \markup {Gis Minor} #}) ;; Gis Minor
))
((= psn 2)
(if (= tonic-semi 6)
(ly:grob-set-property! grob
'text #{ \markup {Fis Major} #}) ;; Fis Major
(ly:grob-set-property! grob
'text #{ \markup {Dis Minor} #}) ;; Dis Minor
))
((= psn 6)
(if (= tonic-semi 1)
(ly:grob-set-property! grob
'text #{ \markup {Cis Major} #}) ;; Cis Major
(ly:grob-set-property! grob
'text #{ \markup {Ais Minor} #}) ;; Ais Minor
))
)
)
((= accsign -1/2) ;; FLAT KEYS
(cond
((= psn 6)
(if (= tonic-semi
Custom key signature stencils, differentiating major and minor keys
Greetings everyone,
I am trying to override the key signature stencil with a custom stencil whose
appearance and position will depend on the key. So far I can determine the key
by looking at the "alteration-alist" property of the key-signature-interface
[1] with the KeySignature grob [2]. Basically, looking at the type and
position of the accidental sign that is furthest to the right in the key
signature, will tell you which key it is. (See snippet below.)
With the custom stencils I would like to indicate whether a key is major or
minor, and also indicate the tonic note of the key (which can't be determined
unless you know whether the key signature is major or minor). So my question
is whether it is possible to tell whether a given key is major or minor based
on the KeySignature grob (for example, C major vs A minor).
Since standard key signatures do not indicate whether a key is major or minor,
I realize that this may not be possible.
>From what I can tell, none of the KeySignature grob properties indicate
>whether the key is major or minor.
I noticed that the Key_engraver [3] has a tonic property (a pitch value that is
the "tonic of the current scale") which seems like it might help, but if so,
I'm not sure how to go about using it for this.
I searched the LSR and the user list archives but did not find anything on this
particular topic.
Thanks in advance for any help or advice on this!
-Paul
[1]
http://lilypond.org/doc/v2.16/Documentation/internals/key_002dsignature_002dinterface
[2] http://lilypond.org/doc/v2.16/Documentation/internals/keysignature
[3] http://lilypond.org/doc/v2.16/Documentation/internals/key_005fengraver
%% Begin Snippet
%% Still very much a work in progress.
%% Currently it breaks with the keys of C major and A minor
%% (since the alteration-alist is empty for those keys).
%% Eventually different stencils and/or vertical positions would be defined
%% for each key, "someStencil" is just a placeholder
\version "2.16.0"
someStencil = #(make-circle-stencil .5 .25 #f)
someOtherStencil = #(make-circle-stencil .5 .25 #t)
keysigger =
#(lambda (grob)
(let* (
(accsign (cdr (list-ref (ly:grob-property grob
'alteration-alist) 0)))
(pstn (car (list-ref (ly:grob-property grob
'alteration-alist) 0)))
)
(cond
((= accsign 1/2);; SHARP KEYS
(cond
((= pstn 6) someStencil)
((= pstn 2) someOtherStencil)
((= pstn 5) someStencil)
((= pstn 1) someOtherStencil)
((= pstn 4) someStencil)
((= pstn 0) someOtherStencil)
((= pstn 3) someStencil)
)
)
((= accsign -1/2) ;; FLAT KEYS
(cond
((= pstn 3) someOtherStencil)
((= pstn 0) someStencil)
((= pstn 4) someOtherStencil)
((= pstn 1) someStencil)
((= pstn 5) someOtherStencil)
((= pstn 2) someStencil)
((= pstn 6) someOtherStencil)
)
)
(else someStencil) ;; C MAJOR, A MINOR
))
)
%% Sharp Keys
<<
\new Staff \with { \override KeySignature #'stencil = #keysigger }
{
\key g \major
c'4
}
\new Staff \with { \override KeySignature #'stencil = #keysigger }
{
\key d \major
c'4
}
\new Staff \with { \override KeySignature #'stencil = #keysigger }
{
\key a \major
c'4
}
\new Staff \with { \override KeySignature #'stencil = #keysigger }
{
\key e \major
c'4
}
\new Staff \with { \override KeySignature #'stencil = #keysigger }
{
\key b \major
c'4
}
\new Staff \with { \override KeySignature #'stencil = #keysigger }
{
\key fis \major
c'4
}
\new Staff \with { \override KeySignature #'stencil = #keysigger }
{
\key cis \major
c'4
}
>>
%% Flat Keys
<<
\new Staff \with { \override KeySignature #'stencil = #keysigger }
{
\key f \major
c'4
}
\new Staff \with { \override KeySignature #'stencil = #keysigger }
{
\key bes \major
c'4
}
\new Staff \with { \override KeySignature #'stencil = #keysigger }
{
\key ees \major
c'4
}
\new Staff \with { \override KeySignature #'stencil = #keysigger }
{
\key aes \major
c'4
}
\new Staff \with { \override KeySignature #'stencil = #keysigger }
{
\key des \major
c'4
}
\new Staff \with { \override KeySignature #'stencil = #keysigger }
{
\key ges \major
c'4
}
\new Staff \with { \override KeySignature #'stencil = #keysigger }
{
\key ces \major
c'4
}
>>
___
lilypond-use
Adventures in defining custom Staff contexts
Hi all, I was tempted by this page to try to create my own custom Staff
context:
http://lilypond.org/doc/v2.16/Documentation/notation/defining-new-contexts
I currently use a number of overrides in the Staff \with block, so was hoping
this would be a more elegant way of achieving that (because it could go in an
\include file).
After trying various things I think I have it working, but I thought I'd share
what I found in case it might help future travelers on this path, and because
the solution I came up with is different from the one on the documentation page
above, and I didn't find it in the LSR.
First I followed the page from the documentation listed above. I included all
of the engravers that a standard Staff uses, to duplicate a staff, to which I
could add my overrides:
Begin 1st Approach
\version "2.16.0"
\layout {
\context {
\name CustomStaff
\type "Engraver_group"
\consists "Accidental_engraver"
\consists "Axis_group_engraver"
\consists "Bar_engraver"
\consists "Clef_engraver"
\consists "Collision_engraver"
\consists "Cue_clef_engraver"
\consists "Dot_column_engraver"
\consists "Figured_bass_engraver"
\consists "Figured_bass_position_engraver"
\consists "Font_size_engraver"
\consists "Footnote_engraver"
\consists "Grob_pq_engraver"
\consists "Instrument_name_engraver"
\consists "Key_engraver"
\consists "Ledger_line_engraver"
\consists "Ottava_spanner_engraver"
\consists "Output_property_engraver"
\consists "Piano_pedal_align_engraver"
\consists "Piano_pedal_engraver"
\consists "Pure_from_neighbor_engraver"
\consists "Rest_collision_engraver"
\consists "Script_row_engraver"
\consists "Separating_line_group_engraver"
\consists "Staff_collecting_engraver"
\consists "Staff_symbol_engraver"
\consists "Time_signature_engraver"
\override StaffSymbol #'line-positions = #'( 4 0 -4 )
\alias Staff
}
\context {
\Score
% Must be capital "S" \Score. Little "s" \score breaks things.
% This was not apparent from that documentation page
% since it uses Voice as its example
\accepts CustomStaff
% Was unclear whether "CustomStaff" needed to be in quotes or
not.
% But maybe it does not matter...
% The documentation page actually shows it both ways (!)
}
}
melody = \relative c' {
c4 d e f g a b
}
\score {
\new CustomStaff {
\melody
}
\layout { }
\midi { }
% including this midi part leads to a warning that it cannot find
"CustomStaff"
%
}
End 1st Approach
After some fiddling (see comments in the snippet above) I got this to run and
for my override to show up in the new custom staff, but I could not get any
noteheads to appear, and I don't know why that is.
Then I tried searching the LSR and user list and found this post:
http://lists.gnu.org/archive/html/lilypond-user/2010-05/msg2.html
Which suggested the following approach instead:
Begin 2nd Approach
\version "2.16.0"
\layout {
\context {
\Staff
\name CustomStaff
\alias Staff
\override StaffSymbol #'line-positions = #'( 4 0 -4 )
}
\context {
\Score
\accepts CustomStaff
}
\context {
\ChoirStaff
\accepts CustomStaff
}
\context {
\GrandStaff
\accepts CustomStaff
}
\context {
\PianoStaff
\accepts CustomStaff
}
\context {
\StaffGroup
\accepts CustomStaff
}
}
melody = \relative c' {
\clef treble
\key c \major
\time 4/4
c4 d e f g a b
}
\score {
\new CustomStaff {
\melody
}
\layout { }
\midi { }
}
End 2nd Approach
This appears to work. (...after I remembered to put "\alias Staff" in.)
But is there anything I'm missing? Is this a good way to go, or would I be
better off sticking to my \with blocks and \overrides applied to the standard
Staff context? Is there a reason it is not covered in the documentation?
If this is a good and legitimate approach, it might be nice to include it on
that documentation page, along with the custom Voice-type context definition
that's already there -- even as just a snippet or extra example. I'm happy to
add it to the LSR in any case.
Cheers,
-Paul
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Changing staff size with custom note head stencils
On Nov 2, 2012, at 4:45 PM, David Kastrup wrote: > Paul Morris writes: > >> On Oct 31, 2012, at 7:11 PM, Paul Morris wrote: >> >> That worked to avoid the error, but didn't seem quite right (since it >> didn't seem to matter what values you fed it). So I checked the >> LilyPond source code (scm/output-ps.scm), and it seems like this is >> the better way to do it: >> >> upTriangle = >> #(ly:make-stencil >>'(path 0.09 >>'(moveto -.1875 -.5 > this quote seems spurious. Thanks David, I tried removing it, but I got the following error: In expression (moveto -0.1875 -0.5 ...) [...] Unbound variable: moveto -Paul >> lineto .65625 .5 >> lineto 1.5 -.5 >> closepath >> ) >>'round >>'round >>#t >>) >>(cons -.1875 1.5) >>(cons -.5 .5) >> ) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Changing staff size with custom note head stencils
On Oct 31, 2012, at 7:11 PM, Paul Morris wrote:
> On Mike's suggestion I also switched to using internal path stencils instead
> of embedded PS. The only problem I ran into was using "fill" to get a filled
> triangle. I used:
>
> upTriangle =
> #(ly:make-stencil
> '(path 0.09
> '(moveto -.1875 -.5
> lineto .65625 .5
> lineto 1.5 -.5
> closepath
> fill ()
> )
> )
> (cons -.1875 1.5)
> (cons -.5 .5)
> )
>
> When I typeset my file the visual output is correct (filled triangles), but I
> get either an "Unsupported SCM value for format" error for each of those
> notes. (Or if I omit the "()" after "fill" then the rendering fails with
> "Wrong type argument in position 1 (expecting pair): ()"). I did not find
> much documentation for "path", only a snippet that doesn't use "fill" [1].
So I figured out that "fill" above just wanted a pair of values in the right
format (no parentheses) like this:
fill 0 . 0
That worked to avoid the error, but didn't seem quite right (since it didn't
seem to matter what values you fed it). So I checked the LilyPond source code
(scm/output-ps.scm), and it seems like this is the better way to do it:
upTriangle =
#(ly:make-stencil
'(path 0.09
'(moveto -.1875 -.5
lineto .65625 .5
lineto 1.5 -.5
closepath
)
'round
'round
#t
)
(cons -.1875 1.5)
(cons -.5 .5)
)
The #t sets fill to true. Presto and voila: filled triangle stencils without
embedded postscript. ('round and 'round are just default settings for how the
caps of lines are drawn and how lines are joined.)
Let me know if I'm missing something, and thanks again for the help. I will
see about adding it to the LSR when I get a chance.
-Paul
PS. I wasn't able to get the "make-connected-path-stencil" approach to work,
but now that the above is working I'm good to go.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Changing staff size with custom note head stencils
On Oct 31, 2012, at 4:52 PM, Thomas Morley wrote: > Hi Paul, > > postscript is scaled with global-staff-size only. > > To work around you could use: > > TwinNoteNoteHeads = > #(lambda (grob) > (let* ((sz (ly:grob-property grob 'font-size 0.0)) > (mult (magstep sz))) > (set! (ly:grob-property grob 'stencil) (ly:stencil-scale > (stencil-notehead grob) mult mult)) > (set! (ly:grob-property grob 'stem-attachment) (stem-adjuster grob > Hi Harm and Mike, Thank you both for your help! Harm's work around does the trick nicely! On Mike's suggestion I also switched to using internal path stencils instead of embedded PS. The only problem I ran into was using "fill" to get a filled triangle. I used: upTriangle = #(ly:make-stencil '(path 0.09 '(moveto -.1875 -.5 lineto .65625 .5 lineto 1.5 -.5 closepath fill () ) ) (cons -.1875 1.5) (cons -.5 .5) ) When I typeset my file the visual output is correct (filled triangles), but I get either an "Unsupported SCM value for format" error for each of those notes. (Or if I omit the "()" after "fill" then the rendering fails with "Wrong type argument in position 1 (expecting pair): ()"). I did not find much documentation for "path", only a snippet that doesn't use "fill" [1]. Does anyone know the value that is needed for "fill" to avoid this error? Thanks again, it will be great to be able to resize staves! -Paul [1] http://lsr.dsi.unimi.it/LSR/Item?id=623 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Changing staff size with custom note head stencils
Hello, I'm trying to increase the overall size of a given staff, as described
in the docs[1] using:
\new Staff \with {
fontSize = #2
\override StaffSymbol #'staff-space = #(magstep 2)
\override NoteHead #'before-line-breaking = \TwinNoteNoteHeads
}
But I'm also using custom note head shapes, with an override that references a
scheme function that alters the NoteHead stencil and stem-attachment
properties.
That is preventing the resizing of the note heads. They just stay the same as
the rest of the staff, stems, clefs, etc, become larger. (This may be related
to using "before-line-breaking", but I need to use that to get the horizontal
spacing to work properly.[2] )
I have tried various things (including putting the size adjustments in the
\layout block [3]) and the only thing I've found that will change the size of
the noteheads is using set-global-staff-size [3]. But that also increases the
size of all the text (lyrics, chord names, titles, etc), when I just want to
increase the size of the staff, not the text.
Anyone know how to get this to work? Any advice or pointers would be greatly
appreciated. I realize that this is non-standard stuff, but LilyPond has been
amazing at handling whatever I've thrown at it, making it possible to
experiment. A simplified version of my code is below.
Thanks!
-Paul
[1] http://www.lilypond.org/doc/v2.15/Documentation/learning/size-of-objects
[2] http://lists.gnu.org/archive/html/lilypond-user/2012-04/msg00145.html
[3]
http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Setting-the-staff-size
\version "2.16.0"
Begin TwinNote scripts
Customize note head stencils based on pitch
upTriangle =
#(ly:make-stencil
(list 'embedded-ps
"gsave
currentpoint translate
newpath
-.1875 -.5 moveto
.65625 .5 lineto
1.5 -.5 lineto
closepath
fill
grestore" )
(cons -.1875 1.5)
(cons -.5 .5)
)
downTriangle =
#(ly:make-stencil
(list 'embedded-ps
"gsave
currentpoint translate
newpath
.08 .34 moveto
.65625 -.4 lineto
1.2325 .34 lineto
closepath
0.12 setlinewidth
stroke
newpath
-.0775 .43 moveto
.65625 -.43 lineto
1.39 .43 lineto
closepath
0.1 setlinewidth
stroke
newpath
-.1675 .48 moveto
.65625 -.48 lineto
1.48 .48 lineto
closepath
0.04 setlinewidth
stroke
grestore" )
(cons -.1875 1.5)
(cons -.5 .5)
)
%Based on the semitone, assign correct note head
#(define (semitone-to-stencil semitone)
(if (= (remainder semitone 2) 0) downTriangle upTriangle)
)
%Get the pitch in semitones from the note head grob
#(define (stencil-notehead grob)
(semitone-to-stencil
(ly:pitch-semitones (ly:event-property (event-cause grob) 'pitch))
)
)
Attach stems to note heads correctly
%Stem attachment values as variables
upTriUpStem = #'(1 . -1)
upTridownStem = #'(1 . .9)
downTriUpStem = #'(1 . .9)
downTriDownStem = #'(1 . -1)
%Based on pitch (odd or even), is the note head an up or down triangle,
%Then based on stem direction, assign stem attachment values
#(define (pitch-to-stem pitch stemdir)
(if (= (remainder (absolute-value (ly:pitch-semitones pitch) ) 2) 1)
(if (= UP stemdir) upTriUpStem upTridownStem) (if (=
DOWN stemdir) downTriDownStem downTriUpStem)
)
)
%Get absolute value
#(define (absolute-value x) (if (> x 0) x (- 0 x)))
%Get the stem from notehead grob
#(define (notehead-get-notecolumn nhgrob)
(ly:grob-parent nhgrob X))
#(define (notehead-get-stem nhgrob)
(let ((notecolumn (notehead-get-notecolumn nhgrob)))
(ly:grob-object notecolumn 'stem)))
%Get the pitch and stem direction from the grob
#(define (stem-adjuster nhgrob)
(pitch-to-stem
(ly:event-property (event-cause nhgrob) 'pitch)
(ly:grob-property (notehead-get-stem nhgrob) 'direction) ))
Begin notehead shape and stem attachment tweaks
TwinNoteNoteHeads =
#(lambda (grob)
(set! (ly:grob-property grob 'stencil) (stencil-notehead grob))
(set! (ly:grob-property grob 'stem-attachment) (stem-adjuster grob))
)
Place pitches on the staff
TwinNotePitchLayout =
#(lambda (p) (floor (/ (+ (ly:pitch-semitones p) 1) 2)))
% End TwinNote scripts
melody = \relative c' {
a4 b c d e f g a
}
\score {
<<
\new Staff = "usual size staff" \with {
\override NoteHead #'before-line-breaking = \TwinNoteNoteHeads
staffLineLayoutFunction = \TwinNotePitchLayout
}
{ \melody }
\new Staff = "larger size staff" \with {
\override NoteHead #'before-line-breaking = \TwinNoteNoteHeads
staffLineLayoutFunction = \TwinNotePitchLayout
fontSize = #3
\override StaffSymbol #'staff-space = #(magstep 3)
}
Re: Moving notes in a chord to the opposite side of the stem?
Hi David,
David Nalesnik wrote:
Hi Paul,
On Mon, Apr 9, 2012 at 9:50 PM, Paul Morris <mailto:p...@paulwmorris.com>> wrote:
Thanks David and Nick! More below...
David Nalesnik wrote:
Hi Paul,
On Mon, Apr 9, 2012 at 4:47 PM, Nick Payne
mailto:nick.pa...@internode.on.net>> wrote:
On 10/04/12 06:56, Paul Morris wrote:
Thank you! This works, but unfortunately (like the Hydra's
heads) it introduces two other problems, one with horizontal
spacing collisions and one with ledger lines.
1. Because the spacing engine does not take into account
this low-level tweak, the tweaked notes sometimes collide
with bar/measure lines and sometimes with other adjacent
notes. Is there a way to use Scheme to also increase the
horizontal space given to the chord? (I am still a beginner
at Scheme.)
Can't help with the second problem, but for the first you
could add additional horizontal space to either the barline
or stem to increase their separation:
\version "2.15.36"
barspace = #(define-music-function (parser location extent)
(pair?) #{
\once \override Staff.BarLine #'extra-spacing-width = #extent
#})
stemspace = #(define-music-function (parser location extent)
(pair?) #{
\once \override Staff.Stem #'X-extent = #extent
#})
\relative c'' {
c2 c c c \barspace #'(0 . 2)
c c
\stemspace #'(-2 . 0) c c
}
___
lilypond-user mailing list
lilypond-user@gnu.org <mailto:lilypond-user@gnu.org>
https://lists.gnu.org/mailman/listinfo/lilypond-user
This seems to do the trick as far as horizontal spacing is concerned:
\version "2.15.36"
#(define ((shift offsets) grob)
(let ((note-heads (ly:grob-array->list (ly:grob-object grob
'note-heads
(map
(lambda (p q) (set! (ly:grob-property p 'X-offset) q))
note-heads offsets)))
displaceHeads =
#(define-music-function (parser location offsets) (list?)
#{
\once \override NoteColumn #'before-line-breaking = #(shift
offsets)
#}
)
{
\displaceHeads #'(0 1.2 0)
4
\displaceHeads #'(0 1.2 1.2)
}
Hope this helps!
-David
Actually, David's approach appears to fix both problems! Ledger
lines are extended and appear twice as wide, just like with other
chords that have notes on both sides of the stem. The horizontal
spacing seems to be working with standard noteheads. (Looks like
a good candidate for the LSR.)
Unfortunately a function I'm using to substitute custom stencils
for NoteHead grobs seems to disrupt the horizontal spacing in some
instances (particularly noticeable with bar lines). I haven't
figured out the pattern yet. But worst case, that's something I
can fix manually using the tweaks Nick suggested. Or maybe there
is a way to expand David's function to access the Stem from the
NoteColumn and automatically give it an X-offset too?
A stripped down version of my code is below, if anyone is
curious. It is still a bit long.
Again, thanks so much! I really appreciate it, as it would take
me forever to try and figure this stuff out on my own.
-Paul
\version "2.15.32"
%Begin TwinNote scripts
%Customizing note head stencils based on pitch
%Defining stencils
upTriangle =
#(ly:make-stencil
(list 'embedded-ps
"gsave
currentpoint translate
newpath
-.1875 -.5 moveto
.65625 .5 lineto
1.5 -.5 lineto
closepath
fill
grestore" )
(cons -.1875 1.5)
(cons -.5 .5)
)
downTriangle =
#(ly:make-stencil
(list 'embedded-ps
"gsave
currentpoint translate
newpath
.08 .34 moveto
.65625 -.4 lineto
1.2325 .34 lineto
closepath
0.12 setlinewidth
stroke
newpath
-.0775 .43 moveto
.65625 -.43 lineto
1.39 .43 lineto
closepath
0.1 setlinewidth
stroke
newpath
-.1675 .48 moveto
.65625 -.48 lineto
1.48 .48 lineto
closepath
0.04 setlinewidth
stroke
grestore" )
(cons -.1875 1.5)
(cons -.5 .5)
)
%Based on the pitch's semitone, which note head
#(define (semitone-to-stencil semitone)
(if (= (remainder semitone 2) 0) downTriangle upTriangle)
)
%Get the pitch from the gro
