Skip to content

Hook height migration#32467

Open
miiizen wants to merge 1 commit intomusescore:masterfrom
miiizen:hookHeightMigration
Open

Hook height migration#32467
miiizen wants to merge 1 commit intomusescore:masterfrom
miiizen:hookHeightMigration

Conversation

@miiizen
Copy link
Contributor

@miiizen miiizen commented Mar 3, 2026

This PR migrates hook height signs (<4.6) on file read to avoid an additional score layout.

It also fixes a bug in ornament cue note layout order covered up by this second layout.

Copy link
Contributor

@mike-spa mike-spa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you mind moving the ornament cui note fix to a separate PR? I think the hook sign fix could potentially go in 4.7, but the cur note fix certainly not

}
}

compat::CompatUtils::resetHookHeightSign(b);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like there's code before the function call that does the same thing as the function?

<HairPin>
<subtype>0</subtype>
<beginHookHeight>-1.9</beginHookHeight>
<endHookHeight>-1.9</endHookHeight>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These tests changes look quite weird: why are we suddenly adding hookHeight tags to hairpins?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've changed the hookHeight value by flipping it so it no longer matches the default. Hairpin's hook heights look like this by default pre 4.6
Screenshot 2026-03-05 at 10 45 40

}
volta->setOffset(PointF()); // ignore offsets
volta->setAutoplace(true);
CompatUtils::resetHookHeightSign(volta);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It makes me a bit uncomfortable to have to add this compat function to 20 different places across all the read module. Could we not move this to EngravingCompat::doPreLayoutCompat? It will perhaps slightly add to the reading time as we need to navigate and find these spanners, but it's well worth it IMO if it saves us from calling it so many times

Copy link
Contributor Author

@miiizen miiizen Mar 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could, but I'm keen to put as much compatibility code which doesn't require score context in the file reading code as possible. Otherwise we need to add the same compatibility fix for palette items in PaletteCompat, which is something we always forget to do and I'd prefer to avoid where possible. This was part of the motivation behind versioning the palette files.

I agree this is a bit messy though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah good point about the palettes, then yeah I think it's fine 👍

@miiizen miiizen force-pushed the hookHeightMigration branch from 1d30c63 to 0fc2d59 Compare March 5, 2026 14:04
@davidstephengrant
Copy link
Contributor

Tested and approved on Ubuntu 24.04.4 LTS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants