incorrect. #'(4 . "4.") does not consult the LilyPond parser
beyond the # and there is absolutely nothing that would magically turn
"4." into a duration. Nor should there be in my book.
--
David Kastrup
ched. Please try again later:
retry timeout exceeded
Reporting-MTA: dns; eggs.gnu.org
Action: failed
Final-Recipient: rfc822;kieren_macmil...@sympatico.ca
Status: 5.0.0
Remote-MTA: dns; mxmta.owm.bell.net
Diagnostic-Code: smtp; 421 Connection limit reached. Please try again later:
retry tim
idea how you arrive at the conclusion
that it is possible to have one work but not the other.
--
David Kastrup
il to you
bounces anyway and including you would likely cause the list server to
not deliver a copy to you, turning the purpose of including you in the
list of recipients on its head.
--
David Kastrup
t *);
lily/time-signature-engraver.cc:Time_signature_engraver::listen_time_signature
(Stream_event *ev)
lily/time-signature-performer.cc: void listen_time_signature (Stream_event *);
lily/time-signature-performer.cc:Time_signature_performer::listen_time_signature
(Stream_event *ev)
--
David Kastrup
that where a feature is not generally associated with a
particular name, it's not really helpful to use a name in that manner.
So I'd rather use something like \musicFraction or so to indicate this
kind of construct.
--
David Kastrup
struct.
>
> Agreed.
>
> I hope nobody inferred from my lighthearted response to Aaron’s post
> that I’d *actually* want any function to literally bear my name!? =)
In which case \macMillan would be the better choice anyway.
--
David Kastrup
said earlier, I'm not sure that it's worth changing the
> internals since they work so well for the lilypond core functionality
> (traditional western music), but I noticed the semantic error as I
> read this thread.
What do you want to change? Entry or internals? And how so?
--
David Kastrup
to the parser could enable more generalized fraction-like
> constructs such as number/duration, but I am unsure the cost.
>
> David, do you know any reasons why FRACTION is a token and not a
> parser rule?
Wagonloads of lookahead?
--
David Kastrup
Carl Sorensen writes:
> On 11/13/21, 1:09 PM, "David Kastrup" wrote:
>
> Carl Sorensen writes:
>
> > I have not been a strong contributor to this thread. And I have not
> > been a strong advocate for the time signatures with a notehead in
onds perfectly to “8 events per measure, each
> event having a duration equal to 1/20th of a whole note”.
What duration is equal to 1/20th of a whole note in LilyPond?
--
David Kastrup
me 1/4
> \tuplet 5/4 { c''16 16 16 16 16 }
> }
>
> The denominator of a #'note-denom time signature would look like this:
> *
> Hope that helps!
> Kieren.
It doesn't answer the question.
--
David Kastrup
tion 4 0 4/5) but that has no
unique printed representation different from (ly:make-duration 4), and
(ly:make-duration 4 0 4/5) and (ly:make-duration 4 0 8/10) are
absolutely indistinguishable.
--
David Kastrup
Aaron Hill writes:
> On 2021-11-13 1:22 pm, David Kastrup wrote:
>> Aaron Hill writes:
>>> David, do you know any reasons why FRACTION is a token and not a
>>> parser rule?
>> Wagonloads of lookahead?
>
> I think the only practical action is for me to
r or
> Lilypond’s internal representation of durations to give a more
> specific or nuanced or helpful answer than that. ;)
The problem is that handwaving looks great in discussions but does not
deliver a definition useful for implementation.
--
David Kastrup
Carl Sorensen writes:
> On 11/13/21, 4:05 PM, "David Kastrup" wrote:
>
> Kieren MacMillan writes:
>
> > Hi David,
> >
> >> It doesn't answer the question.
> >
> > Did my explicit answer in the other email
t time signature representation. That makes that
representation unable to adequately reflect existing music while at the
same time being considerably more complex. You consider both the added
complexity as well as ditching the ability of others to represent
_their_ music an adequate sacrifice for gaining -- what exactly?
--
David Kastrup
Kieren MacMillan writes:
> Hi David,
>
>> There just is no uniquely identified print form using a note in the
>> denominator for that time signature representation.
>
> As I’ve explained several times, there is.
Give it for 8/20 then.
--
David Kastrup
times, there is.
>
> Here’s a screenshot for anyone who can’t envision the uniquely identified
> print form of 8/20 using a
> note in the denominator:
> *
How is that uniquely identified? Why couldn't it be subscripted with 10
instead of 5?
--
David Kastrup
uctured or
expressed, in opposition to your and Carl's statements about what
meaning the parts of a time signature are supposed to inherently have,
leading to a proposal of generally changing the current representation
by involving musical durations for the denominator.
--
David Kastrup
ress previously valid
semantics but also lacks the ability to distinguish between cases it is
supposed to newly be able to express, the design needs fixing rather
than a vigorous defense.
Of course pointing that out makes me the bad guy standing in the way of
progress.
--
David Kastrup
Carl Sorensen writes:
> On 11/14/21, 9:33 AM, "David Kastrup" wrote:
>
> Kieren MacMillan writes:
>
> > Hi David,
> >
> >> How is that uniquely identified? Why couldn't it be
> > subscripted with 10 instead of 5
is that Lilypond has
> *never* handled time signatures correctly (where “correct” means
> “according to the accepted definition of 'time signature'”).
Nor has his ever handled durations correctly according to your
definition of "duration". Which means you should get a grip on what
LilyPond calls a duration before proposing to use it.
--
David Kastrup
Flaming Hakama by Elaine writes:
> From: David Kastrup
>> Kieren MacMillan writes:
>> > The time signature “9/8” does *not* (as you imply) actually convey
>> > *any* information about the number of “beats” — the *convention* does
>> > that.
>>
>
Aaron Hill writes:
> On 2021-11-15 3:30 am, David Kastrup wrote:
>> Not everyone picking 6/8 unambigulously wants to see this
>> interpreted as
>> 2 notes of 4. duration. So forcing a particular duration expressing a
>> length not inherently specified is putting words
ication, or 3 times { 8 8 8 } for a different
representation of 9/8 meter.
With regard to meters, obviously there are also numeric variations like
writing 3+2 in the numerator. The amount of visual possibilities is
large enough that forcing visual and functional components to be
interchangeable seems like a bad idea.
--
David Kastrup
f music were only allowed to express Gould-correct
notation, we would not be having this discussion in the first place.
--
David Kastrup
o the MIDI in Performance::output as far as I can see and
a placeholder is set up in Control_track_performer::initialize .
The standard does not appear to consider this mandatory; it may require
a bit of refactoring to be able to leave it off in LilyPond.
What do people think we should be doing ideally?
--
David Kastrup
Aaron Hill writes:
> On 2021-11-19 11:28 am, David Kastrup wrote:
>> What are other people's feelings here? Should we allow an explicit
>> specification of the title as "" to override such a fallback?
>
> Could it work to add a midiTitle property/field to
o the filename on their own) and the code
appears sort of icky regarding how to implement that behavior so it's
possible that it would entail some work without best payoff for my
particular hardware.
Though I should be easily able to test that case by hardcoding no title
at all in the MIDI and then seeing what happens when I try playing the
file.
Maybe I'll check that first.
--
David Kastrup
David Kastrup writes:
> I have no idea what my arrangers would display then (maybe they even are
> smart enough to fall back to the filename on their own)
Turns out they are. Problem is how to convey to Performance::output the
difference between "" and no name at all. It i
text that may contain
special characters or commands that should not be interpreted, such as
computer input or output ('@example' interprets its text as regular
Texinfo commands). This is especially useful for including
automatically generated files in a Texinfo manual.
--
David Kastrup
to prevent, but
System does not use it.
Note also that all_elements_ is initialised to nullptr only _after_
garbage collection has already been activated: the in-class
initialisation syntax makes it easier to gloss over initialisation order
(which is not changed).
I'll try GC-proofing System. Only time will tell whether this makes a
difference and/or whether other problems remain.
--
David Kastrup
David Kastrup writes:
> Jonas Hahnfeld via Discussions on LilyPond development
> writes:
>
>> Am Donnerstag, dem 25.11.2021 um 08:40 +0100 schrieb Jonas Hahnfeld via
>> Discussions on LilyPond development:
>>> Am Mittwoch, dem 24.11.2021 um 23:01 +0100 schrieb
David Kastrup writes:
> David Kastrup writes:
>
>> Jonas Hahnfeld via Discussions on LilyPond development
>> writes:
>>
>>> Am Donnerstag, dem 25.11.2021 um 08:40 +0100 schrieb Jonas Hahnfeld via
>>> Discussions on LilyPond development:
>>>&
David Kastrup writes:
> David Kastrup writes:
>
>> David Kastrup writes:
>>
>>> Jonas Hahnfeld via Discussions on LilyPond development
>>> writes:
>>>
>>>> Am Donnerstag, dem 25.11.2021 um 08:40 +0100 schrieb Jonas Hahnfeld via
>>
Jonas Hahnfeld writes:
> Am Donnerstag, dem 25.11.2021 um 16:18 +0100 schrieb David Kastrup:
>> > System::init_elements has
>> >
>> > set_object (this, "all-elements", scm_arr);
>> >
>> > So *all_elements_ is protected as par
ce on a page when they are non-empty as well as a given
fraction of their content size to make it possible to account for, say,
two-column footnotes).
The page _breaker_ can then still continue being lowlevel.
--
David Kastrup
Flaming Hakama by Elaine writes:
> On Mon, Nov 15, 2021 at 11:11 AM David Kastrup wrote:
>>
>> Where "convert this into a reasonable time signature" would imply the
>> ability to convert this into the two separate components, a functional
>> and a visu
or Darwin and it's conceivable that a command line
application like LilyPond could be delivered in that manner without
involving Apple's proprietary build environments. Likely without
offering platform-specific font integration.
--
David Kastrup
ing it directly from the command line, with the "-dgui" switch
> added.
Why would you add -dgui when running from the command line?
--
David Kastrup
ight have mistakenly used % as a comment character in
Scheme mode (in Scheme, the comment character rather is ; ).
--
David Kastrup
n events, one will
likely still meet up afterwards in the virtual space at the lecture hall
and walk the usual tables looking for the usual participants, from the
space of one's private computer.
Anyone interested in promoting LilyPond there?
--
David Kastrup
dealing with fluctuation was really kept working by the efforts of
informal Ubermeister Graham and slowly decayed after his departure from
the project.
--
David Kastrup
midiDrumPitches.ridecymbal = fis,,
midiDrumPitches.ridecymbala = b
midiDrumPitches.ridecymbalb = a
midiDrumPitches.crashcymbal = g
\midi
{
\context {
\Score
drumPitchTable = #(alist->hash-table midiDrumPitches)
}
}
you'll get across-session bleed of assignments when making them
destructive. Another option is, of course, to do what amounts to an
in-place modification of a structural copy.
--
David Kastrup
David Kastrup writes:
> For stuff like
>
>
> midiDrumPitches.ridecymbal = fis,,
> midiDrumPitches.ridecymbala = b
> midiDrumPitches.ridecymbalb = a
> midiDrumPitches.crashcymbal = g
>
>
> \midi
> {
> \context {
> \Score
> drumPitchT
; default?
My personal idea would be to use relative links anyway, but that might
possibly not work with the kind of "URL helper" setup that typically
ends up calling lilypond-invoke-editor .
--
David Kastrup
alist in
> its search for a matching pair, it could well set the
> last cdr to add the new pair at the end.
An empty list does not have a last cdr.
--
David Kastrup
as made to save the cost
> of detecting them, as it does not seem to be a code path used heavily
> at all.
Overrides of subproperties are used pretty extensively in some newer
code.
Maybe it would make sense to check where code is being used before
trying to change it?
--
David Kastrup
1.8)
Processing `/tmp/bab.ly'
Parsing.../usr/local/share/lilypond/2.23.5/scm/lily/lily.scm:978:21: In
procedure ly:parse-file in expression (ly:parse-file file-name):
/usr/local/share/lilypond/2.23.5/scm/lily/lily.scm:978:21: Wrong type
(expecting pair): 0
And frankly, I don't see something wrong with that. Could use a better
error locator, sure. But it's not the same as a core dump.
--
David Kastrup
combine”, r“partCombine”, str)
>
> Would that work?
Probably would change a couple too many occurences.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Charles Winston writes:
>> On May 29, 2017, at 1:40 PM, David Kastrup wrote:
>>
>> Charles Winston writes:
>>
>>> Could you explain the following line which appears all over convert
>>> rules.py:
>>>
>>> str = re.sub (r“str
to take further hits to my bodily health.
In a nutshell: I'd appreciate support but it will be a bit of time
before I deliver good value for it again.
All the best
David
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
ng about here.
> I'm telling you this because git grep is your friend; you will want to
> learn to use this tool well when trying to work your way through the
> LilyPond source code.
Little question about that.
--
David Kastrup
___
lily
ly access exported definitions (defined using define-public or
explicitly exported using (export ...)) outside of the module itself.
But even then, only entities defined at top level are part of the module
interface and can be exported: all other definitions are local to the
enclosing definit
o update this?
The manual also says:
You may need to install the additional bash-completion package, but
it is definitely worth it. After installation you must log out, and
then log back in again to enable it.
--
David Kastrup
___
l
y would it not have been this way to begin with? Is there some
> side-effect that I can't predict?
Maybe check the effects that super- and subscripts cause on a block of
text? I'd not be able to tell offhand whether that's a concern, nor
whether it possibly bei
.18.2 does not even compile
using gcc-7 anymore is something I want to avoid.
So I'd rather pitch for a timely release of 2.20. There have been a few
critical bugs flagged, however. I'll take a look at them eventually but
if someone else has a good idea...
--
David Kastrup
___
ore of a
runtime dependency so it's not really something we would refuse a build
for.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
(continuous parts in
> exactly one voice context per part) and change their context
> properties instead?
For shared/non-shared stems that would not seem to fit the current
logic. Mind you: for piano music the rather rigid relation of stems and
slurs and noteheads with v
Paul writes:
> On 06/07/2017 04:34 PM, David Kastrup wrote:
>
>> tomorrow I am leaving for physical therapy.
>
> Hope it goes well David!
>
>> So how is it going to end up? Barring objections, I'll probably branch
>> off a stable release branch earl
are no problem.
>
> In my humble opinion, after or before releasing 2.20,
> it is better to discontinue some platforms' binary release.
If we call it "stable", it better be stable. So I think it would make
sense to make the decision for the release.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
-the-fly #(on-page 3) "blabla"
instead of
\markup \on-page #3 "blabla"
? Where is the point in this particular obfuscation?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Thomas Morley writes:
> 2017-06-11 15:08 GMT+02:00 David Kastrup :
>>
>> \on-the-fly gets as first argument a function that it calls on the
>> second argument as if the first argument was actually a markup command.
>>
>> Why not make the first argument actually
a for a proper fix.
Do you have an idea about the underlying problem?
> So I suggest to revert it.
> At least it should not go into 2.20 in the current state.
Noted.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Paul writes:
> On 06/12/2017 01:00 AM, David Kastrup wrote:
>
>> The use case is similar to that of lambda: creating a procedure on the
>> fly without giving it a name.
>
> Ah, got it. Then makes sense to avoid having to use on-the-fly, by
> converting those named
Lyric project… but that is, I believe, dead in the water. Is
> there any hope of getting this into the codebase? I'm happy to take
> this "stub" (much more than a stub, of course!) and shepherd it
> through the dev process to the goal line — but I don't want to start
27;articulations item in
> 'elements.
All post events are stored in 'elements, not as an 'articulations item.
> Should this code be eliminated?
Have you tried running "git blame" on the passage? It leads to commit
commit d22c6ec121fc0a5740fc7c6ca4277db56d0a4e7d
iro data structures
while keeping most of the current code except where the code would
duplicate Cairo API calls in a reasonably straightforward way.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
d concern font handling
but I think it integrates with FreeType as well as Pango.
It would likely be harder to mess around with things like Woff font
support in SVG but the overall consistency and possibilities for better
hand-off and post-processing of the typesetting results would
Han-Wen Nienhuys writes:
> On Sat, Jun 24, 2017 at 12:43 PM, David Kastrup wrote:
>> What does that mean? Mainly a viable migration strategy where we might
>> be able to drop catering for a whole lot of graphics programming
>> ourselves by introducing a dependency on Ca
k...@aspodata.se writes:
> Han-Wen Nienhuys:
>> On Sat, Jun 24, 2017 at 12:43 PM, David Kastrup wrote:
>> > What does that mean? Mainly a viable migration strategy where we might
>> > be able to drop catering for a whole lot of graphics programming
>> > ours
k...@aspodata.se writes:
> David Kastrup:
>> k...@aspodata.se writes:
>>
>> > Han-Wen Nienhuys:
>> >> On Sat, Jun 24, 2017 at 12:43 PM, David Kastrup wrote:
> ...
>> > If no one else like to care for postscript, I can step in to handle it.
&g
er, so should Cairo-generated PostScript do: using the PostScript
backend of Cairo does not run through PDF in the first place.
> Though, my conclusion was that pdf is not better than ps regarding
> postprocessing, and yes I know that pdf (depending on
e years of
LilyPond 2? Basically you are stating that you want to do exactly that
with the PostScript backend, and I am telling you that it will be more
work than you likely realize.
So you tell me I have no idea what I am talking about but don't bother
to point out _any_ particulars where you consider my analysis faulty.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Han-Wen Nienhuys writes:
> On Sat, Jun 24, 2017 at 5:54 PM, David Kastrup wrote:
>> Han-Wen Nienhuys writes:
>>
>>> On Sat, Jun 24, 2017 at 12:43 PM, David Kastrup wrote:
>>>>
>>>> The first step would likely just involve moving to Cairo data
&
nt integration into Cairo surfaces
is going to work. I guess that this will be the main problem for making
Cairo actually be responsible for producing output rather than serving
"merely" as an internal graphics toolkit.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
k...@aspodata.se writes:
> David Kastrup:
> ...
>> I don't see myself able to deal with all potential icky graphics code
>> in LilyPond, and I don't see anybody else stepping up either.
> ...
>
> Just for the record, I'm interested in icky graphics cod
sts eventual retirement of the existing backends
to be an option that could end up reducing the amount of ongoing
developer effort for keeping the backends in uniformly coherent shape.
Cairo doesn't do stuff like skylines and page layout, so finding good
ways for fudging stuff together will st
use Cairo, our bitmap
output would likely be more representative for PDF viewer output than it
is now.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
with Fedora 24. The Ubuntu GCC6
prerelease does not show this problem; presumably the respective
optimization has been disabled in the Ubuntu/Debian packaging because of
affecting other programs.
Commit-message-by: David Kastrup
Signed-off-by: David Kastrup
--
David Kastr
ou experimented with \slurDashPattern ?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
David Kastrup writes:
> Abraham Lee writes:
>
>> Greetings, Devs!
>>
>> I have always wondered why dashed slurs look the way they do, especially
>> when compared to the Barenreiter snippets found in the essay. The current
>> dashes look better than they us
Thomas Morley writes:
> 2017-06-27 6:47 GMT+02:00 David Kastrup :
>> Thomas Morley writes:
>>>
>>> in the german forum a user reported a segfault.
>>>
>>> In the light of
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746005#278
>&
u think that's slow, try
make doc
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
s one is going to be just as much work with and without
Cairo.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
gin.
Without an actual example I have no real idea what you want to access
where using what kind of function.
At any rate, you are overriding grob callbacks, and maybe you just want
to call (lm (ly:output-def-lookup (ly:grob-layout grob) 'left-margin))
and its ilk?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
{
a4. b'16 c' a8 a'2 g'2. f'4
}
}
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
also intermediate notes without
figure.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
git uses for its diff but
> didn't think about the directory you would want to run patch from.
> I've made a git clone of the repository and used git diff now to get the
> attached patch.
That doesn't help much I think. Create an actual commit with commit
message, then form
, run lilypond again, produce a score video
> without audio and combine that with the recording.
Frankly, I think highlighting single notes instead of having a smoothly
moving time bar (namely letting LilyPond typeset stuff only once and
doing the graphi
graphical elements. Currently, PDF tracks source positions as links.
That's not quite the same thing, particularly as long as Midi does not
offer doing the same. I'm not sure PDF is the best format for that (or
PostScript either): SVG seems like it would be better suited for
graphic
table 2.20 branch in the
interregnum: that way the translation branch can be merged (rather than
individual parts cherry-picked) into the stable branch until the stable
branch gets released.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-de
Federico Bruni writes:
> Il giorno lun 17 lug 2017 alle 19:14, David Kastrup ha
> scritto:
>> Other things up for cherry-picking are documentation changes and
>> their translations. Since translations usually are done in "bulk",
>> it would make sense to only
Paul writes:
> On 07/17/2017 02:14 PM, David Kastrup wrote:
>
>> Currently there is a bit of a lull (not entirely graceful due to me not
>> keeping up with things all the best), so the time seems convenient.
>
> No objections here. What's the latest thinking/status
Dan Eble writes:
>> On Jul 19, 2017, at 15:19, David Kastrup wrote:
>>
>> Paul mailto:p...@paulwmorris.com>> writes:
>>
>>> It's usually `a = b` or `\a b` but not `\a = b` or `\a b = c`.
>>
>> You can only use markup functions when
end-specific definitions.
Still, a color that is not actually fixed at the time a grob is put to
"paper" seems strange, to say the least.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Seems like an obvious addition. Would make stuff (like slurs, hairpins
and so on) starting at the bar move backwards to the bar line. Probably
also useful for non-spanners like a \fermata ?
--
David Kastrup
___
lilypond-devel mailing list
lilypond
Simon Albrecht writes:
> On 24.07.2017 13:58, David Kastrup wrote:
>> Seems like an obvious addition. Would make stuff (like slurs, hairpins
>> and so on) starting at the bar move backwards to the bar line. Probably
>> also useful for non-spanners like a \fermata ?
Simon Albrecht writes:
> On 24.07.2017 15:30, David Kastrup wrote:
>> Making a bar line an event would then place per-chord articulation marks
>> of the following note on the bar line.
>
> You mean
>
> {
> c1
> \bar "||"
> \fermata
> \ba
801 - 900 of 6220 matches
Mail list logo
