Realize the basic functions of Jianpu #19421

Auase · 2023-09-16T19:24:09Z

Resolves: #NNNNN

I signed the CLA
The title of the PR describes the problem it addresses
Each commit's message describes its purpose and effects, and references the issue it resolves
If changes are extensive, there is a sequence of easily reviewable commits
The code in the PR follows the coding rules
There are no unnecessary changes
The code compiles and runs on my machine, preferably after each commit individually
I created a unit test or vtest to verify the changes I made (if applicable)

Auase · 2023-09-16T20:16:26Z

Add a font file (to prevent unknown errors, fonts are added based on Leland text characters), which is only the basic function of Jianpu. There are still some layout issues to be addressed, but I am a bit tired. I will handle them later. If anyone is interested or has time, please help improve it. One person's power is too small.(All changed codes can be found by searching for the keyword "jianpu")
This time the issue mentioned here is solved:https://github.com/musescore/MuseScore/pull/19395（I don’t know why I get 404 when I click directly. If I copy the link and open it in a new tab, the page can be opened normally.）

ss.gp3.2023-09-17.03-43-47.mp4

Auase · 2023-09-23T13:34:31Z

@cbjeukendrup
The problems mentioned earlier are solved. Because the layout and display of Jianpu is completely different from other musical scores, it is inevitable that it cannot pass some automatic checks.

cbjeukendrup · 2023-09-24T12:04:20Z

@Auase Thanks! I'll re-review the changes as soon as possible, but I'm very busy these days so it might take a while. Sorry!

Auase · 2023-09-24T15:09:59Z

@cbjeukendrup
Okay, thank you. My English is not very good, please don't pay too much attention to the English grammar in my comments.

Tantacrul · 2023-09-27T19:20:40Z

I'd be happy to take a look at this from a product design point of view. Is it ready for a review?

Auase · 2023-09-28T16:12:43Z

Yes, thank you @Tantacrul
For layout and style, please refer to Guitar Pro (versions after 8.1 have this function)

cbjeukendrup

Some more comments! This PR will probably require a few more iterations before it is ready to be merged, but don't worry about that; that's always the case with big new things. So, even though code review comments might sometimes come across as a bit strict, never forget that we appreciate your work very much!

cbjeukendrup · 2023-10-01T02:31:27Z

share/locale/musescore_zh_CN.ts

Editing these files is fine, but not very effective, since for release builds they are overwritten with the latest translations from Transifex. So, once this PR gets merged and the 4.2 strings are pushed to Transifex, you can add the translation there: https://app.transifex.com/musescore/musescore/dashboard/

cbjeukendrup · 2023-10-01T02:32:08Z

fonts/jianpu/Jianpu.fcp

What kind of file is this?

cbjeukendrup · 2023-10-01T02:34:17Z

src/engraving/dom/lyrics.cpp

@@ -171,6 +171,14 @@ void Lyrics::layout2(int nAbove)
    LayoutData* ldata = mutLayoutData();
    double lh = lineSpacing() * style().styleD(Sid::lyricsLineHeight);

+    if (staffType() && staffType()->isJianpu()) {
+        double yo = segment()->measure()->system()->staff(staffIdx())->bbox().height();
+        placeBelow();


This function call has no effect; placeBelow does nothing, but only returns whether the placement should be "below". (But yes, the name is a bit confusing.)
You can just remove this line.

cbjeukendrup · 2023-10-01T02:35:59Z

src/engraving/dom/staff.cpp

@@ -104,6 +104,10 @@ staff_idx_t Staff::idx() const

 void Staff::triggerLayout() const
 {
+    if (staffType() && staffType()->isJianpu()) {
+        score()->style().set(Sid::MusicalSymbolFont, "Jianpu");


This is not good; you're changing a score-wide style setting here. During the layout process, no style settings should be changed.

Did you implement it this way because the Jianpu font is currently a copy of Leland with some symbols added? But that means that if you have a score that uses a different font, and you add a Jianpu staff, it will suddenly change to Leland (well, the Jianpu copy of Leland).

I think the Jianpu font should only contain Jianpu characters, and the rest of the score should keep using whatever font it was using; for example, the original Leland.

However, we'll need to think about a good way to keep Jianpu properly separated from SMuFL, while also being able to reuse MuseScore's existing symbol drawing logic. For example, the logic around SymId is indeed quite nice to use. Perhaps we can generalise EngravingFont a bit, so that it can have multiple "subfonts": one for SMuFL symbols, one for Jianpu symbols. Actually, a bit like you're already doing, but a bit more generalised and cleaned up.
@igorkorsukov You doubtlessly have some interesting thoughts about this; could you help us with some ideas here?

@cbjeukendrup I agree with you!

I think we need to add a new style parameter something like JianpuFont
And get the font implementation by Sid or staff type

that is, we need to do something like this:

generalise EngravingFont (and maybe add type to EngravingFontsProvider::addFont, see enum Font::Type)

remove Score::m_engravingFont

change Score:engravingFont() to two methods: Score:engravingFont(Sid ) and Score:engravingFont(const StaffType* )

try compile, fix all code where use Score:engravingFont (change LayoutConfiguration::engravingFont)

I don't think we should have `engravingFont(StaffType*)’. It's not that different staff types should use different fonts. It's that the different staff type uses different symbols at different codepoints, that are not part of the SMuFL spec. That's why we can't use SmuFL fonts for that so we need to combine a SMuFL font with a Jianpu font preferably in one structure (like EngravingFont) so that we can reuse our SymId and symBbox logic etc. The question is how exactly that should work though. Especially since would ideally want the user to be able to choose any text font as their Jianpu font, but for text fonts there is of course no metadata file with bbox info, so we need to compute that info ourselves.

Actually, since Jianpu characters are just text, we should maybe just use plain strings to represent the symbols and FontMetrics to get the metrics. (Of course, we can use named constants for each Jianpu character instead of writing string literals everywhere.)
How do we feel about that idea?

I like your idea.
I'm thinking about how this task is related to the display of Tablatures, it also has its own font...
I also think that this task is rather infrastructural and has little to do with the current PR (that is, we need to improve the font system as general). Therefore, I would prefer that this PR be done as desired, the just working..., and then the system fonts need to be improved separately.

cbjeukendrup · 2023-10-01T02:43:24Z

src/framework/fonts/fonts_Smufl.qrc

@@ -3,5 +3,8 @@
    <file alias="fonts/smufl/classes.json">../../../fonts/smufl/classes.json</file>
    <file alias="fonts/smufl/ranges.json">../../../fonts/smufl/ranges.json</file>
    <file alias="fonts/smufl/glyphnames.json">../../../fonts/smufl/glyphnames.json</file>
+
+    <!--Because MODULE_QRC cannot import multiple qrc, it can only be imported here.-->


Actually I don't see why using multiple qrc files in MODULE_QRC would not work; for MODULE_BIG_QRC it apparently works too. Have you tried it, and what kind of problems did you get?

cbjeukendrup · 2023-10-01T02:44:51Z

src/framework/fonts/fontsmodule.cpp

@@ -34,7 +34,7 @@ static void init_fonts_qrc()
    Q_INIT_RESOURCE(fonts_FreeSans);
    Q_INIT_RESOURCE(fonts_FreeSerif);
    Q_INIT_RESOURCE(fonts_Gootville);
-    Q_INIT_RESOURCE(fonts_Leland);
+    Q_INIT_RESOURCE(fonts_Jianpu);


(Note to other reviewers: Leland is already listed a few lines higher too)

cbjeukendrup · 2023-10-01T03:02:11Z

src/engraving/dom/stafftype.h

@@ -415,6 +415,9 @@ class StaffType
    mu::PointF chordStemPosBeam(const Chord*) const;
    double   chordStemLength(const Chord*) const;

+    //    Check lines() == 0 to prevent conflicts when there are multiple staff;
+    bool isJianpu() const { return (name() == "Jianpu" && lines() == 0) || (xmlName() == "stdJianpu" && lines() == 0); }


Wouldn't it be possible to create a new StaffGroup::JIANPU, so that we can implement this method more similar to isTabStaff() and isDrumStaff()? I think that would also allow us to not worry about properties that are not relevant to Jianpu like number of staff lines, so that we can just ignore the values of these properties.

cbjeukendrup · 2023-10-01T03:11:05Z

src/engraving/rendering/dev/slurtielayout.cpp

+        double symWidth = item->symWidth(SymId::keysigJianpuDo);
+        double symHeight = item->symHeight(SymId::keysigJianpuDo);


In situations like this, it's more efficient to call symBbox once, and then get the width and height from that rectangle. That's more efficient because symWidth and symHeight both call symBbox internally, so if you call both of them separately, the bbox calculation has to be done twice, which is a bit expensive.

cbjeukendrup · 2023-10-01T03:16:06Z

src/engraving/rendering/dev/beamlayout.cpp

There are still quite some "magic numbers" in this file (and some other files), of which the meaning is unclear... at least adding comments and/or named constants would be good. But in some cases, you should perhaps create a special style setting dedicated to Jianpu. For example, you have double lw2 = item->beamWidth() / 6.0;. In my opinion, taking 1/6 of the width of a normal beam is a somewhat random thing to do. I'd just create new style parameter for Jianpu beam width, instead of basing it on normal beam width while there is not a very direct relation between those two values.

cbjeukendrup · 2023-10-01T03:22:01Z

src/engraving/rendering/dev/beamlayout.cpp

+            double symHeight = item->symHeight(SymId::keysigJianpuDo);
+            double lw2 = item->beamWidth() / 6.0;
+            for (const BeamSegment* bs : item->beamSegments()) {
+                double y1 = bs->line.y1() / 1.65 + symHeight / 2.55;


Another one... if you have to divide by 2.55, that looks to me like there should actually not be a direct relation between the height of that symbol and the value you want to calculate here. Instead, you could base the value on the overall size of items in the score (i.e. spatium), or create a style setting for it.

(regarding style settings: I mean those parameters that can be accessed using keys from the Sid enum. Not all of them are (currently) exposed as an actual style setting in the UI, but the Sid system is useful for forcing yourself to use named constants, and makes it easy to make certain values still customisable in the future.)

Tantacrul · 2023-10-01T10:35:50Z

@Auase - I've been looking over this and have a few comments.

First, if I understand correctly, you have created a new font specifically for Jianpu? If so, think it would make more sense to put them in Leland, since there aren't that many unique symbols - and we'd then be able to gradually improve the engraving and not be left with a new font that works by different rules.

In order for that to happen, you'll need to send your font to @oktophonie and me so that we can have a look over it. I would also like to ensure that there is some consistency in the quality of the engraving.

Secondly, there appears to be quite a few issues with placement / clashing elements.

When I enter two notes, Jianpu places them in the same position, instead of arranging them vertically.

When applying it to piano, the bar lines are very tall, intersecting the title and not corresponding to how Jianpy should look

The accidental placement is not ideal. They appear to be too small and positioned too closely to the numbers

I'm aware of a few variations for accidental placement with Jianpu but accidentals seem to either be centred:

Or if they are positioned higher, they are larger for legibility:

Here's the Guitar Pro version:

Again, I think out engraving team, and myself should be helping out here.

I also notice that grace notes are not yet represented in Jianpu. Is that something you are planning to do?

For example, this:

Currently looks like this:

Tantacrul · 2023-10-01T11:05:29Z

@Auase

Just to summarise, I'm very excited about the idea of supporting Jianpu and I'll be happy to help by incorporating the correct symbols into Leland / Leland Text (I'm one of the two creators of Leland by the way).

I would also like to make sure that everything about it has a high level of quality, while @cbjeukendrup helps on the implementation side.

To begin, I would like to know what your intended goal is for this first implementation? Is it to provide the same level of support as Guitar Pro 8.1? In other words, single-line Jianpu only?

yuki0035 · 2023-10-01T14:58:39Z

I'm very glad to hear the idea of supporting Jianpu in MuseScore. I think single-line Jianpu would be fine at the beginning since multi-voices is not the advantage of Jianpu notation. And the situation for multi-voices is quite complicated if using Jianpu.

PMPH (People's Music Publishing House) once published a guidebook for Jianpu. In the multi-voices section, it was divided into two different methods: ① side by side; ② primary and subordinate ( mostly for melody ). Both of them are reduced certain font size. See below:
① side by side:

② primary and subordinate

The accidentals is placed higher but legible enough, and the size of accidentals doesn't reduce in multi-voices:

And here's the grace note in the guidebook:

As the font style of the notes ( number 0 ~ 7 ), I suggest using a specific type of sans-serif font would be nice. Because it is more legible as printed.

Here are two jianpu fonts and both of them are free to download and use.

Tantacrul · 2023-10-01T15:24:55Z

@yuki0035 - thanks for this!

One thing I'm pretty certain about is that we shouldn't use the time signature numbers from Leland for this but should actually just use regular numeral unicodes, so any font can be chosen.

Of course, we'll pick a house style so it looks really nice by default.

Auase · 2023-10-01T16:07:02Z

@Tantacrul
The purpose of Jianpu is to simplify musical notation and make it easier for people with no musical foundation to get started. It does not require a specific instrument or even a musical instrument. Many aspects of playing technique can be discarded in Jianpu's music score. As for what style of font to use, I think any regular style that can be clearly distinguished is fine. If Leland can provide support, it would be best to use Leland's style (the font currently used is copied from Edwin-Bold). What Jianpu lacks now is not a certain font style, but support for range codes.

Auase · 2023-10-01T16:14:20Z

@Tantacrul
Thank you, I really hope to get the support of Leland, there are not many characters that really need to be added, just adding the uppercase letters ABCDEFG and the number 0123456789 in Leland is enough.

Auase · 2023-10-01T16:22:28Z

My goal is to have basically the same level of support as Guitar Pro 8.1, but there is no need to support multiple notes at the same position and some complex playing techniques, because when you really use Jianpu, you don't need these, because these complex things are not Jianpu can be expressed.

Auase · 2023-10-01T16:27:38Z

There are only so many characters that I currently use that are not available in Leland.

cbjeukendrup · 2023-10-01T16:27:55Z

After @Tantacrul's comments I've started to doubt about whether we should put Jianpu characters in Leland or in a separate font. As far as I can see, these are the three options we have:

Put Jianpu characters at unused codepoints in Leland, that are not used by SMuFL.
- Advantage: makes it easy to re-use existing code/logic
- Disadvantage: we can't edit SMuFL-provided metadata files (like glyphnames.json), so we'll then need to get metadata from multiple places: one file about SMuFL characters, one file about Jianpu characters (like you seem to have implemented now)
- Disadvantage: only works with Leland. When the user uses a different SMuFL font for the rest of the score, it should be possible to fall back to Leland for those Jianpu characters, that's not the problem; but if the user wants the Jianpu characters themselves to look different, there’s no option for that.
Use a normal text font
- Disadvantage: can't reuse existing code/logic for computing glyph bbox / glyph names / …, so will need to use/create text font logic instead = some extra work
- Advantage: allowing the user to use any font they like is very easy with this solution
Create our own specification for Jianpu fonts, similar to what SMuFL is, i.e. which character belongs at which code point
- Disadvantage: extra work, because can't reuse SMuFL font logic nor text font logic
- Disadvantage: still limiting the user in which fonts they can use, because each font will need to be built specifically according to MuseScore's specification

As far as I've seen so far, Jianpu only contains usual characters like letters and numbers, so creating a custom specification seems not sensible. So the choice is between option 1 and 2.

I think that for the development of this pull request, we should follow this roadmap:

Decide about the approach for fonts
Make some decisions about how the StaffType logic gets implemented, for example whether to create a new StaffGroup
Finesse the details of the layout/drawing code

Auase · 2023-10-01T16:42:06Z

That's true, but I really don't want to add too much code with repetitive functionality. As for what decision to make, it can only be decided by you and I am powerless.

Auase · 2023-10-01T16:52:07Z

@Tantacrul
At present, I have only made things that are commonly used in Jianpu’s basic functions. I haven’t had time to make things that are not commonly used.

Tantacrul · 2023-10-01T16:53:09Z

A few general comment:

I agree that a basic implementation of Jianpu using single lines makes sense as a first step but I think that should include an appropriate styling for grace notes. Guitar Pro is a very good app but its attention to engraving is not something to aspire to.

I also think I should spend some time designing the ideal visual style for this because I think the current mixture could look much more balanced and legible. Regarding fonts... I'll let @oktophonie weigh in also before making any more comments
Because MuseScore is an ambitious project, I would like to see it set things up with a view to eventually expanding its capability in future - including chord support. Our users are not just beginners and enthusiasts, but also teachers and increasingly, publishers too.

Tantacrul · 2023-10-01T17:01:57Z

@Tantacrul At present, I have only made things that are commonly used in Jianpu’s basic functions. I haven’t had time to make things that are not commonly used.

Oh, I understand this and I think the work you've done so far has been very promising. These things always take time!

Auase · 2023-10-01T17:04:14Z

@yuki0035
If you really need to write this style of music score, I think it can be solved by adding a new part, which will look clearer instead of superimposing the notes.

Auase · 2023-10-01T17:11:00Z

@Tantacrul
Haha, thank you for understanding, my profession is guitar luthier, I will only have time to do this after get off work

Tantacrul · 2023-10-01T17:11:36Z

@Tantacrul Haha, thank you for understanding, my profession is guitar luthier, I will only have time to do this after get off work

There's no rush with this. It's worth taking our time to get it right.

jeetee · 2023-10-01T18:36:14Z

My 2 cents: I think it'd be worth it to take the time to allow using plain text fonts for this. There's a lot of different score styles out there and one of the simplifications offered by Jianpu is that in essence "it's just text" and any word editor can be used to make it.

Given that there is (to our knowledge) no current font standard for the notation system I'd think it be good to support as much variants as possible. Enforcing a new font standard might be a bit less effort, but feels as an unnecessary artificial restriction to me.

I'm really happy to see this long standing request getting some love. Good job @Auase !

Auase · 2023-10-01T18:54:31Z

My 2 cents: I think it'd be worth it to take the time to allow using plain text fonts for this. There's a lot of different score styles out there and one of the simplifications offered by Jianpu is that in essence "it's just text" and any word editor can be used to make it.

Given that there is (to our knowledge) no current font standard for the notation system I'd think it be good to support as much variants as possible. Enforcing a new font standard might be a bit less effort, but feels as an unnecessary artificial restriction to me.

I'm really happy to see this long standing request getting some love. Good job @Auase !

If there are codepoints, it is not difficult to enable users to choose to change font styles.

Auase · 2023-10-02T12:58:46Z

@cbjeukendrup @Tantacrul
What solution do your decide to use in the end? Please let me know after you have made your decision and I will continue.

cbjeukendrup · 2023-10-02T13:05:35Z

@Auase We're still waiting for @oktophonie's opinion. But we'll let you know as soon as possible!

In the meantime, you can already work on my other comments. My general message about layout/drawing code is: calculate things based on the spatium, instead of based on the size of the "do" symbol or any other symbol (unless there is really a direct relation with that symbol). This will be more efficient than having to retrieve the symbol bbox each time, and it will work better when the user chooses a different font (otherwise, there may be a lot of unexpected layout changes when selecting a different font).
(If that makes no sense, please let me know! I'm by no means knowledgeable about Jianpu notation.)

Auase · 2023-10-02T13:08:06Z

Ok

Auase · 2023-10-03T20:25:43Z

@cbjeukendrup @Tantacrul There is a method, but there are several problems: 1. It requires the support of Leland, because the backup font Bravura already has characters; 2. We cannot insist on the symbol name (the name may not be the meaning expressed); 3. I recommend the font Choose one of these styles as the default, but the bytecode needs to be added in Leland (available in Bravura). This method does not require modifying the content of SMuFL.What's your opinion?

Auase · 2023-10-03T20:48:00Z

@Tantacrul
Here is a sample, the Unicode code should be fine (both can be found in Bravura and glyphnames.json), but the font style may need to be adjusted
Leland-Regular.zip

jeetee · 2023-10-03T20:55:33Z

If there are codepoints, it is not difficult to enable users to choose to change font styles.

The codepoints would then be the plain ASCII codepoints for digits; Which would open up any text font to be chosen.
Not unlike how you can select a specific font for each tablature staff currently.

Auase · 2023-10-03T20:59:25Z

If there are codepoints, it is not difficult to enable users to choose to change font styles.

The codepoints would then be the plain ASCII codepoints for digits; Which would open up any text font to be chosen. Not unlike how you can select a specific font for each tablature staff currently.

This is not an ASCII code point, so common text fonts cannot be used, but it is perfectly fine to add other font styles, but they will need to be added manually by the developer.

Tantacrul · 2023-10-03T21:42:15Z

Again @Auase - I just need to discuss with @oktophonie - although I'd be pretty sure we'll end up agreeing with @jeetee that for numbers, we should use basic ASCII unicodes so any font will work. There's no point putting sans serif numerals in Leland for this purpose. I definitely would not point to those unicodes in Bravura because they're almost certainly there for some other intended purpose.

igorkorsukov · 2023-10-04T14:02:48Z

@Auase @Tantacrul @cbjeukendrup

How about adding an option something like MUE_ENABLE_ENGRAVING_JIANPY, disabled by default, that will control the availability of Jianpy in the UI. And merge this PR as it is.

I'm afraid that here are a lot of changes regarding the layout, and we are now actively working on the layout, there may be conflicts or we may even lose this work...

I think we need to disable this function from the interface.
Merge it as is (if we basically want to see it in the editor)
Make a list of tasks that need to be completed
Complete each task using separate PRs

Tantacrul · 2023-10-04T14:48:44Z

@Auase @Tantacrul @cbjeukendrup

How about adding an option something like MUE_ENABLE_ENGRAVING_JIANPY, disabled by default, that will control the availability of Jianpy in the UI. And merge this PR as it is.

I'm afraid that here are a lot of changes regarding the layout, and we are now actively working on the layout, there may be conflicts or we may even lose this work...

I think we need to disable this function from the interface. Merge it as is (if we basically want to see it in the editor) Make a list of tasks that need to be completed Complete each task using separate PRs

I don't mind this as long as there's no way for the user to discover this in the UI.

Then we figure out next steps - start again or keep and refine. @cbjeukendrup ?

cbjeukendrup · 2023-10-04T15:33:59Z

From a code-review point of view, it's not convenient to merge this PR right now. The code will need some refinement before we can consider it "production ready". It is much easier to make these refinements while we have all code together in one Pull Request, where we can easily exchange comments about the code and see what has been addressed and what not.

When we merge it right now, the code is scattered around the codebase, and we'll have to look manually which code was from this PR and which parts of it need refinement; and we'll have to manually write lists of code review comments. This makes nobody happy; not the reviewer but also not the contributor.

What would make these inconveniences even bigger, is that this PR will most likely need a multiple rounds of reviews and refinements: for example, as long as we haven't taken a decision about how to handle fonts, it does not make much sense to look at the specific layout code, because that will probably change anyway when we choose a different way for font handling. All this back-and-forth communication is easier when it happens in one place, and if we can immediately see the updated version of the whole Jianpu code when the contributor makes refinements.

However, Igor has certainly an important point: currently, we're making a lot of changes to the layout code. This can cause conflicts with this big PR. This is a bit inconvenient, but @Auase if you rebase your branch often, and watch Igor's PRs to see what he is doing, then it shouldn't be too much of a problem.

Also, @Auase, we can still help you while the changes are not merged but only in a PR: we can namely also push changes to your branch. If we coordinate this well, this can lead to a very productive collaboration.

Conclusion: let's not merge it now, and make some refinements to it first, until most of it is ready and the "to do list" has been reduced to a few concrete steps (that can easily be performed and verified one by one). Once we reach that point, we can merge it and do those few concrete steps in next PRs.

(I've already discussed this with @igorkorsukov, by the way)

Auase · 2023-10-04T18:09:21Z

From a code-review point of view, it's not convenient to merge this PR right now. The code will need some refinement before we can consider it "production ready". It is much easier to make these refinements while we have all code together in one Pull Request, where we can easily exchange comments about the code and see what has been addressed and what not.

When we merge it right now, the code is scattered around the codebase, and we'll have to look manually which code was from this PR and which parts of it need refinement; and we'll have to manually write lists of code review comments. This makes nobody happy; not the reviewer but also not the contributor.

What would make these inconveniences even bigger, is that this PR will most likely need a multiple rounds of reviews and refinements: for example, as long as we haven't taken a decision about how to handle fonts, it does not make much sense to look at the specific layout code, because that will probably change anyway when we choose a different way for font handling. All this back-and-forth communication is easier when it happens in one place, and if we can immediately see the updated version of the whole Jianpu code when the contributor makes refinements.

However, Igor has certainly an important point: currently, we're making a lot of changes to the layout code. This can cause conflicts with this big PR. This is a bit inconvenient, but @Auase if you rebase your branch often, and watch Igor's PRs to see what he is doing, then it shouldn't be too much of a problem.

Also, @Auase, we can still help you while the changes are not merged but only in a PR: we can namely also push changes to your branch. If we coordinate this well, this can lead to a very productive collaboration.

Conclusion: let's not merge it now, and make some refinements to it first, until most of it is ready and the "to do list" has been reduced to a few concrete steps (that can easily be performed and verified one by one). Once we reach that point, we can merge it and do those few concrete steps in next PRs.

(I've already discussed this with @igorkorsukov, by the way)

I agree, and my opinion is to wait until the font solution is resolved before considering merging it. As for the changes to the main branch, I think there is no problem with the Jianpu branch following the changes to the main branch (the main branch had major changes before I submitted it), because I understand the entire logic.

Auase · 2023-10-04T18:14:41Z

@cbjeukendrup
At present, I have solved some of the problems you mentioned earlier, but I have no idea how to start regarding fonts. I am waiting for your decision.

Auase · 2023-10-06T16:11:16Z

I'm a little busy these days. I'll open it after I finish it in a while.

Tantacrul · 2023-10-06T20:08:46Z

Hey @Auase

Apologies for the delay. Been pretty busy the last week.

After a chat with @oktophonie, and some thoughts from @cbjeukendrup and @jeetee, I think we all feel that the best approach would be this.

We use standard unicodes for numerals, so that any text font can work
We find appropriate standard (non SMuFL) unicodes for some other symbols, like the dots used for dotted durations
We use Edwin for accidentals
We draw other symbols, like rectangles for 8ths, 16ths etc. in code
We do not use Leland at all. Doesn't seem to be any reason. Better to open it up for all fonts.
We do not use a new font. Same reason as Leland. It's messy to have another font just for this purpose.

I'll put together a recommendation about spacing / alignment of elements and share it here soon. This won't block the work. It's simply about making Jianpu look really nice and consistent with the spacing we've used in the score in general.

How does this sound? We can obviously guide you though any uncertainties. We've done a lot of this in the past and we're confident that this approach will work nicely.

Auase · 2023-10-07T16:01:18Z

Hey @Auase

Apologies for the delay. Been pretty busy the last week.

After a chat with @oktophonie, and some thoughts from @cbjeukendrup and @jeetee, I think we all feel that the best approach would be this.

We use standard unicodes for numerals, so that any text font can work

We find appropriate standard (non SMuFL) unicodes for some other symbols, like the dots used for dotted durations

We use Edwin for accidentals

We draw other symbols, like rectangles for 8ths, 16ths etc. in code

We do not use Leland at all. Doesn't seem to be any reason. Better to open it up for all fonts.

We do not use a new font. Same reason as Leland. It's messy to have another font just for this purpose.

I'll put together a recommendation about spacing / alignment of elements and share it here soon. This won't block the work. It's simply about making Jianpu look really nice and consistent with the spacing we've used in the score in general.

How does this sound? We can obviously guide you though any uncertainties. We've done a lot of this in the past and we're confident that this approach will work nicely.

That sounds great, thank you. But this solution may result in some more code with repeated functions. If you have any good ideas, please tell me here. I will follow the main branch to improve it. If I encounter a problem that I am unable to solve, I will ask everyone for advice when the time comes. But recently, there are some things in my company that I need to deal with, so please give me some time.

Gravifer · 2024-04-11T17:04:08Z

Was the @Tantacrul video mentioning jianpu removed?
Sorry to hear that there are new obstacles to overcome though

Tantacrul · 2024-04-11T17:09:24Z

Removing videos of mine is an offence punishable by death.

Gravifer · 2024-04-11T17:44:37Z

Removing videos of mine is an offence punishable by death.

I may be a little confused, but at one point I thought this PR was shipped in v4.2, and was super excited.

I'm trying to adopt a violin piece for a fellow Erhu player of mine, and sincerely hope this get resolved soon 🙏

cbjeukendrup · 2024-04-11T22:31:51Z

I may be a little confused, but at one point I thought this PR was shipped in v4.2, and was supper excited.

This confusion might have arisen from the fact that the Jianpu contribution was mentioned here: https://musescore.org/en/node/355107
At that time we were probably still hoping that it would indeed make it into 4.2, but unfortunately that didn't happen. But hopefully either the original contributor or someone else will pick it up in the future. "Soon" is not realistic though.

cbjeukendrup · 2024-04-11T23:12:29Z

Also, the video you mention, was that https://youtu.be/Eq3bUFgEcb4?feature=shared&t=4279 ?

Gravifer · 2024-04-12T06:22:48Z

Also, the video you mention, was that youtu.be/Eq3bUFgEcb4?feature=shared&t=4279 ?

Ah, yes indeedy!

Auase · 2024-05-01T05:12:27Z

I will continue and haven't given up, but I really don't have time recently. Sorry.

etanman · 2024-07-11T00:31:36Z

We are looking forward to the implementation of this feature and we really need it.

Auase marked this pull request as ready for review September 16, 2023 20:26

Auase mentioned this pull request Sep 16, 2023

Realize the basic functions of Jianpu #19395

Closed

8 tasks

This comment was marked as resolved.

Sign in to view

Auase closed this Sep 23, 2023

Auase force-pushed the Jianpu_1.0 branch from cf58954 to 6d7d80b Compare September 23, 2023 03:31

Auase reopened this Sep 23, 2023

cbjeukendrup reviewed Oct 1, 2023

View reviewed changes

Auase closed this Oct 5, 2023

Auase force-pushed the Jianpu_1.0 branch from 429331f to 1f011ae Compare October 5, 2023 06:13

cbjeukendrup added the archived PRs that have gone stale but could potentially be revived in the future label Mar 31, 2024

musescore deleted a comment from TaoxiaoyuZN May 7, 2024

		double symWidth = item->symWidth(SymId::keysigJianpuDo);
		double symHeight = item->symHeight(SymId::keysigJianpuDo);

Realize the basic functions of Jianpu #19421

Realize the basic functions of Jianpu #19421

Conversation

Auase commented Sep 16, 2023 • edited Loading

Auase commented Sep 16, 2023 • edited Loading

This comment was marked as resolved.

This comment was marked as resolved.

Auase commented Sep 23, 2023

cbjeukendrup commented Sep 24, 2023

Auase commented Sep 24, 2023

Tantacrul commented Sep 27, 2023

Auase commented Sep 28, 2023 • edited Loading

cbjeukendrup left a 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

Choose a reason for hiding this comment

Tantacrul commented Oct 1, 2023 • edited Loading

Tantacrul commented Oct 1, 2023 • edited Loading

yuki0035 commented Oct 1, 2023 • edited Loading

Tantacrul commented Oct 1, 2023 • edited Loading

Auase commented Oct 1, 2023

Auase commented Oct 1, 2023

Auase commented Oct 1, 2023

Auase commented Oct 1, 2023

cbjeukendrup commented Oct 1, 2023

Auase commented Oct 1, 2023

Auase commented Oct 1, 2023

Tantacrul commented Oct 1, 2023 • edited Loading

Tantacrul commented Oct 1, 2023

Auase commented Oct 1, 2023

Auase commented Oct 1, 2023

Tantacrul commented Oct 1, 2023

jeetee commented Oct 1, 2023

Auase commented Oct 1, 2023

Auase commented Oct 2, 2023

cbjeukendrup commented Oct 2, 2023

Auase commented Oct 2, 2023

Auase commented Oct 3, 2023

Auase commented Oct 3, 2023

jeetee commented Oct 3, 2023

Auase commented Oct 3, 2023 • edited Loading

Tantacrul commented Oct 3, 2023

igorkorsukov commented Oct 4, 2023

Tantacrul commented Oct 4, 2023

cbjeukendrup commented Oct 4, 2023

Auase commented Oct 4, 2023

Auase commented Oct 4, 2023

Auase commented Oct 6, 2023

Tantacrul commented Oct 6, 2023

Auase commented Oct 7, 2023 • edited Loading

Gravifer commented Apr 11, 2024 • edited Loading

Tantacrul commented Apr 11, 2024

Gravifer commented Apr 11, 2024 • edited Loading

cbjeukendrup commented Apr 11, 2024 • edited Loading

cbjeukendrup commented Apr 11, 2024

Gravifer commented Apr 12, 2024

Auase commented May 1, 2024

etanman commented Jul 11, 2024

Auase commented Sep 16, 2023 •

edited

Loading

Auase commented Sep 16, 2023 •

edited

Loading

Auase commented Sep 28, 2023 •

edited

Loading

Tantacrul commented Oct 1, 2023 •

edited

Loading

Tantacrul commented Oct 1, 2023 •

edited

Loading

yuki0035 commented Oct 1, 2023 •

edited

Loading

Tantacrul commented Oct 1, 2023 •

edited

Loading

Tantacrul commented Oct 1, 2023 •

edited

Loading

Auase commented Oct 3, 2023 •

edited

Loading

Auase commented Oct 7, 2023 •

edited

Loading

Gravifer commented Apr 11, 2024 •

edited

Loading

Gravifer commented Apr 11, 2024 •

edited

Loading

cbjeukendrup commented Apr 11, 2024 •

edited

Loading