Aaron Hill writes:
> On 2021-03-18 5:24 am, David Kastrup wrote:
>> So "a feature I would like \fixed to have" is more a function of
>> persuading a significant majority that your interpretation of \fixed
>> f''
>> is clearly the best for the sa
fferent virtual machine. I've not kept track of what happened since
then. There may have been experiments with JIT compilation and/or
machine code but I don't really know.
--
David Kastrup
;s curtains or workaround time. Outside of the compiler, there have
been significant fixes, but the number of people willing to invest work
here has shrunk.
> Not being able to use 64-bit addressing on Windows with GUILE 1.8 is
> an extremely serious problem.
I was of the opinion that we di
o old convert-ly conversions?
commit 7b37d8f9e9fb3e4c005dfb5c804f9bfbcc747360
Author: David Kastrup
Date: Tue Jan 5 02:10:44 2021 +0100
convert-ly rule for nested define-music-function calls
The previous convert-ly rule for 2.19.22 failed to properly convert
nested define-music-func
n
about an utterly non-working installation because they are the first to
get to test a version using bytecode.
--
David Kastrup
; but AFAICT Guile only looks at file modification dates (like most other
> software, including 'make'). And those did change when you switched
> between branches.
They should only change when the file contents change since Git
considers a file only changed (and touches it) when its file contents
hash changes.
--
David Kastrup
Jonas Hahnfeld via Discussions on LilyPond development
writes:
> Am Montag, dem 19.04.2021 um 11:48 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld via Discussions on LilyPond development
>> writes:
>>
>> > Am Montag, dem 19.04.2021 um 10:39 +0200 schrieb Thoma
ross-staff" means "reserve no skyline". It should really be more
specific, like "no skyline between systems x and y" because the _outer_
skylines should still be affected. Not sure how this related to
footnote numbers.
--
David Kastrup
hat we would probably have to replace our current pdf rendering system
> (ghostscript) with an alternative (e.g. libcairo). That sounds like a
> significant change.
>
> I would like to hear what other developers think.
Going through Cairo would be both a significant change and very
desirable.
--
David Kastrup
"Griffschrift."
A few years ago Mojca Miklavec was trying to implement something like
that. Maybe check with her how far she got?
--
David Kastrup
hat type of machines
> yet...
So we would depend on Microsoft (via Github) for everything except
Windows support?
That sounds ironic.
--
David Kastrup
2.12.3
> and all upstream versions.
I don't think layout-set-staff-size ever worked in a manner people
expected it to. It retains some globally set sizes and changes some
other ones. People are usually advised to use global-set-staff-size :
maybe layout-set-staff-size only makes sense in a score markup? There
you would not want to use global-set-staff-size I think?
--
David Kastrup
xtensions to indicate things like bookmarks, page links, PDF metadata.
With the pressure to remove non-standard extensions from GhostScript,
those might be under considerably more pressure to change or require
specific setup code to activate.
So we likely need to watch more closely what is happening.
--
David Kastrup
not.
And tempo-independent would leave us with a quite smaller head-ache.
--
David Kastrup
the culprit for much of the original code in lily-guile.hh
regarding the from_scm folderol, but I am somewhat at a loss about what
happens here after numerous changes of the original code (which may or
may not have worked: no idea).
--
David Kastrup
appen in HTML. Here is
one such info page (screen shot):
You see the stray [[image of music]] and some weird artifacts. Hardly
surprising I am currently entering percussion for use in a rhythm
machine, and am not good at reading percussion scores.
--
David Kastrup
David Kastrup writes:
> I read:
>
> make help
>
> infobuild Info documentation with images
> install-infoinstall Info documentation with images
>
> But when I use make info and make install-info, I get total crap pages
> like
Actually, it is a mixe
.
--
David Kastrup
kage configuration on the way.
As long as Guile-1.8 remains a recommended option, I don't see the point
in sabotaging the easiest (and certainly not deprecated as of version
1.8) way of using it.
--
David Kastrup
Dan Eble writes:
> On Jun 6, 2021, at 17:32, David Kastrup wrote:
>>
>> I'd argue that if we have
>>
>> \tempo 60
>> \time 6/8
>>
>> then we should likely interpret this (regarding the MIDI playing speed)
>> as
>>
>> \tem
David Kastrup writes:
> I tried inserting the following into
> Time_signature_performer::process_music ():
>
> Moment base_moment = from_scm (get_property (this, "baseMoment"),
> Moment (Rational (1, 4)));
>
> and I ge
a much more invasive redesign of LilyPond's note values in order
to facilitate more natural mensural notation entry.
I think that the way to work mensural timing at least with LilyPond's
current design is rather relying on scaled durations for note entry,
thus making things fit manually.
--
David Kastrup
would be tempo-independent and
>> probably correct more often than not.
>
> Wouldn't it be better for such cases to simply mention in the
> documentation that the existing information is not sufficient, and
> that the user has to specify a MIDI tempo manually?
Once there even is a way to specify it manually. In the mean time,
there still needs to be a strategy for existing documents.
--
David Kastrup
David Kastrup writes:
>> In my scores that use 6/8, I've already specified the beat as "4.", e.g.
>>
>> \time 6/8
>> \tempo 4. = 64
>>
>> so I don't understand why it would be important to have an
>> alternative that is interprete
Jonas Hahnfeld writes:
> Am Montag, dem 07.06.2021 um 16:03 +0200 schrieb David Kastrup:
>> I was just tripped up by
>>
>> commit 0fdf74b106d7b6c7dbb24a05f289ec4592724766
>> Author: Jonas Hahnfeld
>> Date: Mon Apr 5 21:03:14 2021 +0200
>>
Jonas Hahnfeld writes:
> Am Dienstag, dem 08.06.2021 um 11:08 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>>
>> > Am Montag, dem 07.06.2021 um 16:03 +0200 schrieb David Kastrup:
>> >
>> > > The options correspond in non-obvious ways to
kely
could.
--
David Kastrup
Dan Eble writes:
> On Jun 12, 2021, at 18:48, David Kastrup wrote:
>>
>> So how robust (or not) would be the following approach? Make it
>> possible to write in the timing track something like
>>
>> \rit 2/3 { \skip 1*2 }
>>
>> with the effect th
David Kastrup writes:
> Dan Eble writes:
>
>> On Jun 12, 2021, at 18:48, David Kastrup wrote:
>>>
>>> So how robust (or not) would be the following approach? Make it
>>> possible to write in the timing track something like
>>>
>>>
adware distribution
site temporarily. They resold the site before its reputation/value was
completely destroyed.
The current owners of Freenode don't appear to have such plans as to
yet.
Ok, end of rant.
+1, good thinking. Anybody else opening a vicarious issue for carrying
along the patch, or should I do the honors?
--
David Kastrup
time).
Thanks!
>> Greetings,
>> Janneke
>
> A side question: do I understand it correctly that
> Jan is your formal name and Janneke your nickname?
> I'm asking because a former contributor was called
> Janek, which confused me a lot in the first times.
The file DEDICATION in the LilyPond distribution may explain this to
some degree.
--
David Kastrup
rsteplst))
res
(loop (cdr rsteplst)
(cons* (scaletempo (cadr rsteplst) (car rsteplst))
(make-skip-music (ly:make-duration 0 0 intlen))
res)
'Score)
in it?
--
David Kastrup
Flaming Hakama by Elaine writes:
> David,
>
> On Mon, Jun 14, 2021 at 6:46 PM David Kastrup wrote:
>
>>
>> You saw the followup?
>
>
> Well, it seems I missed the follow up.
> Glad to see the functional approach.
>
>
>> The one with
>>
, existing higher language wrappers (C++ or Guile)
tend to result in somewhat awkward fits with the LilyPond code base.
I'd say "something's rotten in the state of Denmark", but then
Stroustrup has not been a principal driving factor of C++ for quite a
while.
--
David Kastrup
urns out good enough, there might be pressure to retire our
own PostScript generation as a maintenance hog. I don't think that the
case for that is as strong as that for retiring the TeX backend has been
with LilyPond 2.x.
At any rate, changing the default operation to forego Ghostscript would
warrant a major version number change.
--
David Kastrup
would want to work
with PS files rather than let LilyPond use them as intermediates.
>> A lower-maintenance option (longterm) would be to ultimately generate
>> PostScript via Cairo too and make \postscript pass the information to
>> Cairo (I presume that Cairo can be given backend-specific code).
>
> Sounds sensible.
--
David Kastrup
nk GUB has a spec for it, did you test it?
> How is this going to fare in Jonas' experimental
> scripts?
Long-term project: convert a bunch of stencil stuff to direct Cairo data
structures. That would move us towards more interactive LilyPond usage
patterns including integration into things like Frescobaldi's previewer.
--
David Kastrup
tuned to generate much smaller pdf code.
Well, the PostScript code sucks for a reason. It goes to tremendous
effort to make stems in bitmaps end up more consistent in thickness than
rendering left and right edge independently would.
--
David Kastrup
sense of). If
you use 5 as a duration, it's the parser that already bombs out (though
admittedly the lexer will treat it like 4, but then the lexer does not
distinguish durations from integers in general).
--
David Kastrup
"duration", SCM_EOL);
> mmrest_event_->unprotect ();
> }
>
> c->event_source ()->broadcast (mmrest_event_);
> }
Any Smob created with new is initially protected and needs exactly one
call to unprotect to be subject to garbage protection. A Simple_smob is
created as an SCM value via smobbed_copy () and is dependent on garbage
protection via this SCM value from the beginning. No call to unprotect
needed.
Some information may be in lily/include/smobs.hh .
--
David Kastrup
til it doesn't need it
anymore and the caller does not need to keep it live in some contorted
manner.
--
David Kastrup
Jonas Hahnfeld writes:
> Am Dienstag, dem 06.07.2021 um 17:03 +0200 schrieb David Kastrup:
>> Jean Abou Samra writes:
>>
>> > For example, if I were the author of the below code, how
>> > would I understand that the mmrest_event_ should be
>
eads to
more straightforward callers and more awful implementations.
Done right, you can forego looking at the awfulness in most cases,
making it a net win.
--
David Kastrup
gt; \new Staff \fixed c' {
> \new Voice { \tuplet 3/2 4 \grace { g8 g g a8 a a } b1 }
> \new Voice { \grace \tuplet 3/2 4 { g8 g g a8 a a } b1 }
> }
>
Looks like "if someone writes it that way, LilyPond should not take
liberties with it" to me. "Behind Bars" et al are instructions for us,
not excuses.
--
David Kastrup
and that appears to
be the case.
> not an important one though, because the second syntax
> is the intuitive way to write it anyway (at least how
> I'd spontaneously write it).
--
David Kastrup
ists. I consider it pretty
likely that the current code would cease working in Guile-2.x anyway, so
that may be the course forward.
--
David Kastrup
promising. Again, could you take care of that?
I'll take a look at what's happening here. But again: Guile-2.x is
supposed to be better in that respect? I find that surprising.
--
David Kastrup
--- end command line output
Have you uploaded/enabled your public ssh key to your repository?
--
David Kastrup
ook to get a single .texi file. However, I'd like to
> remark that generating zillions of tiny snippets is not really the
> kind of things users tend to do...
It's likely the workload for Wikimedia (though likely not via PDF) where
performance is pretty relevant.
--
David Kastrup
Jonas Hahnfeld writes:
> Am Montag, dem 30.08.2021 um 18:47 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld via Discussions on LilyPond development
>> writes:
>>
>> > Giving timing for a single HTML file is a bit dubious because it
>> > requires processi
ore generally useful, particularly since many examples
are copied by users and/or used as templates. There is no point in
making people depend on the PostScript backend unnecessarily.
--
David Kastrup
urse, probably only David K. can say for sure what
> implications that would have for parasing/lexing.
Guitarists (among other string instrument players) would likely object
to losing string number specifications.
--
David Kastrup
was that \x was the viable alternative to
> \*, not the multiplication sign (which is ASCII, by the by; just not
> commonly found on keyboard layouts).
ASCII is a 7-bit encoding; U+00D7 is certainly not within its range.
--
David Kastrup
Aaron Hill writes:
> On 2021-09-25 5:11 am, David Kastrup wrote:
>> Aaron Hill writes:
>>
>>> On 2021-09-25 12:46 am, Lukas-Fabian Moser wrote:
>>>> Aaron:
>>>>
>>>>> If the asterisk feels overloaded, you could use t
Jean Abou Samra writes:
> Le 25/09/2021 à 14:44, David Kastrup a écrit :
>> Aaron Hill writes:
>>> Still, be pedantic and miss the forest for the trees, my point was
>>> that \x is a good option if \* was going to be problematic.
>> Sure, but the problem
ys. \repeat unfold
> does not copy the music n times, it just wraps it
> in UnfoldedRepeatedMusic.
It's worth remembering that \repeat unfold , like all \repeat variants,
accepts an \alternative clause. And will probably be able to heed it.
I am not sure whether \repeat percent does so, but actually
interspersing material like <>\< <>\p or so would be perfectly
legitimate uses. Whether they make for great syntax is a different
question...
--
David Kastrup
last opportunity to
catch them, with \repeat \repeat ... \alternative possibly being tricky)
or a scorification hook does the final assembly.
Then we'd not need a special syntax (and the lookahead needed by
\alternative is a real nuisance) and could relitigate the meaning of
\repeat 4 .
--
David Kastrup
Dan Eble writes:
> On Sep 25, 2021, at 14:27, David Kastrup wrote:
>>
>> Dan Eble writes:
>>
>> How about we change \repeat ... \alternative in its structure to be
>> \repeat ... { \alternative ... }, namely introduce a separate music
>> expression for
Dan Eble writes:
> On Sep 25, 2021, at 18:55, David Kastrup wrote:
>>
>> Subject: [PATCH] Allow partial \repeat commands without \alternative
>>
>> This allows using
>>
>>\repeat \etc
>>
>> and
>>
>>\repeat \etc
>
nt"
>
> {
> \stemDown
> c'2^\cons
> \undo \stemDown
> c'2
> }
That code works fine here and produces the expected result:
--
David Kastrup
r than an exception (it would be a real nuisance to explain why
\alternative does not work with \etc forms in the current version).
Once \repeat is a proper music functions, it may be a prime example for
\etc usage.
--
David Kastrup
Carl Sorensen writes:
> On 9/27/21, 3:52 PM, "lilypond-devel on behalf of David Kastrup"
> behalf of d...@gnu.org> wrote:
>
> Jean Abou Samra writes:
>
> > is not entirely true: once a function is defined, it can be
> > relied on int
files.
Oh, ok. It would have been my expectation though possibly to be
adjusted for macro usage because macro replacements are not module
specific. Good thing then Han-Wen made that change.
--
David Kastrup
too much
>> or writing a single line in an esoteric, err, not very
>> commonly spoken programming language.
>
> Absolutely. It's an incredibly elegant tool.
<https://lists.gnu.org/archive/html/lilypond-devel/2015-07/msg00054.html>
--
David Kastrup
it doesn't really seem to provide anything to the user
they don't have already". "\etc" tells the reader "it's not necessary
to think more about this" while "\incomplete" tells the reader "it would
be necessary to think more about this".
Effective programming demagoguery. Who would have thought this to be a
thing?
--
David Kastrup
?
Why would you not use it in the paper block? mm is not a constant, it
depends on the output scale.
--
David Kastrup
David Kastrup writes:
> Werner LEMBERG writes:
>
>> Using it with
>>
>> ```
>> #(set-default-paper-size (cons 100 50)))
>> ```
>>
>> works like a charm. However, code like
>>
>> ```
>> #(set-default-paper-size (cons (* 100
g it in a specified module (a paper or layout module,
with the paper module having mm as 1 but the layout module working in
staff spaces or something like that).
--
David Kastrup
Using 'r' or 'R' or 'q'
> as a note name is already not supported.
They are perfectly fine as lyrics though. Entering the alphabet song
with durations would become a nightmare
> To me, the addition of this shorthand is worth a new element on this
> list.
R and r do not intermingle with the lexical categories of numbers.
--
David Kastrup
#(set-default-paper-size ''(100 . 50))
instead since you then need one quote level more. Alternatively you
could call eval only when given a list or a symbol and just retain what
you got otherwise. That may lead to somewhat inconsistent behavior.
--
David Kastrup
an engraver or
performer.
I am somewhat loth to just copy scheme-engraver.{cc,hh} to
scheme-performer.{cc,hh}, throw out everything Engraver-specific
(basically acknowledgers and possibly the associated processing phases)
and get something pretty much the same for now.
Does anybody have a better proposal?
--
David Kastrup
David Kastrup writes:
> So I tried the following
>
> Stress_performer =
> #(define-scheme-function (strong weak) (index? index?)
>(lambda (ctx)
> (define fired #f)
> (define (emit weight)
>(ly:broadcast (ly:event-source ctx)
>
uring out what music
constructs may or may not end up being valid.
So it was more of a point of "nobody uses this anyway" in connection
with "and good luck if they tried" I think.
--
David Kastrup
makefile:576: out/lilypond-notation.info] Error 1
make: *** [/usr/local/tmp/lilypond/stepmake/stepmake/generic-targets.make:6:
all] Error 2
Why does nobody else get this?
--
David Kastrup
Aaron Hill writes:
> On 2021-09-29 12:39 pm, David Kastrup wrote:
>> The question is whether we should do something like this as default,
>> possibly conditioned on whether any acknowledgers are present? Because
>> even if we cannot react to Midi data structures (since t
Jean Abou Samra writes:
> Le 30/09/2021 à 00:13, David Kastrup a écrit :
>> commit a1a418468e5cf481340667d433676dc00adf00fb
>> Author: Jean Abou Samra
>> Date: Wed Sep 1 18:54:24 2021 +0200
>>
>> Markup commands for conditionals
>>
>> has
John Wheeler writes:
> On 9/29/2021 3:35 PM, David Kastrup wrote:
>> John Wheeler writes:
>>
>>> Hello,
>>>
>>> Would someone please help me understand the reasoning behind removing
>>> the grammar from the Contributor's Guide? Was there
or so.
> 2. times = \repeat unfold \etc
When I was just occasionally using LilyPond, at some time when \tuplet
did not exist, I tended to be fuzzy about \time, \times, \tempo . I am
familiar enough these days that this is a mere anecdotal data point: I
have no idea how it would affect newcomers.
--
David Kastrup
Han-Wen Nienhuys writes:
> On Thu, Sep 30, 2021 at 12:24 AM David Kastrup wrote:
>>
>> Well, this is not as much supporting the MIDI layer as it is
>> employing the translator level for messing with music during
>> iteration. It's sort of annoying that it
the English version is not exactly rewarding either.
--
David Kastrup
David Kastrup writes:
> make info
>
> Oops, half of the images in Documentation/out-www/lilypond-changes.info
> are just [Image of music] text tags.
>
> make doc
>
> 45 minutes later:
>
> make info
>
> Still half of the images in Documentation/out-www/lilypo
Dan Eble writes:
> I have created a grob. Later, perhaps in another timestep, I want to
> discard that grob so that it has no bearing on the final score. Is
> there a way to do that? Is there a good example? How late is too
> late, etc.?
ly:grob-suicide! ?
--
David Kastrup
ue.
> As a reminder, this means the ability to merge
> one's patches as well as change merge request
> labels (which is useful often). Thoughts?
I'd ask him first.
--
David Kastrup
t_performer *unspecified*) c)))
}
}
}
I am typing some drum parts for our accordion orchestra into MIDI, and
multi-measure drum rolls become completely incoherent (or rather
completely coherent) without this. Try leaving off the performer...
--
David Kastrup
is any linear
representation being "executed", and source files are interpreted rather
than compiled, with no file-level representation ever being explicit.
That's not an academic difference since it is a non-trivial question
just what the structure of a MusicXML file is supposed to represent from
a given LilyPond input file.
--
David Kastrup
eporting list (and the
documentation does not really mention the list I think) but at least
gets stuff into the system (where it sometimes is left to rot without
further feedback).
That's still preferable to what you propose, but quite worse than having
an actual bug reporting list like we have now.
--
David Kastrup
Jean Abou Samra writes:
> Le 16/10/2021 à 13:09, David Kastrup a écrit :
>> Jean Abou Samra writes:
>>> Hi James, Werner, all,
>>>> I would say that 'most' emails to the bug list do NOT need an
>>>> issue, they are either replies to emails or
discussion where his role and
involvement are sort of given the kind of consideration that a CI script
gets.
Not that I am guilty of that here myself: the average LilyPond
developer's experience and opinion about the topic may differ from
Jean's exactly because we've seen and discussed the difference this
makes to LilyPond, but part of the reason it does of course is that
there actually are/is people/someone who care/s.
--
David Kastrup
DrumStaff"
> \alias "Staff"
>
> % (etc.)
>
> }
>
> That's the only instance of a context definition that contains _both_
> a parent context type (\Staff) _and_ \type "Engraver_group".
>
> Is that correct? I don't know enough about the inner wor
moment 1/4)
e'1
}
}
--
David Kastrup
Dan Eble writes:
> On Nov 3, 2021, at 18:40, David Kastrup wrote:
>>
>>
>> My use case is something different entirely and it does not work as
>> expected. This may or may not be a relevant minimal example for my use
>> case (no idea) but is weird
Dan Eble writes:
>> On Nov 3, 2021, at 19:20, David Kastrup wrote:
>>
>> Dan Eble writes:
>>
>>> On Nov 3, 2021, at 18:40, David Kastrup wrote:
>>>>
>>>>
>>>> My use case is something different entirely and it does
David Kastrup writes:
> Dan Eble writes:
>>
>> Using \tuplet 1/1 instead of \volta 1 causes the same problem.
>>
>> Nesting the \set within <<>> or {} makes the problem go away. Does
>> that serve as a work-around in your use case?
>
> There
David Kastrup writes:
> David Kastrup writes:
>
>> Dan Eble writes:
>>>
>>> Using \tuplet 1/1 instead of \volta 1 causes the same problem.
>>>
>>> Nesting the \set within <<>> or {} makes the problem go away. Does
>>> that
the core C++ parts, he also has done quite a bit of fixing.
There are also a number of other people (like David Nalesnik) who have
contributed large pieces of magic mostly in the Scheme domain, partly as
off-the-cuff contributions to discussions on the list.
--
David Kastrup
ginner stuff. It's actually architecture-level
stuff, diluting the Voice separation that turns ad-hoc polyphony (in
contrast to fixed polyphony determined by player separation or at least
instrument part separation) like that common in piano and other keyboard
music into a nuisance for typesetting with LilyPond.
--
David Kastrup
aving the user enter a dotted duration in the first place if that is
what you want to see.
> 3. Is there an ly:string->duration [or similar] function, that will
> take "4." and turn it into a duration that I can use to generate the
> right glyph(s)?
Just don't use a string to start with.
--
David Kastrup
l
> accept a duration for the “denom” *without breaking existing code or
> requiring a convert-ly rule*, then that would be home run!
I have no idea what you are even imagining here because the denominator
for \time is not written as a separate number in the first place.
--
David Kastrup
uld_ we want it? If it becomes impossible to see what the author
actually wants because there is so much overlap in how the arguments
could be interpreted, where is the advantage?
This is just "I want the computer to typeset what I mean, not what I
say". But that's not just confusing to computers.
--
David Kastrup
t what of a myriad of variants in meaning is intended makes it
reasonable for the user to see what is intended.
It's not like I haven't voiced that opinion before, so I have no idea
how I could contribute towards you considering this question resolved.
--
David Kastrup
701 - 800 of 6220 matches
Mail list logo
