Why not add the lute functionality to 2.1 (especially bass courses)?

• Feb 14, 2017 - 09:58
Reported version
S5 - Suggestion

For me it is a little bit frustrating not to have the possibility to work on 13-course baroque lute (or other lutes with open bass strings) in a release version. As I see, that the 3-version still has much work, and it will last for at least some months (I fear even more), I want to try once again to get it into the 2.1-version, that will hopefully get released soon.

Don't you think it would be possible to include it?
In my work - and I have to do it with development versions, -which shouldn't be used for that @Jojo-Schmitz ;-) - ; but do I have another chance?
IMHO tablature with bourdons works quite well already, but still has some restrictions.

BTW - I think it is a little bit contradictory to have instruments in the instrument list that cannot be really handled by the program ... (even the 2.0.3 has these instruments in the list).


can you name the git commit(s) that added this to master?
Maybe those apply cleanly to 2.1 and don't introduce any backwards compatibility issue with 2.0 x

Probably it is this commit (July 2015): 8e0aeaa5790cdbe8c0a97bba54dcbf902e6b1a55

But I don't know, if it is the only one.
There is a later commit by MarcSabatella correcting something (August 2015): e8145a57fec5fefdbe236f350bc23e13bfd65b18

There seem to have been no further later commits relating directly to tablature ..., which might in this case be a good sign.

Thanks, so we're talking about 8e0aeaa and e8145a5.
The former modifies fonts, so would introduce a backwands compatibility issue when reading scores produced with these modifiications in a musescore version without them, so I believe it won't be possible for 2.1

As far as I see, the modification of the fonts only adds signs, further fonts and does not really change the old ones (beside the 10 -> X, which is not really a problem in my opinion) but does not change anything for earlier scores.

I never had any problems using the 6-course scores in the nightlies!

So this might be no problem at all - but I'm not sure, which commits already are in the 2.0.3.
How can I see that on the search page?

... oh I have found that (in the details it can be found) ...

Probably two more earlier commits would have to be included (they only had been commited to master, but I will look further):

I see, that there are some parents (commits that would have to be applied before?), that only are in master. Probably this is a real problem?

If the changes cannot be applied to 2.1. (and they are only half way, as it would be good to have the added fonts from commit c5bb238180cee67fba55187f567590f711e48de7 , which follows two other commits 6cab2d0f3bcb4e832aaabfa95bf281b2c452bdeb and d073c1feb67000504fec2535c7535315bbc61dfb ),
wouldn't it then be possible to have in not too far future a 3.0-beta, that at least gives a state, that we could reliable work with (without fearing the loss of given features)?

That commit mentioned further up changed the mscore_tab font
But even if it just added it, niehter the Addition nor the Change would be in and 2.0.x, so we'd see a back compat issue
a 3.0 beta would be something to consider a month or 2 before release, way ahead in the Futur, I'm affraid

Do I understand that correct: Every score made with 2.1 should be compatible with the 2.0.3 versions?
If so, that really is a problem.

But anyway I don't understand, why it must be that way.
The addition of bourdons is a new feature, that is essential for many lute types.
For sure, scores with that feature would be incompatible with versions before.
But why should someone use 2.0, if 2.1 is available?
And I don't think it would be a problem, if it would be announced that way.

The current state is really nonsatisfying, as the program is able to do lute tablatures with more than 6 courses, but it won't be possible in a release version for months, if not more than a year (how long that will take, noone knows).
Therefore, if it is possible in any way, I would strongly vote for adding this functionality.

BTW - if I load the files, that I made with the dev-versions, 2.0.3 will grump, that it was made with a newer version, but anyway loads them (without displaying the basses btw) after I press Ignore, without bigger problems ... (some problems in notation, but the basses of the lute are there, but only displayed if I use 13 lines ;-)).

yes, 2.x versions need to be compatible on both directions. Major Versions only Need to be compatible in one direction, newer versins should read older files. Older version reading newer files would lose information at the least (as you've seen) or not read at all (new tags in the file format are throwing MuseScore <=2.0.2 off track) or even crash

Lute tablature is confidential enough that we could add this feature in MuseScore 2.1 if someone wants to make a pull request, test it thoroughly and document the incompatibilities with 2.0.x (including the 10->x). I'm happy to review the PR but I'm not able to do it myself.

Someone to make a pull request?
Miwarre - who implemented this feature in August 2015, we are in 2017 :( - would be the most appropriate person I guess.
Unfortunately, he is absent (or has stopped any collaboration?) since nearly a year I think. A great handicap surely for the development of the tab section (and not only, far from there) of MuseScore.

It would be very fine, if someone could do the pull request (Jojo-Schmitz ?).

About Miwarre: His web site http://www.vistamare.com also seems to be not updated for months ...
I think he also has done the font for tablature. Therefore it would be good, if someone could get me in touch with him, as I have questions about it - or does someone else know, how they work?

I have made some tablature signs for baroque lute after the handwriting of Silvius Leopold Weiss, which could also be included ... But I here still have questions ... (To adapt the fonts/fonts_tablature.xml and the font itself shouldn't be too difficult, but I don't know, how the combinations of time flag and punctations are used and coded in work).

Unfortunately I don't know how to do a pull request, and fear that it would mean too much time to get everything to work for me (I don't have much time before the end of next week, and then only 6 days of vacancy).
But I can offer help to document the differences and also am willing help to test the new version!

How long will there be time to make these changes for 2.1?
Is it possible to do this in smaller steps, including the adjusted commits or should this be one big pull request?

I still don't know, if I could do it, but I have already made a fork (which was not at all complicated) and I also have some experience with git and some programming languages ...

Let this be a good reminder that finding new developers and standing by active developers is one of the most important aspects of further growing MuseScore. The entire MuseScore user community should be aware of this. Nothing happens by accident.

I'm very happy, that I could get in touch with Miwarre.
He will adapt his source files to include them to musescore 2.1!
I hope we have enough time for that.

Hi lasconic, unfortunately I didn't hear anything from miwarre for some time.
But I took your question as opportunity to write to him. If I won't hear anything from him, I will try to do that, although I'm sure, that this will be quite difficult for me, as my programming skills are not too good - often only trial and error ... (but anyway that would help me to understand the functionality and to be able to change some more things, that could be improved).
How long will there be time to include it?