[WIP] Instrument change improvements #5128

joshwd36 · 2019-06-15T19:52:03Z

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.

mscore/palette.cpp

mscore/dragdrop.cpp

jthistle

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

mscore/dragdrop.cpp

mscore/palette.cpp

libmscore/instrchange.h

jthistle

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

Jojo-Schmitz · 2019-07-09T19:16:44Z

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 · 2019-07-09T19:22:52Z

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.

Jojo-Schmitz · 2019-07-11T07:00:32Z

2 mtest failures actually crashes: https://travis-ci.org/musescore/MuseScore/jobs/556958555#L4166-L4189 and https://travis-ci.org/musescore/MuseScore/jobs/556958555#L4270-L4348

jthistle

Some more comments :)

libmscore/edit.cpp

libmscore/instrchange.cpp

mscore/propertymenu.cpp

jthistle · 2019-07-28T09:37:52Z

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

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
Changing the instrument of an existing change updates both the key sig and clef

Things that... aren't so good

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.
If I change the instrument of an existing instrument change, the warning text is not updated with the new text instrument's name.
If I delete an instrument change immediately after another, the key signature, although correct, remains as a duplicate of the last one
If I add an instrument change exactly where the instrument enters, there is still warning text
When I create an instrument change, then manually delete its clef and key signature, and then delete the instrument change, there is a segfault
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 · 2019-07-28T09:56:49Z

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.

jthistle

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.
There's some weird stuff going on with key sigs. I'm not entirely sure how I got it into this state, sorry:
Here is an example of another problem related to the above:

jthistle · 2019-08-10T18:44:09Z

libmscore/chordrest.cpp

@@ -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()) {


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?

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.

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.

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

jthistle · 2019-08-10T18:46:19Z

libmscore/clef.cpp

@@ -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")


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

jthistle · 2019-08-11T07:43:03Z

libmscore/edit.cpp

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


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.

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

jthistle · 2019-08-11T07:44:30Z

libmscore/edit.cpp

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


jthistle · 2019-08-11T07:45:12Z

libmscore/edit.cpp

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


Why this change?

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.

And deleteItem makes use of undoable functions?

jthistle · 2019-08-11T07:57:24Z

libmscore/instrchange.cpp

@@ -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();


See above - do we really need to write it?

jthistle · 2019-08-11T07:58:41Z

libmscore/instrchange.h

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


Nice, I had forgotten completely about translations.

jthistle · 2019-08-11T08:02:53Z

libmscore/instrument.cpp

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


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

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

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.

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.

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

jthistle · 2019-08-11T08:05:53Z

mscore/inspector/inspectorInstrchange.cpp

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


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

jthistle · 2019-08-11T08:08:04Z

mscore/propertymenu.cpp

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


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

jthistle · 2019-08-21T16:44:08Z

Here's a nice crash I found:

Seems to be originating from setupInstrument...

jthistle

Looking very good! Just a few comments.

jthistle · 2019-08-23T08:23:24Z

libmscore/instrument.h

+      StaffGroup staffGroup()                                { return _staffGroup; }
+      void setLines(int lines)                               { _lines = lines; }
+      const int lines() const                                { return _lines; }
+      int lines()                                            { return _lines; }


This should be int lines() const, since we're not modifying any values of Instrument.

jthistle · 2019-08-23T08:34:35Z

libmscore/instrument.h

@@ -292,6 +294,12 @@ class Instrument {
      QString instrumentId()                                 { return _instrumentId; }
      void setInstrumentId(const QString& instrumentId)      { _instrumentId = instrumentId; }

+      void setStaffGroup(const StaffGroup staffGroup)        { _staffGroup = staffGroup; }
+      const StaffGroup staffGroup() const                    { return _staffGroup; }
+      StaffGroup staffGroup()                                { return _staffGroup; }


As above, StaffGroup staffGroup() const is better.

Also, const StaffGroup staffGroup() const and the similar one for lines cause compiler warnings for me. When the keyword const comes after a declaration, it means that the function itself is const - as in, the function cannot change the value of any members of the class. This is good, because for a simple getter, we don't want anything to be modified.

When const comes before, however, it's referring to the return type. So, saying const StaffGroup tells the compiler that this function will return a StaffGroup with an unchangeable value. Except, it doesn't.

IIRC, the const keyword for types can only be applied to pointers or references. For a copyable type like StaffGroup, const StaffGroup doesn't make sense - there are no side effects if you change the value of a StaffGroup, so why care if it's const? However, with references and pointers, there is the side effect of changing the original value that the pointer/reference was created from. So, const StaffGroup* or const StaffGroup& both make sense and would be fine.

That said, you have a couple of options to avoid the compiler warning:

make both the functions (const and non-const) return const StaffGroup&. This speeds up execution, since you're not copying the value of _staffGroup around (references are just pointers but better), and _staffGroup cannot be changed by changing that object, because it has the const qualifier.

remove the first const qualifier from const StaffGroup staffGroup() const

Everything I've just said about _staffGroup also applies for _lines.

Thank you, that makes a lot more sense. I think at that point I was just copying the format from other getter/setters, but I must have been copying from a pointer one. I've changed them all to making them non-const. I think returning const StaffGroup* wouldn't work, as you shouldn't return pointers to non-heap allocated objects or local variables, as they may be deleted before accessing them, leading to use after free errors.

That's true, a pointer wouldn't be suitable. AFAIK a reference would though, although in this case it's pretty much negligable because it's such a small object.

I don't think the reference would work either, as under the hood references are just pointers, just const and non-null, and with automatically dereferencing

jthistle · 2019-08-23T08:55:03Z

libmscore/instrument.cpp

+      switch (_staffGroup) {
+            case StaffGroup::PERCUSSION: xml.tag("staffGroup", 1); break;
+            case StaffGroup::TAB: xml.tag("staffGroup", 2); break;
+            }


Although there are exceptions, we prefer words, e.g.:

case StaffGroup::PERCUSSION: xml.tag("staffGroup", "percussion"); break case StaffGroup::PERCUSSION: xml.tag("staffGroup", "tab"); break

For this, you could invest in a couple of helper functions similar to Dynamic::speedToName and Dynamic::nameToSpeed. Or you could do the quicker thing, which is hardcoding it. Your choice.

OK, I will do that instead. I'll probably stick with hardcoding for now, as there would only need to be 2 options (with standard being the default), and it's unlikely that there'll ever be more.

jthistle · 2019-08-23T08:58:05Z

libmscore/utils.cpp

@@ -1051,7 +1051,7 @@ Chord* Score::nextChord(Segment* seg, const Part* part, bool lookForIc)
                        }
                  }
            seg = seg->next1();
-            if (lookForIc) {
+            if (lookForIc && seg) {


This is the fix for the crash, I guess? Nice 👍

jthistle · 2019-08-23T09:37:17Z

Bugs and things

I don't know if this is quite right... should the key change come before or after the clef change?

Undoing staff type changes is broken. Just try it, and you'll see the effects.

No change to treble clef here, where there should be.

I can't add notes when change instrument after being in a drumset. Repro:

create a score with a drumset
add an instrument change to voice at some point
try to add notes after it

Expected: I can add notes

Actual: I cannot add notes (this seems to be related to the fact that, with drumsets, you must select notes from a kind of palette of notes). Sometimes, adding notes segfaults.

Deleting an instrument change that changes key does not make another one ahead of it, which should change key, change the key instead. See this video:

That's what I've found so far. The general operation of instrument changes (that is, without staff changes) seems to be working great! Undo is working well, I can copy and paste stuff everywhere without corruption (well, mostly), and the sounds change perfectly.

joshwd36 · 2019-08-23T10:04:46Z

Thank you for this. I'm aware of a lot of the bugs related to percussion and tab changes, and I'll try and get them fixed today. I'm already aware of the problem with clefs and key signatures halfway through a bar, although that's not a problem with instrument changes specifically (try adding a clef and key change to the same point, in any order), but I'll see if I can work out why that happens if I have time. That fix could probably go in a different PR though, since it is an independent problem.

…ge is deleted

…t change warning have the same style as instrument changes

…nters between them and instrument changes

…the instrument change warning should be shown or not

…t text

…oshwd36/MuseScore into instrument-change-improvements

Jojo-Schmitz · 2019-10-31T12:58:53Z

That last commit should not be there, don't merge, but rebase.
Also Travis CI isn't happy, but that doesn't seem to be your fault, looks like a timeout

joshwd36 · 2019-10-31T13:00:59Z

I tried to do a rebase, but there were merge conflicts between master and my branch. What would be the correct way to resolve those without a merge?

Jojo-Schmitz · 2019-10-31T13:55:10Z

Here's how OI usually do it: git pull --rebase MuseScore master, fix conflict(s), git add the fixed file(s), git rebase --continue, git push -f

dmitrio95 · 2019-11-12T08:49:12Z

@joshwd36 could you please do a rebase of your branch? Currently Github shows changes in 423 files and 438 commits in this PR which makes it not very convenient to review the actual changes.

Jojo-Schmitz · 2019-11-12T08:50:42Z

So not just rebase, but also squash?

Oh, I see, there are many commits in here that just don't belong there, apparently the result of a merge commit (cdf03ae) rather than a rebase.
Try git pull --rebase musescore master; git push -f (if "musescore" is the name of your "upstream")

shoogle · 2019-11-14T00:43:47Z

@joshwd36, best make another copy of this branch as backup before you do anything else.

git checkout instrument-change-improvements
git checkout -b instrument-change-improvements-backup
git push origin instrument-change-improvements-backup

Then ideally you would undo that merge commit somehow, get everything back how it was before, and then do a rebase instead of a merge.

If that's not possible then I would start again creating a new branch from the latest master, and cherry-pick your commits into the new new branch one-by-one, using the commit SHA's from this page.

git checkout master
git pull upstream master
git checkout -b try-again
git cherry-pick 1db0960ac # Adding instrument changes to a score automatically shows…
git cherry-pick 525e17887 # Fix adding objects to multiple staves through selection
git cherry-pick d6c3c36d3 # etc.
...

Lesson for the future: never use git merge except on the master branch. On all other branches you should use git rebase.

dmitrio95 · 2019-11-27T10:27:10Z

I have also tested this PR some time ago, and while most of changes are really useful improvements, the "warning text" feature (which places a special warning element when the changed instrument actually starts having any notes) doesn't seem to perform well with linked parts and has a number of other issues (for example, deleting the warning text is not synchronized with "show warning text" property, changes to warning text properties get reset when user clicks on the corresponding instrument change element). If this feature could be split out to a separate PR to make it possible to fix the issues with it separately it would be especially good as the rest of the project could be merged much sooner.

Otherwise I could try picking and merging the relevant changes from this branch manually. However this might make further rebasing more difficult so please let me know if you are planning to split or rebase this PR.

dmitrio95 · 2020-03-03T13:48:57Z

See #5782 with certain features from this pull request rebased to current master.

dmitrio95 · 2020-03-10T08:57:04Z

Replaced by #5782

dmitrio95 added the GSoC PRs created by GSoC participants during coding period label Jun 15, 2019

Jojo-Schmitz reviewed Jun 16, 2019

View reviewed changes

mscore/palette.cpp Outdated Show resolved Hide resolved

Jojo-Schmitz reviewed Jun 16, 2019

View reviewed changes

mscore/dragdrop.cpp Outdated Show resolved Hide resolved

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

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

jthistle reviewed Jun 18, 2019

View reviewed changes

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 force-pushed the instrument-change-improvements branch 3 times, most recently from 6424ed4 to 0d3c0a9 Compare June 26, 2019 17:12

joshwd36 force-pushed the instrument-change-improvements branch from 0d3c0a9 to 429b54d Compare July 7, 2019 12:02

jthistle reviewed Jul 9, 2019

View reviewed changes

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

joshwd36 force-pushed the instrument-change-improvements branch from 429b54d to e09317c Compare July 10, 2019 19:29

jthistle reviewed Jul 12, 2019

View reviewed changes

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 force-pushed the instrument-change-improvements branch from e09317c to a61b376 Compare July 13, 2019 21:20

joshwd36 force-pushed the instrument-change-improvements branch from b4c0929 to e2b0799 Compare August 1, 2019 16:08

jthistle reviewed Aug 11, 2019

View reviewed changes

joshwd36 force-pushed the instrument-change-improvements branch 2 times, most recently from cc7c997 to fcfe0aa Compare August 20, 2019 22:30

joshwd36 force-pushed the instrument-change-improvements branch 2 times, most recently from af47c61 to 328b76b Compare August 22, 2019 23:13

jthistle reviewed Aug 23, 2019

View reviewed changes

joshwd36 added 18 commits October 31, 2019 01:17

Add new file to CMakeLists

1f9c96a

Automatically move instrument change warning when first note in passa…

501f8f4

…ge is deleted

Fix moving instrument change when note is deleted, and make instrumen…

20f5bb0

…t change warning have the same style as instrument changes

Change structure of warnings, key signatures, and clefs to remove poi…

1ed8fff

…nters between them and instrument changes

Add checkbox to instrument change inspector panel to specify whether …

b1bd4c7

…the instrument change warning should be shown or not

Fix problems with instrument change warnings changing to the incorrec…

a3ccb13

…t text

Basic implementation for changing to unpitched percussion

31c12b2

Improve stability of unpitched percussion changes

6a10b5d

More fixes for changing to different staff types (undo still broken)

63943f4

More bug fixes for instrument changes to percussion instruments

f19ac07

Fix bugs and add new test

a16a075

Fix small bugs

02c9855

Add another test

3578316

Add another test, and fix previous test

7d02e35

Add two more tests

2ff9869

Fix warning 2 test

668f095

Simplify xml tag for lines

162fd46

Merge branch 'instrument-change-improvements' of https://github.com/j…

cdf03ae

…oshwd36/MuseScore into instrument-change-improvements

dmitrio95 mentioned this pull request Mar 3, 2020

[GSoC 2019] Instrument change improvements #5782

Merged

dmitrio95 added the archived PRs that have gone stale but could potentially be revived in the future label Mar 10, 2020

dmitrio95 closed this Mar 10, 2020

[WIP] Instrument change improvements #5128

[WIP] Instrument change improvements #5128

Conversation

joshwd36 commented Jun 15, 2019 • edited

jthistle left a comment

Choose a reason for hiding this comment

jthistle left a comment

Choose a reason for hiding this comment

Jojo-Schmitz commented Jul 9, 2019 • edited

joshwd36 commented Jul 9, 2019

Jojo-Schmitz commented Jul 11, 2019

jthistle left a comment

Choose a reason for hiding this comment

jthistle commented Jul 28, 2019 • edited

Things that are good

Things that... aren't so good

joshwd36 commented Jul 28, 2019

jthistle left a comment

Choose a reason for hiding this comment

Bugs found during testing

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jthistle Aug 11, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jthistle commented Aug 21, 2019 • edited

jthistle left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jthistle Aug 23, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jthistle Aug 23, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jthistle commented Aug 23, 2019 • edited

Bugs and things

joshwd36 commented Aug 23, 2019

Jojo-Schmitz commented Oct 31, 2019

joshwd36 commented Oct 31, 2019

Jojo-Schmitz commented Oct 31, 2019 • edited

dmitrio95 commented Nov 12, 2019

Jojo-Schmitz commented Nov 12, 2019 • edited

shoogle commented Nov 14, 2019

dmitrio95 commented Nov 27, 2019

dmitrio95 commented Mar 3, 2020

dmitrio95 commented Mar 10, 2020

joshwd36 commented Jun 15, 2019 •

edited

Jojo-Schmitz commented Jul 9, 2019 •

edited

jthistle commented Jul 28, 2019 •

edited

jthistle Aug 11, 2019 •

edited

jthistle commented Aug 21, 2019 •

edited

jthistle Aug 23, 2019 •

edited

jthistle Aug 23, 2019 •

edited

jthistle commented Aug 23, 2019 •

edited

Jojo-Schmitz commented Oct 31, 2019 •

edited

Jojo-Schmitz commented Nov 12, 2019 •

edited