Valentin Petzel writes:
> Am Samstag, 1. Juli 2023, 18:48:31 CEST schrieb David Kastrup:
>> The funny thing is that I suspect Han-Wen might still be surprised to
>> hear what Staff.property "actually means".
>>
>> It's been around for quite longer than its "actual meaning". But of
>> course I s
Am Samstag, 1. Juli 2023, 18:48:31 CEST schrieb David Kastrup:
> The funny thing is that I suspect Han-Wen might still be surprised to
> hear what Staff.property "actually means".
>
> It's been around for quite longer than its "actual meaning". But of
> course I should be the last person to compl
Le samedi 01 juillet 2023 à 11:30 -0700, Curt McDowell a écrit :
> I tend not to use convert-ly because I feel upgrading a file version
> would unfairly force anyone who wants to compile my music to upgrade
> their LilyPond installation. Upgrading might not be straightforward when
> using a stan
I tend not to use convert-ly because I feel upgrading a file version
would unfairly force anyone who wants to compile my music to upgrade
their LilyPond installation. Upgrading might not be straightforward when
using a standard distro, and I'd hate for someone to risk destabilizing
their workin
On Sat, Jul 1, 2023 at 3:41 AM Valentin Petzel wrote:
> Yes, of course it is :). But I think there are reasonable cases to do so.
> The
> issue here is of course stability: If we wanted to issue some code which
> is
> supposed to remain functional for years to come, this is ill suited, as it
> do
Valentin Petzel writes:
> Hello Vlad,
>
> in addition to Jean’s answer it might be helpful to understand what
>
> Staff.property
>
> actually means. This get’s parsed to a list of the symbols 'Staff and
> 'property. So you can in fact simply remain with scheme, and directly enter
> #(list scope
Hello Vlad,
in addition to Jean’s answer it might be helpful to understand what
Staff.property
actually means. This get’s parsed to a list of the symbols 'Staff and
'property. So you can in fact simply remain with scheme, and directly enter
#(list scope 'property) like this
%
\version "2.
Le samedi 01 juillet 2023 à 16:42 +0200, Volodymyr Prokopyuk a écrit :
> I'm trying to define a music function as below, however I've faced
> difficulties with parameter predicates, visibility of the Staff object, and
> flexibility of the solution ideally without code duplication
>
> **Desired
Hi,
I'm trying to define a music function as below, however I've faced
difficulties with parameter predicates, visibility of the Staff object, and
flexibility of the solution ideally without code duplication
*Desired music function* (the code is not working)
momentBeat = #(define-music-functio
Le samedi 01 juillet 2023 à 12:46 +0200, Valentin Petzel a écrit :
> Maybe Lilypond should also give a warning if it on a lower language version.
> The assumption here is that lower language versions are generally compatible
> with higher program versions, but this is not true. So basically we on
Maybe Lilypond should also give a warning if it on a lower language version.
The assumption here is that lower language versions are generally compatible
with higher program versions, but this is not true. So basically we only
guarantee that a specific language version will be working with the s
Yes, of course it is :). But I think there are reasonable cases to do so. The
issue here is of course stability: If we wanted to issue some code which is
supposed to remain functional for years to come, this is ill suited, as it
does not solely rely on the interface Lilypond provides. So if you
12 matches
Mail list logo
