Optionally fill GridLY cells with rests

[uliska]

Currently GridLY fills empty cells with spacer rests.

For real-world use it would be good to have the option of filling with MultiMeasureRests instead.
I think it would be enough to enter one MultiMeasureRest of the respective duration.

[Cecca]

This can be easily addressed in gridSetSegmentTemplate, where you can set default music content for yet-to-be-filled cells.

For instance, to use multi measure rests in the ly/gridly/usage-examples/example.ly you can just replace (for all the segments you like)

\gridSetSegmentTemplate 3
{
  s1 | s1 |
}

with

\gridSetSegmentTemplate 3
{
  R1*2 |
}

to get something like

[uliska]

Now, after doing the first real-world work with GridLY I'd repeat that wish. One nice use case of the grid approach is having the output different for cells that just haven't been entered and cells where the instrument actually pauses. The approach for that in "Das trunkne Lied" is the following:

• Have the cells prepared with spacer rests
• When the instrument pauses: delete the file
• in that case let the grid fill the cell with MultiMeasure rests

This way one can always distinguish unfinished input from cells that are intended to be empty.
Using GridLY I now do the following:

• I have one file called empty-segments, which contains music variables for all the segments, defining their structure with \time commands and spacer rests.
• I have one function (read here) that reads all those variables and uses \setSegmentTemplate to fill the templates with MultiMeasureRests of the length of the music variable.
• The effect of this is that the segment template is filled with MultiMeasureRests, while these are "shadowed" by generated files with spacer rests. So initially the output will have spacer rests, but when an input file is deleted the template with the real rests will become "visible".

I think this use case is interesting enough to be added to the core of GridLY. Mainly because the very idea of a system like GridLY is to handle larger projects where it is no good idea to "replace (for all the segments you like)".

I think of an option in the \with {} block that makes the function convert the music input to a #(mmrest-of-length) before assigning.

[Cecca]

OK, now I get your objection, but I think it is something strictly related to the fact that GridLY has been introduced after most of the work was already done in "Das trunkne Lied", when the workflow was already well established.

The workflow with GridLY as I intend it is something like:

• Have yet-to-be-entered cells rendered with spacer rests (if you set so in the template for the cell)
• All the cells will need to be defined in the end. So, even if you only have rests in that cell, the cell should be defined anyway.

This has the advantage of not being tied to file manipulation, but has the drawback of requiring a cell definition for all the cells. Since my background is mostly in choral music, this was not an issue, but I now see that in orchestral scores this can require a lot of cells filled with only multi-measure rests.

Using GridLY I now do the following:

• I have one file called empty-segments, which contains music variables for all the segments, defining their structure with \time commands and spacer rests.
• I have one function (read here) that reads all those variables and uses \setSegmentTemplate to fill the templates with MultiMeasureRests of the length of the music variable.
• The effect of this is that the segment template is filled with MultiMeasureRests, while these are "shadowed" by generated files with spacer rests. So initially the output will have spacer rests, but when an input file is deleted the template with the real rests will become "visible".

OK, but this is because you already had an empty-segments file in place, so it makes sense that you use it to define the templates. However gridly is intended to be used the other way around: first the grid templates are defined and then the structure is defined in a part. For instance, in "la bomba" I have a file defining the templates and a file defining the structure, like tempo changes and so on.
Anyway, I think that for your project this was the most reasonable thing to do, given that you had all that work already in place.

---

I agree with you that having to explicitly define each cell even if it contains only multi measure rests is a pain. So some sort of automation is needed.

I think of an option in the \with {} block that makes the function convert the music input to a #(mmrest-of-length) before assigning.

I'd like to keep the interface to gridPutMusic small. So, instead of an option in the with block I'd prefer a small helper function, say gridPutRests (for symmetry with gridPutMusic). This way one can write

\gridPutRests "horn" 4

to fill with multi measure rests the fourth cell of the "horn" part. The length of the rest is taken from the template. One could then easily create a single file defining all the pause cells.

What do you think about this?

[uliska]

OK, now I get your objection, but I think it is something strictly related to the fact that GridLY has been introduced after most of the work was already done in "Das trunkne Lied", when the workflow was already well established.

Not really. It is related to the wish that cells can be either empty or filled with rests to distinguish between unfinished work and pausing music.

I see your motivation to avoid pre-generating input files, and I agree that this is a good idea. However, I would probably do it again, as the pregeneration is also done to provide my contributors with a consistent template to work in.

I think there would be a reasonably simple solution to fulfil both needs:

• a cell has a property like e.g. is-empty that tells us that it isn't intended to have any music in it (i.e. the instrument/voice is pausing)
• a cell has a function to return a #(mmrest-of-length length-of-the-template-music)
• \getGridMusic does the following:
  • if a cell is not defined: return the template's content (or the error message)
  • if a cell is defined: return its music content
  • if a cell is defined and has the empty flag set: return the MMR (or the error message if the template isn't defined)

The advantage of this approach over a command that explicitly fills the cell with rests is that the length of the rest is only determined on calling time.

Finally create a new command, e.g. \gridSetEmptyCells that defines the given cells and sets them to empty. (We could check if the cell is already defined and print a warning - but I'm not 100% clear what should really happen then). The argument would be either a pair of part and a list of cell numbers or a list of these pairs:

\gridSetEmptyCells #'("soprano" . (4 6 7))
% or
\gridSetEmptyCells
#'(("soprano" . (4 6 7))
   ("alto" . (3 6 7)))
% extend the syntax by ranges:
\gridSetEmptyCells #'("soprano"  . (4 (6 . 12) 15))