Re: Issue 5624: ignore \barNumberCheck when processing MIDI (issue 579140043 by nine.fierce.ball...@gmail.com)
LGTM, thanks! https://codereview.appspot.com/579140043/diff/549240043/ly/music-functions-init.ly File ly/music-functions-init.ly (right): https://codereview.appspot.com/579140043/diff/549240043/ly/music-functions-init.ly#newcode243 ly/music-functions-init.ly:243: (if (and (number? cbn) (not (= cbn n))) Is there a special reason to retain the two spaces here? https://codereview.appspot.com/579140043/
PATCHES - Countdown for November 28th
Hello, Here is the current patch countdown list. The next countdown will be on November 30th. A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ Countdown Push: 5617 Prepare for encoding changes in Python 3 - Jonas Hahnfeld https://sourceforge.net/p/testlilyissues/issues/5617 http://codereview.appspot.com/573280043 5614 hara-kiri-group-spanner: int->vsize for indices - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5614 http://codereview.appspot.com/579120043 5613 remove dead code in Interval_t and Spanner - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5613 http://codereview.appspot.com/555010043 5612 run ly->midi->ly checks once (not twice) - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5612 http://codereview.appspot.com/545270043 5610 add suggestAccidentals = #'cautionary option - Malte Meyn https://sourceforge.net/p/testlilyissues/issues/5610 http://codereview.appspot.com/577130043 5602 Implement MeasureSpanner - David Nalesnik https://sourceforge.net/p/testlilyissues/issues/5602 http://codereview.appspot.com/571180043 Countdown: 5618 configure: Fix tests for compiler warning flags. - Werner LEMBERG https://sourceforge.net/p/testlilyissues/issues/5618 http://codereview.appspot.com/551210043 Review: No patches in Review at this time. New: 5624 ignore \barNumberCheck when processing MIDI - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5624 http://codereview.appspot.com/579140043 5623 fix int/vsize conversion warnings in System - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5623 http://codereview.appspot.com/553230043 5622 simplify Spanner pure property cache - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5622 http://codereview.appspot.com/549220043 5620 Change vector to vector - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5620 http://codereview.appspot.com/545280043 5619 Add configure option `--with-flexlexer-dir`. https://sourceforge.net/p/testlilyissues/issues/5619 http://codereview.appspot.com/569120043 *** Regards, James
Re: Midi block gives errors with bar number checks
On Nov 27, 2019, at 14:19, Dan Eble wrote: > > On Nov 27, 2019, at 12:06, Carl Sorensen wrote: >> >> From the user point of view, the ideal solution would be that if a score >> that includes bar number checks was handled by a midi block , the bar >> number checks would be ignored. > > That's probably easily achievable. > > I'm looking at the existing regression tests, and I don't see why we need > both of these: > >./input/regression/bar-number-check.ly >./input/regression/bar-number-check-warning.ly > > Am I overlooking something? I went ahead and removed one of them. https://sourceforge.net/p/testlilyissues/issues/5624/ — Dan
Re: Midi block gives errors with bar number checks
On Nov 27, 2019, at 12:06, Carl Sorensen wrote: > > From the user point of view, the ideal solution would be that if a score that > includes bar number checks was handled by a midi block , the bar number > checks would be ignored. That's probably easily achievable. I'm looking at the existing regression tests, and I don't see why we need both of these: ./input/regression/bar-number-check.ly ./input/regression/bar-number-check-warning.ly Am I overlooking something? — Dan
Re: Midi block gives errors with bar number checks
On 11/27/19, 9:55 AM, "Dan Eble" wrote: On Nov 27, 2019, at 11:35, Carl Sorensen wrote: > > It’s not bar checks causing the problem, it's bar number checks. Oh, thanks for the correction. It doesn't look difficult to add a context property to deactivate bar number checks. Would that be the ideal solution? I don't know the answer to this question. I'm not familiar enough with the mechanics of bar number checking to know how and when the bar number checks occur. From the user point of view, the ideal solution would be that if a score that includes bar number checks was handled by a midi block , the bar number checks would be ignored. If that behavior could happen by means of a context property ignoreBarNumberChecks, and the midi block would set that context property #t by default, that would certainly be a feasible solution. Whether it's the best solution or not is beyond my ability to say. It would not be an ideal solution if the user needed to add an override in the midi block to ignore the bar number checks, but it would still be a workable solution, because we could document the procedure. Thanks, Carl
Re: Midi block gives errors with bar number checks
On Nov 27, 2019, at 11:35, Carl Sorensen wrote: > > It’s not bar checks causing the problem, it's bar number checks. Oh, thanks for the correction. It doesn't look difficult to add a context property to deactivate bar number checks. Would that be the ideal solution? — Dan
Re: Lilypond Issue Tracker Access
Hi Austin I'm trying to make a (small) contribution to Lilypond. The instructions I found at http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl tell me to email this address and ask for write access to the Lilypond issue tracker. Sourceforge username: austinglaser Added as a Developer on SourceForge, with permissions to Create and Update Issues as well as Read them. Welcome aboard! Trevor
Re: Midi block gives errors with bar number checks
On 11/27/19, 9:29 AM, "lilypond-devel on behalf of Dan Eble"
wrote:
> On Wed, 27 Nov 2019 10:51:15 +0100 (CET), Martin Tarenskeen
wrote:
>
>> I use MIDI output mainly for proofreading, but at occasions where I need
>> better MIDI output I always create separate scores for layout{} and
>> midi{}. In the midi-only version I copy/paste all music in the correct
>> order instead of using any repeat instructions. Also suitable for
complex
>> Da Capo / Segno / Coda types of repeats. If I arrange my music in blocks
>> using variables and use my favorite texteditor it really isn't that much
>> extra work and it is a usable workaround for Lilypond's restrictions.
>>
>> Sometimes even \unfoldRepeats doesn't do the trick.
I haven't used bar checks. Have you tried setting the ignoreBarChecks
property? If you don't know what that means, and if you are willing to post a
minimal example of the problem, I am willing to try setting it for you.
It’s not bar checks causing the problem, it's bar number checks.
The beginning of this thread had a minimal example.
Thanks,
Carl
Re: Midi block gives errors with bar number checks
> On Wed, 27 Nov 2019 10:51:15 +0100 (CET), Martin Tarenskeen
> wrote:
>
>> I use MIDI output mainly for proofreading, but at occasions where I need
>> better MIDI output I always create separate scores for layout{} and
>> midi{}. In the midi-only version I copy/paste all music in the correct
>> order instead of using any repeat instructions. Also suitable for complex
>> Da Capo / Segno / Coda types of repeats. If I arrange my music in blocks
>> using variables and use my favorite texteditor it really isn't that much
>> extra work and it is a usable workaround for Lilypond's restrictions.
>>
>> Sometimes even \unfoldRepeats doesn't do the trick.
I haven't used bar checks. Have you tried setting the ignoreBarChecks
property? If you don't know what that means, and if you are willing to post a
minimal example of the problem, I am willing to try setting it for you.
—
Dan
Re: Midi block gives errors with bar number checks
On 11/27/19, 7:20 AM, "lilypond-devel on behalf of James Lowe"
wrote:
Hello,
On Wed, 27 Nov 2019 10:51:15 +0100 (CET), Martin Tarenskeen
wrote:
>
>
> On Wed, 27 Nov 2019, Peter Toye wrote:
>
> > I'm not sure how many LP user use the MIDI output anyway, given its
restrictions. Personally, I use it for proof-reading only, so lack of repeats
isn't an issue.
>
> I use MIDI output mainly for proofreading, but at occasions where I need
> better MIDI output I always create separate scores for layout{} and
> midi{}. In the midi-only version I copy/paste all music in the correct
> order instead of using any repeat instructions. Also suitable for complex
> Da Capo / Segno / Coda types of repeats. If I arrange my music in blocks
> using variables and use my favorite texteditor it really isn't that much
> extra work and it is a usable workaround for Lilypond's restrictions.
>
> Sometimes even \unfoldRepeats doesn't do the trick.
>
> --
>
> MT
Do we need an @knownissue in the Notation Reference?
James
I believe that @knownissue is the correct way to deal with this, unless we are
going to go all out and remove \barNumberCheck from the midi performers.
We shouldn't spend a lot of time documenting the current behavior, since it's
not consciously designed, but rather an unanticipated result.
Carl
Re: Midi block gives errors with bar number checks
Hello,
On Wed, 27 Nov 2019 10:51:15 +0100 (CET), Martin Tarenskeen
wrote:
>
>
> On Wed, 27 Nov 2019, Peter Toye wrote:
>
> > I'm not sure how many LP user use the MIDI output anyway, given its
> > restrictions. Personally, I use it for proof-reading only, so lack of
> > repeats isn't an issue.
>
> I use MIDI output mainly for proofreading, but at occasions where I need
> better MIDI output I always create separate scores for layout{} and
> midi{}. In the midi-only version I copy/paste all music in the correct
> order instead of using any repeat instructions. Also suitable for complex
> Da Capo / Segno / Coda types of repeats. If I arrange my music in blocks
> using variables and use my favorite texteditor it really isn't that much
> extra work and it is a usable workaround for Lilypond's restrictions.
>
> Sometimes even \unfoldRepeats doesn't do the trick.
>
> --
>
> MT
Do we need an @knownissue in the Notation Reference?
James
Helmholtz-Ellis accidentals
> On 21 Oct 2018, at 10:56, Torsten Hämmerle wrote: > > If I understand it correctly, the main reason for switching to Bravura are > missing Emmentaler accidental glyphs (obviously the multi-arrowed ones, if I > look at your definition files). > > Incidentally, I'm planning to fill in the Emmentaler gaps in the (very) near > future directly after issue #3356 has been fixed (in two weeks latest). What is the state of these accidentals? —This notation recently came up on the users list. > In the course of issue #3356 "add triple flats/sharps" I've unified and > considerably generalized the Metafont accidental glyph definitions so that > it is now possible to create a whole variety of arrowed accidentals (the > existing standard arrows as well as new stacked smaller arrows, "black" > flats (with filled-in counters), etc. > The Metafont overhaul was, among others, the reason why it took so long (but > it's in the final internal testing phase now, struggling with > spacing/positioning issues for big-arrow-up doublesharp). > > The new glyph names for the tiny-arrowed accidentals (just the ones you > currently use are mentioned here) will be > > accidentals.flatflat.1up > accidentals.flatflat.2up > accidentals.flatflat.1down > accidentals.flatflat.2down > accidentals.flat.1up > accidentals.flat.2up > accidentals.flat.1down > accidentals.flat.2down > accidentals.natural.1up > accidentals.natural.2up > accidentals.natural.1down > accidentals.natural.2down > accidentals.sharp.1up > accidentals.sharp.2up > accidentals.sharp.1down > accidentals.sharp.2down > accidentals.doublesharp.1up > accidentals.doublesharp.2up > accidentals.doublesharp.1down > accidentals.doublesharp.2down >
