Skip to content
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

Closed
lpugin opened this issue Sep 21, 2021 · 32 comments · Fixed by #100
Closed

Encoding of fermata #3

lpugin opened this issue Sep 21, 2021 · 32 comments · Fixed by #100
Labels
Status: Waiting for feedback Currently waiting for more information Type: Spec Change Changes to the PAE Specification

Comments

@lpugin
Copy link
Contributor

lpugin commented Sep 21, 2021

The current specifications of PAE support the encoding of fermata with the ( and ) character.

From the current specifications

fermata (include only one note or rest; accidentals or octave symbols must be outside the parentheses. See also "Special rhythmic groupings" below.)

The main problems with this a approach are:

  • fermata uses the same characters as the special rhythmic groupings (tuplets), which causes some additional validation / parsing problems. Only the analysis of the content gives the meaning of the signs, which is not very good practice.
  • there are some contradictions with trill and tie encoding when saying that only a note or a rest should be included since the trill and tie characters are supposed to follow the note immediately. In other words, encoding a note with a fermata and a trill is currently impossible when following strictly the current PAE specifications.

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

@lpugin lpugin added the Type: Spec Change Changes to the PAE Specification label Sep 21, 2021
@BaMikusi
Copy link
Collaborator

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).

@ahankinson
Copy link
Contributor

Would it be possible to choose a letter that isn't also a pitch name?

@BaMikusi
Copy link
Collaborator

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

@lpugin
Copy link
Contributor Author

lpugin commented Mar 25, 2022

I thought about using the u for ties also with a visual similarity argument in mind. I would stay away from capital letters for anything that is not a pitch name.

@BaMikusi
Copy link
Collaborator

(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.)

@BaMikusi
Copy link
Collaborator

NB: I think the _ much better expresses the idea of tying than a lowercase u.

ahankinson added a commit that referenced this issue May 27, 2024
Changes the fermata character to a p

Fixes #3
ahankinson added a commit that referenced this issue May 27, 2024
Changes the fermata character to a p

Fixes #3
@lpugin lpugin reopened this May 28, 2024
@lpugin
Copy link
Contributor Author

lpugin commented May 28, 2024

I think it would be better to have the p following the note. Musically - so to speak - it makes more sense, but the main point is that I think it is important to have accidental and note names together with octave and duration. So I see it more as a additional attribute appended to it.

One would need to clarify the order with t and _. I would expect:

  • Trill t
  • Fermata p
  • Tie _

For chords, t and p would come after the chord closing character (relates to #65)

@ahankinson
Copy link
Contributor

Trilled chords seem out of scope to me…

@lpugin
Copy link
Contributor Author

lpugin commented May 28, 2024

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.

@ahankinson
Copy link
Contributor

#110 would get weird if we had tied and trilled chords…

@ahankinson
Copy link
Contributor

Also, the fermata modifies the duration of the note, so it makes sense that it goes before the note name?

@lpugin
Copy link
Contributor Author

lpugin commented May 28, 2024

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 4pCEG be

1 image or 2 image ?

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.

@lpugin
Copy link
Contributor Author

lpugin commented May 28, 2024

PS V1 does 4x(F), changing to 4xFp makes more sense than changing to 4pxF

@ahankinson
Copy link
Contributor

ahankinson commented May 29, 2024

If you see it bound to the duration, it should be 2., otherwise it should be placed after the note

Sure, but we haven't really established such a concept -- it's not really "bound" to the duration. The g and q also comes before the note name, but it only lasts for one note. There's no expectation that it translates to the following notes.

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?

@ahankinson
Copy link
Contributor

PS V1 does 4x(F), changing to 4xFp makes more sense than changing to 4pxF

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 4xpF, which is just as easy to convert as 4xFp.

@lpugin
Copy link
Contributor Author

lpugin commented May 29, 2024

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?

@ahankinson
Copy link
Contributor

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.

@lpugin
Copy link
Contributor Author

lpugin commented May 29, 2024

OK, let's move it after. The pattern I have in mind is:

  • duration and pitch codes before the note
  • modifiers (trill, fermata, ties) codes after

@ahankinson
Copy link
Contributor

ahankinson commented May 29, 2024

OK, sounds good to me.

In general:

  • Things that can be omitted go before and are inherited by following notes: duration, accidentals? octaves
  • Things that are specific to a single note go after: grace, trill, fermata

Ties: See #112

@ahankinson
Copy link
Contributor

ahankinson commented May 29, 2024

Modelling this out, I think we'll run into a problem with appogiatura. Consider:

8Aq{8CD}E

image

and

8Aqq{8CD}rE

image

The first adds the q at the end of the note (based on this conversation), but the second starts a new grace group for the notes that are following. If you're parsing the string, it's difficult to know, until the second q, that the appogiatura applies to the current note, or if it's the start of an appogiatura group.

Potential solutions:

  • Change the appogiatura character
  • Change the appogiatura group start character(s)
  • Live with the uncertainty
  • Keep the appogiatura at the beginning

Personally, I might go for the second option, and change appogiatura groups to start with a letter like t or s, e.g.,

8At{8CD}rE

@lpugin
Copy link
Contributor Author

lpugin commented May 29, 2024

I would keep the appogiatura at the beginning. We don't want to change too much when it is not strictly needed.

@ahankinson
Copy link
Contributor

qq is a weird one, though. It's the only grouping mechanism that uses two characters instead of one.

Interestingly, the original papers had q as the start of the group, and qq as the cancellation.

image

@ahankinson
Copy link
Contributor

Also important is that it didn't distinguish between acciaccatura and appogiatura.

@lpugin
Copy link
Contributor Author

lpugin commented May 29, 2024

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.

@lpugin
Copy link
Contributor Author

lpugin commented May 29, 2024

Or y so every grace note start has a glyph going under the baseline?

@ahankinson
Copy link
Contributor

I like y as the start of a group.

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.

@lpugin
Copy link
Contributor Author

lpugin commented May 29, 2024

I see this as a major, more duration-like, qualifier, which is why it comes before. This is different from t or p.

@ahankinson
Copy link
Contributor

Maybe we should talk this over in person. p (fermata) seems to definitely be a 'duration-like' qualifier, but now we're just going around in circles.

@ahankinson
Copy link
Contributor

Yeah, it's the "some" coherence I'm worried about. Right now it all seems a bit arbitrary.

@lpugin
Copy link
Contributor Author

lpugin commented May 29, 2024

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)

@ahankinson
Copy link
Contributor

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?

@lpugin lpugin added the Status: Waiting for feedback Currently waiting for more information label May 29, 2024
@BaMikusi
Copy link
Collaborator

BaMikusi commented Jun 5, 2024

I actually think that @lpugin's argument about the gracenote being "a major, more duration-like, qualifier" makes sense. In the case of g it certainly is, for this character tells you that the following note will not need a strictly measured duration, and should instead be rendered as a really short one -- so here the g sort of functions as a substitute for an explicit duration value. But if the g comes before the pitch, the q should arguably do the same -- and one can in fact also positively argue that here, too, the q qualifies the following duration from the start, making clear that it should not strictly be taken at face value.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Waiting for feedback Currently waiting for more information Type: Spec Change Changes to the PAE Specification
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants