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

[WIP] Instrument change improvements #5128

Open
wants to merge 32 commits into
base: master
from

Conversation

@joshwd36
Copy link
Contributor

commented Jun 15, 2019

The aim of this pull request is to make a number of improvements to instrument changes, to reduce the amount of work users need to do, and to introduce some new functionality. The currently implemented functionality is:

  • Adding an instrument change object automatically opens the instrument change dialog
  • After the instrument has been chosen, the instrument change text automatically changes
  • After the instrument has been chosen, the clef is changed automatically, if necessary
  • After the instrument has been chosen, the key signature is changed automatically, if necessary
  • If a key change is placed before one or more instrument changes, the key signatures for those instrument changes update too
  • When an instrument change is placed, a warning is placed at the first note after it to remind the player to play the new instrument.
  • If a note is added after an instrument change, before a subsequent passage, the warning is moved to that note.
  • It is now possible to change to an unpitched percussion or tab staff, and have the clefs and staves appear properly.

Much of this work was completed during the Google Summer of Code 2019. The last commit of the GSoC period was 34a1b27.

@dmitrio95 dmitrio95 added the GSoC label Jun 15, 2019

mscore/palette.cpp Outdated Show resolved Hide resolved
mscore/dragdrop.cpp Outdated Show resolved Hide resolved

@joshwd36 joshwd36 force-pushed the joshwd36:instrument-change-improvements branch 2 times, most recently from d210d5a to 7c82f41 Jun 17, 2019

@anatoly-os anatoly-os changed the title Instrument change improvements [WIP] Instrument change improvements Jun 18, 2019

@jthistle
Copy link
Contributor

left a comment

A couple of notes, but generally seems good. Any 👍s are just for bits that we've agreed on in other conversations, as a reminder.

libmscore/edit.cpp Outdated Show resolved Hide resolved
libmscore/edit.cpp Outdated Show resolved Hide resolved
mscore/dragdrop.cpp Show resolved Hide resolved
mscore/palette.cpp Show resolved Hide resolved
libmscore/instrchange.h Outdated Show resolved Hide resolved

@joshwd36 joshwd36 force-pushed the joshwd36:instrument-change-improvements branch 3 times, most recently from 6424ed4 to 0d3c0a9 Jun 23, 2019

@joshwd36 joshwd36 force-pushed the joshwd36:instrument-change-improvements branch from 0d3c0a9 to 429b54d Jul 7, 2019

@jthistle
Copy link
Contributor

left a comment

Generally, this looks like a good basis for adding the warning text. Nothing stands out as a major problem, but there are just a few smaller issues. Keep at it :)

libmscore/edit.cpp Outdated Show resolved Hide resolved
libmscore/edit.cpp Outdated Show resolved Hide resolved
libmscore/edit.cpp Outdated Show resolved Hide resolved
libmscore/edit.cpp Outdated Show resolved Hide resolved
@Jojo-Schmitz

This comment has been minimized.

Copy link
Contributor

commented Jul 9, 2019

Travis is not happy, see https://travis-ci.org/musescore/MuseScore/jobs/555267917#L2108-L2112:

/home/travis/build/musescore/MuseScore/libmscore/key.cpp: In function ‘Ms::Interval Ms::calculateInterval(Ms::Key, Ms::Key)’:
/home/travis/build/musescore/MuseScore/libmscore/key.cpp:132:42: error: cannot call constructor 'Ms::Interval::Interval’ directly [-fpermissive]
return Interval::Interval(chromatic);
^
/home/travis/build/musescore/MuseScore/libmscore/key.cpp:132:42: note: for a function-style cast, remove the redundant ‘::Interval’

@joshwd36

This comment has been minimized.

Copy link
Contributor Author

commented Jul 9, 2019

Travis is not happy, see https://travis-ci.org/musescore/MuseScore/jobs/555267917#L2108-L2112:

/home/travis/build/musescore/MuseScore/libmscore/key.cpp: In function ‘Ms::Interval Ms::calculateInterval(Ms::Key, Ms::Key)’:
/home/travis/build/musescore/MuseScore/libmscore/key.cpp:132:42: error: cannot call constructor ‘Ms::Interval::Interval’ directly [-fpermissive]
return Interval::Interval(chromatic);
^
/home/travis/build/musescore/MuseScore/libmscore/key.cpp:132:42: note: for a function-style cast, remove the redundant ‘::Interval’

Thank you, I've fixed that now.

@joshwd36 joshwd36 force-pushed the joshwd36:instrument-change-improvements branch from 429b54d to e09317c Jul 10, 2019

@Jojo-Schmitz

This comment has been minimized.

@jthistle
Copy link
Contributor

left a comment

Some more comments :)

libmscore/edit.cpp Outdated Show resolved Hide resolved
libmscore/instrchange.cpp Show resolved Hide resolved
mscore/propertymenu.cpp Outdated Show resolved Hide resolved
mscore/propertymenu.cpp Outdated Show resolved Hide resolved

@joshwd36 joshwd36 force-pushed the joshwd36:instrument-change-improvements branch from e09317c to a61b376 Jul 13, 2019

@jthistle

This comment has been minimized.

Copy link
Contributor

commented Jul 28, 2019

Hi Josh, I've had a quick test and found a few things that I thought I'd mention. This was all tested with b4c0929.

Things that are good

  1. When I add an instrument change directly after an instrument change, there is no warning text for the first change and the key signature and clef are changed correctly Screenshot from 2019-07-28 10-20-49
  2. Changing the instrument of an existing change updates both the key sig and clef
    Screenshot from 2019-07-28 10-17-43

Things that... aren't so good

  1. When I paste an instrument change that I cut from elsewhere, there is no warning text added, and the clef and key signature are not changed.
    Screenshot from 2019-07-28 10-20-11

  2. If I change the instrument of an existing instrument change, the warning text is not updated with the new text instrument's name.
    Screenshot from 2019-07-28 10-18-19

  3. If I delete an instrument change immediately after another, the key signature, although correct, remains as a duplicate of the last one
    Screenshot from 2019-07-28 10-29-40

  4. If I add an instrument change exactly where the instrument enters, there is still warning text
    Screenshot from 2019-07-28 10-16-16

  5. When I create an instrument change, then manually delete its clef and key signature, and then delete the instrument change, there is a segfault

  6. Other various segfaults - if I can get some consistent reproduction methods, I'll post them on this PR

Hope that helps! I know it seems like a lot, but I'm sure a lot of those issues have relatively simple fixes.

@joshwd36

This comment has been minimized.

Copy link
Contributor Author

commented Jul 28, 2019

Thank you for this, it's very helpful to have another set of eyes on it. Some of the things I'm aware of, like the cutting and pasting and the various segfaults, and I've been working on fixing them this week, but some of them are things I've overlooked, and will have a look at fixing, so thank you.

@joshwd36 joshwd36 force-pushed the joshwd36:instrument-change-improvements branch from b4c0929 to e2b0799 Aug 1, 2019

@jthistle
Copy link
Contributor

left a comment

I have 'a few' comments :)

Overall, it's looking good. Just the last few bugs to iron out, and now that everything is separated into functions, it should be easier to fix. At least, that's what I'd hope...

Bugs found during testing

  • adding an instrument change before an entry, and then another after that but before the entry, then deleting the second instrument change leads to the warning text disappearing until I click on the first instrument change.
    bug

  • There's some weird stuff going on with key sigs. I'm not entirely sure how I got it into this state, sorry:
    image

  • Here is an example of another problem related to the above:
    bug2

@@ -556,6 +550,24 @@ Element* ChordRest::drop(EditData& data)
score()->undoAddElement(e);
return e;
}
case ElementType::INSTRUMENT_CHANGE:
if (e->isInstrumentChange() && part()->instruments()->find(tick().ticks()) != part()->instruments()->end()) {

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 11, 2019

Contributor

e->isInstrumentChange() is redundant AFAIK, because we already switch e->type() and are in a block where the type is ElementType::INSTRUMENT_CHANGE.

Also, not tested, but if I try to add an instrument change to the first bar of a score, won't this block run?

This comment has been minimized.

Copy link
@joshwd36

joshwd36 Aug 16, 2019

Author Contributor

Thank you, I'll remove the isInstrumentChange(). I've tested it, and it doesn't block if you add to the first bar of the score.

This comment has been minimized.

Copy link
@joshwd36

joshwd36 Aug 16, 2019

Author Contributor

For clarity, this was an existing piece of code, that had a fall-through in it, hence the check. I rearranged it so that the above items didn't fall-through to it, so I could add some more specific code for instrument changes.

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 17, 2019

Contributor

Sorry, when you say it 'doesn't block', you mean that block doesn't run, right?

@@ -286,6 +286,8 @@ void Clef::read(XmlReader& e)
_clefTypes._transposingClef = Clef::clefType(e.readElementText());
else if (tag == "showCourtesyClef")
_showCourtesy = e.readInt();
else if (tag == "forInstrumentChange")

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 11, 2019

Contributor

I'm always wary about adding new tags, but I think this can be justified 👍

deleteItem(clef);
InstrumentChangeWarning* warning = nextICWarning(ic->part(), ic->segment());
if (warning)
undoRemoveElement(warning);

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 11, 2019

Contributor

I think a solution here (for the first bug described) would be to somehow check if we need to add a new warning for any previous instrument change. i.e., if we search backwards for ICs and IC warnings, and hit and IC before an IC warning, we need to add a new warning for that IC.

This comment has been minimized.

Copy link
@joshwd36

joshwd36 Aug 16, 2019

Author Contributor

Yes, I'll investigate this further, but I think that sounds like the right sort of thing.

{
InstrumentChangeWarning* warning = toInstrumentChangeWarning(el);
InstrumentChange* ic = prevInstrumentChange(warning->segment(), warning->part(), false);
ic->setShowWarning(false);

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 11, 2019

Contributor

👍

continue;
if (!annotation->systemFlag() && annotation->track() == track)
undoRemoveElement(annotation);
deleteItem(annotation);

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 11, 2019

Contributor

Why this change?

This comment has been minimized.

Copy link
@joshwd36

joshwd36 Aug 16, 2019

Author Contributor

The code to delete an instrument change warning when an instrument change is is deleted is kept in deleteItem(), as is the same for special cases for all objects. So if an instrument change is deleted as part of a selection, without that change it wouldn't delete the warning associated with it.

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 17, 2019

Contributor

And deleteItem makes use of undoable functions?

@@ -118,6 +220,8 @@ void InstrumentChange::read(XmlReader& e)
const QStringRef& tag(e.name());
if (tag == "Instrument")
_instrument->read(e, part());
else if (tag == "init")
_init = e.readBool();

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 11, 2019

Contributor

See above - do we really need to write it?

InstrumentChangeWarning* _warning = nullptr;
bool _init = false;
bool _showWarning = true;
Q_DECLARE_TR_FUNCTIONS(setupInstrument)

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 11, 2019

Contributor

Nice, I had forgotten completely about translations.

|| !(*i.stringData() == *stringData())
|| i._singleNoteDynamics != _singleNoteDynamics;
//return !operator==(i);
}

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 11, 2019

Contributor

Why not just make this whole function return !(*this == i)? (That syntax may not be exactly correct off the top of my head).

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 11, 2019

Contributor

I do see now that that's been commented out. Why?

This comment has been minimized.

Copy link
@joshwd36

joshwd36 Aug 16, 2019

Author Contributor

This was something I was unsure about. Because the equals function compares the channels vector, and creating a new instrument in an instrument change creates a new channel, it would not return equal, even if they were the same instrument, which is what I was wanting to check. However, thinking about it, this should probably be in a new function, as it's quite confusing to have these work slightly differently.

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 17, 2019

Contributor

OK, that makes sense. As you say, I'd consider putting the conditions that are common between them into a new function and using that to reduce duplication.

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 17, 2019

Contributor

And make sure to comment why it's like that as well for confused people like me!

}
score->setLayoutAll();
score->endCmd();
}

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 11, 2019

Contributor

Nice, it's good to have options for this stuff in the inspector.

ic->setPlainText(tr("To %1").arg(it->trackName));
Instrument instr = Instrument::fromTemplate(it);
ic->setInit(true);
ic->setupInstrument(&instr);

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 11, 2019

Contributor

This is great! It's so much more simplified.

@joshwd36 joshwd36 force-pushed the joshwd36:instrument-change-improvements branch 2 times, most recently from cc7c997 to fcfe0aa Aug 20, 2019

@jthistle

This comment has been minimized.

Copy link
Contributor

commented Aug 21, 2019

Here's a nice crash I found:

output

Seems to be originating from setupInstrument...

@jthistle

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2019

Another thing I'd check is whether you really need a StaffTypeChange. What functionality do you gain from adding it in InstrumentChange::setupInstrument?

@joshwd36

This comment has been minimized.

Copy link
Contributor Author

commented Aug 23, 2019

I think I do need that, as that allows it to change between different staff groups (standard, percussion, tab), and also allows it to change the number of lines on the staff. Although I suppose I could just change the staff type without the object, although that may be a bit less transparent to the user.

@jthistle
Copy link
Contributor

left a comment

Looking good, just a few more comments

@@ -8843,7 +8843,7 @@
<description>Banjo (Tablature)</description>
<musicXMLid>pluck.banjo</musicXMLid>
<stafftype staffTypePreset="tab5StrCommon">tablature</stafftype>
<!-- <clef>TAB</clef> -->
<clef>TAB</clef>

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 23, 2019

Contributor

I'm sure there's a good reason, but why did you uncomment all of these?

This comment has been minimized.

Copy link
@joshwd36

joshwd36 Aug 23, 2019

Author Contributor

Previously, when you added a change to a tab instrument, it would default to a G clef, which it wouldn't be able to add as it is the wrong staff group. So this reverts them back to tab clefs, which it can then add properly.

void setNextChord(ChordRest* chord);
void setLines(const int lines) { _lines.push_back(lines); }

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 23, 2019

Contributor

No need for const int. const refers to a value that shouldn't be changed. But, since lines is passed as an int, a copy of it will be passed (if it were int& or int*, that would be different). So, it makes no sense to add a const qualifier.

bool init() const { return _init; }
void setInit(bool init) { _init = init; }

bool showWarning() const { return _showWarning; }
void setShowWarning(bool showWarning) { _showWarning = showWarning; }
void setShowWarning(const bool showWarning) { _showWarning = showWarning; }

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 23, 2019

Contributor

Same here as above.

@@ -240,6 +249,13 @@ void InstrumentChange::write(XmlWriter& xml) const
_instrument->write(xml, part());
if (_init)
xml.tag("init", _init);
switch (_staffGroup) {
case StaffGroup::PERCUSSION: xml.tag("staffGroup", "percussion"); break;
case StaffGroup::TAB: xml.tag("staffGroup", "tab"); break;

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 23, 2019

Contributor

+1 for names

else if (text == "tab")
_staffGroup = StaffGroup::TAB;
else
_staffGroup = StaffGroup::STANDARD;

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 23, 2019

Contributor

Is _staffGroup set to StaffGroup::STANDARD by default in instrChange.h? Otherwise, it will technically be uninitialized on read.

@@ -43,6 +43,8 @@ class InstrumentChange final : public TextBase {
Instrument* _instrument; // Staff holds ownership if part of score
bool _init = false; // Set if the instrument has been set by the user, as there is no other way to tell.
bool _showWarning = true;
std::vector<int> _lines;
StaffGroup _staffGroup = StaffGroup::STANDARD;

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 23, 2019

Contributor

nevermind my above comment 😄

@jthistle
Copy link
Contributor

left a comment

This looks really great, it's much cleaner without the StaffTypeChange element. Just a few questions from me.

part->staff(i)->staffTypeListChanged(segment()->measure()->tick());
Staff* staff = part->staff(i);
if (part->staff(i)->staffType(tickStart)->lines() != _lines || _staffGroup != StaffGroup::STANDARD) {
clefOffset = setupStaffType(staff);

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 24, 2019

Contributor

+1 for putting this in a separate function

{
StaffType* st = staff->staffType(segment()->measure()->tick());
Spatium oldOffset = st->yoffset();
Spatium newOffset = Spatium(2.5 - 0.5 * (float)_lines);

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 24, 2019

Contributor

what are these magic numbers doing here?

This comment has been minimized.

Copy link
@joshwd36

joshwd36 Aug 24, 2019

Author Contributor

It's necessary to adjust the offset of the staff when adding a staff type change to a different number of lines. I'm not sure how better to represent this, as the numbers don't really lend themselves to names for constants.

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 24, 2019

Contributor

So I'm guessing this bit is inspired/copied from StaffTypeChange? If it is, do you think it'd be feasible to avoid duplication and put the code in any one single place?

This comment has been minimized.

Copy link
@joshwd36

joshwd36 Aug 24, 2019

Author Contributor

I don't think it is present anywhere else in the project, as even when you add a staff type change you have to manually change the offsets to make it line up, if you change the number of lines. I haven't done a thorough search though.

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 25, 2019

Contributor

Oh right, sorry. The numbers should be fine to leave in in this case, although a comment wouldn't hurt.

void setLines(const int lines) { _lines.push_back(lines); }
void clearLines() { _lines.clear(); }
void setLines(int lines) { _lines = lines; }
int lines() const { return _lines; }

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 24, 2019

Contributor

👍 seems like you've got the hang of const now ;)

@@ -1425,9 +1425,13 @@ void ChangeStaff::flip(EditData*)

void ChangeStaffType::flip(EditData*)
{
StaffType st = *staff->staffType(Fraction(0,1)); // TODO
StaffType st = *staff->staffType(tick);

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 24, 2019

Contributor

Nice, seems like that was probably what the TODO was for.

if (it->staffTypePreset)
ic->setLines(it->staffTypePreset->lines());
else
ic->setLines(5);

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 24, 2019

Contributor

why the magic 5 here, and the removal of clearLines?

This comment has been minimized.

Copy link
@joshwd36

joshwd36 Aug 24, 2019

Author Contributor

When lines was a vector, when I was storing the number of lines for each stave, it would clear it before setting up the instrument to make sure it was a clean setup, but as it's now just storing the default number of lines, it's unnecessary. And standard instruments don't have a stafTypePreset, for some reason, so this was to set the number of lines to 5 manually. I've set this as a default value in the header file, which should fix the tests, although its still necessary to keep it here to facilitate changing from a percussion/tab instrument to a standard one.

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 24, 2019

Contributor

Huh, that's a bit odd. Should be fine though.

@Jojo-Schmitz

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2019

Travis CI is not happy, an mtest for instrument change fails, seee https://travis-ci.org/musescore/MuseScore/jobs/576225538#L4204-L4253, I doubt that this

   +            <lines>-1094795586</lines>

is intended?

@joshwd36

This comment has been minimized.

Copy link
Contributor Author

commented Aug 26, 2019

Travis CI is not happy, an mtest for instrument change fails, seee https://travis-ci.org/musescore/MuseScore/jobs/576225538#L4204-L4253, I doubt that this

   +            <lines>-1094795586</lines>

is intended?

Yes, I think that's an uninitialized memory bug. Hopefully should be fixed now.

@joshwd36 joshwd36 force-pushed the joshwd36:instrument-change-improvements branch from 9dc7cb0 to e936a39 Aug 26, 2019

@jthistle
Copy link
Contributor

left a comment

Ok, I was in the middle of a review when you force-pushed the last commit again (which of course changes its hash, so GitHub couldn't find it). That's no problem though; here are all the comments I managed to get down. It looks good, especially the addition of more comments.

if (instr && instr->isDifferentInstrument(*prevInstr)) {
ic->setupInstrument(instr);
}
InstrumentChange* nextIc = score()->nextInstrumentChange(segment(), part(), false);

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 26, 2019

Contributor

This variable isn't used. What reason is there for adding this line?

compiler warning:

libmscore/chordrest.cpp:569:43: warning: unused variable ‘nextIc’ [-Wunused-variable]
                         InstrumentChange* nextIc = score()->nextInstrumentChange(segment(), part(), false);

This comment has been minimized.

Copy link
@joshwd36

joshwd36 Aug 26, 2019

Author Contributor

Oh, that was from when I was trying something out, that didn't work. I've removed that now.

if (staff()->isTabStaff(Fraction(0,1)) )
tab = staff()->staffType(Fraction(0,1));
if (staff()->isTabStaff(tick()) )
tab = staff()->staffType(tick());

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 26, 2019

Contributor

This all looks good 👍

Interval oldV = part->instrument(tickStart)->transpose();
Interval currentV = part->instrument(tickStart)->transpose();
Interval oldV = part->instrument(prevTick)->transpose();
InstrumentChange* nextIc = score()->nextInstrumentChange(segment(), part, true);
//Instrument* oi = ic->instrument(); //part->instrument(tickStart);
//Instrument* instrument = new Instrument(Instrument::fromTemplate(it));

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 26, 2019

Contributor

These comments should probably be removed

{
int minTrack = part->staff(0)->idx() * VOICES;
int maxTrack = (part->staff(part->nstaves() - 1)->idx() + 1) * VOICES;
while (seg = seg->next1()) {

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 26, 2019

Contributor

The compiler suggests writing this as while ((seg = seg->next1())) instead because it's being used as a truth value. I'd make that change if I were you; I know how much @Jojo-Schmitz hates compiler warnings ;)

score->deleteItem(ic);
score()->endCmd();

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 26, 2019

Contributor

There's some weird indentation here. Also, tests are failing because score() doesn't exist in this scope. I think you mean score->startCmd() (without parentheses), because score is assigned a few lines above.

@jthistle
Copy link
Contributor

left a comment

mostly indentation problems, but somehow only in the test code

score->endCmd();
score->doLayout();
test_post(score, "add_before");
}

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 26, 2019

Contributor

The braces here (incl. the opening one) are indented badly.

ic->setXmlText("Instrument Oboe");
score->undo(new ChangeInstrument(ic, ic->instrument()));
ic->setInit(true);
ic->setupInstrument(new Instrument(*ni));

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 26, 2019

Contributor

Weird indentation here still

score->deleteItem(ic);
score->endCmd();

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 26, 2019

Contributor

Indentation's gone wrong here

@joshwd36

This comment has been minimized.

Copy link
Contributor Author

commented Aug 26, 2019

mostly indentation problems, but somehow only in the test code

Thank you, I think I've fixed all of those now. I'll push again once the tests have completed.

@joshwd36 joshwd36 force-pushed the joshwd36:instrument-change-improvements branch from 2ba50d6 to 0516253 Aug 26, 2019

@joshwd36 joshwd36 force-pushed the joshwd36:instrument-change-improvements branch 4 times, most recently from 9eb4a83 to e66c1c1 Aug 26, 2019

@joshwd36 joshwd36 force-pushed the joshwd36:instrument-change-improvements branch 3 times, most recently from baa0d54 to e0f0e46 Aug 26, 2019

@jthistle
Copy link
Contributor

left a comment

All looking good! The controller tags are interesting - it's not a problem here, but I'm wondering how they got there...

@@ -258,7 +258,8 @@ void InstrumentChange::write(XmlWriter& xml) const
case StaffGroup::PERCUSSION: xml.tag("staffGroup", "percussion"); break;
case StaffGroup::TAB: xml.tag("staffGroup", "tab"); break;
}
xml.tag("lines", _lines);
if (_lines != 5)
xml.tag("lines", _lines);

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 26, 2019

Contributor

good! 👍

This comment has been minimized.

Copy link
@Jojo-Schmitz

Jojo-Schmitz Aug 26, 2019

Contributor

Simpler: xml.tag("lines", _lines, 5);, no if needed (that is done inside xml.tag() if a 3rd arg is given)

This comment has been minimized.

Copy link
@joshwd36

joshwd36 Aug 26, 2019

Author Contributor

That's helpful, thank you

@@ -121,12 +121,14 @@
<gateTime>100</gateTime>
</Articulation>
<Channel name="open">
<controller ctrl="0" value="0"/>

This comment has been minimized.

Copy link
@jthistle

jthistle Aug 26, 2019

Contributor

Did you change any of the patches in the mixer, by any chance?

This comment has been minimized.

Copy link
@joshwd36

joshwd36 Aug 26, 2019

Author Contributor

I don't think so. I've tried to stay away from the mixer so unless I've inadvertently changed something, it shouldn't be something I've done.

@joshwd36 joshwd36 force-pushed the joshwd36:instrument-change-improvements branch from e0f0e46 to 443e35e Aug 26, 2019

joshwd36 added 2 commits Aug 26, 2019
@Jojo-Schmitz

This comment has been minimized.

Copy link
Contributor

commented Sep 17, 2019

A rebase is needed.

While at it, maybe you could also look at https://musescore.org/en/node/294595, which requests multimeasure rests not being interrupted it an instrument change happens at its first measure?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.