Can now copy and paste notes in piano roll editor using the right click menu.
Allowing cut and paste of nodes in piano roll editor.
Allowing cut and paste of nodes in piano roll editor.
Cleaning code.
Using Fraction::fromTicks to convert ticks.
Changing variable names.
Updating cut/paste to use Fraction
Adding cut shortcut.
Undo now reverts all notes from paste.
Cleaning up code
Refactoring method
Fixing rebase
Making PRE child of main window.
Can now drag notes in PRE
Fixing layout of PRE levels window
Now showing note blocks when dragging.
Can now drag notes with relative offset
Escape will now cancel drag
Fixing rebase
Removing code that accidentally undid PR #6006
Fixing text, can now set voices of selected notes.
Resolves: https://musescore.org/en/node/294542.
Up until now, notehead scheme has only been a StaffType property. If a Note is going to have its own notehead scheme, it seems fitting to do a bit of reorganization. Here is a summary of the changes made:
- Moved enum class NoteHeadScheme to NoteHead::Scheme, alongside NoteHead::Group and NoteHead::Type.
- Added HEAD_AUTO as a possible value for NoteHead::Scheme.
- Moved scheme2userName(), scheme2name(), and name2scheme() from class StaffType to class NoteHead.
- Renamed Pid::STAFF_NOTEHEAD_SCHEME to Pid::HEAD_SCHEME. This change is reflected in the Plugin API, with Element property staffNoteheadScheme being renamed to headScheme. This should not break too many existing plugins, because the NoteHeadScheme enum values have never been exposed until now. Speaking of which,
- Exposed the NoteHead::Scheme enum values to the Plugin API as NoteHeadScheme.HEAD_AUTO, etc. And finally, (and the main point of all of this):
- Added a property of type NoteHead::Scheme to class Note, and exposed it via the Inspector. If set to HEAD_AUTO (the default), the StaffType’s noteHeadScheme will be used. Otherwise, this will override the StaffType’s noteHeadScheme.
Resolves: https://musescore.org/en/node/290987.
Make sure that B#, B##, Cb, and Cbb describe themselves as being in the correct octave. This is accomplished by calculating the octave based on what the pitch would be if there were no accidental. Thus, there is no need to special-case certain tpcs.
Resolves: https://musescore.org/en/node/301605.
Prior to this commit, ScoreView::cmdAddSlur() could be called multiple times from within ScoreView::addSlur(), resulting in the need for multiple "undo" commands to completely undo a single "add-slur" command. This commit swaps the names of these two functions, and, more importantly, only calls Score::startCmd() and Score::endCmd() once for the entire operation.
Resolves: https://musescore.org/en/node/301414.
During paste, if a note has a tie, that tie is remembered as a pending connector which is later added to the score when XmlReader::checkConnectors() is called. If a note is too long to fit in the measure, it is split up into a series of tied notes, but the pending tie needs to be adjusted to begin at the last tied note in the series, instead of at the original note.
Corrects first problem: Status doesn't display the pitch of note that have an
ottave line. This is solved in Note::tpcUserName().
Solves the second problem in issue 293593: Accidentals do apply if 8va sign is added.
This is solved in Note::updateAccidental(). All calculations are based on the
effective pitch of the a note rather than the actual pitch. The solution now
takes to ottava signs into account by using the actual pitch.
For easily find out wheather an ottava is applied, a new method ottavaCapoFret()
is added which returns the pitch offset by an ottava (or capo fret). To prevent
code dublication, ppitch() also use this new ottavaCapoFret() method.
The staff index did not count `staffMove()` in, which resulted in possibly getting the wrong clef for `line2pitch()`. This commit uses `chord->vStaffIdx()` to get the right staff index.
This happened because the acceptDrop check wasn't checking that the
editData it had for the text element was TextEditData. So, if the text
had been moved before, then it would have ElementEditData, and
acceptDrop would incorrectly return true.
This fixes the problem by adding a type() method to ElementEditData and
its derived classes so a proper check can be carried out in acceptDrop.
* Found via `codespell -q 3 -S ./share/locale,./thirdparty -L ba,cann,clas,dur,foto,iff,nd,ois,ot,pres,possibile,snaped,strack,tage,te,uint,thru,valu`
* Some revisions made per feedback given during review.
* Follow-up typos for review
* Add revisions per feedback
Resolves: https://musescore.org/en/node/297957.
When searching for a note to complete a tie, what matters is not so much that the note doesn't already have a tieBack(), but rather that the two notes have the same unisonIndex().
when handling paste, a switch statement is used on dropElement.type() (result is of type ElementType). Before this commit, there was no case for ElementType::STICKING, and paste wouldn't work (default behavior).
There turned out to be several aspects to this.
In 3.2.3, we could get a hang if there was literally only one note,
as the navigation would loop back around and we didn't always catch it.
For 3.3 I eliminated the looping back around on navigation,
but neglected to add a check for start/end of score in "fingering mode".
This adds that check (in ScoreView::textTab(), the test for el2 == el).
But further testing revealed further checks we need to make to be safe.
The checks that the current element is actually a child of the note
in Note::nextInEl() and Note::prevInEl() prevents a crash
if one navigates before the fingering has been added to its parent
or after it has been removed (which happens with empty fingering elements).
For consistency with how chord symbols work, and to circumvent other future problems,
I elected to have Space *exit* "fingering mode" after reaching the end of the score.
This required making a reasonable selection (the "exit cleanly" code in textTab)
but also calling mscore->endCmd() and returning immediately in events.cpp in that case.
This had the side benefit of allowing me to remove the updateInspector() call
in textTab(), as it is covered by the endCmd() call.
I should note there are other code paths in, for example, the harmony tab functions,
that can leave an empty / deleted element still selected
when hitting space upon reaching the last note of a score.
But I could cause an actual problem to occur and chose to not deal with that here.
Script test added to cover the basic issue here.
Paste of a note onto a grace note has never worked;
the operation has always been silently rejected.
Now, however, it crashes, because we are attempting to select the note
we think we just pasted.
But there was no reason to reject the operation;
the same code that handles pasting onto a normal note
also works when pasting onto a grace note.
So this change removes the unnecessary check for grace notes.
By removing these four lines of code, it fixes the crash,
and allow the operation to actually succeed where it never did before.
Resolves: https://musescore.org/en/node/279179.
Also resolves: https://musescore.org/en/node/293984, which is really the same issue.
NATURAL_SHARP and NATURAL_FLAT are handled in the same way as microtonal accidentals, but unlike microtonal accidentals, NATURAL_SHARP and NATURAL_FLAT affect the playback pitch of the note. Therefore, when these accidentals are encountered, it is incorrect to set the accidental state to NATURAL. Instead, it must be set to the AccidentalValue that corresponds to the accidental's subtype.
In the original implementation of accessibility,
we had the screenreader always read all extra information associated with a chord
(including articulations, lyrics, staff text, etc)
every time a note in that chord was selected.
This was necessary becayse we had no no way at the time to reach those elements individually.
Now that the next/previous element commands can access those elements directly,
we no longer need to read them on selection of the note.
And yet, reading this information on ordinary navigation (left/right) is not without value.
So this change simply limits the reading of the extra info to the top note of a chord,
and even then also checks voices for segment annotations.
The result is, when navigating, you'll hear the extra information read
when the chord is first hit, because we navigate chords top to bottom,
ut will not hear the extra information repeated for each subsequent note in the chord.
Beat information continues to be read always.
Added code to track the staff & bar number when constructing accessibility text.
If we detect that a navigation has not changed either, we skip reading it,
by constructing a separation "optimized" version of the appropriate text.
Also skip reading voice for measures that have only a single voice,
by suppressing the buiding of that string in screenReaderInfo() for both Note and Rest.
The status line and screenreader info do not currently include string or fret info for tab.
This was requested, and seems logical and easy to do, so this commit adds the support
by incorporating the info into the return value of Note::accessibleInfo()
and Note::screenreaderInfo().
This adds addition translation strings for string and fret,
which could be a consideration in the timing for this.
It is not as high a priority for me as my other main accessibility.
