Completely separating notation from output logic
I'm trying to develop an include file with Scheme functions that will
allow notation files to contain nothing more than a header block and
music for one or more voices. Below is what I've got so far. What
I'm finding is that I can easily define a music function that appends
voices to a list and a corresponding function that retrieves them in
order within the context of a \score block. What doesn't work so
far is trying to generate the score block itself. I get an error
complaining about Unexpected \score. I'm assuming that's because a
\score isn't a music type. Is that right? Also, what I'm doing now
feels a bit hackish. Is there a more elegant approach?
Thanks,
Mike
%% To go into an include file, e.g. myinclude.ly ...
\version 2.12.3
%% Append music for one voice to a list.
appendVoice = #(define-music-function (P L ml m) (list? ly:music?)
(append! ml m))
%% Insert a voice in a score block
newvoice = #(define-music-function (P L M) (ly:music?)
#{
\new Voice $M
#})
%% Insert list of voices to a score block
allvoices = #(define-music-function (P L mlist) (list?)
(if (eq? mlist '())
#{ #}
(let ((v (car mlist)))
#{
\newvoice $v
#}
(allvoices (cdr mlist)
%% Generate a score block containing voices from a list.
thescore = #(define-music-function (P L mlist) (list?)
#{
\score {
\allvoices \myvoices
}
#})
%% ---
%% To go into a notation file
%\include myinclude.ly
#(define myvoices '())
\appendVoice \myvoices \relative c' { e f g a }
\appendVoice \myvoices \relative c' { c d e f }
%% THIS WORKS
\score {
\allvoices \myvoices
}
%% THIS DOES NOT
\thescore \myvoices
Cheers,
Mike
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Completely separating notation from output logic
On 1/3/11 1:01 PM, Michael Ellis michael.f.el...@gmail.com wrote: I'm trying to develop an include file with Scheme functions that will allow notation files to contain nothing more than a header block and music for one or more voices. Personally, I think you're going about this exactly backwards. Rather than including the score in a notation file, I think you should include the notation in a score file. That way, you can easily reuse the notation in multiple places. Below is what I've got so far. What I'm finding is that I can easily define a music function that appends voices to a list and a corresponding function that retrieves them in order within the context of a \score block. What doesn't work so far is trying to generate the score block itself. I get an error complaining about Unexpected \score. I'm assuming that's because a \score isn't a music type. Is that right? I think that's right. The Score (capital S) context is created automatically by LilyPond. We used to use \new Score, but we have eliminated that. I think that the cleanest way to do this is to have a notation file for each of the pieces of notation, and then have a score file that includes all of the notation files. HTH, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Completely separating notation from output logic
Thanks, Carl. I probably should have included some background
information. If I had only one piece of music to worry about, I'd do
it exactly as you suggest. Problem is I've got 404 Bach Chorales on
the Solfege Resources site and expect to eventually have hundreds or
even thousands more from other composers whose work is public domain.
Each one has a separate \book { \score {} \score{} } block to
generate pdf + midi files for all parts together plus each part
individually. There are also some mildly hairy Scheme functions that
invoke the NoteNames engraver and use quoteDuring to add fermatas from
the Soprano part to individual parts.
Having all the output logic in a single include file would:
1. Allow me to define a dead-simple format for contributions of
other public domain transcriptions, e.g
\include common.ly
\head { }
#(define voices '())
\appendVoice \voices { ... } % e.g. Soprano
\appendVoice \voices { ... ) % e.g. Alto
...
\theOutput \voices % all the files for all the voices
2. Make it easy to improve who wanted a to change the formatting
by only requiring them to modify the common.ly
3. Eliminate the need for (or at least greatly simplify) external
scripts to rebuild the world after changes.
I'm not sure how I could do all that by including named files in score files.
Cheers,
Mike
On Mon, Jan 3, 2011 at 5:04 PM, Carl Sorensen c_soren...@byu.edu wrote:
Personally, I think you're going about this exactly backwards. Rather than
including the score in a notation file, I think you should include the
notation in a score file. That way, you can easily reuse the notation in
multiple places.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Completely separating notation from output logic
On Mon, Jan 3, 2011 at 5:41 PM, Michael Ellis michael.f.el...@gmail.com wrote: 2. Make it easy to improve who wanted a to change the formatting by only requiring them to modify the common.ly Meant to say: 2. Make it easy for myself or users to improve the formatting ... ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Completely separating notation from output logic
On Mon, Jan 03, 2011 at 05:41:48PM -0500, Michael Ellis wrote: Thanks, Carl. I probably should have included some background information. If I had only one piece of music to worry about, I'd do it exactly as you suggest. Problem is I've got 404 Bach Chorales on the Solfege Resources site and expect to eventually have hundreds or even thousands more from other composers whose work is public domain. This has been solved a few times. Look in the mailing list archives, and/or look at Reinhold's orchestralily, etc. Personally, I'd just reinvent the wheel and generate score files with python, using some naming scheme for directories and files. But I'd do so knowing that this solution was stupidly reinventing the wheel. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Completely separating notation from output logic
Thanks Graham, I did use python to generate the first set of files
and, being fairly expert with it, python is always my weapon of
choice. The limitation I see in this case is trying to support a
minimal input format for contributors to use. I was able to make it
work for the Greentree files because MuseScore emitted voice name
variables with a recognizable pattern e.g. AAvoiceBA = \relative c''
{ and always ended the music with a closing } on a line by itself,
and so forth.
I don't want to burden contributors with anything that rigid and I
don't want to write a python parser for LilyPond syntax or even adapt
the one that comes with Frescobaldi. That would feel like hunting
flies with an elephant gun.
Hence the reluctant decision to handle it in Scheme. I did find a
thread from 2008 between Reinhold K., Han-Wen, and Nicolas S, but they
are operating with pretty high-level knowledge of Lily internals. It
would be nice to find a well-documented solution that didn't require
combing through the Lily sources. I'll keep looking. This can't be
that hard to do, right?
Cheers,
Mike
On Mon, Jan 3, 2011 at 9:44 PM, Graham Percival
gra...@percival-music.ca wrote:
On Mon, Jan 03, 2011 at 05:41:48PM -0500, Michael Ellis wrote:
Thanks, Carl. I probably should have included some background
information. If I had only one piece of music to worry about, I'd do
it exactly as you suggest. Problem is I've got 404 Bach Chorales on
the Solfege Resources site and expect to eventually have hundreds or
even thousands more from other composers whose work is public domain.
This has been solved a few times. Look in the mailing list
archives, and/or look at Reinhold's orchestralily, etc.
Personally, I'd just reinvent the wheel and generate score files
with python, using some naming scheme for directories and files.
But I'd do so knowing that this solution was stupidly reinventing
the wheel.
Cheers,
- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
