Automatic Repeats Detection with Custom Endings

Sure, David, a clarification is due, the scenario you describe is absurd for me as much as it is for you :-).

So, my scenario is:
-) I find some interesting music that I like to learn/play on the Internet, normally in form of MIDI files;
-) I open it with MuseScore, then I simplify it and often adapt it to the one instrument (or a few) voice(s) I'm interested into (i.e., cut out many voices I'm not interested into), sometimes I transpose it if the original is too difficult for me;
-) then I print it down, and I can play it, and/or read it directly from the screen in MuseScore, etc......
Both when printed on paper, and when displayed on screen, if the notation gets more compact, I get happier, as I have to switch fewer times my hands between my instrument and the PC (or turn paper pages). So, automatic detection of repeating segments allows me to make the notation more compact easily and quickly (and I don't have to compare the segments note by note by myself in order to be really sure that the notes are exactly the same -- in my scenario, I don't know the piece so well to the point to realize whether there's any slight difference between the two repetitions -- so, while learning the piece, the automatic detection of repeats also makes it easier for me to realize that, hey, now I just have to repeat again this part I've already read).

Hope now it's clearer.

I just dropped a video showing the feature in action in a simple scenario at:
http://www.youtube.com/watch?v=JakubiKVrfg&feature=plcp

Various enhancements would be possible, but before trying them out, I'd like to see whether the patch can actually be merged.
Among the ideas that flood my mind:
-) the current patch has 2 parameters (see description above) that might be left tunable for the user through a dialog that pops up when you invoke the feature;
-) the dialog might contain a "scope" of the repeats search, i.e., the common case is for the user to actually provide a hint for the interval (e.g., a selection of measures) in which to search for repeating patterns;
-) the dialog might contain a few options, so as to consider or ignore various notation elements while searching (e.g., ignore notes velocity or embellishments possibly present in the measures, etc.);
-) given a score, the way you can "compress" it using repeats may not be unique, i.e., various possibilities would lead to different "compression ratio" (sorry for the computer science terms applied to music notation);
-) one possibility could be to search exhaustively for the "optimum compression solution", i.e., the one leading to the maximum savings in terms of overall score length;
-) another possibility might be to identify all the possible repeating patterns at once (out of which some might partially overlap or contain/be contained within each other), and allow the user to check them all, one after the other, deciding which one he/she wants to apply; for example, a dialog or dockable window might show the search results in terms of a list of found matches, then clicking on one of them the user gets a temporary preview of their effect on the score, then a button allows to apply the detected repeat(s) to the score or cancel the whole operation;
-) perhaps the algorithm might try to identify a third repetition with the "3." custom ending as well (but I'm not sure I've ever seen that in real scores, is that actually used in music ?);
-) last, but not least, the performance of the search may be largely improved (useful for very long scores / imported MIDI files).

I've just realized a sketch of the GUI behavior described above. This version of the patch finds all the repeating segments and presents them to the user via a dockable panel. Clicking on each found solution causes a highlight of the repeating segment as a selection, then one can apply/pick it or choose a different one from the list.

You can see how it works at:
http://www.youtube.com/watch?v=84nsUdm5zzE
The patch was already introduced in
http://www.youtube.com/watch?v=JakubiKVrfg&feature=plcp
The new GUI allows users to choose which one(s), among all the repeating segments that have been found in a score, have to be highlighted with the repeating bars notation, so the user can choose the one that suits best his/her own needs/tastes.

Hi, this sounds as a great news for me! After a quick walkthrough your CLA, I had (much to my regret, being this a hobby-ish thing) to burden my employer, and as the CLA here is mentioning explicitly Intellectual Properties, it seems it will have to go through our layers. I hope they'll provide the necessary clearance. A bit strange that, for this open-source project, it seems that contributing needs a step that is so formal. In many other open-source projects I've seen (including one where I've been contributing for years), it seems sufficient to drop into an e-mail a message like:

I hereby grant permission to licence my contributions to MuseScore under the Gnu General Public Licence.
Therefore, all contributions are to be considered free software; you can redistribute and/or modify them under the terms of the Gnu General Public Licence as published by the Free Software Foundation, version 2 or (at your option) any later version. These contributions are distributed in the hope that they will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

Having MuseScore itself a GPL license granting freedom of use for the software and source code, would you please detail what the CLA adds to that ?

Thanks.

Hi David,

thanks for your feedback on this feature. A couple of further comments and thoughts:
-) the highlight of the repetition via regular selection might be improved by adding the highlighting of the 2nd repetition as well (currently it selects and highlights only the first repetition), but with some different color; for example, a color for the 1st repetition, a color for the 2nd repetition, and a color for the custom ending parts.
-) the comment on the usability is very helpful. I realize myself that, at a first glance, it might discourage the use by occasional users, as it seems to present too complex information. Though, I was happy that this way of displaying things is very compact on the screen so that the dockable panel remains small. Perhaps one might keep both a compact and extended display mode, and allow users to switch among the 2 (via a preferences option)
-) being this a dockable panel, I guess the feature might be moved to the Display-> menu, taking your advice to not have it in the Edit menu, where far more frequent actions are included
-) apart from when you open a MIDI file, that remains my personal use-case, I'd find it useful in other cases as well, for example if you open a score and try to simplify it (e.g., extracting fewer voices, or simplifying the music so as to make it accessible to a beginner player, etc.); in such cases, the simplified version might happen to have repetitions that the original fully detailed version didn't have, because originally different measures might be now equal in their simplified form.

Finally, a technical issue I have with the "dockable panel" way of implementing it, is that, once I found the repetitions, these should be invalidated as soon as the user tries to edit the score, because he/she can edit without closing the auto-repeat-detection panel. It would be painful to update the panel in real-time as the user edits, because the user might do a number of different actions (modifying, inserting and deleting measures both within detected segments and before and after them). On the other hand, recomputing the detected repetitions at each editing action when the panel is open seems an overkill as well. What would you suggest, from a usability perspective ?

Thanks again.

Reading a bit the history and motivations about this CLA business, I came across a few points:

1) the CLA existence seems motivated from the need to put mscore on the Apple Store;
2) for example, vlc had to be removed from the Apple Store due to it being GPL;
3) vlc can still be installed on Apple devices, i.e., from Cydia;
4) developers may be very happy to voluntarily contribute with GPL code, but not so happy to sign this CLA.

So, my two questions constituting at the same time concrete proposals:

a) why don't you simply make MuseScore available through Cydia, for example ?
b) why don't you handle a separate branch for distributing MuseScore through the Apple Store ? so, you would have two branches, one including all the GPL contributions; the other one, including all the features and contributions whose developers signed the CLA as well.

Any comment is welcome, thanks.

> This ons still seems waiting on Thommaso to sign the CLA?

Hi all,

yes, basically I asked for clearance from my employer, but I don't have it yet.

On a related note, in the mean-time I tried to think a bit more to the situation, and my personal feeling is anyway the one that I would be enthusiastic to release the patch as GPL (and, with ICTs evolving to cloud computing and the like, I think something more appropriate should be seeked, actually), but in the end this CLA is really something that hurts my view and perception of open-source and free software, as I see it should be and it could work.

Probably I should have evaluated better the situation since the beginning, and I should have developed my toy as an independent application that parses MusicXML and writes it back as such. Anyway...