is is sent to very many people who may or may not be interested in
> all topics on the list.
Did you really have to _quote_ all of the quoted messages of last week
_again_ to make that point?
That will make all of those nonsensically quoted messages from last week
appear _twice_ in next week
ing.aux to
be created/written.
This made the punishment for writing \include{something.tex} instead of
the correct \include{something} pretty severe (until MikTeX was made to
detect this special case and refuse the operation).
--
David Kastrup
\language "deutsch"
\new NoteNames { b1 }
This outputs `h♭` instead of `b`.
--
David Kastrup
error: failed files: "scheme-sandbox"
--
David Kastrup
reak r1 1 }
>
>
> Not sure it’s ever going to trigger in real-life situations, but it’s
> a crash without error handling. “Output code 11.”
That is not a minimal example. Try
\new Staff \with { \consists "Custos_engraver" } { 1 }
--
David Kastrup
where HP had a bit of a
different reputation regarding printers... It also helps that complete
service manuals with detailed disassembly instructions are available.
Of course, this cannot make up for letter/A4 discrepancy either, but it
should be possible to tell the printer driver to make up for that with
scaling.
--
David Kastrup
.0"
#(define mydrums '( (hightom default #f 3)))
\score {
\new DrumStaff \with { drumStyleTable = #(alist->hash-table mydrums) }
{
\new DrumVoice { \voiceTwo \drummode { \partial 2 \acciaccatura tomh8 tomh4
\acciaccatura tomh8 tomh4 } }
}
}
--
David Kastrup
by default), but I can't see why we wouldn't want 'barcheck
> failed' warnings whenever ANY note goes across a barline (other than
> via a tie), for whatever reason. It's a really useful warning for
> double-checking the entered durations in &q
nce for "simile" triplets entered as
>> durations with *2/3 multiplier.
>
> OK, then we'd have to say "it's a warning only if the resulting
> note is longer than the bar". Can the existing bar-check code
> be modified to take these multipliers into account?
Hm.
e for "simile" triplets entered as
durations with *2/3 multiplier.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
> compressed rests bars but the eight bars are unfolded.
>
> If I remove the two partial before, it works.
Why don't you do that, then? The first one is utterly wrong anyway
since it does not match the beat structure of the following partial bar.
\partial carves out material _before_ a bar, no
gt; NameError: name 'path_replace' is not defined
>
> Is this a known issue?
commit 3d3f8531da00247ad55b6a613bf0adc5e9b71954
Author: Jean Abou Samra
Date: Tue Oct 25 01:28:28 2022 +0200
convertrules.py: define path_replace on toplevel
Fixes #6446 (bug introd
siderable overlap of glyphs, that may
be a more appropriate choice?
Or isn't there actual glyph overlap?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
David Kastrup writes:
> Jean Abou Samra writes:
>
>> Thus I wrote to the general GNU list server admins and proposed
>> to step up for being an admin on these lists, just like I am
>> already an admin on lilypond-user-fr (the French-speaking equivalent
>> of lil
.
That's the impression I also get from current LilyPond list moderators
(thanks David!): you don't really get the impression that there is
anybody doing anything except that the amount of visible spam is
essentially zero and that doesn't happen by itself.
--
David Kastrup
_
David Kastrup writes:
> Kenneth Wolcott writes:
>
>> Hi;
>>
>> This is an extremely minor bug.
>>
>> Which version of "English" is the Lilypond documentation written in?
>>
>> If it is American English, then:
>>
>> N
ul Davis, developer of
@uref{https://jackaudio.org/, JACK} and @uref{https://www.ardour.org/, Ardour}
Documentation/en/web/introduction.itexi:of LilyPond's behaviour. Please read
this manual before doubting
Ok, essentially just "behaviour".
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
general level of discourse should be at a user-accessible level.
And if it isn't, asking questions is not supposed to be frowned upon.
You can check out the archives to see whether you think frequenting it
might be something that might benefit you and/or others.
<https://lists.gnu.org/archive/htm
don't know if there's any
> action to take, but I thought I'd document it here.
Historically, multiple grace parts in sequence were just not supported.
I have no idea whether some refactoring by Dan has changed the substance
of the matter but my gut feeling would be
on to
> redefine something that already exists?
Why?
>
>
> \version "future"
>
> foo = { c2 } % Works, providing \foo does not exist.
> bar = { c4 4 } % Warns, since \bar does exist.
Why would that warrant a w
in the lilypond-usage manual.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
and
>>
%%%
Now that \stopStaff is placed at the time where you actually want to
have the staff end, that's exactly where the staff _does_ end.
And what you see now in terms of stems deserves the title "bug, or at
least ugly".
But at least the staff length is what you want, and y
tinct tokens; it would be prohibitive to have to
define all of c c1 c2 c4 c8 c16 c32 c64 c128 c' c'1 c'2 c'4 cis? cis?1 ...
separately.
Having spaces count as an additional token would make it troublesome to
deal with durations like \breve .
Yes, it can be a source of entry errors. Still worth it
rk polyphonically as in per-note but
rather per-channel, but with the usual per-Staff channel mapping used in
LilyPond, that should be good for covering some distance. But LilyPond
would need to support it.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
d another
repetition).
> They are used in VerticalAxisGroup pure calculations, to estimate how
> tall a staff will be between two certain points in order to score page
> breaking configurations.
Yes, that's more like it.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
David Kastrup writes:
[Percussion notes]
> To get a better headstart for knowing what one needs to tamper with, it
> would be nice to give the MIDI instrument number as well where one is
> assigned.
Ouch. The MIDI _instrument_ number for channel 10 sets the drum _kit_
(and since Lily
here one is
assigned.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
ial scores from crashing MIDI generation but I guess both our
work was not really plugging the problem at its root and so one can
apparently still generate circumstances where it pops up.
So while it certainly is helpful to see where stuff crashes here (and
possibly fix this particular crash), there
ing, cross fingers
programming error: no dynamic span to finish
continuing, cross fingers
MIDI output to `bah.midi'...
Compilation segmentation fault (core dumped) at Sun Oct 24 00:14:21
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
David Kastrup writes:
> I just had the pipeline run
>
> https://gitlab.com/lilypond/lilypond/-/pipelines/393509219
>
> finish. This change adds engravers/performers including engraver
> information, stuff that is extracted into the IR. It also adds a
> regtest.
>
&
which
presumably means that the documentation will not be updated until after
some other change adds documentation.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
James writes:
> On 17/10/2021 21:45, David Kastrup wrote:
>>
>> Since it is sort of a nuisance to get rid of files you don't own, it
>> would be good if make install-* did not create any files in-tree when
>> the respective make * commands have already been run.
David Kastrup writes:
> Example file:
>
> timetrack =
> {
> \set Score.skipTypesetting = ##t
> \skip 1
> \set Score.skipTypesetting = ##f
> \skip 1*2
> }
>
> music =
> {
> c1\mf
> c1\f
> c1\ff
> }
>
>
> \score {
>
starting at 2
continuing, cross fingers
Success: compilation successfully completed
Compilation finished at Mon Oct 18 20:12:07
~~~
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
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 LilyP
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 pointer
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
_
Federico Bruni writes:
> Il giorno mar 21 set 2021 alle 22:48:04 +0200, David Kastrup
> ha scritto:
>> "make doc-clean" appears to work better. I find it somewhat
>> surprising
>> that it should not have been implied by "make clean".
>
>
Federico Bruni writes:
> Il giorno mar 21 set 2021 alle 22:48:04 +0200, David Kastrup
> ha scritto:
>> "make doc-clean" appears to work better. I find it somewhat
>> surprising
>> that it should not have been implied by "make clean".
>
> IIRC i
Jean Abou Samra writes:
> Le 21/09/2021 à 22:03, David Kastrup a écrit :
>> Jean Abou Samra writes:
>>
>>> Le 21/09/2021 à 21:24, David Kastrup a écrit :
>>>> I am reverting
>>>>
>>>> commit 79114c78d12a24b6089af0375dcac5b739c29a0c
&g
Jean Abou Samra writes:
> Le 21/09/2021 à 21:24, David Kastrup a écrit :
>> I am reverting
>>
>> commit 79114c78d12a24b6089af0375dcac5b739c29a0c
>> Author: Jean Abou Samra
>> Date: Tue Aug 31 17:49:30 2021 +0200
>>
>> Doc: Better h
Jean Abou Samra writes:
> Le 21/09/2021 à 21:12, David Kastrup a écrit :
>> David Kastrup writes:
>>
>>> dak@lola:/usr/local/tmp/lilypond$ CPU_COUNT=9 make -j9 info
>>> Making Documentation/out-www/lilypond-changes.info < texi
>>> Making Docume
David Kastrup writes:
> David Kastrup writes:
>
>> dak@lola:/usr/local/tmp/lilypond$ CPU_COUNT=9 make -j9 info
>> Making Documentation/out-www/lilypond-changes.info < texi
>> Making Documentation/out-www/lilypond-learning.info < texi
>> Making Documenta
David Kastrup writes:
> dak@lola:/usr/local/tmp/lilypond$ CPU_COUNT=9 make -j9 info
> Making Documentation/out-www/lilypond-changes.info < texi
> Making Documentation/out-www/lilypond-learning.info < texi
> Making Documentation/out-www/en/notation.texi < tely
> Maki
exi
lilypond-book.py: error: file not found: en/hyphenation.itexi
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Jonas Hahnfeld writes:
> Am Dienstag, dem 17.08.2021 um 21:43 +0200 schrieb David Kastrup:
>> Seems a bit wasteful not to include !882 while fixing point-and-click.
>
> Not really, the official binaries continue to be Guile 1.8 so nothing
> really changes there. I woul
to Guile's %load-path.
>
> Yes, the wrapper from GUB uses the wrong directory in GUILE_LOAD_PATH.
> The fix is rather simple (https://github.com/gperciva/gub/pull/87),
> maybe it would be a good idea to release 2.23.4 with this. Phil, what
> do you think?
Seems a bit wasteful not to
ode anyway. The downside is that
// this will get us confused when given something like
//
// \new Voice { \oneVoice \grace { c''8 8 } g'1 }
//
// where \grace executes its actions already before \oneVoice, causing
// different stem directions.
which is related.
--
David Kastrup
__
; TabNoteHead.font-size } d'
> }
> }
Do not pair \override and \revert. Instead pair \temporary \override
with \revert. Otherwise you may get interactions with outer overrides,
and grace notes do come with their own set of overrides.
--
David Kastrup
_
James writes:
> Hello
>
> On 01/07/2021 22:36, David Kastrup wrote:
>> Please look/listen at the following:
>>
>>
>> Separate rolls are not separated, articulations are executed on every
>> single stroke (where they are inaudible for drums) instead o
differentiate between producing performance material or producing Midi
as an intermediate for importing into a different notation program.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Hans Åberg writes:
>> On 1 Jul 2021, at 23:36, David Kastrup wrote:
>>
>> Separate rolls are not separated, articulations are executed on every
>> single stroke (where they are inaudible for drums) instead of the note
>> as such, ties (indicating an actual l
the note
as such, ties (indicating an actual lack of separation) instead tie the
whole roll into a single stroke, dynamics, well...
This is pretty much a disaster.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
k one thing we should be doing as part of \partial is to
trigger the issuance of a time signature at the next bar start
regardless of whether the signature stays the same.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
David Kastrup writes:
> \include "articulate.ly"
>
> \score
> {
> \articulate
> {
> \tempo 4 = 60
> c'1:32-"rall."
> c'1-"a tempo"
> }
> \midi { }
> }
Ok, putting \displayLilyMusic before \articulate delivers
\include "articulate.ly"
\score
{
\articulate
{
\tempo 4 = 60
c'1:32-"rall."
c'1-"a tempo"
}
\midi { }
}
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
orking executable not using Xcode.
How feasible or hard that path is (and how much Apple is invested in
making Darwin available in a timely or useful manner) is a different
question.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
ikely to get us into hot water.
Opposed to that, we know for sure that the 64bit SDKs are off-limits.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
LilyPad and doing a Darwin-only version of LilyPond, assuming that we can
>> do this with suitably free components.", by David Kastrup. I don't think
>> many people are using the limited editor LilyPad. There are a
>> lot of better
>> tools available (F
Carl Sorensen writes:
> On 4/22/21, 9:49 AM, "Bart Kummel" wrote:
>
> I think you should re-consider this comment: "The other option is ditching
> LilyPad and doing a Darwin-only version of LilyPond, assuming that we can
> do this with suitably free
Bart Kummel writes:
> I think you should re-consider this comment: "The other option is
> ditching LilyPad and doing a Darwin-only version of LilyPond, assuming
> that we can do this with suitably free components.", by David
> Kastrup. I don't think many people are us
o financially sponsor his unofficial porting
work so that he does not end up shortchanged for providing the Apple
installers created on his Apple hardware.
In short: as long as people are not willing to work themselves for the
change they want to see, it will not happe
Kevin Barry writes:
> On Wed, Mar 31, 2021 at 01:42:17AM +0200, David Kastrup wrote:
>> David Kastrup writes:
>>
>> > Apparently, images are no longer copied when doing
>> >
>> > make install-info
> I always work in a terminal so I wouldn't not
David Kastrup writes:
> Apparently, images are no longer copied when doing
>
> make install-info
>
> making the documentation near useless. Pages look like
>
> File: lilypond-notation.info, Node: Pitches, Next: Rhythms, Up: Musical
> notation
>
> 1.1 Pitches
-info creates a link
lrwxrwxrwx 1 root root 35 Mär 31 01:28 lilypond ->
../doc/lilypond/html/Documentation/
in /usr/local/share/info
that is entirely useless since I am not interested in installing the
HTML documentation.
--
David Kastrup
___
bu
nteed, but LilyPond tries
preserving straightforward relations of the input to the music
expression. Mapping the music expression to some behavior during
iteration is then a different endeavor.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
direction #DOWN -\markup
It won't make a difference for text scripts that are going to appear
below the system anyway. But for example in \voiceOne settings, they'd
go above the system by default.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypon
on fluids.
So unless you don't know what version of LilyPond will parse your code,
I'd strongly suggest omitting them. In particular, code preceded by
\version "2.23.1"
is more or less defined to not require their use.
When the function actually needs parser/locatio
pp/Contents/Resources/share/lilypond/current/scm/lily.scm:1036:21:
> Wrong type argument in position 1: (1 "4.." . #f)
>
> What am I missing here?
convert-ly ?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
changed function is now more robust against
different input, but I have no idea if the different input constitutes a
bug.
So it would be good if Dan checked whether the current behavior is the
desired one.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Aaron Hill writes:
> On 2020-09-22 5:54 am, David Kastrup wrote:
>> The whole code in the find-non-empty loop, apart from this error, is
>> garbage. Here is a bit more code and analysis:
>> (define-public (add-quotable name mus)
>> (let* ((tab (eval '
David Kastrup writes:
> Pierre-Luc Gauthier writes:
>
>> Hi there,
>>
>> When I compile :
>>
>> test = {}
>> \addQuote "test" \test
>>
>> I get :
>>
>> GNU LilyPond 2.21.7
>> Processing `test.ly'
>> Pa
ange must have affected context-list which
previous to that change apparently always contained raw-voice somewhere,
or at least in the case you now posted.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
this?
>
> ```
> { \grace { c8 d8 } e4 }
> ```
\grace does not just introduce grace timing. It also does things like
\stemUp and size reduction. So what should happen with
{ \grace { \stemDown c8 } { d8 } }
?
--
David Kastrup
___
bug
>> unsuccessful with cherry picking (more my skills than David's
>> instructions though), so this is going to be tedious to bisect I expect.
>>
>> James
> I can try to hunt this down today, but please, gurus, intervene if you
> have an immediate guess what's going on.
age of f372c695a52cf83ea00ff3be40acc542b4d46cbd
> \new Staff \with { instrumentName = "3" }
> \relative {
> \partial 4
> \repeat volta 4 { e'4 | c2 d2 | e2 f2 | }
> \alternative { { g4 g g } { a a a a } }
> a b2.
> }
>
> %% Accidental missing
> \new Sta
nts with a GPL program (which would
make it silly to choose Affero GPL in the first place, but I chose to
check anyway).
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
t now I'm too tired ...
You don't need something like git-cl: the basic setup is really quite
simple. The most efficient way to organise continuous ongoing work is
something we are still figuring out, but you are talking about entry
hurdles here. Those are not rea
of Lilypond. Can you please have a look at this?
You downloaded the wrong version. On all download pages I can find on
the web page (including for developer versions), there are unofficial
downloads for 64Bit MacOSX that should be working with Catalina.
--
David Kastrup
_
nas
> Hahnfeld). I'm not sure that this is plausible, maybe I was to naive
> in bisecting.
Did you restrict bisection to changes of a single file, or did you do it
on the full commit series?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
use case.
> https://sourceforge.net/p/testlilyissues/issues/5964/
> Since it got broken recently, that should be fairly easy to bisect.
Uh, there are several years of development between 2.20.0 and 2.21.1.
Unfortunately. But at least few version changes...
--
David Kastrup
___
t; <http://lilypond.1069038.n5.nabble.com/file/t5463/BookOutputName_with_variable.png>
>
You don't say what your problem is and your screenshot is marked up with
conflicting statements.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
you post there, please also look there for
replies. For likely user-level problems rather than genuine LilyPond
bugs, please try the lilypond-u...@gnu.org list first.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.or
-event. See:
>
> http://lilypond.org/doc/v2.18/Documentation/notation/writing-parts#quoting-other-voices
Huh. Why wouldn't that be the default? This report triggered a Deja vu
with me; I thought it was fixed previously? Or was this some other kind
of event recently added?
--
David Kastrup
n) fields
and the last one before that in 2015 (something related to grace notes).
It has been ported over to Python 3, though.
I don't think there are active plans for anything at the moment (or even
any active developer who had significant involvement with abc2ly), so
feel free to jump in.
--
optimizing (!this) away as being always false, basically
because we called member functions on a null pointer, and the member
functions then checked the condition.
There are other reasons why current compilers do no longer compile
2.18.2, so it would be rather tricky to track this down.
Can you t
y I think it is
a bit too special-cased to certain context types, but one can probably
adapt it to be more general while leaving the same kind of messages for
the types you now special-cased.
Thanks!
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypon
n
\consists "Merge_rests_engraver"
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Jean Abou Samra writes:
> Hi,
>
> Le 3 mars 2020 à 20:58, David Kastrup < d...@gnu.org> a écrit :
>
> Well, the less reason for quibbling (which I myself tend to indulge in
> more than appropriate) ends up on our list and the less confusion ends
> up wit
and 2.19 the results mirror my local result with 2.18,2 on debian
Which 2.19? The documentation corresponds to 2.19.84.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
ext for
everything: we can special-case some cases).
And rather than wasting unnecessary time with LilyPond (like you
probably feel the current text made you do), you'll invest time for an
actual improvement benefitting users that may see the same problem in
future.
All the best
--
David Kastrup
My
to `down': not changing to same
>context type: Staff
>\change Staff = "down"
>
>A workaround is to add a \grace s8 in all voices, between the end of
>simultaneous voices and the \change invocation.
>
>Regards,
>
&g
"Peter Ogonek" writes:
> Dear members,
>
> I have installed fontforge-20190801, which is not getting detected by
> lilyponds config step.
How did you install it? On what kind of system?
--
David Kastrup
___
bug-lilypond mai
e.net/p/testlilyissues/issues/5798/)
Rietveld issue: 567280043 (https://codereview.appspot.com/567280043)
Issue description:
Make make-autochange function upwards-compatible to 2.18 This
entails putting the ref-pitch argument last and making it an
optional argument.
--
David Kastrup
_
n loading order
for enabling the aliases.
There will probably be a few more commits outside of the mf directory
that belong to the same issues.
Could any of those commits have an effect like that? Would that likely
show just on one particular computer, or might other systems also be
affected?
ff <<
\mergeDifferentlyDottedOn\mergeDifferentlyHeadedOn
\context Voice = "PartPOneVoiceOne" { \PartPOneVoiceOne }
>>
>>
>>
\layout {}
% To create MIDI output, uncomment the following line:
% \midi {\tempo 4 = 100
sted a notice regarding the tracker issue to the
thread once it was done. Giving people the mistaken impression that
nobody cares about their bug reports is needlessly wasting their
motivation for reporting problems.
Sorry for having forgotten about that.
--
David Kastrup
My replies have a t
quartertone
names should all be derived from h instead of b since beh was being
used inconsistently. Fix deutsch language of musicxml2py Use b
only for hes and nothing else. Also use asas and asah instead of
ases and aseh.
should fix either. It doesn't use patterns for hes. Somewhat art
hat as
an independent vote that this might be the sanest extension into
quarternote territory.
> On 2/9/20 5:52 PM, David Kastrup wrote:
>> mari+lilyp...@mailbox.org writes:
>>
>>>> On 2/9/20 1:49 PM, David Kastrup wrote:
>>>>> mari+lilyp...@mailbox.org
mari+lilyp...@mailbox.org writes:
>> On 2/9/20 1:49 PM, David Kastrup wrote:
>>> mari+lilyp...@mailbox.org writes:
>>>
>>>> when converting a mxl file with "musicxml2ly --language=deutsch" the
>>>> note "beses" is converted to
1 - 100 of 1473 matches
Mail list logo
