Re: ANN: Spontini-Editor version 1.12-alfa
Thanks for these infos. 1) once I download a development snapshot, how can I test it? 2) Is there a plan of when it will be included into a released version? 3) Is it already well working, or is it in unstable/buggy state? Cheers, P On Friday, February 11, 2022, Jean Abou Samra wrote: > Le 11/02/2022 à 00:33, Paolo Prete a écrit : > >> 1) support for PDF output, in order to speed up the compilation of >> scores. Thanks to the PDF mode, instead of SVG, the compilation time >> drastically decreases: once the score has been sketched it is possible to >> switch to SVG mode, in order to complete it through tweaks with the mouse. >> > > > For your information, a new backend for LilyPond has been developed > over the last year, based on the Cairo library, which solves this > problem (it makes PDF output a bit faster and brings SVG on par > with PDF in speed). This is just a heads-up, since it not enabled > in released versions yet. > > Best, > Jean > > >
Re: ANN: Spontini-Editor version 1.12-alfa
> Am 11.02.2022 um 00:33 schrieb Paolo Prete : > > Hello, > > I have published a new version of Spontini-Editor (1.12-alpha): it is still > in the testing phase and therefore not available in the list of releases, but > it is already working and it can be downloaded from the main project page. > > https://github.com/paopre/Spontini > > The important features of this version are: > Hello, after installation I get an application window at localhost:8000/spontini-editor/, but cannot use it: "Error while connecting to SpontiniServer.“ Did I miss something? Thomas macOS Monterey 12.1 LilyPond 2.23.6
Re: ANN: Spontini-Editor version 1.12-alfa
> Le 11/02/2022 11:07, Paolo Prete a écrit : > > > Thanks for these infos. > > > 1) once I download a development snapshot, how can I test it? If you mean an unstable release, you cannot, since these aren't built with Cairo yet -- the switch to Guile 2 and the new infrastructure for binaries was already enough for a single release. So if you want to test it (which will be very much appreciated if you can report any problems you find), you have to compile LilyPond yourself by following the procedure described in http://lilypond.org/doc/v2.23/Documentation/contributor/compiling To enable Cairo, you have to configure with ../configure --enable-cairo-backend and then you run with Cairo using lilypond --svg -dbackend=cairo file.ly (if you use --svg, -dbackend=cairo must be last). > 2) Is there a plan of when it will be included into a released version? I haven't followed this story very closely, but I guess it will be included at some point in this development series. When it will become the default is another question. > 3) Is it already well working, or is it in unstable/buggy state? Working quite well overall. Best, Jean
Re: Accent size and stem length
Thank you for the answers, Leo and Paul! It seems that \override Script.font-size = #-1.5 works nicely, at least for now. There is something about the stems that doesn't look right to my eye, but maybe it is not the length. Best, Erika
Re: Is the slur too close to the top note?
Yes, I think the slur is way too close to the top note. Another issue with slurs I have encountered is that they look very awkward when there is a line break in the middle of a slur, because it looks like two slurs instead of one longer one continuing over the line break. (I might try to produce an example at some point.) Best, Erika
Re: Is the slur too close to the top note?
Hello Knute,
this is a common issue with big slurs. To allow a better shape for the slur
increase the height limit of the slur (grob path Slur.height-limit).
The problem here is that having a single height limit is not able to handle
each possible situation well. What we might try to do is to heuristically try
to guess a good value, depending on the length of the passage, the curve of the
note heads and such.
Cheers,
Valentin
11.02.2022 01:53:45 Knute Snortum :
> Hi all,
>
> I have what I guess is a request for comment on how close this slur is
> to the topmost note. If you engrave this input file...
>
> %%%
> \version "2.23"
> \language "english"
>
> \relative {
> \clef bass
> \key c \minor
> c,16( g' c d ef g c d ef d c g ef d c g) |
> }
> %%%
>
> ...you get a slur that to my eye is much too close to the "ef" in the
> third beat (see attached). What do others think? Is this just a case
> of "LilyPond sometimes doesn't render perfect slurs" or is there an
> algorithm that can be tweaked?
>
> --
> Knute Snortum
Re: Is the slur too close to the top note?
Thanks Valentin and Kieren. I didn't know you could control this kind
of thing with grob parameters! I'll try out both suggestions. I was
always using \shape to change the shape of the slur, but now I'll look
for parameters to tweak.
--
Knute Snortum
On Fri, Feb 11, 2022 at 4:55 AM Valentin Petzel wrote:
>
> Hello Knute,
>
> this is a common issue with big slurs. To allow a better shape for the slur
> increase the height limit of the slur (grob path Slur.height-limit).
>
> The problem here is that having a single height limit is not able to handle
> each possible situation well. What we might try to do is to heuristically try
> to guess a good value, depending on the length of the passage, the curve of
> the note heads and such.
>
> Cheers,
> Valentin
>
> 11.02.2022 01:53:45 Knute Snortum :
>
> > Hi all,
> >
> > I have what I guess is a request for comment on how close this slur is
> > to the topmost note. If you engrave this input file...
> >
> > %%%
> > \version "2.23"
> > \language "english"
> >
> > \relative {
> > \clef bass
> > \key c \minor
> > c,16( g' c d ef g c d ef d c g ef d c g) |
> > }
> > %%%
> >
> > ...you get a slur that to my eye is much too close to the "ef" in the
> > third beat (see attached). What do others think? Is this just a case
> > of "LilyPond sometimes doesn't render perfect slurs" or is there an
> > algorithm that can be tweaked?
> >
> > --
> > Knute Snortum
Re: Is the slur too close to the top note?
Hello Knute,
you if you check out the internals for Slur (also Tie) you'll find that you
have quite a lot of control over the demerits and penalties used for
calculating the Slur shape in the details property, as well options like
height-limit, rate, excentricity and stuff.
This means that many times instead of using shape it can be better to simply
tweak a small parameter. Sadly there is little documentation for this.
Valentin
11.02.2022 16:33:27 Knute Snortum :
> Thanks Valentin and Kieren. I didn't know you could control this kind
> of thing with grob parameters! I'll try out both suggestions. I was
> always using \shape to change the shape of the slur, but now I'll look
> for parameters to tweak.
>
> --
> Knute Snortum
>
>
> On Fri, Feb 11, 2022 at 4:55 AM Valentin Petzel wrote:
>>
>> Hello Knute,
>>
>> this is a common issue with big slurs. To allow a better shape for the slur
>> increase the height limit of the slur (grob path Slur.height-limit).
>>
>> The problem here is that having a single height limit is not able to handle
>> each possible situation well. What we might try to do is to heuristically
>> try to guess a good value, depending on the length of the passage, the curve
>> of the note heads and such.
>>
>> Cheers,
>> Valentin
>>
>> 11.02.2022 01:53:45 Knute Snortum :
>>
>>> Hi all,
>>>
>>> I have what I guess is a request for comment on how close this slur is
>>> to the topmost note. If you engrave this input file...
>>>
>>> %%%
>>> \version "2.23"
>>> \language "english"
>>>
>>> \relative {
>>> \clef bass
>>> \key c \minor
>>> c,16( g' c d ef g c d ef d c g ef d c g) |
>>> }
>>> %%%
>>>
>>> ...you get a slur that to my eye is much too close to the "ef" in the
>>> third beat (see attached). What do others think? Is this just a case
>>> of "LilyPond sometimes doesn't render perfect slurs" or is there an
>>> algorithm that can be tweaked?
>>>
>>> --
>>> Knute Snortum
Re: Tablature - Parenthesizing Tied Notes
Thanks Jean,
but it looks like I am a little behind with my Debian package-based
Lilypond 2.18.2 installation. So I get some complaints about "Unbound
variable: grob::rhythmic-location" and Lilypond exits in error with return
code 1.
I still need to grok all this scheme/guile mechanics, because so far I did
not dive into the deeper layers of Lilypond yet. Eventually I can get it
to work also with 2.18.2, or manage to update to the latest version.
Again thanks for the help, this is very appreciated.
Stefan
--
Stefan E. Mueller
stefan.e.muel...@gmx.de
On Wed, 9 Feb 2022, Jean Abou Samra wrote:
Le 06/02/2022 à 22:55, Stefan E. Mueller a écrit :
Ties over a line break are parenthesized by default in tablature - I was
wondering if one could also have parenthesized tablature notes for ties
over a bar line.
Thanks for any help.
Stefan
The default logic is in Tie.after-line-breaking, by default
tie::handle-tab-note-head in TabStaff. When the span-start
property of TabNoteHead is #t, it remains parenthesized
even if it would normally be hidden (this is used by default
when the tab note head starts a slur or glissando). You can
override the default logic to set it also in the case where
the tie spans a bar line.
\version "2.22.1"
#(use-modules (ice-9 match))
#(define (tie::tab-note-head-parenthesized-after-bar-line grob)
(match-let* ((left (ly:spanner-bound grob LEFT))
(right (ly:spanner-bound grob RIGHT))
((left-bar-number . _) (grob::rhythmic-location left))
((right-bar-number . _) (grob::rhythmic-location right)))
(if (and (grob::has-interface right 'tab-note-head-interface)
(not (eqv? left-bar-number right-bar-number)))
(ly:grob-set-property! right 'span-start #t))
(tie::handle-tab-note-head grob)))
\layout {
\context {
\TabStaff
\override Tie.after-line-breaking =
#tie::tab-note-head-parenthesized-after-bar-line
}
}
\new TabStaff {
c'2~ 2~ 2~ 2~ \break 2~ 2
}
Best,
Jean
Re: Usually this makes sense: "warning: More alternatives than repeats. Junking excess alternatives"
Le 11/02/2022 à 22:33, Kenneth Wolcott a écrit :
Hi;
Usually this makes sense:
"warning: More alternatives than repeats. Junking excess alternatives"
But I'm having trouble finding the problem.
Here's the result of calling lilypond:
GNU LilyPond 2.22.1 (running Guile 2.2)
Processing `Willson_Till_There_Was_You.ly'
Parsing...
warning: More alternatives than repeats. Junking excess alternatives
warning: More alternatives than repeats. Junking excess alternatives
Interpreting music...[8][16]
Preprocessing graphical objects...
Interpreting music...
MIDI output to `Willson_Till_There_Was_You.midi'...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Converting to `Willson_Till_There_Was_You.pdf'...
Success: compilation successfully completed
I have attached the origin (pdf arranged by www.TubaPeter.com), my
engraved pdf, and my Lilypond source.
I know that this is now an MWE; but would you guys be willing to
look at this in spite of that? It's not huge.
I just can't seem to find where my error is.
I read
\repeat volta 2 {
\tuba_one_ii
}
\alternative {
{ \tuba_one_iii }
{ \tuba_one_iv }
{ \tuba_one_v }
}
Indeed, you have more alternatives than repeats.
\repeat volta 3 will make LilyPond behave.
Best,
Jean
Re: Tablature - Parenthesizing Tied Notes
Le 11/02/2022 à 22:31, Stefan E. Mueller a écrit :
Thanks Jean,
but it looks like I am a little behind with my Debian package-based
Lilypond 2.18.2 installation. So I get some complaints about "Unbound
variable: grob::rhythmic-location" and Lilypond exits in error with
return
code 1.
I still need to grok all this scheme/guile mechanics, because so far I
did
not dive into the deeper layers of Lilypond yet. Eventually I can get it
to work also with 2.18.2, or manage to update to the latest version.
Again thanks for the help, this is very appreciated.
What version of Debian? In Bullseye, the version packaged is 2.22.
If you want to keep an older version of your distribution, you could
install 2.22 via the official generic packages from
http://lilypond.org/unix.html. These are pretty easy to use, just
unpack them and run the script
('sh lilypond-blabla.sh --prefix=/I/want/it/here' and I can't
remember if you need sudo; use --help for a list of options).
Best,
Jean
Re: ANN: Spontini-Editor version 1.12-alfa
Hello, I tested the editor on macOS Catalina, with LilyPond 2.22.0 from unofficial 64-bit app bundles and had no problems. 1) Which browser are you using? 2) Please can you paste the complete log of the SpontiniServer window on the issues page of GitHub https://github.com/paopre/Spontini/issues (or pm to my email)? thanks On Fri, Feb 11, 2022 at 11:18 AM Thomas Scharkowski < t.scharkow...@t-online.de> wrote: > > > > Am 11.02.2022 um 00:33 schrieb Paolo Prete : > > > > Hello, > > > > I have published a new version of Spontini-Editor (1.12-alpha): it is > still in the testing phase and therefore not available in the list of > releases, but it is already working and it can be downloaded from the main > project page. > > > > https://github.com/paopre/Spontini > > > > The important features of this version are: > > > Hello, > > after installation I get an application window at > localhost:8000/spontini-editor/, but cannot use it: > > "Error while connecting to SpontiniServer.“ > > Did I miss something? > > Thomas > > macOS Monterey 12.1 > LilyPond 2.23.6 > >
Re: ANN: Spontini-Editor version 1.12-alfa
Thanks, I was not aware of it and I'll surely test it ASAP Cheers, P On Fri, Feb 11, 2022 at 1:10 PM Jean Abou Samra wrote: > > Le 11/02/2022 11:07, Paolo Prete a écrit : > > > > > > Thanks for these infos. > > > > > > 1) once I download a development snapshot, how can I test it? > > > If you mean an unstable release, you cannot, since these > aren't built with Cairo yet -- the switch to Guile 2 > and the new infrastructure for binaries was already enough > for a single release. So if you want to test it (which > will be very much appreciated if you can report any > problems you find), you have to compile LilyPond yourself > by following the procedure described in > > http://lilypond.org/doc/v2.23/Documentation/contributor/compiling > > To enable Cairo, you have to configure with > > ../configure --enable-cairo-backend > > and then you run with Cairo using > > lilypond --svg -dbackend=cairo file.ly > > (if you use --svg, -dbackend=cairo must be last). > > > > 2) Is there a plan of when it will be included into a released version? > > I haven't followed this story very closely, but I guess > it will be included at some point in this development > series. When it will become the default is another question. > > > > 3) Is it already well working, or is it in unstable/buggy state? > > Working quite well overall. > > Best, > Jean >
Re: Is the slur too close to the top note?
On Fri, Feb 11, 2022 at 9:01 AM wrote:
-- Forwarded message --
> From: Valentin Petzel
> To: Knute Snortum
> Cc: kie...@kierenmacmillan.info, lilypond-user@gnu.org
> Bcc:
> Date: Fri, 11 Feb 2022 15:45:42 + (UTC)
> Subject: Re: Is the slur too close to the top note?
> Hello Knute,
>
> you if you check out the internals for Slur (also Tie) you'll find that
> you have quite a lot of control over the demerits and penalties used for
> calculating the Slur shape in the details property, as well options like
> height-limit, rate, excentricity and stuff.
>
> This means that many times instead of using shape it can be better to
> simply tweak a small parameter. Sadly there is little documentation for
> this.
>
> Valentin
>
> 11.02.2022 16:33:27 Knute Snortum :
>
> > Thanks Valentin and Kieren. I didn't know you could control this kind
> > of thing with grob parameters! I'll try out both suggestions. I was
> > always using \shape to change the shape of the slur, but now I'll look
> > for parameters to tweak.
> >
> > --
> > Knute Snortum
I find it is useful to start making sure that the global parameters
get you as close as possible,
before dealing with individual slurs.
Sometimes the thing you need to fix the worst offenders actually helps
everything else, in more moderate applications.
As an example, here is what is in most of my style sheets.
I think the free-head-distance is worth playing around with.
\layout {
\context {
\Staff
\override Tie #'thickness = #2.1
\override Slur #'thickness = #2.2
\override PhrasingSlur #'thickness = #2.6
}
\context {
\Voice
\override Slur.height-limit = 3.6
\override Slur.ratio = 0.36
\override Slur.minimum-length = 2.3
\override Slur.details.free-head-distance = 1.0
}
}
HTH,
Elaine Alt
415 . 341 .4954 "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
