bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "dodecaphonic-first" accidental style


From: Phil Holmes
Subject: Re: "dodecaphonic-first" accidental style
Date: Wed, 26 Mar 2014 10:16:35 -0000

"Urs Liska" <address@hidden> wrote in message news:address@hidden
Am 25.03.2014 11:59, schrieb James:
On 24/03/14 14:45, Rutger Hofman wrote:
On 03/24/2014 01:50 PM, Gilberto Agostinho wrote:> Gilberto Agostinho wrote
The correct syntax is with the "s" [...]

I meant without.... without the "s", as in "repeat" and NOT "repeats"
Rutger Hofman-2 wrote
[...]
As a fix, I made a small addition to music-functions.scm to add a
dodecaphonic-first accidental style. Patch against 2.17.18-1 attached.
[...]
Using dodecaphonic-first and adding ! here and there works fine for me.

I already apologize for replying to an old post (almost 1 year old!), but I
am really interested in this dodecaphonic-first accidental style. The
problem is I do not know how to deal with this .patch file!

Right, so there is a new style dodecaphonic-no-repeat from 2.19.3 onwards. But it does something else than the style dodecaphonic-first that I wrote about, long ago. dodecaphonic-no-repeat suppresses accidentals for immediately repeated notes. dodecaphonic-first suppresses accidentals for any notes that already occurred earlier in the bar. My opinion is that there is still good use for dodecaphonic-first; the main reason is that wiping out undesired accidentals leaves visible traces because it consumes horizontal space, whereas adding occasional forced accidentals works fully as desired.

I would love it if the dodecaphonic-first style can be patched into lilypond; not only for the Greater Good, but also to relieve me from applying it to each and every lilypond release, and maintaining it across changes...

I renewed the patch for versions from 2.19.3 upwards. It is attached (pre-2.19.3 and 2.19.3 onwards; it used to be a reverse-patch, no longer now). It is extremely small. I also keep it in my github repo for lilypond additions, in the patches/ dir:

https://github.com/rfhh/lily-contribs

That repo currently also contains my converter from NIFF to lilypond (and the NIFF sdk, with 64-bit patch), and an upgraded version of Han-Wen's pmx2ly converter that I used to prepare an edition of Bach's BWV 146/1052a (on IMSLP).

Rutger





--
View this message in context: http://lilypond.1069038.n5.nabble.com/dodecaphonic-first-accidental-style-tp141907p160773.html
Sent from the User mailing list archive at Nabble.com.

_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user




_______________________________________________
lilypond-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-devel
adding 'bug'

I've created http://code.google.com/p/lilypond/issues/detail?id=3889

However if you want a proper review/test can you upload to reitveld as per our process else this won't get the review it might.

If you need help on doing this let us know.


We now have issue
https://code.google.com/p/lilypond/issues/detail?id=3889
and patch
https://code.google.com/p/lilypond/issues/detail?id=3890

What is the correct way to deal with this?
3889 should be closed, marked as duplicate or merged in 3890.
I'd like to learn how to do that and do it myself rather than simply asking "someone" to do it.

Urs

Change the status to duplicate. There will then be a box asking which issue to merge with.

--
Phil Holmes





reply via email to

[Prev in Thread] Current Thread [Next in Thread]