10-01-2024, 04:30 AM (This post was last modified: 10-01-2024, 04:53 AM by Cerio.)
Hi, this is what I get when trying the new Chord Grid feature with standard settings:
Chords are so tiny that they are barely visible.
However, if I try to increase the grid size vía Text Display Setting, this is what I get:
As you can see, chords/bars in the 3rd and 4th columns are simply lost.
In either case, the whole feature is unusable to me. I know this is a brand new feature, but I'm not sure if I'm missing something or the feature simply still needs some work to be usable. Any hint?
10-01-2024, 05:31 AM (This post was last modified: 10-01-2024, 05:33 AM by Zubersoft.)
The chord grid should be using the available space on the screen to figure out how much width to use, with a predefined maximum width dependent on the font size that is used (to ensure the chord grid doesn't just use the full screen size in every scenario which would be undesirable). You did not provide the chord pro file you used or even the definition of the chord grids, so it will be hard for me to know what you tried to use for it. I'm guessing you defined an absolutely massive grid, which is inadvisable. You can see if I use a more simple definition:
I don't currently support breaking up grids on multiple lines, as I don't even know if users would want that. If you can attach your chord pro file, I want to run it through the main ChordPro application to see how it appears with that.
10-01-2024, 07:03 AM (This post was last modified: 10-01-2024, 07:05 AM by Zubersoft.)
Sure thing. You'll definitely have much wider grids with 4x8, as MobileSheets will make room for the 32 instances of the maximum cell size that would be needed with the current font size. If you plug that into the ChordPro app itself, it just lets each column of the grid bleed into the grids beside it (with the default settings) due to the extreme width required. So I'm not sure if you'll really want to use 4x8. Regardless, I'll have to reconsider the maximum cell size used at the moment, and calculate the scenario where the cell size causes the grid to go offscreen. In that scenario, I'll have to forcefully shrink the cell sizes down which could cause characters to overlap each other.
I fully agree with Cerio's first post: chord grids still need fundamental changes.
Not only are they incompatible with Sciurius' reference implementation, how it is today is simply not usable.
Until now I create PDFs with the reference implementation. I created a number of config files for different font sizes, most of them using the same font size for lyrics, comments, chords and chord grids. To make the output as big as possible I choose the font size that fits best, here it's 20 pt:
BengerzBrauneBrieh_F_ChordPro_6.050_029.pdf (Size: 160.78 KB / Downloads: 10)
This is what happens if I choose a much bigger font, e.g. 28:
Lyric lines get broken up
Chords in the grid overlap the measure bars (in other cases even the chords themselves overlap each other), but the measure width stays unchanged (as specified in the grid header in fractions of the page width: {start_of_grid 8x4} means 8 measures, each with 4 beats, one measure is 1/8 page width wide). The overlapping looks more or less ugly, but all measures and all chords are shown and the output stays valid and usable.
BengerzBrauneBrieh_F_ChordPro_6.050_029_FontSize_28.pdf (Size: 161.82 KB / Downloads: 6)
This is what happens when I import the same file in MobileSheets:
The last about 1 1/2 measures are cut off, the chords they contain are missing without any notice that the output is incomplete!
10-02-2024, 10:45 AM (This post was last modified: 10-02-2024, 10:47 AM by Zubersoft.)
how it is today is simply not usable
That's a pretty strong statement considering they output perfectly fine many situations. In development, I was using chord pro as a reference guide and ensured the output in MobileSheets matched what was shown in Chord Pro. Is it correct in every situation? Apparently not, based on the reference implementation, but as mentioned, I'm going to make adjustments. I didn't think it was correct to wrap chord grids to the next line, but apparently that was an incorrect assumption as well, so I'm going to have to make changes for that. I'm not sure why you are saying they are incompatible with the reference implementation - like I mentioned, they were developed to match exactly what I was seeing in the test files with the ChordPro application. Is it an exact match in every situation? You have demonstrated that no, that is not the case, so I'll work on that. Calling something incompatible suggests the two are not the same in any situation, which is just not the case.
10-06-2024, 07:55 AM (This post was last modified: 10-06-2024, 08:47 AM by itsme.)
The reference implementation always uses the given page width, divides it into the pieces that are required for the specified number of measures plus the left and right margins. No matter how big the chord font is, the width of the measures stays the same and all measures and chords are visible.
In MobileSheets the width of the measures depends on the font size. So grid lines are created that might be too wide to fit on the page.
That's what I call incompatible.
If the chord font is too big, measures and chords are cut off at the right edge.
Or I have to reduce the chord size to make the line fit on the page. This might result in unreadably small chords.
That's what I call unusable.
Sorry to say that.
I have dozens of ChordPro files that me and my bandmates used to create PDFs with the ChordPro reference implementation. They contain many examples of chord grids and ABC snippets.
I will look up some relevant ones and provide them for testing in separate threads, one thread per song.
Fair enough - I'm not sure what logic ChordPro is currently using to decide what the cell size should be, or how you control that without going into the configuration file (is that possible?). I'll have to do more research before deciding on what the implementation should be.
I think (just watching what happens and guessing) the available width of the page (without left and right page margins) is divided into a number of 'boxes' that are equally wide. There's a left and a right column for comments with a number of measures in between. The measures are enclosed in measure bars.
See example post ChordGrid, additional left column - Musikaner https://www.zubersoft.com/mobilesheets/f...12152.html
{start_of_grid 3+4x4+1} divides the page into 20 columns, whereas {start_of_grid 7+4x4+1} makes 24 columns.
{start_of_grid 3+4x4+1}: one measure takes (100/20)*4 = 20 % of the page width, in the PDF opened on my screen it's 42 mm
{start_of_grid 7+4x4+1}: one measure takes (100/24)*4 = 16,66 % of the page width, in the PDF opened on my screen it's 35 mm
That confirms exactly my guess above.
Again: the width of the columns is NOT changed when the font size is changed by my config files, instead chords are placed left aligned in the column where they belong. If the column is not wide enough the chord symbols just overlap.
I think I go one step back and compare the rendering of MobileSheets with the default output of ChordPro without any user config.
(10-06-2024, 07:44 PM)itsme Wrote: compare the rendering of MobileSheets with the default output of ChordPro
Please keep in mind that ChordPro provides just a way how a song can be rendered. There is no such thing as the way. Tools like MobileSheets are free to choose how they fill in the details.
When you and I play the same song, it will also sound differently.
That's how it is, sure. But better compatibilty allows doing interesting things.
By now I used ChordPro for songs in MobileSheets as far as possible mainly to be able to transpose instantly.
As soon as I wanted to integrate chord grids or ABC snippets (btw. for such a combination ChordPro is by far the best tool that I know of, many thanks for your brilliant work) I used ChordPro, created a PDF and imported that into MobileSheets. When I needed such a song in different keys I transposed it in ChordPro and created a PDF for every required key. Doable but not the most flexible way.
Having chord grids and ABC supported natively within MobileSheets gives the maximum flexibility.
Maybe I will keep importing PDFs made with ChordPro into MobileSheets every now and then to make use of all the latest bells and whistles of ChordPro, but in general using the ChordPro files directly will be the fastest, most convenient and most flexible way to do it.
Another idea of a convenient workflow: I could create a book as PDF, with title page, TOC, CSV and so on from a selection of songs from my MobileSheets library just by writing a filelist of the songs that I want to include and let ChordPro do the job.
All this works best if there's no need to touch the ChordPro source - that's why I'm testing compatibility and point to differences that I find in the hope to improve the final result.
