Hi Karl,
> Everybody, don't cc me, I'm on the list and don't want double mails.
I’ll do my best to remember that… but it’s a big list, and the standard is
Reply All.
> You need to include the lyrics somehow, perhaps call it
> \makeVocalScore ... or make the argument a string to be parsed,
> then you could include syntax to differntiate between "violin viola"
> and "alt bass". E.g.
> vocals could be "[ Sop Alt Ten Bas ]",
> a grandstaff could be "{ Via Vib }", etc.
>
> But basasically you want:
> \makeScore #’( tenor )
>
> to mean the same thing as something like:
> score { <<
> \new ChoirStaff <<
> \new Staff ...
> \lyricsto ...
>>>
>>> }
>
> And I think that would be possible to accomplish, but the downside
> is that when you want to change the layout, you still need to do
> the nitty gritty details, or make another function/template_equivalent.
> Or some convenience tools to make such functions.
> Would that be accepable ?
Absolutely. Again, most engravers I intersect with either don’t want to use
Lilypond because “there’s too much coding”, or use Lilypond and complain that
“there’s too much coding [to make a simple score]”.
If I had the following two things, I could probably convert a half-dozen of my
colleagues (who already marvel at the output I get) to using Lilypond for lead
sheets:
1. a \makeLeadSheet function that Did The Right Thing™ (modulo 80/20 rule, of
course!); and
2. a stylesheet system that allowed me to [potentially] quickly generate each
colleague their own housestyle.ily stylesheet.
> Unfortunately name + number will not work, lilypond would interpret
> the number as a duration.
It’s pseudo-code, Karl. ;)
> Ok, then you want something that only depends on a lilypond installation.
Correct.
> . just the lilypond installation
> . just lilypond and/or scheme code
Correct.
Now, I recognize that such a framework might require modification to the
non-Lilypond-non-Scheme part of the codebase (e.g., the C++ core), but the END
USER should never see any of that — and optimally shouldn’t need to know any
Scheme.
> If you accept frescobaldi then what you wrote above is not true, since
> frescobaldi is a non-Lilypond code/app.
I’m not sure how many different ways I can say the same thing: My “perfect
world scenario” is a situation where the end-user shouldn’t have to see or
interact with anything except their own note-code, an \include file or two, and
a pretty powerful function (or *VERY LIMITED* set of functionS).
> Also any command line tool could
> be hidden behind a graphical gui if that is the deciding part.
> I cannot help if what you write is confusing and contains contradictions.
Ditto.
> We don't really know what an "average Lilypond user" is.
You like to bike-shed, don’t you? ;)
Thanks,
Kieren.
__________________________________________________
My work day may look different than your work day. Please do not feel obligated
to read or respond to this email outside of your normal working hours.
