Re:Glissandos
My daughter is arranging a simple song to be sung by primary school children in an eisteddfod in the next few weeks and I am trying to typeset her arrangement in LP (2.12.2 on WINDOWS XP). There are non lyric passages where vocal sounds are used to indicate city noises, forest noises and ocean noises. These are to be defined by pictorial impressions of the way the sound fluctuates together with attached words like "Vrmmm", "bbring bbring" etc on the song sheet submitted to the adjudicator before the performance and the song must presented with no deviation from that format. I have been using cross headed notes, arpeggios (with hidden notes), zigzag glissandos (also with hidden notes) etc to show these effects. However, I have struck a few problems. 1) I would like to be able to vary the width and lengthy of the zigzag on glissandos to better indicate the variation in pitch to be obtained. 2) Where noises vary from low pitch to high pitch and back down again, I have been using a series of connected glissandos (hidden notes) but there are gaps where the hidden notes are missing. I have attempted to close these gaps by adding to the length of the individual glissandos by changing the appropriate bound-details. This does lengthen the glissandos appropriately but also raises their angle from the horizontal so that the missing note space remains but at a higher pitch. I tried to avoid this by using the same function but using X instead of Y e.g. #'(bound-details right X). This did not work but showed no error in the log and did not show the glissando at all in any shape. I realize I am completely ignorant when it comes to modifying the behaviour of LP objects and rely on what I am able to read that someone else has devised. Does anyone in the LP community have any practical advice on either or both of these problems (not just read the manuals) or can they suggest other symbols that already exist where these changes would not be required. Thanks for your interest. Ossie Wilson ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Glissandos
If you please send some example code of what you tried, it's much easier for us on the mailing list to provide relevant answers to your questions. (Don't forget to press "Reply All", so that the followup is sent to the mailing list when you do that) /Mats Ossie Wilson Snr wrote: My daughter is arranging a simple song to be sung by primary school children in an eisteddfod in the next few weeks and I am trying to typeset her arrangement in LP (2.12.2 on WINDOWS XP). There are non lyric passages where vocal sounds are used to indicate city noises, forest noises and ocean noises. These are to be defined by pictorial impressions of the way the sound fluctuates together with attached words like “Vrmmm”, “bbring bbring” etc on the song sheet submitted to the adjudicator before the performance and the song must presented with no deviation from that format. I have been using cross headed notes, arpeggios (with hidden notes), zigzag glissandos (also with hidden notes) etc to show these effects. However, I have struck a few problems. 1) I would like to be able to vary the width and lengthy of the zigzag on glissandos to better indicate the variation in pitch to be obtained. 2) Where noises vary from low pitch to high pitch and back down again, I have been using a series of connected glissandos (hidden notes) but there are gaps where the hidden notes are missing. I have attempted to close these gaps by adding to the length of the individual glissandos by changing the appropriate bound-details. This does lengthen the glissandos appropriately but also raises their angle from the horizontal so that the missing note space remains but at a higher pitch. I tried to avoid this by using the same function but using X instead of Y e.g. #’(bound-details right X). This did not work but showed no error in the log and did not show the glissando at all in any shape. I realize I am completely ignorant when it comes to modifying the behaviour of LP objects and rely on what I am able to read that someone else has devised. Does anyone in the LP community have any practical advice on either or both of these problems (not just read the manuals) or can they suggest other symbols that already exist where these changes would not be required. Thanks for your interest. Ossie Wilson ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- = Mats Bengtsson Signal Processing School of Electrical Engineering Royal Institute of Technology (KTH) SE-100 44 STOCKHOLM Sweden Phone: (+46) 8 790 8463 Fax: (+46) 8 790 7260 Email: mats.bengts...@ee.kth.se WWW: http://www.s3.kth.se/~mabe = ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Website "easier editing"
Hi all, Colin Campbell has been working with me on the Introduction of the new website. However, we're still debating what to do with the "Easier editing" page: http://lilypond.org/website/easier-editing.html In particular, should we: 1) list all programs that help or produce lilypond input code on this page, or 2) only list a few programs here and list the rest elsewhere? (probably somewhere in Usage, with a link from this page to that location) When he began working, he had one opinion and I had the other. But over the past four months, we've switched positions like a finely-honed comedy act -- we still disagree, but we've both taken up the other person's initial position. The argument for #1: we have a unified place for people to look; it's easier to update; it's easier to find; etc. The argument for #2: it doesn't make sense to have algorithmic programming environments like Strasheela and FOMUS in the same list as Denemo, Frescobaldi, and LilyPondTool; having the extra options will only confused newbies; if we keep 4 or 5 "highlighted" programs in this list and move the rest somewhere else, it won't be much harder to maintain the list; etc. I'm not particularly looking for votes on this issue -- rather, I'm looking for reasons for (or against) #1 and #2 that we haven't thought of. It would be great if somebody said "we should do #x because XYZ" and then have us go "of course! XYZ! That makes everything totally clear; we all agree due to XYZ." If you have other concerns about the website, please don't mention them here. I'll be posting other questions once this issue is resolved. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Website "easier editing"
A somewhat pragmatic approach would be to use a single page suitably subdivided if no scrolling is involved. Else use a two page solution. The fewer pages a user has to link to the faster that person finds what they are looking for. --hsm On Fri, May 7, 2010 at 8:13 AM, Graham Percival wrote: > Hi all, > > Colin Campbell has been working with me on the Introduction of the > new website. However, we're still debating what to do with the > "Easier editing" page: > http://lilypond.org/website/easier-editing.html > > In particular, should we: > 1) list all programs that help or produce lilypond input code on > this page, or > > 2) only list a few programs here and list the rest elsewhere? > (probably somewhere in Usage, with a link from this page > to that location) > > When he began working, he had one opinion and I had the other. > But over the past four months, we've switched positions like a > finely-honed comedy act -- we still disagree, but we've both taken > up the other person's initial position. > > The argument for #1: we have a unified place for people to look; > it's easier to update; it's easier to find; etc. > > The argument for #2: it doesn't make sense to have algorithmic > programming environments like Strasheela and FOMUS in the same > list as Denemo, Frescobaldi, and LilyPondTool; having the extra > options will only confused newbies; if we keep 4 or 5 > "highlighted" programs in this list and move the rest somewhere > else, it won't be much harder to maintain the list; etc. > > > I'm not particularly looking for votes on this issue -- rather, > I'm looking for reasons for (or against) #1 and #2 that we haven't > thought of. It would be great if somebody said "we should do #x > because XYZ" and then have us go "of course! XYZ! That makes > everything totally clear; we all agree due to XYZ." > > > If you have other concerns about the website, please don't mention > them here. I'll be posting other questions once this issue is > resolved. > > Cheers, > - Graham > > > ___ > lilypond-user mailing list > lilypond-user@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-user > ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Website "easier editing"
Yeah, that's right. One page is better. But the order is important. Also describing how "easy" or "difficult" a method is. On 7 May 2010 11:59, Hugh Myers wrote: > A somewhat pragmatic approach would be to use a single page suitably > subdivided if no scrolling is involved. Else use a two page solution. > The fewer pages a user has to link to the faster that person finds > what they are looking for. > > --hsm > > > On Fri, May 7, 2010 at 8:13 AM, Graham Percival > wrote: >> Hi all, >> >> Colin Campbell has been working with me on the Introduction of the >> new website. However, we're still debating what to do with the >> "Easier editing" page: >> http://lilypond.org/website/easier-editing.html >> >> In particular, should we: >> 1) list all programs that help or produce lilypond input code on >> this page, or >> >> 2) only list a few programs here and list the rest elsewhere? >> (probably somewhere in Usage, with a link from this page >> to that location) >> >> When he began working, he had one opinion and I had the other. >> But over the past four months, we've switched positions like a >> finely-honed comedy act -- we still disagree, but we've both taken >> up the other person's initial position. >> >> The argument for #1: we have a unified place for people to look; >> it's easier to update; it's easier to find; etc. >> >> The argument for #2: it doesn't make sense to have algorithmic >> programming environments like Strasheela and FOMUS in the same >> list as Denemo, Frescobaldi, and LilyPondTool; having the extra >> options will only confused newbies; if we keep 4 or 5 >> "highlighted" programs in this list and move the rest somewhere >> else, it won't be much harder to maintain the list; etc. >> >> >> I'm not particularly looking for votes on this issue -- rather, >> I'm looking for reasons for (or against) #1 and #2 that we haven't >> thought of. It would be great if somebody said "we should do #x >> because XYZ" and then have us go "of course! XYZ! That makes >> everything totally clear; we all agree due to XYZ." >> >> >> If you have other concerns about the website, please don't mention >> them here. I'll be posting other questions once this issue is >> resolved. >> >> Cheers, >> - Graham >> >> >> ___ >> lilypond-user mailing list >> lilypond-user@gnu.org >> http://lists.gnu.org/mailman/listinfo/lilypond-user >> > > > ___ > lilypond-user mailing list > lilypond-user@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-user > ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Website "easier editing"
For a user inexperienced new Lilypond user in programming (deal with text and editors) I think he/she should make contact as fast as possible with something like LilyPondTool. In this respect I think this way should be as easy as possible for this type of new user. Later he/she can choose a different method, but it's not likely that he/she will stick with Lilypond if things become to uncommon in a first moment. It's nice because it facilitate some common troubles for new-users and it run on all platforms. I'm not saying it's the "best" editor, but it's the best one for a first experience with Lilypond, in my opinion. I like Emacs, I'm waiting to see more functionalities in Emacs/lilypond-mode (maybe someone is doing extensions to lilypond-mode right now???), but JEdit/Lilypond is running faster, I think. On 7 May 2010 11:13, Graham Percival wrote: > The argument for #2: it doesn't make sense to have algorithmic > programming environments like Strasheela and FOMUS in the same > list as Denemo, Frescobaldi, and LilyPondTool; having the extra > options will only confused newbies; if we keep 4 or 5 > "highlighted" programs in this list and move the rest somewhere > else, it won't be much harder to maintain the list; etc. > > > I'm not particularly looking for votes on this issue -- rather, > I'm looking for reasons for (or against) #1 and #2 that we haven't > thought of. It would be great if somebody said "we should do #x > because XYZ" and then have us go "of course! XYZ! That makes > everything totally clear; we all agree due to XYZ." > ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Website "easier editing"
One solution would be ask if the new user have experience in this respect? So it will be redirect to one of two different pages: one for each case. On 7 May 2010 12:18, Bernardo Barros wrote: > For a user inexperienced new Lilypond user in programming (deal with > text and editors) I think he/she should make contact as fast as > possible with something like LilyPondTool. In this respect I think > this way should be as easy as possible for this type of new user. > Later he/she can choose a different method, but it's not likely that > he/she will stick with Lilypond if things become to uncommon in a > first moment. It's nice because it facilitate some common troubles for > new-users and it run on all platforms. I'm not saying it's the "best" > editor, but it's the best one for a first experience with Lilypond, in > my opinion. I like Emacs, I'm waiting to see more functionalities in > Emacs/lilypond-mode (maybe someone is doing extensions to > lilypond-mode right now???), but JEdit/Lilypond is running faster, I > think. > > On 7 May 2010 11:13, Graham Percival wrote: >> The argument for #2: it doesn't make sense to have algorithmic >> programming environments like Strasheela and FOMUS in the same >> list as Denemo, Frescobaldi, and LilyPondTool; having the extra >> options will only confused newbies; if we keep 4 or 5 >> "highlighted" programs in this list and move the rest somewhere >> else, it won't be much harder to maintain the list; etc. >> >> >> I'm not particularly looking for votes on this issue -- rather, >> I'm looking for reasons for (or against) #1 and #2 that we haven't >> thought of. It would be great if somebody said "we should do #x >> because XYZ" and then have us go "of course! XYZ! That makes >> everything totally clear; we all agree due to XYZ." >> > ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Website "easier editing"
How about a HTML table: Row per tool, significant attributes per column? Attributes would include things like "GUI", "TEXT MODE", "TOOL MATURITY", "FEATURES", and a link to a fuller description and additional link in the description to where to get the tool. Descriptions include constraints, equipment requirements, etc. The value of the page itself to the user depends much on the search sophistication of the user. Some will like one approach, some another. If the summary page can convey enough info to be useful without scrolling, fine, but that shouldn't be a major consideration. If the user prefers a graphical tool, for instance, (s)he won't be discouraged by a bit of scrolling! Joe On 05/07/2010 10:13 AM, Graham Percival wrote: > Hi all, > > Colin Campbell has been working with me on the Introduction of the > new website. However, we're still debating what to do with the > "Easier editing" page: > http://lilypond.org/website/easier-editing.html > > In particular, should we: > 1) list all programs that help or produce lilypond input code on > this page, or > > 2) only list a few programs here and list the rest elsewhere? > (probably somewhere in Usage, with a link from this page > to that location) > > When he began working, he had one opinion and I had the other. > But over the past four months, we've switched positions like a > finely-honed comedy act -- we still disagree, but we've both taken > up the other person's initial position. > > The argument for #1: we have a unified place for people to look; > it's easier to update; it's easier to find; etc. > > The argument for #2: it doesn't make sense to have algorithmic > programming environments like Strasheela and FOMUS in the same > list as Denemo, Frescobaldi, and LilyPondTool; having the extra > options will only confused newbies; if we keep 4 or 5 > "highlighted" programs in this list and move the rest somewhere > else, it won't be much harder to maintain the list; etc. > > > I'm not particularly looking for votes on this issue -- rather, > I'm looking for reasons for (or against) #1 and #2 that we haven't > thought of. It would be great if somebody said "we should do #x > because XYZ" and then have us go "of course! XYZ! That makes > everything totally clear; we all agree due to XYZ." > > > If you have other concerns about the website, please don't mention > them here. I'll be posting other questions once this issue is > resolved. > > Cheers, > - Graham > > > ___ > lilypond-user mailing list > lilypond-user@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-user > > ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Website "easier editing"
Anyway, if Fomus will be mentioned it is important to state there it *IS* being actively developed... josé Em 07/05/10 11:13, Graham Percival escreveu: Hi all, Colin Campbell has been working with me on the Introduction of the new website. However, we're still debating what to do with the "Easier editing" page: http://lilypond.org/website/easier-editing.html In particular, should we: 1) list all programs that help or produce lilypond input code on this page, or 2) only list a few programs here and list the rest elsewhere? (probably somewhere in Usage, with a link from this page to that location) When he began working, he had one opinion and I had the other. But over the past four months, we've switched positions like a finely-honed comedy act -- we still disagree, but we've both taken up the other person's initial position. The argument for #1: we have a unified place for people to look; it's easier to update; it's easier to find; etc. The argument for #2: it doesn't make sense to have algorithmic programming environments like Strasheela and FOMUS in the same list as Denemo, Frescobaldi, and LilyPondTool; having the extra options will only confused newbies; if we keep 4 or 5 "highlighted" programs in this list and move the rest somewhere else, it won't be much harder to maintain the list; etc. I'm not particularly looking for votes on this issue -- rather, I'm looking for reasons for (or against) #1 and #2 that we haven't thought of. It would be great if somebody said "we should do #x because XYZ" and then have us go "of course! XYZ! That makes everything totally clear; we all agree due to XYZ." If you have other concerns about the website, please don't mention them here. I'll be posting other questions once this issue is resolved. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- http://zepadovani.info ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond 12.2.2 doesn't do \header?
I did that and it didn't work, but then I used \bookpart as well it it worked smoothly again after a few ... lilypond crashes. -Eluze wrote: > > have a look at > http://lilypond.org/doc/v2.13/Documentation/notation-big-page#Titles-and-headers > http://lilypond.org/doc/v2.13/Documentation/notation-big-page#Titles-and-headers > > > there it says: If you define the \header inside the \score block, then > normally only the piece and opus headers will be printed. Note that the > music expression must come before the \header. > > hth > -- View this message in context: http://old.nabble.com/Lilypond-12.2.2-doesn%27t-do-%5Cheader--tp28475799p28490084.html Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re:Glissandos
>
> Message: 7
> Date: Fri, 7 May 2010 16:39:49 +1000
> From: "Ossie Wilson Snr"
> Subject: Re:Glissandos
> To:
> Message-ID: <000301caedb0$17578880$0202a...@grandpa>
> Content-Type: text/plain; charset="us-ascii"
>
> My daughter is arranging a simple song to be sung by primary school
children
> in an eisteddfod in the next few weeks and I am trying to typeset her
> arrangement in LP (2.12.2 on WINDOWS XP). There are non lyric passages
where
> vocal sounds are used to indicate city noises, forest noises and ocean
> noises. These are to be defined by pictorial impressions of the way the
> sound fluctuates together with attached words like "Vrmmm", "bbring
bbring"
> etc on the song sheet submitted to the adjudicator before the
performance
> and the song must presented with no deviation from that format.
>
>
>
> I have been using cross headed notes, arpeggios (with hidden notes),
zigzag
> glissandos (also with hidden notes) etc to show these effects. However,
I
> have struck a few problems.
>
>
>
> 1) I would like to be able to vary the width and
lengthy
> of the zigzag on glissandos to better indicate the variation in pitch to
be
> obtained.
>
> 2) Where noises vary from low pitch to high pitch and
back
> down again, I have been using a series of connected glissandos (hidden
> notes) but there are gaps where the hidden notes are missing. I have
> attempted to close these gaps by adding to the length of the individual
> glissandos by changing the appropriate bound-details. This does lengthen
the
> glissandos appropriately but also raises their angle from the horizontal
so
> that the missing note space remains but at a higher pitch. I tried to
avoid
> this by using the same function but using X instead of Y e.g.
> #'(bound-details right X). This did not work but showed no error in the
log
> and did not show the glissando at all in any shape. I realize I am
> completely ignorant when it comes to modifying the behaviour of LP
objects
> and rely on what I am able to read that someone else has devised.
>
> Does anyone in the LP community have any practical advice on either or
both
> of these problems (not just read the manuals) or can they suggest other
> symbols that already exist where these changes would not be required.
>
>
>
> Thanks for your interest.
>
>
>
> Ossie Wilson
Ossie,
Would something like this work?:
\version "2.13.16"
#(set-global-staff-size 24)
\header {
title = "Clusters snippet"
}
\layout { ragged-right = ##t
\context { \Voice \override ClusterSpanner #'minimum-Y-extent =
#'(-0.5 . 0.5)}
}
fragment = \relative c' {
\time 4/4
2 2 |
}
<< \new Staff \makeClusters \fragment
\new Staff \fragment
>>
-
(I tried to make the clusters thinner with no success. Maybe someone else
can say how to do that.
Or can you output lilypond to svg and add or fill in the glissandos you
want using Inkscape?
Tim Reeves
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Glissandos
2010/5/7 Ossie Wilson Snr :
>
> [...]
>
> I have been using cross headed notes, arpeggios (with hidden notes),
> zigzag glissandos (also with hidden notes) etc to show these effects.
> However, I have struck a few problems.
>
>
> 1) I would like to be able to vary the width and lengthy
> of the zigzag on glissandos to better indicate the variation in pitch to be
> obtained.
For the width use:
\override Glissando #'zigzag-width = #2 %% default: 0.75
For the length I would do it with hidden notes in parallel small value:
g2\glissando c %% normal
<< { g2\glissando c } %% bigger space -> longer glissando
\new Voice { \hideNotes \repeat unfold 8 g16 g2 \unHideNotes } >>
> 2) Where noises vary from low pitch to high pitch
> and back down again, I have been using a series of connected
> glissandos (hidden notes) but there are gaps where the hidden notes
> are missing. I have attempted to close these gaps by adding to the
> length of the individual glissandos by changing the appropriate
> bound-details. This does lengthen the glissandos appropriately but
> also raises their angle from the horizontal so that the missing note
> space remains but at a higher pitch. I tried to avoid this by using
> the same function but using X instead of Y e.g.
> #’(bound-details right X). This did not work but showed no error in
> the log and did not show the glissando at all in any shape.
> I realize I am completely ignorant when it comes to modifying the
> behaviour of LP objects and rely on what I am able to read that
> someone else has devised.
I am completely ignorant about that too.
But according to the doc (internals) the #'bound-details value should
be in the form:
#'((right (attach-dir . 0) (padding . 1.5)) (left (attach-dir . 0)
(padding . 1.5)))
Which code did you try actually?
Cheers,
Xavier
--
Xavier Scheuer
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
changes in lilypond-mode.el to process lytex?
Hi.. I have made some changes on my lilypond-mode.el (for emacs) to process .lytex files with the commands... lilypond-book --pdf yourfile.lytex pdflatex yourfile.tex I would like to know who maintains lilypond-mode and how can I help to add these commands to the sources? (I was having problems to use the default "Book" and "LaTeX" commando of lilypond-mode menu.) thanks josé -- http://zepadovani.info ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond 12.2.2 doesn't do \header?
searchfgold wrote:
>
> I did that and it didn't work, but then I used \bookpart as well it it
> worked smoothly again after a few ... lilypond crashes.
>
i have tried
\book {
\bookpart {
\score {
\new PianoStaff <<
\new Staff = "upper" <<
\new Voice { \upperVoiceRightHand }
\new Voice { \lowerVoiceRightHand }
>>
\new Staff = "lower" <<
\new Voice { \upperVoiceLeftHand }
\new Voice { \lowerVoiceLeftHand }
>>
>>
}
\header {
title = "___"
%composer = "Richie Gress"
copyright = "© 2010 Richie Gress"
%piece = "Ice Waltz"
subtitle = "I. Ice Waltz"
}
}
\bookpart {
\score {
\new PianoStaff <<
\new Staff = "upper2" <<
\new Voice { \upperVoiceRightHandb }
>>
\new Staff = "lower2" <<
\new Voice { \upperVoiceLeftHandb }
>>
>>
}
\header {
title = "___"
subtitle = "II. Folle Vecchia Insegnante Musica"
copyright = "© 2010 Richie Gress"
}
}
}
… and i got both the titles + subtitles (just a little complaint about
colliding notes…)
hope this is what you need!
--
View this message in context:
http://old.nabble.com/Lilypond-12.2.2-doesn%27t-do-%5Cheader--tp28475799p28491452.html
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: changes in lilypond-mode.el to process lytex?
2010/5/7 josé henrique padovani : > Hi.. > I have made some changes on my lilypond-mode.el (for emacs) to > process .lytex files with the commands... > > lilypond-book --pdf yourfile.lytex > pdflatex yourfile.tex > > I would like to know who maintains lilypond-mode and how can I help > to add these commands to the sources? > > (I was having problems to use the default "Book" and "LaTeX" commando > of lilypond-mode menu.) Hi, According to the AUTHORS page http://lilypond.org/doc/v2.12/Documentation/topdocs/AUTHORS Chris Jackson, Emacs mode indentation. Heikki Junes, Major Emacs- and Vim-mode updates. David Svoboda, what-beat emacs module. Their e-mail addresses can be obtained through the page. ;-) But I suppose sending a PATCH on lilypond-de...@gnu.org would be just fine to help to add these commands to the sources. + Cc: to Chris, Heikki and David ; appreciated. Cheers, Xavier -- Xavier Scheuer ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Hacking Lyqi to use quater-tones
Le 5 mai 2010 à 14:25, Bernardo Barros a écrit : > 1. Is there an easy way to hack Lyqi to i and e increase and lower a > quarter tone instead of half step? I'm looking at the file > lyqi-mode.el to figure out if it is easy of not. > > 2. Impossible to use MIDI in OSX? Huh, actually I've rewritten this emacs extension completely, but it fits my needs, and may not be suitable for any other. It is possible to use midi on OSX. As for quater tones, adapting the existing code should be straight forward. If you like, we'd rather discuss that privately. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
RE: Glissandos
-Original Message- Xavier Scheuer said >I am completely ignorant about that too. >But according to the doc (internals) the #'bound-details value should >be in the form: >#'((right (attach-dir . 0) (padding . 1.5)) (left (attach-dir . 0) >(padding . 1.5))) >Which code did you try actually? I tried this code from the Notation manual. \once \override Glissando #'(bound-details right Y) = #-2 Which can be used to alter the left end by substituting left for right. Will try the code suggested later when I do my chores and can get to my other computer downstairs. Thanks for your interest. Ossie Wilson ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Glissandos
On 7 May 2010 22:36, Ossie Wilson Snr wrote:
> I tried this code from the Notation manual.
>
> \once \override Glissando #'(bound-details right Y) = #-2
>
> Which can be used to alter the left end by substituting left for right.
That just changes the angle of the line, so you'll still be left with a gap.
Try overriding 'padding instead:
\relative c' {
\once \override Glissando #'(bound-details right padding) = 0
c\glissando
\hideNotes
\once \override Glissando #'(bound-details left padding) = 0
c'
\glissando
\unHideNotes
c,
}
Cheers,
Neil
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
