make clean error
When I try to "make clean", I get this: make[1]: Entering directory `/home/lilypond/lilypond/mf' make[1]: *** No rule to make target `/home/lilypond/lilypond/buildscripts/./out/gen-emmentaler-scripts', needed by `out/emmentaler-26.dep'. Stop. make[1]: Leaving directory `/home/lilypond/lilypond/mf' make: *** [clean] Error 2 Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Incipits
Le 3 févr. 08 à 21:07, Till Rettig a écrit : Whow, this is really great. I guess from that base it is somehow simple to have also changing of notehead/flags etc styles possible -- and not to forget: for most socres of renaissance music the ligature-engraver will have to be added to the score and the ligature bracket engraver removed (which will have to be restored for the main score, where there are usually notated as brackets to indicate the original ligatures). My first idea was that the note head, clef, etc, styles and the engraver settings would be set in the \incipit functions: it would be up to the user to define a custom \incipit function based on the default one. But maybe, using an IncipitStaff context, which properties would be overridden in the score layout block, that could be done more easily. That's what I'll try. But there are some flaws in the instrument name hack appraoch. The notes are not aligned (which may or may not be a problem), and the alignment of the incipit with the staff is manually tuned (hence the use of two \incipit and \vocalIncipit functions is the example). nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Incipits
Whow, this is really great. I guess from that base it is somehow simple
to have also
changing of notehead/flags etc styles possible -- and not to forget: for
most socres
of renaissance music the ligature-engraver will have to be added to the
score and
the ligature bracket engraver removed (which will have to be restored
for the main
score, where there are usually notated as brackets to indicate the
original ligatures).
Esp. the spaces between the incipit and the starting bracket makes it
look really
good to me, in opposite to what most publishers do today (maybe this is
due to Sibelius,
which just isn't able...)
I will be a happy user!
Greetings
Till
Nicolas Sceaux schrieb:
Grr, I just wanted to simply print two different clefs at the
beginning of a score, and now I found myself trying to implement
full featured incipits, damnit!
I have something, based on the instrument name hack, which gives
the following result:
The score looks like:
\score {
\new StaffGroup <<
\new Staff <<
\set Staff.instrumentName = \markup Toto
\vocalIncipit { \clef "neomensural-c1" c'4 d' e' f' }
\lyricmode { do ré mi fa }
\new Voice = melody {
\clef "treble" c'4 d' e' f'
c'1
}
\lyricsto melody \new Lyrics \lyricmode { do re mi fa }
>>
\new Staff <<
\set Staff.instrumentName = \markup Titi
\incipit { \clef "neomensural-c2" c'4 g c'2 }
{
\clef "alto" c'4 g c'2
c'1
}
>>
\new Staff <<
\set Staff.instrumentName = \markup Tutu
\incipit { \clef "neomensural-c3" c'4 g c'2 }
{
\clef "alto" c'4 g c'2
c'1
}
>>
>>
\layout {
indent = 5\cm
ragged-right = ##t
\context {
\Staff
\remove "Instrument_name_engraver"
\consists "Incipit_engraver"
}
}
}
Is it nearer to people expectations wrt to incipits?
nicolas
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Incipits
Nicolas Sceaux <[EMAIL PROTECTED]> writes: > Grr, I just wanted to simply print two different clefs at the > beginning of a score, and now I found myself trying to implement > full featured incipits, damnit! > > I have something, based on the instrument name hack, which gives > the following result: [...] > Is it nearer to people expectations wrt to incipits? Quite nice in my non-expert opinion. Whether or not the syntax would warrant tweaking is out of my depth. As it stands, it looks reasonable, and the output appears appropriate. Certainly something that should go in after the experts vetted it. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Incipits
Le 3 févr. 08 à 02:04, Juergen Reuter a écrit :
However, I see a very important feature missing in this approach:
An incipit should (at least in my view) be thought of as the
beginning of a piece written in notation that comes close to the
autograph or first publishing. That is, the incipit actually starts
the music. Then, at some point (e.g. after the clef or after the
first note of each voice or after the first few notes), the music is
reset to its start, the notation switches to modern style, and
printing starts again, this time from the very beginning to the very
end.
In particular, as Laura points out, many people want to include one
or more notes in the incipit. More generally, virtually any music
expression could appear in an incipit -- it's just printed in an old-
fashioned style or otherwise coming much closer to the original.
Thus, the ideal behavior of an incipt engraver would be to ordinary
start printing the piece, using (for example) a mensural context and
the info from IncipitClef, IncipitSignature, and
IncipitTimeSignature. Then, when the InciptEngraver has done its
work, the music should rewind back to the very beginning, and
ordinary type setting should start.
A couple of weeks ago, I think I already posted the idea of having a
scheme function, say "\makeIncipit { }", that takes all of
the music as argument and creates from it another music expression
with the incipit. You could then say something like "\makeIncipt
{ } " to create the incipit, followed by the actual
music. However note, that currently it is not possible to implement
such a scheme function for several technical details, such as the
system start delimiter that would also have to be placed *after* the
incipit. Maybe with some more changes at your incipit engraver,
this engraver can be used to actually implement the "\makeIncipit"
scheme function. This is what I thought of when I used the word
"challenging". ;-)
Grr, I just wanted to simply print two different clefs at the
beginning of a score, and now I found myself trying to implement
full featured incipits, damnit!
I have something, based on the instrument name hack, which gives
the following result:
<>
The score looks like:
\score {
\new StaffGroup <<
\new Staff <<
\set Staff.instrumentName = \markup Toto
\vocalIncipit { \clef "neomensural-c1" c'4 d' e' f' }
\lyricmode { do ré mi fa }
\new Voice = melody {
\clef "treble" c'4 d' e' f'
c'1
}
\lyricsto melody \new Lyrics \lyricmode { do re mi fa }
>>
\new Staff <<
\set Staff.instrumentName = \markup Titi
\incipit { \clef "neomensural-c2" c'4 g c'2 }
{
\clef "alto" c'4 g c'2
c'1
}
>>
\new Staff <<
\set Staff.instrumentName = \markup Tutu
\incipit { \clef "neomensural-c3" c'4 g c'2 }
{
\clef "alto" c'4 g c'2
c'1
}
>>
>>
\layout {
indent = 5\cm
ragged-right = ##t
\context {
\Staff
\remove "Instrument_name_engraver"
\consists "Incipit_engraver"
}
}
}
Is it nearer to people expectations wrt to incipits?
nicolas
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] first-clef property
Am Sonntag, 3. Februar 2008 schrieb Juergen Reuter: > Thus, the ideal behavior of an incipt engraver would be to ordinary start > printing the piece, using (for example) a mensural context and the info > from IncipitClef, IncipitSignature, and IncipitTimeSignature. Then, when > the InciptEngraver has done its work, the music should rewind back to the > very beginning, and ordinary type setting should start. Exactly. The only difference is that the system start bracket should not be in front of the incipit, but between the incipit and the real start of the system, and that the incipit is often written in smaller notes... Cheers, Reinhold -- -- Reinhold Kainhofer, Vienna University of Technology, Austria email: [EMAIL PROTECTED], http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: info documentation with images?
Le jeudi 31 janvier 2008 à 17:59 +0100, Jan Nieuwenhuizen a écrit :
> David Kastrup writes:
>
> > Actually, current documentation. I think it is close to impossible for
> > the average developer/user to guess that he is supposed to say
> >
> > make doc info out=www
> >
> > I don't think I am alone in being completely flustered by this
> > non-information: the standard Debian info packages don't come with
> > images, either.
Info docs miss images in Lily 2.10.33 Fedora 8 RPM too.
When installing info docs with images with "make web-install" with /usr
or /usr/local as a configure prefix, info files and images are written
in /usr/[local/]share/info/lilypond/. The dir entries
(lilypond/lilypond, lilypond/music-glossary, etc.) are correct, but
cross-references between different LilyPond Info documents don't work,
because both Emacs and Info standalone expect to open
usr/[local/]share/info/lilypond-foo.info when reading a cross-reference
"*note (lilypond-foo)Node_xyz::.".
We could fix this with conditional macro definitions in macros.itexi
with "@ifset info-images"/"@ifclear info-images" blocks, and call
makeinfo with a flag "-dinfo-images", but that's quite messy.
I rather suggest putting .info* files in /usr/[local/]share/info/, and
images in a lilypond/ subdirectory. This requires changing
lilypond-book a little, so it says
@image{lilypond/lily-354d7a5697,,,[image of music],}
instead of
@image{lily-354d7a5697,,,[image of music],}
Maybe "lilypond/" should be defined with a "--info-images-subdir"
lp-book command line option.
The latter approach has an important advantage: the Info files would
always be installed in the same location, whether they have images or
not. May I go ahead with this?
> Yes, the whole doc/info/web out=www targets and options have always been
> a bit of a mess. It has not gotten any easier now with online and
> offline web doc building.
>
> I have made `make help' now print:
>
> ..
> doc update all documentation (without images)
> cvs-clean also remove out directories and generated files
> infoupdate info docs (without images)
> info out=www update info docs with images
>
> but I guess that a some other new targets (offline, online web)
> are missing too. We may want to add this to a more prominent
> place in INSTALL.
I documented offline and online web targets in INSTALL.
BTW it would be very cool to distribute Info docs with GUB, and add
support in the installation script for installing them and other stuff
like Emacs and Vim modes and HTML/PDF docs in standard locations
(/usr[/local]/... or /home/...). I may have a look at this, but not
immediately, I'm already too busy.
Cheers,
John
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
