Configure Courtesy Accidentals Plugin
As it has come up several times, that a plugin (or a future build-in function) to generate courtesy accidentals should be configurable, I thought it might be useful to actually find out, what different configurations would be considered most useful and how this configuration itself should be implemented as long as we use a plugin.
Styles
As a starting point I'd suggest the different styles available in Lilypond.
The most interesting to me seem to be:
- piano
My plugin almost follows these rules, with the exception of adding courtesy accidentals to notes of a different octave in the same measure. I think I'm going to add this.
- *-cautionary
It is already possible to have the plugin use parenthesis, but one has to change that in the source code, which is not the desired way of configuration.
- dodecaphonic
It would be easy to write such a version.
A note concerning the modern style: This would require a change in the plugin framework (expose ChordRest::staffMove) and thus not be compatible with v2.0.
Implementing
- Using different plugins for each style supported. That would mean to have several source files and one could activate them via the Plugin Manager. However, this could be confusing if we come up with too many different options.
- Open a dialog window every time the plugin is used. Besides from being annoying, there also seems to be no way for the plugin to remember the user's previous choice.
Comments
For the most part, the distinctions they are talking about seem mostly relevant for piano or other polyphonic music. Personally, I don't care quite so much about automatic behavior in those cases, because I tend to dealing with this music on a more detail-oriented level in the first place and expect to take more manual control, but those do seem like fine options.
My main use case for the plugin is ensemble music, particularly for transposing instruments. I enter music at concert pitch and am thinking vertically as much as linearly. Even I enter courtesy accidentals at that stage, it's based on the concert pitch spelling, but I also very often "correct" the spelling in the transposed part, to favor readability over harmonic correctness. So it's at that stage - after I've turned Concert Pitch off, perhaps while looking at the linked part rather than the score (although I do this both ways), suddenly seeing these individual lines divorced from their original harmonic context - that's when I do most of my entry of courtesy accidentals.
I mention all this to point out that for me, it's going to be single line instruments I care about more than piano, so the concerns about which voice or staff don't concern me much. But I *do* care about transposition a lot, and about linked parts. The main control I want is over how "generous" to be. Often, I find it useful to include courtesy accidentals more than one measure later. I might go two measures, or up to the next double bar / rehearsal mark, or up to next full measure rest, etc. Those are perhaps idiosyncratic choices on my part, but still, it is very common to see courtesy accidentals included more than a measure later - often *much* more than a measure later.
As for the configurations, ultimately, I'd love to be able to move this functionality into the main core of the program. This would have many advantages. Not needing to load a plugin being an obvious one of course, but also, a dialog could more easily remember choices (although it's not a given even then, unelss maybe we made these "Style" options, which I guess is possible).
If you have any interest in incoporating this functionality into the program core, I'm willing to help. Or perhaps I could do the work of setting it up and you could just help with the algorithm itself.
In reply to As for the configurations, by Marc Sabatella
I'd be happy to try the latter suggestion of yours. So (on my side) I'm going to continue developing a plugin version (easy to debug...) containing more features (including your requests: n measures, up to next double bar) and add a configuration dialog. Then I'll move the algorithm to a C++ function (probably in Ms::Score?). I could come back on you when I'm done with these steps, so you can see what we have and tell me what changes/additions you'd need to do the set up for the main core.
In reply to I'd be happy to try the by heuchi
Great! The plugin will be useful for now, then maybe the code can move into the mian program for 2.1. BTW, when that happens, yes, I think the algorithm itself will want to live in Score. The command that invokes this might end up being ScoreView rather than Score if it has its own dialog that it needs to invoke and interact with, but it can be in Score if it just accesses Style settings, which may be the best way to go so that the settings can be saved automatically. And in any event, it will be easier enough to change those details later if need be.