MULTIPLE IDEAS OF IMPROVING MUSESCORE 3:

So here we go again; cross-topic argumentation of whichever and whatever. At least you've changed your initial reply to something more based on reason and as such I'll once again reply to your points. Maybe one day you'll be bothered enough to actually read the response and take it to heart. Who know, perhaps even reply with the relevant answers to questions posed?

> 1. Why does MS deletes the first 3 lines and not the last 3 staff-lines?
Because it was programmed this way.
> Simply because it actually wrongly numbers the staff lines.
As you've been informed many times, internal staff line numbering is irrelevant to your purpose.
> Besides that, why doesn’t MS let the user to choose which line he wants to preserve? (rhetorical question: because MS is still primitive in many ways). It is surely a minus of MS the fact that it doesn’t allow the user the choose what staff-lines he chooses to preserve (when choosing a staff with less than 5 lines).
Now that we all agree on. This is a good feature request! So go ahead and add it to the issue tracker as a suggestion.

> 2. It is clear from my first thread that Sabatella didn't know about the bottom-to-up line numbering. Don't try to defense him: it is useless and unconvincing for me (besides it is essentially and generally unethical to hide the truth)! Time already proved that sad truth.
Apparently you still haven't read the replies to your first thread; nor the ones I gave you in your recommendations thread. So I have no real hopes that you'll read this one either.
But in your original thread Marc agrees that the different line numbering makes sense. It's just that as a programmer we are very much aware that the way line numbering is presented to the user can be detached from how it is presented internally in the data model.

> 3. My LeadMuse and PMS articles are in fact thesis-like paper and explain ALL the advantages of PMS: [...] You may be sure that I can transform any score into a PMS-based one.
I personally see the possibilities in your PMS system, contrary to some of the other "new" notation systems that have come along here in the past years.
There is educational value in the positioning simplicity it gives.

> 4. [...]The fact that I’m not a native English speaker thus DIDN’T stop in anyway for my papers to be read daily worldwide. I have more than 10-20 reads totally worldwide on all my scientific papers.
Fair enough; we'll no longer comment on how your tone comes across.

> 5. With specialized software, the rework of any score written in xml wouldn't be a problem and that software would be a batch converter, converting hundreds of files once to this PMS-based format.
But MuseScore isn't PMS-specialized software. Again, I'm not saying that it can't facilitate this task (especially given it already having a batch converter plugin). But we won't break parts of standard notation to support PMS. If the feature to be able to choose which stafflines remain (thus which pitch they should represent), then I believe your major roadblock to be cleared?

> 6. For the new generations, [...] (because one doesn't need to learn new clefs).
This is just what you wrote in point 3, so see my reply there.
Additionally, in my LeadMuse I’ve even proposed the integration of alteration signs in the shape of noteheads so that one may also abandon all key signatures in my PMS and simplify even more the musical notation.
This might make it more difficult for programs that support standard notation and adhere to the SMuFL standard to display your notation. Although you can probably use a plugin to mark the normal noteheads invisible and attach your images on top of them..

> 7. You may be sure that this is my last reply to you (already given you much undeserved time with apparently no use: sadly, I didn’t manage to surpass your vanity!): with the hope that I've somehow stretched your narrow views.
Two more things:
First: someone who doesn't agree with your views isn't automatically vain or narrow minded; they might just have a different opinion.
Second: This isn't the first "last time" post of you stating how you've been wasting time. I truly hope that next time you decide you wish to waste time here, you'll do so actually reading the answers given to you and responding to the points and counter questions that matter (which means, not the personal attacks, if you so experience them).

I am choosing to ignore your personal insults and will also choose to do you the honor of not responding in kind.

However, I'm still hoping to see a single, concise, and clear example of the problem. I have limited spare time as well. A simple short paragraph with a sample score and precise steps for me to follow - would take about five minutes to write up, tops, certainly far less than the time spent thus far, would help immensely more.

The best I can tell is the issue is, again not related even the slightest bit to the question of internal line numbers. The issue as I can best understand it absent a simple, concise, and clear example is, a two line staff with treble clef currently uses those two lines for D4 & F4. This suits the purposes of some custom non-standard notations just fine. But for your particular custom non-standard notation, it would suit you better if a two-line treble clef staff used those two lines for E & G. It would save you the trouble of needing to use the "Fix to line" setting in the Inspector (which would actually solve the problem for you for now).

If this understanding is correct, then all that is needed is a simple setting in the staff properties to control this. No rewrite of the internal line numbering data structures, just a simple spin box to add to the dialog and then factor in, so the user has control over this.

To some extent this is already possible using the staff type change element instead of staff/part properties. but, it does not behave as one might want for this particular special purpose with respect to clef position or ledger lines. Again, probably the current behavior makes sense for some particular unusual non-standard use case, just not this particular unusual non-standard use case.

If you would care to spend a few minutes writing up that simple request in the issue tracker as a suggestion - no need to add a lot of extra information, it's a simple enough request and doesn't require reference to a thesis to explain - then we can finally begin the process of considering and perhaps implementing this request.

If you can do so without further personal insults, that would greatly expedite the process.

Dear "Dr"

It may interest you to know that I have some experience in the medical publishing world. I picked at total random one of the journals you publish in. It came up in a Google search. GS Journal .net. This journal claims to be peer reviewed. Not true. Actual peer review means that an author submits a paper. The publisher then sends this paper to other experts in the field. if enough experts find the paper credible the paper goes to a copy editor to have the English corrected and the paper is published. The GS Journal publishes your papers and and then other people write reviews. Not the same. The journals you publish in doubtless can afford a copy editor, so you have no idea how poor your English is. So please, stop already with the superior act.