-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Encoding of fermata #3
Comments
I guess the most straightforward solution would be to use the f character to indicate a fermata, assuming that it might no longer be needed in its previous function (repeated figures). |
Would it be possible to choose a letter that isn't also a pitch name? |
If we have some sort of visual connection in mind, which I tend to find helpful, perhaps a "u" could remind PAE users of a fermata standing below the note? Or, merely from the visual point of view, even better an uppercase one: U |
I thought about using the |
(That's also why I added the note about the uppercase U only in passing at the end -- that way it would look more like a fermata, but the capitalization feels nonetheless suboptimal regarding the coherence of the full system.) |
NB: I think the _ much better expresses the idea of tying than a lowercase u. |
Changes the fermata character to a p Fixes #3
Changes the fermata character to a p Fixes #3
I think it would be better to have the One would need to clarify the order with
For chords, |
Trilled chords seem out of scope to me… |
Maybe. We have about only 10 of them https://rism.online/sources/300000052/. As long as it is clearly specified, I don't see a problem with them, though. |
#110 would get weird if we had tied and trilled chords… |
Also, the fermata modifies the duration of the note, so it makes sense that it goes before the note name? |
Yes, I agree. But then would If you see it bound to the duration, it should be 2., otherwise it should be placed after the note IMO. And I see 1. to be less of a change with V1, where I don't see a major reason to go for 2. - both have valid arguments. |
PS V1 does |
Sure, but we haven't really established such a concept -- it's not really "bound" to the duration. The We can also move those after the notes if we want to introduce the idea that "inherited" attributes come before the note name, while "note-specific" attributes come after? |
As they are written now, the rules say the fermata must be immediately before the note name, and after all other attributes. So it would be |
Yes, so it does not look like it is modifying the duration. It is modifying the note, and as I proposed initially it should be placed after. I am not sure where the problem is with this. Could you explain why you decided against it? |
I didn't decide against it... I just had to choose one or the other. I'm ok moving it, but I think we should establish a pattern for this so that it's not just arbitrary about which things come before, and which come after. |
OK, let's move it after. The pattern I have in mind is:
|
OK, sounds good to me. In general:
Ties: See #112 |
Modelling this out, I think we'll run into a problem with appogiatura. Consider:
and
The first adds the Potential solutions:
Personally, I might go for the second option, and change appogiatura groups to start with a letter like
|
I would keep the appogiatura at the beginning. We don't want to change too much when it is not strictly needed. |
Also important is that it didn't distinguish between acciaccatura and appogiatura. |
I completely agree. As a matter of fact, one thing the Verovio parser does is replace qq with Q before doing any parsing. Maybe we can change qq to s, but I would definitely keep q before the note. |
Or y so every grace note start has a glyph going under the baseline? |
I like Not sure where that leaves us with any sort of logical order with note attributes, though. It would be nice to have some way of explaining their order, instead of it being arbitrary. |
I see this as a major, more duration-like, qualifier, which is why it comes before. This is different from t or p. |
Maybe we should talk this over in person. |
Yeah, it's the "some" coherence I'm worried about. Right now it all seems a bit arbitrary. |
Sure. Let's talk about it. But we shouldn't try to draw too hard lines when trying to organise things as long as we can show some coherence. Being too strict in domains and concepts never works with music notation. Maybe another way to look at this is to categories them as primary modifiers (duration, octave, accidental, grace) essential for basic rendering, and secondary ones (trill, fermata) |
Symbols above the note? That seems to be what fermata and trills are. Maybe, if you squint hard enough, ties would fit in that class too? |
I actually think that @lpugin's argument about the gracenote being "a major, more duration-like, qualifier" makes sense. In the case of I of course understand @ahankinson's point that a fermata also affects the duration in the end, but the effect of that seems quite different in that in this case (I am of course speaking of the modern text-book interpretation of fermate here) the explicitly stated duration is absolutely relevant, the note is held that long -- and after that moment comes a (more or less) unexpected turn, namely that the note does not end there, but is held even longer. Viewing the music in this way as a process, the fermata sign seems to become relevant only after the pitch -- quite similarly to a tie, which in certain constellations indeed has a rather similar psychological effect. I won't argue that this is a waterproof train of thought, but I also have the clear impression that the fermata should come only after, and I think this is the actual musical reason for my strongly feeling so. |
The current specifications of PAE support the encoding of fermata with the
(
and)
character.From the current specifications
The main problems with this a approach are:
The proposal would be to use a single characters for encoding fermata since there is no need to have a start and end delimiter. It would avoid overlap with tuplets, it would also work better with chords and would be more inline with the current encoding of trills.
Some possible characters could be:
?
*
c
(corona)h
(hold)p
(pause and point d'orgue)Placement of the sign should be after the note / chord
The text was updated successfully, but these errors were encountered: