Incorrect pitch when using insert input mode in first measure with alto clef

[L0uisc]

Issue type

Engraving bug (incorrect score rendering)

Description with steps to reproduce

1. Select "new score" on "Scores" page in home tab.
2. Create a new score based on treble clef template
3. Change treble clef to alto clef
4. Change note input mode to "insert"
5. Enter note input mode on the first beat of the first bar.
6. Type "C" to enter C
7. Expected: Note C is input and sounds.
8. Actual: Note is drawn on Middle C (middle line of the stave), but it sounds B4 and is displayed as B4 on the bottom note property display area.
9. Inserting more notes by typing "C" are consistently an octave above the previous one. See screenshot. These octaves are also indicated and sound as B, even though they are technically C.

Workaround: add first note in step time input mode.

Supporting files, videos and screenshots

What is the latest version of MuseScore Studio where this issue is present?

4.5 prerelease 8 Jan 2025

Regression

No

Operating system

OS: Windows 11 Version 2009 or later, Arch.: x86_64, MuseScore Studio version (64-bit): 4.5.0-, revision: github-musescore-musescore-

Checklist

• This report follows the guidelines for reporting bugs and issues
• I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
• I have attached all requested files and information to this report
• I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible

[sammik]

Any clef changed in first measure causes this issue.
(For example bass cleff staff with changed celf to treble in firs measure).

[L0uisc]

Indeed. Should have mentioned it in the report.

[sammik]

Not a regression, same issue in MU 3.6.2 too.

[L0uisc]

I've started to look into this. Will try to investigate further, but afaict the issue must originate here

MuseScore/src/engraving/dom/noteentry.cpp

Line 758 in ed9f1f2

Ret Score::insertChordByInsertingTime(const Position& pos)

in Score::insertChordByInsertingTime() somewhere before

MuseScore/src/engraving/dom/noteentry.cpp

Line 871 in ed9f1f2

putNote(p, true);

.

The issue only manifests in insert mode, and step time note input mode just directly calls putNote(). So my suspicion is that the bug is somewhere in the code which only gets executed when inserting, but not in the other input modes.

[sammik]

In fact, core of issue is in Staff::insertTime, and affects also key signatures (and may be instrumentChanges too).

In short, if clef is after barline (start of score, or option "after barline") record in staffList is manipulated (moved).

MuseScore/src/engraving/dom/staff.cpp

Lines 1406 to 1437 in 4d5ea05

	// check if there is a clef at the end of measure
	// before tick
	Clef* clef = 0;
	Measure* m = score()->tick2measure(tick);
	if (m && (m->tick() == tick) && (m->prevMeasure())) {
	m = m->prevMeasure();
	Segment* s = m->findSegment(SegmentType::Clef, tick);
	if (s) {
	track_idx_t track = idx() * VOICES;
	clef = toClef(s->element(track));
	}
	}
	ClefList cl2;
	for (auto i = m_clefs.lower_bound(tick.ticks()); i != m_clefs.end();) {
	ClefTypeList ctl = i->second;
	Fraction t = Fraction::fromTicks(i->first);
	if (clef && tick == t) {
	++i;
	continue;
	}
	m_clefs.erase(i++);
	cl2.setClef((t + len).ticks(), ctl);
	}
	m_clefs.insert(cl2.begin(), cl2.end());
	// check if there is a clef at the end of measure
	// before tick: do not remove from clefs list
	if (clef) {
	setClef(clef);
	}

Some situations are handled on many different places, I think (basic "clef before barline" directly in insertTime, other situations, if I remember in Scorre::insertMeasure / removeMeasure, others in Undo:InsertMeasure)

Short fix could be to add option to move / remove elements at tick.

Another variant of this issue is removing first note in place of key signature (select note, Ctrl + Del) - key signature itself remains in score, but record from keyList is removed see:

keysig-removeTime-issue.mp4

But I think, something deeper, redesign and refactor would be neccessary in future. Sorry for my language, I dont know right terms, but I hope, it would be understable.

I think realtion between Clef (in score) and clefList /and same for Key signature and keyList, Instrument change and instrumenList, staffTypeChange and staffTypeList/

It is good, that under the hood, it is possible to manipulate Celf, and clefList independently, but in most situations, they should be "linked", so (re)moving Clef erase/move record in clefList /or vice versa, (re)moving record in clefList (re)moves Clef itself.

So I think, there sould be "trinity":
manipulateClefOnly
manipulateClefListOnly
manipulateClef (which process both manipulateClefListOnly and manipulateClefOnly under the hood), and in most cases, we should use this third function.

(And same for others, keys, times, instruments, whatever...)

[sammik]

I belive, same core in #21095