search

leonawicz / tabr

R package: tabr. Notation-based and tidy music data analysis and transcription.
https://leonawicz.github.io/tabr/
Other
126 stars 10 forks source link

(some) paper specifications do not work #24

Closed HanOostdijk closed 5 years ago

HanOostdijk commented 5 years ago

Working with version 0.3.9.9000 of tabr and version 2.19.83 of LilyPond on Windows 10.

The size paper specifications do not seem to work: paper <- list(textheight = 55,linewidth = 120) has no effect. I got it working by adapting the generated .ly file:

See function edit_ly_file in blog entry.

I also saw that print-first-page-number is handled identical to print-page-number and derived from paper$page_numbers.

I am impressed by the amount and quality of the work done on tabr and Lilypond.

leonawicz commented 5 years ago

Thank you for the detailed submission, including that post. It's very helpful. I will update the underlying template that R is assembling so that the paper block is at the top. My machine is currently still using LilyPond version 2.18.2 so I will update that as well when I test it out. I'll let you know when it is patched.

leonawicz commented 5 years ago

Oh that's the development version. I see it's still the 2.18.2 for the release version so I'm not going to update yet. But I bet I'll see the issue you describe and will still rearrange the template.

leonawicz commented 5 years ago

Try again with the latest commit. You should now see the LilyPond paper block at the top of the .ly file. My testing using your example shows it working for me now. I can confirm that using v2.18.2 I had the same problem you had with the development version.

You can also now conveniently suppress printing the tempo with tempo = NULL.

page_numbers remains a global setting (TRUE allows all page numbers, FALSE suppresses all page numbers including first page). But now you can separately suppress the first page when page_numbers = TRUE if, on the R side, you provide first_page_number = NULL instead of a number.

Please confirm if this solves these issues, mainly the page size. You shouldn't have to make all that custom function code to do these things.

I love the idea of adding an option to display the pitches as lyrics. However, for this I really need to understand how that would or could work generally, i.e., (1) when chords are present, (2) when there are multiple tracks (or voices per track), (3) if any tracks have a transposed music staff. Until I dig deeper I'm hesitant to incorporate your addition of pitches since it is done for this one-track, single-note edge case. But it looks great!

HanOostdijk commented 5 years ago

Looks good with one exception:

paper <- list(textheight = 55,linewidth = 120,first_page_number = F)

is translated in (NB FALSE) in

#(set! paper-alist (cons '("papersize" . (cons (* 120 mm) (* 55 mm))) paper-alist))
\paper{
  #(set-paper-size "papersize")
  indent = 0.\mm
  first-page-number = FALSE
  print-page-number = ##t
  print-first-page-number = ##t
}

I agree that adding lyrics is a separate study ;)

HanOostdijk commented 5 years ago

Sorry: did not mean to 'close'

leonawicz commented 5 years ago

FALSE is blocked now. It will only allow numeric, or NULL to suppress that value. I'll close this now.

But if you happen to look into the more general possibility of pitch lyrics before I do (I won't get to it right away) and it looks feasible, feel free to open a new issue. It's a great idea. I don't want to over-complicate it before we dig deeper, but just to share my thoughts on it for the moment- I think it would be nice to provide some user configuration options that (1) allow the octave number to be optional and (2) to switch to "pretty notes" (Ab A A#). Perhaps there could eventually be something like a "lyrics" (maybe not that name if it is too broad) argument to lilypond that takes a named list of related arguments like paper and header. For example, pitch_lyrics = list(octaves = FALSE, pretty = TRUE). That is, if it ends up making sense to do this. It is more important if it will work well for multiple tracks or chords.

I also plan to make some new functions alongside tab. Now that the package is much more general than it was originally. tab is very specific. There is render_chordchart now. So I may add something like render_tab (possibly just an alias to the original tab) but also render_music for sheet music which has different defaults such as tab staff suppressed. More appropriate for users who are not playing fretted, stringed instruments. I recently added analogs to track such as track_bc, track_tc and track_bass. This is the kind of direction I am leaning in.