Issue with package in MacOS

[brunaw]

When I run one of the basic examples provided in the documentation:

library(tabr)
p1 <- p("r a2 c f d a f", "4 8*6")
track1 <- track(p1)
song <- score(track1)
tab(song, "phrase.pdf", key = "dm", time = "4/4", tempo = "4 = 120")

I get:

#### Engraving score to phrase.pdf ####
arguments 'show.output.on.console', 'minimized' and 'invisible' are for Windows only
unknown option --pdf
usage:  [option] ... [-c cmd | -m mod | file | -] [arg] ...
Try `python -h' for more information.

This is very likely to be due to the fact that I'm using MacOS (Darwin, to be more specific) and not Windows since the error is being generated by the options that are for a Windows OS. I tried changing Lilypond's path, but that didn't help. What could be the next steps for us to figure how to solve this problem?

[leonawicz]

Try using this build:

remotes::install_github("leonawicz/tabr", ref = "os")

Let me know if that helps with the message about system options that are Windows only.

If it is separately complaining about --pdf being an unknown document output format argument for LilyPond then maybe it needs to be different for Mac. I'll see if I can find anything in the LilyPond documentation about the Mac command line calls and relevant Python scripts.

[leonawicz]

In the past I have had Mac users report both success and difficulty. I don't have a Mac to test on, but in any case I am not very familiar with the OS.

If any Mac users can chime in, I am curious if steps 1, 2, 4, and 5 under the Running on the command-line section in the LilyPond documentation are necessary setup for all users to use tabr successfully on Mac? Some users? Is this setup relevant to the issue at hand?

If so, is this something I should add to my installation instructions for Mac users like how I mention adding LilyPond to the system path for Windows users? Or can I automate that as part of package setup? (I'm guessing the latter violates CRAN policy, so probably not. And I prefer not to try and manage others' system setup anyhow; users should handle that themselves in most cases).

For now, I haven't found anything that suggests the system call itself needs to be different on Mac, but maybe it does?

[znh1992]

It looks like the code used to build the call_string doesn't actually construct a call when is_windows is false, thus the error : command not found.

It also looks like installing the package doesn't actually provide the crucial bits of LilyPond on MacOS. I got a few lily-* executables, but I am not sure what they are. To get around this, I installed the program from here. Then, I half-followed the instructions on the side of the web page:

1. Unzip the bz2 tarball and move the LilyPond.app folder to /Applications
2. Create a lilypond executable somewhere you can point to that contains the following: #!/bin/bash exec /Applictions/LilyPond.app/Contents/Resources/bin/lilypond "$@"
3. Give the executable proper permissions chmod u+x lilypond
4. In R, set the proper options, pointing to the new executable: tabr_options(lilypond='path/to/lilypond')
5. I then tested with: phrase("c3 d3 e3 f3 g3 a3 b3 c4", "4 4 4 4 4 4 4 4") %>% track %>% score %>% tab("Desktop/C_major.pdf")
6. Voila

I don't know anything about package management, so I'm not sure if any of this could be handled on the install.

[leonawicz]

Thank you, I saw the lack of call being put together. I fixed this much on GitHub now, though this won't address the real issues.

Basically when the package loads, if a Windows users put the bin folder on their PATH, they should be all set. If a Linux user has LilyPond installed, they should automatically be all set. And my test suite confirms this as far as I can see. For Mac I've heard it should be just as simple as Linux, but it's clearly not.

For all three systems, when the package is loaded it uses Sys.which to find: (1) lilypond (lilypond.exe for Windows) (2) python (python.exe for Windows) (and Python is bundled with LilyPond so users should never need to install that separately, I don't think) (3) midi2ly.py

But this check on load that potentially sets the values in tabr_options() is only meant to assist Windows users who may have failed to add the LilyPond bin directory to their PATH. None of this is necessary for Linux. Theoretically it's not necessary for Mac either. When the values in tabr_options() are the empty string "", Linux and Mac will just call lilypond rather than /full/path/to/lilypond anyway, and that should suffice, I think. I just fixed that bug where it wasn't actually filling in the command lilypond.

But the bigger issue is it sounds like there is potentially more to do on Mac to set up LilyPond. Yeah, the details at that url are the same as at the url I shared earlier in the thread asking people to test out. If I can get confirmation from more Mac users that this is in general the recommended way to set things up, I can just point users to it in my documentation. I don't know if it affects some Mac users or literally all Mac users. In the past Mac users said it "just worked" but maybe they had done those steps as part of their setup. I'm not allowed to mess generally with users' systems through my package when installing, not that I'd have any desire to take responsibility for external software setup even if I could. On all systems, users have to install and set up their own external software, by whatever means necessary I suppose. But the package won't do that.

[leonawicz]

Closing this issue as it is pretty specific and I believe was fixed a long time ago. But for Mac users in general:

As part of the latest repo updates and package release to CRAN (today), the build for MacOS has been integrated into the repo's Github Actions workflow.

It builds and tests successfully.

Though in general I only ensure to support for Windows and Linux and can't offer further MacOS assistance, Lilypond and integration with tabr on MacOS do appear to work now. :)