Removing rests in voice 2,3,4 causes problems in writing the RetroGrade

[elsewhere37]

If you remove rests in voice 2,3,4 you also lose their segment which causes problems. As you wrote in the code: // weird bug when on voices 2, 3, 4 the cursor advances twice This fix in the clear selection code seems to work:

if ((cursor.track % 4 != 0) && (e.type === Element.REST)){ // do nothing } else if(e.tuplet) {

[elsewhere37]

Or better yet: do not remove any rests. Voice1 rests cannot be removed anyhow

[elsewhere37]

Here is a picture of what I mean: run the plugin on measures 4-5 & you get measures 1-3. I can imagine scenarios where my proposed fix would not work. Safest would be to fill the internal voices with the shortest encountered rests (see e.g. my plugin: https://musescore.org/en/project/fill-voices-rests)

[ellejohara]

I've been away from my plugin, and MuseScore, for a bit. But I'm back, finally, and I'm looking into these issues. Just need to plug the API back into my brain first! The MuseScore boilerplate snippets have been very helpful, as well as several experiments I rediscovered from when I was making version 2.0. So hopefully between it all there is a way to properly retrograde multiple voices.

[elsewhere37]

Welcome back. Hereby a mini version (everything is in voice 2). Copy measure1 in measure3 & run the plugin: you get the result shown. In writing out the retrograde you get cursor.ticks at 0,1200,1440,1920 because the 3/8 rest (and its segment) was deleted. Correct cursor.ticks 0,480,720,1440 occur with my fix. I am unable to find a case where my fix does not work, but still not completely sure. Looking forward to your take on this.

[ellejohara]

I completely rewrote the plugin (again) using some ideas I had come up with back in December that used the retrograde array much more directly. I also finally figured out the best order for writing each element back into the score that reduces redundancies and for() loop confusion. Now retrograding all four voices goes much better, and it doesn't generate oddities like the examples you provided above.

I tested the new version with some very busy measures full of chords and rests and tuplets and rests in tuplets all across multiple voices, and it all seems to work pretty well. Give it a try with some of your own test combinations and see what you think.

[elsewhere37]

Congrats! Looks good in initial testing. But in the project page you write: Basic Instructions: Make a selection of notes, chords, and/or rests, on a single staff with a single voice, then run NewRetrograde to reverse the selection. 'Single' no longer needed!

[elsewhere37]

P.S. The only potential danger with the cursor.element approach is this: if you were to consider retrograding chord symbols (but why would you?), you would have to iterate via segment.next() (see https://musescore.org/en/node/307565)

[elsewhere37]

Alert! Tpc is a problem again: run the retrograde on measure 1-3 & you get the result in measures 4-6

[ellejohara]

Hmm... I did a retrograde of just the first measure (resulting in the sixth measure) and got the same result as you. But looking at the console.log output, all the TPC values from the selection outputted correctly for each note. But something must be going on somewhere. Because while that whole note looks like a C#, there was no matching TPC 21 for it when it was written. However, if I re-retrograde the selection, that TPC 21 magically appears. So honestly I'm not sure if that's a bug with my code, or a bug with MuseScore. I'll look into it, though.

[ellejohara]

Ah. Selecting only the bass clef staff results in a null in the retrograde. That's a problem that needs fixing right away.

[elsewhere37]

Since your previous version does not have the tpc problem it must be fixable, but plugin programming is indeed voodoo…

Regarding chords: tpc of chord notes needs to be set ‘again’ after addNote (chord.notes[i].tpc = tpc) https://musescore.org/en/node/333755 https://musescore.org/en/node/285030

But now you also get tpc errors in melody notes. Here’s what I get after line 184

Debug: cursor.element.tpc = undefined Debug: cursor.element.pitch = undefined Debug: retro[i].notes[0].pitch = 58 Debug: retro[i].notes[0].tpc = 12 Debug: cursor.tick = 0 Debug: cursor.element.tpc = undefined Debug: cursor.element.pitch = undefined Debug: retro[i].notes[0].pitch = 61 Debug: retro[i].notes[0].tpc = 9 Debug: cursor.tick = 960

There is something wrong here…

Another ‘minor’ bug: if you enter the example in a score of 3 measures total, and select with ctrl-A the plugin does nothing. If you select all manually (without including the final barline), the plugin runs. This could indeed be a MuseScore bug.

I confirm: selecting only the bass clef staff results in a null in the retrograde

[ellejohara]

I just now discovered this as well. For whatever reason, the cursor.element.tpc is not getting updated. I'll have a look at my old code to see how I worked around it.

The bass clef can now be selected in 3.0.1. And I'll check out the 'select all' weirdness.

[ellejohara]

Yeah, the tpc solution was pretty simple. Just had to specify at the cursor.element 'notes[0].tpc'. The answer was staring me in the face with the retro[i].notes[0].tpc, but I just wasn't connecting the dots. It may be because it's 2am.

Check out 3.0.2 and see what you think.

[elsewhere37]

Didn't mean to keep you up. Everything is great now, except for one little thing: https://www.youtube.com/watch?v=RnEwIQQybh0&ab_channel=AlineCunio Paste measures 1-3 in 5-7, select 5-7 & run the plugin. Result shown there. There's a problem if the last measure of the score is included in the selection

[ellejohara]

I got it to write the last chord properly with 3.0.3, but there's still something weird going on with the re-select after the retrograde. It doesn't properly select all and can't figure out why.

[elsewhere37]

You need endTick + 1 in curScore.selection.selectRange See the API documentation for selectRange endTick: end tick of selection, excluded from selection

Commenting this line out also works

[ellejohara]

Ah! Seems obvious now. Thank you! I think with everything basically working now in 3.0.4 (hooray!), I can finally close the open issues.

[elsewhere37]

Yes, everything seems OK now. Your idea to just collect the cursor.elements is super!