Re: Put the property of a grob in the output-attributes list
Hi Paolo, I'm glad you found it useful! Could you give me an example of
what you want to do with TextScripts? Besides giving them an id, what
properties do you need stored in the svg output attributes?
El dom., 22 dic. 2019 a las 14:04, Paolo Prete ()
escribió:
> Thank you again Stefano. This helps again and you will see how good it
> will fit in the library I'm coding.
> However, I can't make it work for a TextScript (either before the notevent
> or before the markup token). I tried also map-some-music(), but it doesn't
> fix it.
>
> \version "2.19.83"
>
> token = #(let* ((ctr 0)
> (ctr! (lambda ()
> (set! ctr (1+ ctr))
> ctr)))
>(define-music-function (mus) (ly:music?)
> (let* ((id (format #f "foobar_~a" (ctr!)))
> (type (ly:music-property mus 'name))
> (mexp (case type
> ((BeamEvent NoteEvent TextScriptEvent )
> #{ \tweak TextScript.after-line-breaking #(lambda
> (grob)
>(let* ((outprop (ly:grob-property grob
> 'direction))
> (prop (ly:grob-property grob 'direction))
> (outprop (append outprop
> `((beam-thickness . ,prop)
> (display (format #f "\n\n~a\n\n"
> prop))
> (ly:grob-set-property! grob
> 'output-attributes outprop)))
> \tweak TextScript.output-attributes.id #id #mus
> #} )
> (else #{ \tweak output-attributes.id #id #mus #}
>mexp)))
>
> \relative { c'4 d8-\token [ e ] \token f^\markup {'iii'} g c,4 }
>
> On Sun, Dec 22, 2019 at 4:21 PM Stefano Troncaro <
> stefanotronc...@gmail.com> wrote:
>
>> Hi Paolo,
>>
>> The main problem here is that \tweak can only modify the object that is
>> next to it, so you can tweak a NoteHead to modify an automatic beam, but to
>> modify a beam that is created manually because of a [ in the input you need
>> to place the tweak before the [. See:
>>
>> %
>> \version "2.19.83"
>>
>> \relative {
>> c'8[ \tweak Beam.color #red d] %doesn't work
>> \tweak Beam.color #red e f %works
>> \tweak Beam.color #red g[ a] %doesn't work
>> b -\tweak Beam.color #red [ c ] %works
>> }
>> %
>>
>> That said, I modified the function you sent so that it also considerds
>> NoteEvents and modifies the automatically created beams with the desired
>> properties:
>>
>> %
>> \version "2.19.83"
>>
>> token = #(let* ((ctr 0)
>> (ctr! (lambda ()
>> (set! ctr (1+ ctr))
>> ctr)))
>>(define-music-function (mus) (ly:music?)
>> (let* ((id (format #f "foobar_~a" (ctr!)))
>> (type (ly:music-property mus 'name))
>> (mexp (case type
>> ((BeamEvent NoteEvent)
>> #{ \tweak Beam.after-line-breaking #(lambda (grob)
>>(let* ((outprop (ly:grob-property grob
>> 'output-attributes))
>> (beam-thickness (ly:grob-property grob
>> 'beam-thickness))
>> (outprop (append outprop
>> `((beam-thickness . ,beam-thickness)
>> ;(display (format #f "\n\n~a\n\n"
>> beam-thickness))
>> (ly:grob-set-property! grob
>> 'output-attributes outprop)))
>> \tweak Beam.output-attributes.id #id #mus #} )
>> (else #{ \tweak output-attributes.id #id #mus #}
>>mexp)))
>>
>> \relative { c'4 d8-\token [ e ] \token f g c,4 }
>> %
>>
>> The code could be cleaner I think, I'll try to improve it if I get some
>> free time. Meanwhile I hope this helps
>>
>> El dom., 22 dic. 2019 a las 7:58, Paolo Prete ()
>> escribió:
>>
>>> Hello all.
>>>
>>> the following function (thanks to Stefano!) inserts the beam-thickness
>>> property of a Beam in the list of output-attributes of the corresponding
>>> SVG item. It does its job if I place the function soon before a beam symbol
>>> "[". But it doesn't work (no errors, but the output-attributes property is
>>> not set) if place it before a notename. How can I fix that? Should I
>>> map-some-music() and iterate until I find the BeamEvent? I tried that too,
>>> but without success.
>>> Thanks.
>>>
>>> token = #(let* ((ctr 0)
>>> (ctr! (lambda ()
>>> (set! ctr (1+ ctr))
>>> ctr)))
>>>(define-music-function (mus) (ly:music?)
>>> (let* ((id (format #f "foobar_~a" (ctr!)))
>>> (mexp #{ \tweak output-attributes.id #id #mus #} )
>>> (type (ly:music-property mus 'name))
>>> (mexp (case type
>>> ('BeamEvent
>>> #{ \tweak Beam.after-line-breaking #(lambda (grob)
>>>
Output file extension
Hello, is it possible, in some way (without an external script) to override the extension for the output file? I need that output.svg is renamed as output.html Thanks
Re: Swing/Shuffle rhythmMark
Mats, thanks a lot for the convert-ly hint.
Yes, after converting the example as well as my score work as expected -
but only with pdf output! The svg output is still crappy. Happy me that
scribus which I use to build the booklet is able to embed (successfully
though experimental) pdfs as well. I originally started with embedding svg.
Thanks to Bill as well: Working with Scribus would allow me to add such
a separately generated "graphical element" as a workaround with ease.
Regards
Steff
Am 18.12.2019 um 08:54 schrieb Mats Bengtsson:
> Did you remember to convert the file to the latest version:
>
> convert-ly --from=2.18.2 -e yourfile.ly
>
> After such a conversion, the example looks fine when I try it with 2.19.83.
>
> /Mats
>
> On 2019-12-17 22:27, mu...@gmx.ch wrote:
>> Hi folks
>>
>> Back again after quite a while.
>>
>> I'm starting to typeset a songbook (or song sheets) for a
>> singer-songwriter friend of mine who is about to launch another
>> swiss-german children songs cd.
>>
>> First hurdle:
>>
>> I'd like to typeset a shuffled/swinged melody with 8th only instead of
>> - a8. a16 a8. a16 (punctuated) or
>> - \tuplet 3/2 {a4 a8}
>>
>> which both make the score extremely cluttered.
>>
>> I tried the example from http://lsr.di.unimi.it/LSR/Snippet?id=204,
>> where "Swing" or "Shuffle" would be exactly what I'm looking for.
>> I copy the entire functions an example code from this link into a
>> single file (commenting line 274 "system-system-spacing ..." which
>> throws a return code 1).
>> The output of both functions \rhythmMark and \rhythmMarkC is missing the
>> note heads. (additionally the \rhythmMarkC function prints the text
>> strings in the middle of the system (3rd line as baseline) instead of
>> over the sytem in front of the rhythmic patterns.)
>>
>> In the snippet source code there are links to the v2.18 documentation
>> which indicates that the code at least worked with 2.18. I'm running
>> 2.19.83. Might this be the reason for the errors? How to fix the errors?
>> (No idea about scheme programming :-/ ) I uninstalled v2.18 from my
>> system quite a while ago.
>>
>> Or are there other hints how to address my challenge?
>>
>> TIA
>>
>> Steff
>>
>>
Re: Notes or chords sustained with a pedal
Hi Robin, Thanks for your critical comment. I can see your point, but personally I am not very disturbed with or hindered by the result of my amateurish hack. I tried several other hacks, for example coupling the notes with real ties, but I found the result extremely ugly. And finally I will be the only one who will use this transcription. I would have liked it to be perfect and that is why I posted my question on the LilyPond mailing-list. The expert solutions that were proposed didn’t work in my score, no idea why not. Best regards. Robert > On 21 Dec 2019, at 17:38, Robin Bannister wrote: > > Robert Blackstone wrote: > > > > I’m presently transcribing some piano-scores in which schords, > > sustained with a pedal are notated in a way had not seen before > > (see screenshot). > > Referring to that original screenshot, surely there is no pedal here. The > pedal would blur what the right hand is doing. > > This is much more likely laissezvibrer asking for the lefthand fifth to be > allowed to resonate to the sounds produced by the right hand. > It wants the keys kept pressed even when the initial pp may have decayed to > . > > > > > Anyway, I found something that gave me a result, not quite identical > > to what I wanted to get, but good enough for me and probably > > sufficiently clear for a pianist. See the attached screenshot. > > That wouldn't be good enough for me. > > In sightreading mode I would glimpse that in the lefthand there is nothing at > the start of the second measure, and so would release the fifth sooner than > is intended. > > In sightreading mode I would ignore the middle of the second measure. > It is only in the context of this thread that I can guess what is meant. > > I think there should be something tie-like (complete or open) crossing from > the first measure to the second. > > > Cheers, > Robin > > > > > > >
Re: A suggestion - add rf to built-in dynamics
Sunday, December 22, 2019, 4:12:42 PM, Malte Meyn wrote: > Am 22.12.19 um 13:23 schrieb Peter Toye: >> I >> agree about \sp and \spp - what on earth are they meant to mean - a >> sudden quiet note in the middle of louder ones? Not a common musical >> gesture. > Maybe they mean “subito piano” and “subito > pianissimo”? Then they would > not be for only a single not like an accent > (fz, sf, …) but for all > future notes like a regular “piano”, just with an additional “don’t > decresc. before this”. But that’s only me guessing … Possible. New Oxford hasn't heard of them. The point about sf, fz, sfz, rf, rfz is that they are abbreviations of normal words according to my Italian dictionary (not a language I speak).
Re: Put the property of a grob in the output-attributes list
Thank you again Stefano. This helps again and you will see how good it will
fit in the library I'm coding.
However, I can't make it work for a TextScript (either before the notevent
or before the markup token). I tried also map-some-music(), but it doesn't
fix it.
\version "2.19.83"
token = #(let* ((ctr 0)
(ctr! (lambda ()
(set! ctr (1+ ctr))
ctr)))
(define-music-function (mus) (ly:music?)
(let* ((id (format #f "foobar_~a" (ctr!)))
(type (ly:music-property mus 'name))
(mexp (case type
((BeamEvent NoteEvent TextScriptEvent )
#{ \tweak TextScript.after-line-breaking #(lambda
(grob)
(let* ((outprop (ly:grob-property grob
'direction))
(prop (ly:grob-property grob 'direction))
(outprop (append outprop
`((beam-thickness . ,prop)
(display (format #f "\n\n~a\n\n" prop))
(ly:grob-set-property! grob 'output-attributes
outprop)))
\tweak TextScript.output-attributes.id #id #mus #}
)
(else #{ \tweak output-attributes.id #id #mus #}
mexp)))
\relative { c'4 d8-\token [ e ] \token f^\markup {'iii'} g c,4 }
On Sun, Dec 22, 2019 at 4:21 PM Stefano Troncaro
wrote:
> Hi Paolo,
>
> The main problem here is that \tweak can only modify the object that is
> next to it, so you can tweak a NoteHead to modify an automatic beam, but to
> modify a beam that is created manually because of a [ in the input you need
> to place the tweak before the [. See:
>
> %
> \version "2.19.83"
>
> \relative {
> c'8[ \tweak Beam.color #red d] %doesn't work
> \tweak Beam.color #red e f %works
> \tweak Beam.color #red g[ a] %doesn't work
> b -\tweak Beam.color #red [ c ] %works
> }
> %
>
> That said, I modified the function you sent so that it also considerds
> NoteEvents and modifies the automatically created beams with the desired
> properties:
>
> %
> \version "2.19.83"
>
> token = #(let* ((ctr 0)
> (ctr! (lambda ()
> (set! ctr (1+ ctr))
> ctr)))
>(define-music-function (mus) (ly:music?)
> (let* ((id (format #f "foobar_~a" (ctr!)))
> (type (ly:music-property mus 'name))
> (mexp (case type
> ((BeamEvent NoteEvent)
> #{ \tweak Beam.after-line-breaking #(lambda (grob)
>(let* ((outprop (ly:grob-property grob
> 'output-attributes))
> (beam-thickness (ly:grob-property grob
> 'beam-thickness))
> (outprop (append outprop
> `((beam-thickness . ,beam-thickness)
> ;(display (format #f "\n\n~a\n\n"
> beam-thickness))
> (ly:grob-set-property! grob
> 'output-attributes outprop)))
> \tweak Beam.output-attributes.id #id #mus #} )
> (else #{ \tweak output-attributes.id #id #mus #}
>mexp)))
>
> \relative { c'4 d8-\token [ e ] \token f g c,4 }
> %
>
> The code could be cleaner I think, I'll try to improve it if I get some
> free time. Meanwhile I hope this helps
>
> El dom., 22 dic. 2019 a las 7:58, Paolo Prete ()
> escribió:
>
>> Hello all.
>>
>> the following function (thanks to Stefano!) inserts the beam-thickness
>> property of a Beam in the list of output-attributes of the corresponding
>> SVG item. It does its job if I place the function soon before a beam symbol
>> "[". But it doesn't work (no errors, but the output-attributes property is
>> not set) if place it before a notename. How can I fix that? Should I
>> map-some-music() and iterate until I find the BeamEvent? I tried that too,
>> but without success.
>> Thanks.
>>
>> token = #(let* ((ctr 0)
>> (ctr! (lambda ()
>> (set! ctr (1+ ctr))
>> ctr)))
>>(define-music-function (mus) (ly:music?)
>> (let* ((id (format #f "foobar_~a" (ctr!)))
>> (mexp #{ \tweak output-attributes.id #id #mus #} )
>> (type (ly:music-property mus 'name))
>> (mexp (case type
>> ('BeamEvent
>> #{ \tweak Beam.after-line-breaking #(lambda (grob)
>>(let* ((outprop (ly:grob-property grob
>> 'output-attributes))
>> (beam-thickness (ly:grob-property grob
>> 'beam-thickness))
>> (outprop (append outprop
>> `((beam-thickness . ,beam-thickness)
>> (begin
>> (ly:grob-set-property! grob
>> 'output-attributes outprop)
>>
Re convert-ly problems
The final piece of the jig saw was this batch file forfiles /s /p "C:\Users\Peter\Lilypool\Music_Files\Bouffil" /M **.ly /c "cmd /c convert-ly.py -e @file" Getting this to work was non trivial. I will try and get a batch file to ask for the folder "Bouffil" etc to make updating easy. Shame that Fresco is still deficient. Thanks everyone - no one advice solved the whole thing. Path. and assoc. were needed Regards Peter
Re: A suggestion - add rf to built-in dynamics
Am 22.12.19 um 13:23 schrieb Peter Toye: I agree about \sp and \spp - what on earth are they meant to mean - a sudden quiet note in the middle of louder ones? Not a common musical gesture. Maybe they mean “subito piano” and “subito pianissimo”? Then they would not be for only a single not like an accent (fz, sf, …) but for all future notes like a regular “piano”, just with an additional “don’t decresc. before this”. But that’s only me guessing …
Re: Put the property of a grob in the output-attributes list
Hi Paolo,
The main problem here is that \tweak can only modify the object that is
next to it, so you can tweak a NoteHead to modify an automatic beam, but to
modify a beam that is created manually because of a [ in the input you need
to place the tweak before the [. See:
%
\version "2.19.83"
\relative {
c'8[ \tweak Beam.color #red d] %doesn't work
\tweak Beam.color #red e f %works
\tweak Beam.color #red g[ a] %doesn't work
b -\tweak Beam.color #red [ c ] %works
}
%
That said, I modified the function you sent so that it also considerds
NoteEvents and modifies the automatically created beams with the desired
properties:
%
\version "2.19.83"
token = #(let* ((ctr 0)
(ctr! (lambda ()
(set! ctr (1+ ctr))
ctr)))
(define-music-function (mus) (ly:music?)
(let* ((id (format #f "foobar_~a" (ctr!)))
(type (ly:music-property mus 'name))
(mexp (case type
((BeamEvent NoteEvent)
#{ \tweak Beam.after-line-breaking #(lambda (grob)
(let* ((outprop (ly:grob-property grob
'output-attributes))
(beam-thickness (ly:grob-property grob
'beam-thickness))
(outprop (append outprop
`((beam-thickness . ,beam-thickness)
;(display (format #f "\n\n~a\n\n"
beam-thickness))
(ly:grob-set-property! grob 'output-attributes
outprop)))
\tweak Beam.output-attributes.id #id #mus #} )
(else #{ \tweak output-attributes.id #id #mus #}
mexp)))
\relative { c'4 d8-\token [ e ] \token f g c,4 }
%
The code could be cleaner I think, I'll try to improve it if I get some
free time. Meanwhile I hope this helps
El dom., 22 dic. 2019 a las 7:58, Paolo Prete ()
escribió:
> Hello all.
>
> the following function (thanks to Stefano!) inserts the beam-thickness
> property of a Beam in the list of output-attributes of the corresponding
> SVG item. It does its job if I place the function soon before a beam symbol
> "[". But it doesn't work (no errors, but the output-attributes property is
> not set) if place it before a notename. How can I fix that? Should I
> map-some-music() and iterate until I find the BeamEvent? I tried that too,
> but without success.
> Thanks.
>
> token = #(let* ((ctr 0)
> (ctr! (lambda ()
> (set! ctr (1+ ctr))
> ctr)))
>(define-music-function (mus) (ly:music?)
> (let* ((id (format #f "foobar_~a" (ctr!)))
> (mexp #{ \tweak output-attributes.id #id #mus #} )
> (type (ly:music-property mus 'name))
> (mexp (case type
> ('BeamEvent
> #{ \tweak Beam.after-line-breaking #(lambda (grob)
>(let* ((outprop (ly:grob-property grob
> 'output-attributes))
> (beam-thickness (ly:grob-property grob
> 'beam-thickness))
> (outprop (append outprop
> `((beam-thickness . ,beam-thickness)
> (begin
> (ly:grob-set-property! grob
> 'output-attributes outprop)
> (display "\n\n")
> (display beam-thickness)
> (display "\n\n"
> #mexp #} )
> (else mexp
>mexp)))
>
> \relative { c'4 d8-\token [ e ] \token f[ g ] c,4 }
>
Re: A suggestion - add rf to built-in dynamics
Andrew, Malte,
Thanks for the opposing views!
Andrew, my point was that if two extremely well-known composers use a dynamic
symbol, it's hardly non-standard, which is why I think it should be included
even if it is a synonym for rfz.
Malte, I think I've seen all of these (but I can't remember where I saw pf -
was it Mozart somewhere?) but extremely rarely. Schubert has fffz - how he
managed that on an 1820s piano without breaking it I can't imagine. I wouldn’t
suggest adding this though as it's very rare. I agree about \sp and \spp - what
on earth are they meant to mean - a sudden quiet note in the middle of louder
ones? Not a common musical gesture.
Best regards,
Peter
mailto:lilyp...@ptoye.com
www.ptoye.com
-
Sunday, December 22, 2019, 6:06:01 AM, lilypond-user-requ...@gnu.org wrote:
> Send lilypond-user mailing list submissions to
> lilypond-user@gnu.org
> To subscribe or unsubscribe via the World Wide Web, visit
>
> https://lists.gnu.org/mailman/listinfo/lilypond-user
> or, via email, send a message with subject or body 'help' to
> lilypond-user-requ...@gnu.org
> You can reach the person managing the list at
> lilypond-user-ow...@gnu.org
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of lilypond-user digest..."
> Today's Topics:
>1. Re: convert-ly problems (Knute Snortum)
>2. Re: A suggestion - add rf to built-in
> dynamics (Andrew Bernard)
>3. Re: Notes or chords sustained with a pedal (David R)
>4. Re: Notes or chords sustained with a pedal (Aaron Hill)
> --
> Message: 1
> Date: Sat, 21 Dec 2019 14:45:06 -0800
> From: Knute Snortum
> To: peter.gen...@sunscales.co.uk
> Cc: Lilypond Users
> Subject: Re: convert-ly problems
> Message-ID:
>
>
> Content-Type: text/plain; charset="UTF-8"
-->>C:\"Program Files (x86)"\LilyPond\usr\bin\python.exe<--
> This looks like the quotes are in the wrong place.
> ---
> Knute Snortum
> (via Gmail)
> On Sat, Dec 21, 2019 at 4:32 AM Peter Gentry
> wrote:
>> I spoke too soon.
>> C:\WINDOWS\system32>convert-ly
>> C:\WINDOWS\system32>C:\"Program Files (x86)"\LilyPond\usr\bin\python.exe
>> C:\"Program Files (x86)"\LilyPond\usr\bin\convert-ly.py
>> C:\Program Files (x86)\LilyPond\usr\bin\python.exe: can't open file
>> 'C:"Program': [Errno 22] Invalid argument
>> C:\WINDOWS\system32>
>> This did work first time but now another wonderful windows surprise.
>> From: Peter Gentry
>> Sent: 21 December 2019 12:02
>> To: Lilypond Users (lilypond-user@gnu.org)
>> Cc: 'ksnor...@gmail.com'
>> Subject: convert-ly problems
>> Thanks Knute
>> However the problem for windows (as usual) is more difficult. In addition
>> to the PATH I needed the following to set up the association.
>> First get check the associated name of the python file type.
>> In an admin command prompt run the following
>> assoc {Python} result “no association……”
>> I created one
>> Python="C:\Program Files (x86)\LilyPond\usr\bin\python.exe" "%1"
>> Now I look in Default Apps and there is PYTHON
>> SUCCESS!
>> Now convert-ly.py works
>> I could have use something Lily specific as the association PYTHONLILY say
>> maybe I will later.
>> I expect I will have to do something similar if I go back to PYTHON proper.
>> Isn’t Windows wonderful
>> Regards Peter
> --
> Message: 2
> Date: Sun, 22 Dec 2019 10:23:46 +1100
> From: Andrew Bernard
> To: lilypond-user Mailinglist
> Subject: Re: A suggestion - add rf to built-in dynamics
> Message-ID:
>
>
> Content-Type: text/plain; charset="UTF-8"
> Hi Peter,
> Well I have a library file with over 150 custom dynamics, for use with
> engraving new complexity school scores. It's a big file, with all
> sorts of rare dynamics. I see no need to push non-standard or rare
> dynamics on everybody. Just make an include file for your score and
> add 'rf'. One could argue that the original
> composers are in error, or
> it's an obsolete convention, and perhaps this would mislead modern
> players anyway (the infinite discussion of the urtext!).
> I don't see a need for rf to be added to the core set.
> [And amusingly I have all the ones Malte
> suggested. and lots of marks
> like 'f (poco)' and similar which is actually commonly found, and yet
> does not need to be in the core.]
> Andrew
> On Sat, 21 Dec 2019 at 23:42, Peter Toye
> wrote:
>> May I suggest adding 'rf' to the built-in dynamics? Beethoven and Brahms
>> used it quite a lot, even if it is synonymous with 'rfz' (pedants might
>> disagree). As did some other, lesser, composers (one of whose music I am
>> currently engraving).
>> A far as I can see, it just needs adding
>> rfz = #(make-dynamic-script "rfz")
>> to dynamic-scripts-init.ly
>> There's an easy workaround of course - just put
Re: Notes or chords sustained with a pedal
Am So., 22. Dez. 2019 um 11:52 Uhr schrieb Robert Blackstone < blackstone.rob...@gmail.com>: > Hi Aaron, Mark, Kieren and Rutger, > > Many thanks for your solutions for my “Laissez vibrer”-problem. > I’m very impressed by your "LilyPond -creativity”. > Introducing my notes into your examples works perfectly. > Unfortunatly, introducing your codes into my scores either does not change > anything, when I use my own score-definition, or they do not compile when I > use yours, or better, the crucial elements of your scores. > I’ve spent hours to find and try to remove the causes of the errors, to no > avail. > > I use “my score” for all of my piano transcriptions, and so far the only > thing that sometimes fails is connecting arpeggio’s but I know the remedy. > Maybe I should mention that I use TeXShop as my editor. > Aaron's code should work. If not, I'd be interested how you do “my score. Probably one could track down the problem. Cheers, Harm
problem with convert-ly
Phew The command prompt method solved. C:\Program Files (x86)\LilyPond\usr\bin>convert-ly -e -b "C:\users\peter\Lilypool\Music_Files\Bouffil\Opus7 No 1\alto.ly" convert-ly.py (GNU LilyPond) 2.19.81 convert-ly.py: Processing `C:\users\peter\Lilypool\Music_Files\Bouffil\Opus7 No 1\alto.ly'... Applying conversion: 2.15.7, 2.15.9, 2.15.10, 2.15.16, 2.15.17, 2.15.18, 2.15.19, 2.15.20, 2.15.25, 2.15.32, 2.15.39, 2.15.40, 2.15.42, 2.15.43, 2.16.0, 2.17.0, 2.17.4, 2.17.5, 2.17.6, 2.17.11, 2.17.14, 2.17.15, 2.17.18, 2.17.19, 2.17.20, 2.17.25, 2.17.27, 2.17.29, 2.17.97, 2.18.0, 2.19.2, 2.19.7, 2.19.11, 2.19.16, 2.19.22, 2.19.24, 2.19.28, 2.19.29, 2.19.32, 2.19.40, 2.19.46, 2.19.49, 2.19.80 C:\Program Files (x86)\LilyPond\usr\bin> But all this typing for one file is doomed to induce errors - so now to crack the batch file method. Thank all. Regards Peter
Re: Notes or chords sustained with a pedal
Hi Aaron,
Am So., 22. Dez. 2019 um 07:06 Uhr schrieb Aaron Hill
:
>
> On 2019-12-21 9:15 am, Kieren MacMillan wrote:
> >> Here is my attempt at hacking the BarLine stencil to add overlapping
> >> ties:
> >
> > This is so cool. Is there an easy way to make the function determine
> > the "current" set of LVs (i.e., the LV configuration from the most
> > recent LV-ed chord) and automagically apply it to the subsequent
> > barlines (e.g., with a \temporary, to be \reverted manually)?
>
> Things get trickier if you need to keep track of past events. But here
> is another approach that uses a Scheme engraver to do the bulk of the
> work:
this is really great stuff.
How about putting it in LSR?
Seems to work with 2.18.2 as well.
After a very quick first glnce over it some remarks:
>
> \version "2.19.83"
>
> #(begin
>(set-object-property! 'activeLaissezVibrer 'translation-type? list?)
>(set-object-property! 'activeLaissezVibrer 'translation-doc
> "A list of LaissezVibrerTies which should span BarLines.")
>(set! all-translation-properties
> (cons 'activeLaissezVibrer all-translation-properties)))
>
> #(define (SpanLaissezVibrer_engraver context)
>(define (spanLaissezVibrer? grob)
> (let* ((cause (ly:grob-property grob 'cause))
> (class (ly:event-property cause 'class '()))
> (span? (ly:event-property cause 'span #f)))
>(and (memq 'laissez-vibrer-event class) span?)))
>(define (past-events tie)
> (ly:moment(define (rescale-control-points cp xex)
> (let* ((xmin (apply min (map car cp)))
> (xmax (apply max (map car cp)))
> (xmid (/ (+ xmin xmax) 2))
> (xhw (/ (- xmax xmin) 2)))
(map (lambda (pt) pt <-- this `pt` looks superfluous or am I
overlooking something?
> (let ((t (/ (- (car pt) xmid) xhw)))
>(cons (interval-index xex t) (cdr pt cp)))
>(define ((stencil-proc ties) grob)
> (let* ((bd (ly:item-break-dir grob))
> (orig (ly:bar-line::print grob))
> (xex (ly:stencil-extent orig X))
> (x (interval-index xex 0))
> (w (+ 0.8 (/ (interval-length xex) 2)))
> (tie-xex (cons (- x w) (+ x w
Some code-duplication here, iiuc:
>(ly:stencil-add (ly:bar-line::print grob)
> (apply ly:stencil-add
>(map (lambda (tie)
> (let* ((cp-orig (ly:grob-property tie 'control-points))
> (cp-temp (rescale-control-points cp-orig tie-xex))
> (sten '()) (xex '()) (yex '()))
>(ly:grob-set-property! tie 'control-points cp-temp)
>(set! sten (ly:tie::print tie))
>(ly:grob-set-property! tie 'control-points cp-orig)
>(set! xex (ly:stencil-extent sten X))
>(set! yex (ly:stencil-extent sten Y))
>(ly:make-stencil (ly:stencil-expr sten)
> (cons (car xex) (if (> 0 bd) x (cdr xex))) yex)))
> (map cdr ties))
>(make-engraver
> (acknowledgers
>((bar-line-interface engraver grob source-engraver)
> (let ((ties (ly:context-property context
>'activeLaissezVibrer '(
>(set! ties (filter past-events ties))
>(if (not (null? ties)) (ly:grob-set-property!
> grob 'stencil (stencil-proc ties)
>((semi-tie-interface engraver grob source-engraver)
> (if (spanLaissezVibrer? grob)
>(ly:context-set-property! context 'activeLaissezVibrer
> (cons (cons (ly:context-now context) grob)
>(ly:context-property context
> 'activeLaissezVibrer '()
>
> spanLaissezVibrer = #(make-music 'LaissezVibrerEvent 'span #t)
>
> stopSpanLaissezVibrers = \applyContext #(lambda (context)
>(ly:context-set-property! (ly:context-find context 'Staff)
> 'activeLaissezVibrer '()))
>
> Upper = {
>| r2 r8 g'8 b' c''
>| 1\spanLaissezVibrer
>| R1 \stopSpanLaissezVibrers \bar "||"
>| r8 a' g' e' c'2 \bar "|."
> }
> Lower = {
>| 1\spanLaissezVibrer
>| R1
>| g8 b 2.^\spanLaissezVibrer
>| R1 \stopSpanLaissezVibrers
> }
> \score {
>\new PianoStaff <<
> \new Staff { \clef "treble" \Upper }
> \new Staff { \clef "bass" \Lower }
>>>
>\layout { \context { \Staff
> \consists \SpanLaissezVibrer_engraver } }
> }
>
>
> This is quite different from my previous manual approach, but this has
> advantages of exactly matching the vertical positioning of LV ties
> without needing manual intervention.
>
>
> -- Aaron Hill
Thanks,
Harm
Re: Separating note names into pitch and accidentals
> On 22 Dec 2019, at 11:05, Malte Meyn wrote: > > Am 22.12.19 um 10:51 schrieb Hans Åberg: >> To simplify the writing of note input names, they might be separated into >> separate parts for pitch and accidentals (or intervals). Testing this, I >> made C++ code where one first reads the longest pitch name available in a >> table, and then proceeds for a succession of accidentals, also the longest >> available in a separate table, and it looks like nice. > > I’m not sure if I understand correctly, but if I do that won’t work for all > languages: In German “fes” is f-flat, while “f es” is f and e-flat, you > cannot know whether “es” is the suffix “-flat” or the complete pitch name > “e-flat”. And how about “feses”? That could be “f es es”, “fes es” or “f > eses”. I do it in a way that is upwards compatible, specifically, if one puts all note names into the table, as is the case now, and no separate accidentals, the result is exactly the same as currently. Also, rather than writing pitch and accidental names separately with a separator like a space, I split the note name that is parsed, so that is also upward compatible, and avoids having to tweak the lexer and parser. So "f es” is two notes as before, whereas “fes” a single note. In German, one could this keep it as it is, or define the note names c d e f g a b h, plus the accidentals is es, and the microtonal accidentals ih eh. Doing the latter, “feses” is split up as “f es es”, and their pitch and alterations values added. But one gets more combinations, for example “fisih” and “fihis” will be the same, as they are split up as “f is ih” and “f ih is”. Also, any number of accidental names can follow the note name.
Put the property of a grob in the output-attributes list
Hello all.
the following function (thanks to Stefano!) inserts the beam-thickness
property of a Beam in the list of output-attributes of the corresponding
SVG item. It does its job if I place the function soon before a beam symbol
"[". But it doesn't work (no errors, but the output-attributes property is
not set) if place it before a notename. How can I fix that? Should I
map-some-music() and iterate until I find the BeamEvent? I tried that too,
but without success.
Thanks.
token = #(let* ((ctr 0)
(ctr! (lambda ()
(set! ctr (1+ ctr))
ctr)))
(define-music-function (mus) (ly:music?)
(let* ((id (format #f "foobar_~a" (ctr!)))
(mexp #{ \tweak output-attributes.id #id #mus #} )
(type (ly:music-property mus 'name))
(mexp (case type
('BeamEvent
#{ \tweak Beam.after-line-breaking #(lambda (grob)
(let* ((outprop (ly:grob-property grob
'output-attributes))
(beam-thickness (ly:grob-property grob
'beam-thickness))
(outprop (append outprop
`((beam-thickness . ,beam-thickness)
(begin
(ly:grob-set-property! grob
'output-attributes outprop)
(display "\n\n")
(display beam-thickness)
(display "\n\n"
#mexp #} )
(else mexp
mexp)))
\relative { c'4 d8-\token [ e ] \token f[ g ] c,4 }
Re: Notes or chords sustained with a pedal
Hi Aaron, Mark, Kieren and Rutger, Many thanks for your solutions for my “Laissez vibrer”-problem. I’m very impressed by your "LilyPond -creativity”. Introducing my notes into your examples works perfectly. Unfortunatly, introducing your codes into my scores either does not change anything, when I use my own score-definition, or they do not compile when I use yours, or better, the crucial elements of your scores. I’ve spent hours to find and try to remove the causes of the errors, to no avail. I use “my score” for all of my piano transcriptions, and so far the only thing that sometimes fails is connecting arpeggio’s but I know the remedy. Maybe I should mention that I use TeXShop as my editor. So, in the end, I will stay with my own tweaks that resulted in a, for me, acceptable notation, as in the screenshot I attached in my mail of a few days ago. Thanks again. Best regards, Robert
Re: Separating note names into pitch and accidentals
Am 22.12.19 um 10:51 schrieb Hans Åberg: To simplify the writing of note input names, they might be separated into separate parts for pitch and accidentals (or intervals). Testing this, I made C++ code where one first reads the longest pitch name available in a table, and then proceeds for a succession of accidentals, also the longest available in a separate table, and it looks like nice. I’m not sure if I understand correctly, but if I do that won’t work for all languages: In German “fes” is f-flat, while “f es” is f and e-flat, you cannot know whether “es” is the suffix “-flat” or the complete pitch name “e-flat”. And how about “feses”? That could be “f es es”, “fes es” or “f eses”.
Separating note names into pitch and accidentals
To simplify the writing of note input names, they might be separated into separate parts for pitch and accidentals (or intervals). Testing this, I made C++ code where one first reads the longest pitch name available in a table, and then proceeds for a succession of accidentals, also the longest available in a separate table, and it looks like nice.
