Hi,
Finally getting a chance to play around with this. Thanks for writing up
this proof of concept! I'm learning a lot.
A few questions:
1) When you build alive?-instr-list you seem to assume a correspondence
between vertical-axis-group-list and instrument-names-list. But is that
actually guaran
Hi all,
I posted some earlier versions of this Scheme engraver to the user list. It
provides an intuitive user interface to control whether shared or separate
staves are printed, and should work for combinations of 4 or more parts.
The examples are in the tests.ly file attached, while the engraver
Thanks, Thomas.
As you can probably tell, the Scheme code as currently submitted is more
like a proof of concept. I will go through and properly integrate it into
the Lilypond code organization.
Re cdr is not a predicate — the list being processed here is composed of
pairs, the cdr of which is ##
Will play around with AnnounceNewContext — looks like it does what I'm
looking for. Thanks!
For segmenting list by ##t/##f tail, my code needs to preserve order. The
##t/##f value represents whether the next staff down may be condensed
upward. So:
((1 . #t) (2 . #f) (3 . #t) (4 . #t)), if we imag
Surprised to see that the http versions of those pages are accessible.
Shouldn't they redirect to https?
On Sat, Feb 18, 2023 at 12:13 PM Jonas Hahnfeld via LilyPond user
discussion wrote:
> On Sat, 2023-02-18 at 14:43 -0500, Shane Brandes wrote:
> > That is great, but where can one find a list
Hooray! I can finally compile my whole symphony draft on Windows! Thanks
devs for all the work that went into this.
On Sat, Jun 24, 2023 at 6:42 AM Jonas Hahnfeld via LilyPond user discussion
wrote:
> We are happy to announce the release of LilyPond 2.25.6. This is termed
> a development release
Hi all,
Sharing here some extremely rough ideas on ways to potentially improve
spacing for MetronomeMarks, RehearsalMarks, etc. Please pardon the very
long message and rough code. Since I'm unsure how consistently I will be
able to work on this, I wanted to share my proof of concept/work in
progre
Hello friends,
I’ve found that one of the more cumbersome tasks in Lilypond is engraving
chromatic music for concert harp. When entering markups manually for each
pedal change, it’s difficult to achieve clean and consistent formatting,
and very easy to make errors. I’d like to share my solution to
I can see duration vs. moment becoming a source of confusion, since these
are not the same type. I would expect a property named baseDuration to take
a value of type ly:duration?.
That is starting to open a can of worms, though, because the usage of
duration vs. moment is inconsistent in the codeb
Hi Luca,
I believe the package you need is called guile-3.0-dev.
Saul
On Fri, Sep 20, 2024 at 10:16 AM Luca Fascione wrote:
> Hi all,
> I'm trying to build lilypond and it fails I think while building the
> documentation
>
>
> Setting GUILE_AUTO_COMPILE to '0'
> Setting GUILE_WARN
baseBeatLength? I don't have a strong opinion either way, but it seems like
another natural possibility.
On Thu, Oct 3, 2024, 12:44 AM Werner LEMBERG wrote:
>
> > To follow up the replacement of make-moment by \musicLength [1], I
> > think it would make sense to rename baseMoment to beatBaseLeng
Hi all,
I'm trying to figure out how to compile Lilypond on MacOS (Sequoia, Intel
Mac, Homebrew) so I can do things when I'm away from my desktop.
So far I've succeeded in compiling Lilypond itself, but I'm completely
stumped on why I can't build regtests. The error I get is:
Making input/regres
Thanks, attached is the log from running `make test-baseline VERBOSE=1`.
Not zipped because it's pretty small. This is after compiling using Xcode
clang-16, which should be the same as used by Homebrew for Guile. Other
than using clang, same options and environment variables as in my earlier
messag
ebrew installed gmake,
which is up to date.
On Sat, Dec 28, 2024 at 10:27 PM Saul Tobin
wrote:
> Thanks, attached is the log from running `make test-baseline VERBOSE=1`.
> Not zipped because it's pretty small. This is after compiling using Xcode
> clang-16, which should be the same
LilyPond has never guaranteed backward compatibility of its API between
versions, except for minor versions of the same stable release. It's
usually the case that between any given two versions only a small subset of
code requires changes, but you should always assume that when upgrading to
a new L
I don't want to speak for Dan, but I believe the objective is to get user
code moved over to actually using exact rationals rather than moments for
these properties, not just to allow the use of exact rationals in addition
to moments.
It's worth pointing out that there were extended discussions on
>
> Do you think this isn't prominently enough? If so, how could this be
> improved?
>
I think that as with many warnings, the fact that it's always there leads
to it fading into the background for many readers, particularly as they
learn from experience that for *most* code, *most* of the time,
>
> Isn't that the reason that the changes documentation is written in the
> first place...to warn users about upcoming changes? So an extra warning
> in the email would be redundant, and this warning would also fade into
> the background? (by the way, I don't think that comparatively a _lot_ of
>
Hi all,
I want to share a new feature I just pushed for lilypond-ts-mode: cycle
forward/backward through the same rhythmic position in all parts, even if
they are spread across multiple files. This is made possible by evaluating
LilyPond code within a Guile REPL using an engraver that outputs a l
>
> I think it is unfair to put this burden on us developers
> for the 2.25.xx series.
Fair enough. I was mainly thinking it could be worthwhile for the
developers' sake to reduce the number of email threads from users taken by
surprise when their code stops working. A fair amount of time seems t
>
> Btw, if I were on my phone, the manipulation necessary to drop the reply
> block would have taken substantially longer than
> typing the message itself.
>
> As Luca
> pointed out, it's not just Google: most of the popular email clients
> behave the same way.
> I think that if this "email e
Doesn't width typically refer to a pair of numbers?
On Wed, Dec 11, 2024 at 6:37 PM David Kastrup wrote:
> Dan Eble writes:
>
> > On 2024-12-11 14:04, Trevor Bača wrote:
> >
> >> Regardless of the names of Lily's underlying (and therefore
> >> user-invisible?) types, these user-facing context p
Regarding length vs. moment, David's comment from the previous thread on
this topic may shed some light:
https://mail.gnu.org/archive/html/lilypond-devel/2024-10/msg00017.html
On Thu, Dec 12, 2024 at 11:16 AM Trevor Bača wrote:
> On Wed, Dec 11, 2024 at 4:32 PM Dan Eble
> wrote:
>
> > On 2024-1
milar reasons
to duration vs. musicLength.
On Thu, Dec 12, 2024 at 5:37 PM Christopher Heckman <
christopher.heck...@asu.edu> wrote:
> On Thu, Dec 12, 2024 at 9:17 AM Saul Tobin
> wrote:
> >
> > Doesn't width typically refer to a pair of numbers?
> >
>
> No; s
I mean it's not a Lilypond specific construct. Duration log + augmentation
dots is a music notation construct that Lilypond faithfully represents
using a type named duration. I don't think there's any inherent reason that
representation of musical time is more deserving of the name duration than
wh
I'm not sure what in my message gave the impression that I'm in love with
the term "music length." All I said is that I think it's completely clear
what it means.
Is there a concrete proposal of a more elegant name that doesn't require
using the same name for two different types?
On Fri, Dec 13,
In English, I would also use the term "note value" or "rhythmic value" to
describe something like "dotted quarter." I would have mild concerns with
the use of the word "value" as part of a type name, since it also
generically refers to any data bound to a variable.
On Fri, Dec 13, 2024 at 6:32 PM
I've used it once to draw a vertical connecting line in a diagram of chord
relationships. But I don't think it was really the intended use and I could
probably have accomplished the same thing using other methods.
On Thu, Dec 19, 2024 at 5:30 PM Dan Eble wrote:
> Are "grid lines" used in the rea
I think merging \compoundMeter into \time as a single command would be
great. IMO an even bigger improvement would be to support compound meters
without requiring Scheme syntax. The parser already supports
comma-separated integer lists and dot-separated symbol lists. How feasible
would it be to sup
On Tue, Jan 28, 2025 at 6:18 PM David Kastrup wrote:
> Saul Tobin writes:
>
> > I think merging \compoundMeter into \time as a single command would be
> > great. IMO an even bigger improvement would be to support compound meters
> > without requiring Scheme syntax
lists on the other
hand seems quite useful.
Saul
On Tue, Jan 28, 2025 at 7:11 PM David Kastrup wrote:
> Saul Tobin writes:
>
> >> On Tue, Jan 28, 2025 at 6:18 PM David Kastrup wrote:
> >>
> >>> Saul Tobin writes:
> >>>
> >>> > I thi
Hi all,
I've been working for a few months on a Lilypond major mode for Emacs using
Treesitter: https://github.com/shevvek/lilypond-ts-mode. I had mentioned
this in issue 6743 earlier, but it's now far enough along that it feels
worth sharing on the list.
Currently, lilypond-ts-mode supports:
* R
Yup. I believe both are in non-GNU ELPA.
On Wed, Jan 29, 2025 at 12:50 AM Werner LEMBERG wrote:
>
> > I've been working for a few months on a Lilypond major mode for
> > Emacs using Treesitter: https://github.com/shevvek/lilypond-ts-mode.
>
> Sounds very good! However, on this page there is no
> working using pdf-tools.
> Greetz,
> Immanuel
>
>
> On Wed, Jan 29, 2025 at 2:59 AM Saul Tobin
> wrote:
>
>> Hi all,
>>
>> I've been working for a few months on a Lilypond major mode for Emacs
>> using
>> Treesitter: https://github.com/s
Would this MR potentially also fix
https://gitlab.com/lilypond/lilypond/-/issues/6640 and
https://gitlab.com/lilypond/lilypond/-/issues/6641?
On Thu, Jan 2, 2025 at 3:21 PM Simon Albrecht
wrote:
> On 30.12.24 16:04, Thomas Morley wrote:
> > There's alsohttps://gitlab.com/lilypond/lilypond/-/merg
ly:context-property-where-defined returns differently depending on if a
property is unset or explicitly set to '() – I'm guessing this is one of
the things you had in mind by "not really pretty"?
On Sat, Jan 4, 2025 at 5:18 PM David Kastrup wrote:
> Dan Eble writes:
>
> > Old-timers,
> >
> > Fo
A deep loss to the Lilypond community. Urs lives on through the many
musical projects that incorporate his work.
Saul
On Tue, Dec 31, 2024 at 7:41 AM Jan-Peter Voigt wrote:
> Dear Lilypond developers!
>
> At the turn of the year I received very sad news. Urs Liska, co-initiator
> and developer
>
> if you have reasonable ideas how such API changes could be
> communicated better I am sure people would love to hear them and if
> feasible
> incorporate them.
IMO one relatively simple change would be to add a note to the release
announcement email mentioning that users should expect to need
I assume this is directed at least in part toward me. Including thread
history below the reply is Gmail's built-in behavior. If there were a
setting to change that, I'd be more than happy to use it, but as far as I
know it's not possible to change that default. I can do my best to remember
to manua
>
> Instead of the old interface use this deprecated new interface,
> instead of just: Use the same interface, but you will need to add a type
> conversion.
The deprecated properties aren't intended for end users to write in their
code. New human written code should use the non-deprecated names a
Hi all,
One of the longstanding workflow limitations of LilyPond is the difficulty
of inserting or removing measures, stemming from an inability to navigate
"vertically" through a score's music input code (i.e. cycling through the
same rhythmic position in different parts). I've been working with
>
> This looks very interesting, thanks! Could you provide a short video
> (i.e., a screen capturing session) that demonstrates the
> functionality? I guess we would all benefit from seeing this 'in
> action' :-)
>
Great idea! Here is a quick demo:
https://www.youtube.com/watch?v=IFtCpMpOM1o
Sa
42 matches
Mail list logo
