You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When thinking about an interface to MEI I came across the idea of using GridLY to create a compatible input structure to map LilyPond's input to MEI's (mostly) measure-based encoding structure. Having a grid with each cell representing one measure of a part comes very close to MEI's concept.
For this to be at least viable we need a non-intrusive interface to enter music measure-based. There is the \parallelMusic approach but I'm not sure that is a good idea in this context.
I thought about a command that takes a list of music expressions and stores them in subsequent cells of the grid. Then I thought about using barchecks for that cause. This could even be realized by modifying the existing \gridPutMusic with an extra flag-style option. Then barchecks in the music option would be parsed and used to split the music expression in consecutive items to be stored in the grid's cells.
The text was updated successfully, but these errors were encountered:
I now see that this would be a nice addition even without the concrete "measure" restriction. I suggest a command to enter music in a sequence of cells, one horizontally and one vertically. The horizontal one could (maybe) even take care of necessary opening/closing contents.
The idea is to provide a single ly:music? argument and split that into chunks using barchecks.
shows that this should be possible. These chunks are then stored to consecutive cells, starting from a given cell. A direction parameter could decide about the direction (hor/vert).
In that situation it doesn't matter whether the cells hold single measures or not, it would nevertheless be a way to conveniently (and LilyPond-ishly) enter consecutive cell contents. And no, this doesn't compromise the library's idea.
When entering consecutive cells in a vertical fashion the command could have an optional property that specifies a list of "row" contexts. Otherwise the user would have to supply empty elements for the contexts that currently don't play. This is a) tedious, b) error-prone and c) pretty impractical when copying from a frenched score. It should probably be easier to write
\gridPutMusicCells\with {
start =28% measure number or column index
direction =#'VERT
rows =#'("fluteI""fluteII""clarinetII")
music = { c''1| a''2 g'' | e''1 }
}
than having to use
music = { c''1| a''2 g'' | R1| R1| R1| e''1 }
and "count" the empty contexts for the oboes and clarinet 1.
This issue is just for my own note-keeping.
When thinking about an interface to MEI I came across the idea of using GridLY to create a compatible input structure to map LilyPond's input to MEI's (mostly) measure-based encoding structure. Having a grid with each cell representing one measure of a part comes very close to MEI's concept.
For this to be at least viable we need a non-intrusive interface to enter music measure-based. There is the
\parallelMusic
approach but I'm not sure that is a good idea in this context.I thought about a command that takes a list of music expressions and stores them in subsequent cells of the grid. Then I thought about using barchecks for that cause. This could even be realized by modifying the existing
\gridPutMusic
with an extra flag-style option. Then barchecks in themusic
option would be parsed and used to split the music expression in consecutive items to be stored in the grid's cells.The text was updated successfully, but these errors were encountered: