[laurent]

Hey,

I would like to use .abc notation for all my brazilian choro tunes, with Mobilesheets as my viewer of choice, because it is awesome.

One of the prerequisites is that I can control how it looks like on my 10" Android tablet, more precisely:
* I want to use all the vertical space, so that the notes are as big as possible
* I don't necessarily want to use all the horizontal space, because if I remove all left and right margin, the notes are sometimes too spaced out and I find it harder to read.

Here is a sample piece that I have:

%%propagate-accidentals octave
%%partsfont Times-BoldItalic 20 box
%%leftmargin 50
%%rightmargin 50
%%topmargin 0
%%botmargin 0


X:1
T:Seu Louren\cco no Vinho
C: Pixinguinha/Benedito Lacerda
%%MIDI gchord fc2cfhcf
M:2/4
L:1/16
P:AABBACCA
Q:1/4=92
R:Choro
K:C clef=treble
%%pagescale 1.20
P:A
: E Gcec | "G7"df2d BAGF | "C"E2zE Gcec | "G7"df2d BAGF |
"C"EGce dcBA | "E7"^GBdf edcB | "Am"A^GAB cBA=G | "D7"^F2zd cA^FD |
"G7"A3G zA^GA | "A7"_BA^GA "A7/C#"BA^GA | "Dm"_BA^GA BA^GA | "A7"d^c^Bc dcBc |
"Dm"ed^cd edf2 | "Fm6"z_afd c_AFD | "C/E"GEGc "Ab7"_A_EAc | "Dm"AFAc "G7"BGBd | "C"c2 .|
P:B
[K: Am]: B dcBA | "E7/G#"^GE^DE GEDE | "Am"AE^DE cEDE | "E7/B"B2^GB dfed |
"A7/C#"^cege cAGE | "Dm"D2e2 d2z2 | "Am/E"z2d2 c2z2 | "B7/D#"zcBc BcBc |
"E7"BcBc BcBc | "G7"Beda gfdB | "C"dcfe dcBA | "E7/G#"^G2z2 EGBd |
"A7"^ceg_b agfe | "Dm"gfdB AFDB, | "Am"z2e2 "F7"z2f2 | "Bb"z2 _b2 "E7"z2e2 | "Am"za2 .|
P:C
[K: F]: c Bcdc | "F"f3A ^GABA | "F/A"c3F EFGF | "F"AC=B,C FAce |
"Gm"dcBG E2z2 | "A7"zage ^c_BAG | "Dm"FAd^c edA=B | "A"^cecA "E7/G#"=BdB^G |
"A"Az3 z4 | "D7/F#"z2c2 B2A2 | "Gm"D3A "G7/B"G4 | "C7"z2B2 A2G2 | "F"c2Ac "Db"ffff |
"Ddim"z^G=Bd "Bbm6/Db"ffff | "F"zagf edc=B | "Gm"_Bc^cd "C7"AG=cA | "F"F3 .|

The process I'm going through right now to tweak the rendering of the ABC for my tablet is:
1. I set %%rightmargin and %%leftmargin to 0
2. I set %%pagescale (defined just before the notes after the headers) to the highest value that
   * uses all the vertical space
   * doesn't have measures overflowing to another line, I want to keep the same number of lines defined in the ABC.
3. I then adjust %%rightmargin and %%leftmargin to higher values if I find that the notes are too spread apart.


This works, but it is a bit tedious, I need to do it for every piece, and if I send the .abc file to someone else with a tablet with other dimensions, it might not display as well.

I understand the "crop" feature doesn't work for .abc files as the music sheet is rendered on opening. But could we imagine to have an option in Mobilesheets Pro to "fit to page" so that I don't have to specify the "%%pagescale" at all?
Any other suggestions are welcome.

Additionally, I noticed that %%topmargin and %%botmargin don't seem to do anything. Looking at this documentation [ http://moinejf.free.fr/abcm2ps-doc/index.html ] for abc2svg, it seems it's only taken into account for "page" mode, which I'm not sure what this is.


Thanks again for the awesome work on Mobilesheets and I hope this .abc integration will bring a lot of new users.

[Zubersoft]

MobileSheets should be already using the entire screen as the bounds for the image that is generated. I pass that width and height into abc2svg by dynamically modifying the abc content to set %%pagewidth and %%pageheight. I also dynamically insert %%pagescale to account for the display density of the screen. It places this %%pagescale after the X: line. If it detects that the first line is %%pagescale, it will multiply that pagescale value by the density of the screen. I also already write the left and right margins as the first two lines of the abc file, so if you place those after those lines, then it will just overwrite the margins that MobileSheets is trying to set (which is fine). I set the top and bottom margins after the X:, so you would have to place your top and bottom margins after the X: as well if you want them to overwrite the margins specified by MobileSheets. 

So I'm a little surprised you aren't seeing the ABC file take up the entire width of the screen. I'm also not sure what exactly you would want me to change, as it should already be generating images that matches the width of the screen.

Mike

[laurent]

It's more easily show with images. Here's how it looks with no pagescale instructions.
   

And here's how I would like it to show on my tablet.
   

[laurent]

Maybe the thing that I'm doing different is that I don't try to maximize the width, as I noticed it only stretches the notes apart from one another and doesn't make them bigger. I maximize the height while making sure the measures don't overflow. I actually like it better visually when semiquavers are tighter together.

[Zubersoft]

This may be something that is difficult for me to address automatically. Perhaps I can add some more options for ABC scaling and you could apply a default extra scaling to every score, or something along those lines.

Mike

[laurent]

I understand this is a hard problem. It depends on the score and on the dimensions and screen characteristics of the device.

I sent a mail to the abcusers mailing list explaining the challenge to find the optimal pagescale, and hope that abc2svg's developer Jean-François Moine can give some insight.

For the margins, I don't know what values you use, but would it be possible to expose them as a setting? For my personal taste, I would rather use 0 for all margins by default, and I might sometimes adjust right and left margins to other values on a per score basis.

[Zubersoft]

I can certainly consider adding support for setting the margins, as this wouldn't require too much effort if I'm already going to support adjusting the page scaling. This also opens up the option to control other properties of the ABC file through MobileSheets in the future if there is a need.

Mike

[laurent]

Thank you, I'll keep you posted on my findings for autoscale, if you're not on the abcuser mailing list already ( https://groups.io/g/abcusers ).

For the topmargin and botmargin, what are the reasons why you inject them after the X:?

It was a bit puzzling to see that my rightmargin and leftmargin annotations worked, and the topmargin and botmargin were ignored - until you told me where to put them.
Wouldn't it be better to not inject them at all if they are provided in the .abc?

[Zubersoft]

It's complicated to parse out all of the potential information from the ABC file before deciding whether to insert the margins, because I would basically need to do two passes over the file (and some files can be very large with many individual pieces in them) in order to know if the user inserted their own margins, because there is no fixed position that they would have to be placed at. The top and bottom margins can also be specified per piece in the file (so after X:1, X:2, etc). The same is true of the pagescaling, as there is no requirement for it to be placed at a specific place. There is also, to my knowledge, no easy way for me to identify exactly when I've reached the point in the file where notes are being placed (versus all the other supported settings that come before the notes). So I just didn't want to go down this huge rabbit hole of trying to account for every potential scenario, and slow down the parsing in order to accomodate settings from users, as I wasn't even sure how many users really specified their own margins.

Mike

[laurent]

Ok, I get it, that makes sense.

I use a single tune per file in Mobilesheets Pro for my part, because it takes the title from the filename, and I want the tunes to be easily searchable in Mobilesheets.
By the way, is there an option to populate the title, composer, and other properties from the .abc headers when importing the file? And possibly update them after each time we open them if they were ever edited after import.

For the abc settings, in addition to the margin settings, could we also consider having a field where we can enter arbitrary abc instructions to add at the beginning of each abc file before rendering, so that each user can tweak whatever default setting without adding them to all their .abc files.

I would edit the fonts, the spacing.
I can also imagine clarinet players wanting to add an automatic "%%transpose 2" so that they don't have to hit the transpose button manually if all their scores are in C. Though the "transpose" setting does deserve to have a setting on its own, for added discoverability for non ABC-savvy users.

[BRX]

Mike already promised improvements of the GUI for ABC files.

And one is certainly a transpose button (probably not only for Bb-instruments, but similar to the chpro with a way to change in semitones).

But what I additionally wanted to suggest some "customizable buttons" or menus you can choose and edit yourself.

So you can have a button which for example switches of lyrics, or chords, or the grid, or a certain transpose (for directly transposing for Bb-instruments).

If you now the ABC syntax you can make your own buttons/GUI with those functions you need. As I imagine MS would only need to add an % to the specific line in the syntax (or insert/delete it completely by itself, whatever Mike considers best).

[Zubersoft]

I am going to support reading metadata out of an abc file, but I'm a little unsure of how I should handle scenarios where there are multiple songs in a single abc file (do I just use the first and ignore all the rest?). As far as your recommendations, these all sound like nice features to have, and I'd like to support them, but in terms of weighing priorities, I really need to get a sense for how many people are utilizing .abc files. If it's only a very small percentage of users, then I don't think I should be prioritizing any of this over more general features that would benefit more users. So that's something I'm going to need to figure out.

Mike

[laurent]

I can't talk for the other people so I don't know how they are going to use .abc with Mobilesheets.

I used to have all my tunes in one file, in order to be able to re-use the common abc instructions, but when I imported into Mobilesheets, it made more sense to me to separate them, so that's what I did.
I wouldn't mind personally that you index the first song of each file, if you want to incentivize users to keep their .abc collection in a Mobilesheets friendly way.

I suppose that ideally, you would index all tunes in Mobilesheets and clicking on any of them would get you to the correct file and page, just like a link to an HTML page that has a # anchor, but I don't know if that's even possible.

I understand that probably not a lot of users are using .abc right now.
I was interested in .abc support for a long time actually, and I only discovered it was supported for standalone .abc files last month, so I suppose the word is not spread even for Mobilesheets Pro users.
I have to admit I don't read all the details in the release notes...

I just sent an email to the maintainer of https://abcnotation.com/software#mobile to ask him to add Mobilesheets to the list of apps supporting abc. You haven't implemented playback yet, is that correct?

[Zubersoft]

Correct - I do not support playback.

Mike

[laurent]

<some user from the ABC mailing list said>

I looked at the web page https://www.zubersoft.com/mobilesheets/features/files/
and there isn't a mention of ABC. Are you using the standard release and do you know
if the other versions such as iPad or Windows include the ABC feature?
thanks
Paul

It would be worth mentioning that you support .abc in your website as well. Fellow members from the abc usergroup were not aware of the abc support. Is it also supported for iPad or Windows? I'll answer him.