Q: how to create end bar? about tabr HOT 5 CLOSED

Thanks. I'm unsure why I was adding a line break after bar checks. I've removed this now. In your example it was probably failing because of the line splitting inside the quotes for your literal bar.

Your approach should work now (no line break). But I've also added better support for adding various types of bars at the end of a phrase with the bar argument. It used to be strictly logical. bar = TRUE would insert a bar check (just the pipe |, no \\bar or quotes around the pipe).

You can still insert a bar check with TRUE, but providing the LilyPond string, e.g., bar = "|." will insert an actual bar like in your example. Try with the latest GitHub version.

from tabr.

Thanks Matt, this works fine.

Not clear to me what a bar check is/does: I tried to insert the pipe symbol in the phrase (in combination with bar=T) but it is found 'invalid'. I liked the idea to be able to insert them in 'notes' and 'times' so much that I created helper functions for this in my package HanOostdijk/tabraux

from tabr.

@HanOostdijk

bar check

Just inserting a pipe by itself is a bar check. This is used to make the LilyPond code more readable by breaking up measures and also help LilyPond check for sections of music whose time adds up to one or multiple measures rather than some invalid fraction of a measure. The bar check does not create bar notation in the output like for example \bar "|" does.

better bar injection for phrases

Thanks for the reference! I'll give some thought to how I may be able to integrate something similar into phrase for LilyPond-specific transcription, without having it impact the broader tabr package that doesn't relate to transcription. Maybe specifying an vector that gives the indices for which specific measures you want to insert a bar at (type of bar can also be a vector if different bars are required). Perhaps similar to how labels and at arguments work for as_music. This could be very convenient for longer phrases. Could also be a lot easier than injecting LilyPond bar syntax directly into these notes or info arguments. On that note, if you haven't checked out the music class and as_music, it has a more efficient music data entry than how phrase requires up to three separate inputs, and phrase can take a music object as a single input to notes and nothing else needed.

other stuff

There are also time helper functions in tabr for computing cumulative durations in note info strings. These can be used to inform where new measures begin. I would probably leverage these when I next improve phrase for something like inserting bars at specific time steps.

As the package has developed, I have really downplayed the use of integer-format octave numbering because of various limitations and generality compared to tick marks. It was a mistake on my part in early releases to promote integer format as the default and use it in lots of examples. I have worked that back over time. I continue to support it, but it is definitely the more restrictive format.

Sorry about the lack of handling of repeated white space and untrimmed whitespace with phrase concatentation. That was super easy to fix and should work now with pc and pn. Just for context, I'm not a big fan of pc and pn. I feel like my need to use these functions can partly indicate that my other functions are failing to meet a need directly.

It makes sense if you are trying to append a string to a phrase like in your example, but recently the package has gained a lot of generic method implementations for various classes like phrase, making them much easier to concatenate, repeat, etc.- as long as you make things of the right class first. Unfortunately, in your example this wouldn't work currently (as_phrase() is not smart enough) unless you cheated and forced the bar string to a phrase like the following.

x1 <- p("a", 1)
x2 <- structure('\\bar "|."', class = "phrase")
c(x1, x2)

But generally speaking it is really nice to be able to use generic methods where possible. If I can create less need over time for pc that will be a good thing. There will probably always be some convenience to it though.
Regards

from tabr.

Thank you Matt for your thoughts on this (and of course for the change in pc and pn).

Following up on your ideas I created a new blog entry with my experiences.

Summary:

• a request to accept "s" as an alternative for "r" in notes. I will create a separate issue for this
• an alternative for inserting (more general things than) bar ends
• a confession that I have only limited insight of the possibilities of tabr

Regards Han

from tabr.

Here are some time-related functions based on beats and measures. I will probably add more; these are pretty new and limited.

I like your idea of some kind of hook character used for inserting arbitrary text in phrases subsequently. This gives the user a lot more power. I will give this some thought. Adding or changing syntax can be a lot of work because of the potential side effects it can have throughout the functions in the package. When I recently added support for LilyPond-style note articulations this required more generalization of the behavior of the hyphen character in note info strings and in total it took me 7 hours to rework all the affected package code. This kind of change could be challenging because it means I need the ability to carry along some special hook or placeholder character without ever changing it, but always ignoring it, no matter what function performs some kind of transformation on the data. It also is strictly applicable to phrases (for LilyPond transcription) and would otherwise serve no purpose in noteworthy, noteinfo, or music objects. Perhaps the best place to specify the timesteps at which hooks are placed is with an argument in the call to phrase itself at the moment of phrase creation. I do want to keep the "noise" of LilyPond/transcription-specific use cases isolated to the phrase-track-score-render_* pipeline of functions if possible.

from tabr.