PS failure with 1.6.6
Hello-- Having just downloaded and compiled the 1.6.6 sourcecode, I ran ly2dvi -P on an .ly sourcefile without error messages and got a surprise when I tried to view the results with xdvi. It loaded with this error message: "Cannot find PostScript file for inclusion in document: music-drawing-routines.ps" The .ps file produced by the same ly2dvi run loaded perfectly with gv. The same thing happens with all my .ly sourcefiles. Is there a diagnostic I can run to track down the problem? This did not happen with 1.6.5, and I was careful to run the font cleaning script after installation. Thank you, my friends. Carter -- +-+ |Carter Brey ([EMAIL PROTECTED])| +-+ Homepage: http://www.nyplive.org/music/orchestra/index.cfm?page=profile&personNum=7 All I can think of is a platter of organic PRUNE CRISPS being trampled by an army of swarthy, Italian LOUNGE SINGERS ... 9:44am up 3 days, 23:57, 5 users, load average: 0.06, 0.01, 0.00 ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: tempo markings
Graham Percival wrote:
On Fri, 25 Oct 2002 10:30:06 -0700
Paul Scott <[EMAIL PROTECTED]> wrote:
For a simple piece with score and parts how do I cause the tempo marking
to appear only at once above the top part in the score and and once at
the beginning of each part. This will be a fairly standard marking like:
AFAIK, there is no easy good way of doing this. I've been thinking about
requesting this feature for a while.
Actually your last two solutions sound like they have possibilities.
Possibly something from this could be added to the docs when you have
time. When I get clearer on this I'll post my solution. Of course this
also needs to work anywhere else in the score.
where I do know how to create ' = 100' as per the manual.
Text markup, IIRC. It's in one of the "text" sections in the reference manual.
As I said I found that one:
"One practical application of complicated markup is to fake a metronome
marking:"
even though I intend to dig further into how those defines work.
So far I put it in the first part and it, of course, appeared on the
score and on the first part and of course not on the other parts.
Three options:
- Place a mark (see the reference manual) in every single part of your piece.
Print parts. Then go back and comment out the marks in all parts apart from
the first one, then print a score.
That sounds very awkward for a full orchestral score. (Not for me in
this case but for others).
- use something like \header {meter="Allegro (quarter = 120)"
That has possibilities and might solve another problem. I'm going to
post a question or two about vertical spacing when I get a chance. My
tempo marking is too close to the notes right now.
- define a "tempopart" part which looks like this:
tempopart = \notes { s1^#(note (something "= 120) see-refman) }
In your parts, include both the actual part and tempopart.
\context Staff < \violinpart \tempopart>
In the full score, only include the \tempopart in the first staff.
That sounds more straight forward. I'll work on that.
I've done all three of them, and they all have disadvantages.
What are the disadvantages of the last one.
Thanks very much,
Paul
___
Lilypond-user mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: HaraKiriStaffContext question
On Sat, 26 Oct 2002 01:37:47 +0200 Rune Zedeler <[EMAIL PROTECTED]> wrote: > Graham Percival wrote: > > One of these days I'll add a note to HaraKiri refman that empty lyrics > > don't count as empty bars. > > A Much Better (tm) solution would be to add a property telling whether > to look at lyrics when determining if a measure is empty. Probably. Are you volunteering? I don't code, and I've never used lyrics. My intention is to help out by editing documentation and doing odd documentation jobs. When difficulties arise and are solved on the maillists, I try to add the solution to the docs (although I'm a bit behind on that). As Jan or Han said a while ago, there are Bugs (Lilypond's behaviour doesn't match with what the docs say it should do) and Problems (Lilypond doesn't do something). My goal is to eliminate Bugs by documenting things. :) Cheers, - Graham ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: HaraKiriStaffContext question
Graham Percival wrote: One of these days I'll add a note to HaraKiri refman that empty lyrics don't count as empty bars. A Much Better (tm) solution would be to add a property telling whether to look at lyrics when determining if a measure is empty. This would also solve the "lyrics as chords hari-kiri"-problem. -Rune ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: HaraKiriStaffContext question
On Tue, 22 Oct 2002 23:44:08 -0400
Jule Slootbeek <[EMAIL PROTECTED]> wrote:
> yeah i forgot the includes, sorry, here they are, i'm using 1.6.0 on
> Mac OS X
In the future, please include *all* files necessary to compile the
example -- I had already deleted your previous email, so I had to find
dngg.ly in the web archives. In addition, don't use subdirectories (the
\include "notes/tenor.ly") when sending stuff. When I investigate
stuff, I save the ly files in my ~/tmp and then compile it. I don't
want to mess around making subdirectories.
The problem is that you have lyrics in the beginning. Comment out the
\repeat { _2.*7 } lines in your voices. In the score, do this:
(example)
\context Staff = soprano
<
\global
\clef treble
\property Staff.instrument = "Soprano "
\property Staff.midiInstrument = "flute"
\sopranoNotes
\notes { R2.*7
\context Lyrics = sopranoLyrics
\sopranoLyrics
}
>
HaraKiri now behaves properly.
One of these days I'll add a note to HaraKiri refman that empty lyrics
don't count as empty bars.
Cheers,
- Graham
___
Lilypond-user mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: tempo markings
On Fri, 25 Oct 2002 10:30:06 -0700
Paul Scott <[EMAIL PROTECTED]> wrote:
> For a simple piece with score and parts how do I cause the tempo marking
> to appear only at once above the top part in the score and and once at
> the beginning of each part. This will be a fairly standard marking like:
AFAIK, there is no easy good way of doing this. I've been thinking about
requesting this feature for a while.
> where I do know how to create ' = 100' as per the manual.
Text markup, IIRC. It's in one of the "text" sections in the reference manual.
> So far I put it in the first part and it, of course, appeared on the
> score and on the first part and of course not on the other parts.
Three options:
- Place a mark (see the reference manual) in every single part of your piece.
Print parts. Then go back and comment out the marks in all parts apart from
the first one, then print a score.
- use something like \header {meter="Allegro (quarter = 120)"
- define a "tempopart" part which looks like this:
tempopart = \notes { s1^#(note (something "= 120) see-refman) }
In your parts, include both the actual part and tempopart.
\context Staff < \violinpart \tempopart>
In the full score, only include the \tempopart in the first staff.
I've done all three of them, and they all have disadvantages.
HTH,
- Graham
___
Lilypond-user mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-user
tempo markings
Hi, For a simple piece with score and parts how do I cause the tempo marking to appear only at once above the top part in the score and and once at the beginning of each part. This will be a fairly standard marking like: Allegro = 120 where I do know how to create ' = 100' as per the manual. So far I put it in the first part and it, of course, appeared on the score and on the first part and of course not on the other parts. TIA, Paul Scott ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: common rests between two voices in one staff
Here's a third to answer your request. Take a look at
\partcombine, see
http://lilypond.org/stable/Documentation/user/out-www/lilypond/Automatic-part-combining.html
/Mats
> I am just doing some SATB pieces and I wonder if there is a way
> to share common rests between the two voices of one staff.
>
> The default behaviour for something like the following is that there
> are two rests generated, one typeset above the other.
>
> I know of the possibility to use s instead of r in one of the voices,
> but consider this more to be a workaround, then a solution because it
> makes voice extracts a little uncomfortable.
>
> thanks in advance for any comments and ideas
>
> --sample
> \score {
> \context Staff = women <
> \notes \context Voice = soprano {
> r1
> }
> \notes \context Voice = alto {
> r1
> }
> >
> }
> ---end sample---
>
>
>
> ___
> Lilypond-user mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/lilypond-user
___
Lilypond-user mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: common rests between two voices in one staff
On Fri, 25 Oct 2002 14:35:34 Klaus Zimmermann wrote: > I am just doing some SATB pieces and I wonder if there is a way > to share common rests between the two voices of one staff. > > The default behaviour for something like the following is that there > are two rests generated, one typeset above the other. > > I know of the possibility to use s instead of r in one of the voices, > but consider this more to be a workaround, then a solution because it > makes voice extracts a little uncomfortable. In that case, can't you put one on top of the other by giving them the same pitch? If that doesn't look right in an extracted part, you should probably have two anyway. If it looks ok in the parts, problem solved. DaveA ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: common rests between two voices in one staff
what i do is use a third voice for the rests
soprano =
\notes
{
c4 s c c
}
alto =
\notes
{
e4 s c c
}
rests =
\notes
{
s4 r s s
}
score{
\context Staff = women
<
\soprano
\rests
\alto
>
something along those lines works for me.
and of course if there's a rest in only one voice you can just put that
in the individual voice.
Jule
On Friday, Oct 25, 2002, at 10:35 US/Eastern, Klaus Zimmermann wrote:
I am just doing some SATB pieces and I wonder if there is a way
to share common rests between the two voices of one staff.
The default behaviour for something like the following is that there
are two rests generated, one typeset above the other.
I know of the possibility to use s instead of r in one of the voices,
but consider this more to be a workaround, then a solution because it
makes voice extracts a little uncomfortable.
thanks in advance for any comments and ideas
--sample
\score {
\context Staff = women <
\notes \context Voice = soprano {
r1
}
\notes \context Voice = alto {
r1
}
>
}
---end sample---
___
Lilypond-user mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-user
Jule Slootbeek
[EMAIL PROTECTED]
___
Lilypond-user mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-user
common rests between two voices in one staff
I am just doing some SATB pieces and I wonder if there is a way
to share common rests between the two voices of one staff.
The default behaviour for something like the following is that there
are two rests generated, one typeset above the other.
I know of the possibility to use s instead of r in one of the voices,
but consider this more to be a workaround, then a solution because it
makes voice extracts a little uncomfortable.
thanks in advance for any comments and ideas
--sample
\score {
\context Staff = women <
\notes \context Voice = soprano {
r1
}
\notes \context Voice = alto {
r1
}
>
}
---end sample---
___
Lilypond-user mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: Persistent font problems
> dvipslist: > kdebug:search(feta-nummer8.vf) => > kdebug:search(feta-nummer8.720pk) => ./feta-nummer8.720pk > kdebug:search(feta16.vf) => > kdebug:search(feta16.720pk) => ./feta16.720pk > kdebug:search(feta-braces4.vf) => > kdebug:search(feta-braces4.720pk) => ./feta-braces4.720pk Simply remove the feta* files in your working directory and everything should be fine. Apparently, you used paper16 in your file, that's why our instructions to look for feta20 didn't give any output. Strange that dvips and xdvi use different paths. > xdvilist: > kdebug:search(feta-braces4.vf) => > kdebug:search(feta-braces4.300pk) => /var/lib/texmf/pk/cx/feta-braces4.300pk > kdebug:search(feta-nummer8.vf) => > kdebug:search(feta-nummer8.300pk) => /var/lib/texmf/pk/cx/feta-nummer8.300pk > kdebug:search(feta16.vf) => > kdebug:search(feta16.300pk) => /var/lib/texmf/pk/cx/feta16.300pk > /Mats ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: Persistent font problems
I've attached the dvipslist and xdvilist. They appear to have different lists of fonts in them. I also printed the dvips generated file and it looks just like it does in gv (completely messed up). Russell. On Fri, 2002-10-25 at 02:58, Mats Bengtsson wrote: > Try the following: > > export KPATHSEA_DEBUG=32 > dvips yourfile.dvi 2>&1 | grep '=>' | grep feta > dvipslist > xdvi yourfile.dvi 2>&1 | grep '=>' | grep feta > xdvilist > > This will give you two log files with paths to the font files > that dvips and xdvi use. Normally, the same fonts should be > used by both dvips and xdvi. > > By the way, have you tried to print the PS file generated by > dvips. Some month ago, one guy on the list experienced font > problems when viewing the PS file in gv/ghostview/... but > they printed nicely on paper and when he sent an example file, > it looked completely normal here. > > /Mats > > > > > > > > ___ > Lilypond-user mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/lilypond-user > -- Russell Smiley [EMAIL PROTECTED] kdebug:search(feta-nummer8.vf) => kdebug:search(feta-nummer8.720pk) => ./feta-nummer8.720pk kdebug:search(feta16.vf) => kdebug:search(feta16.720pk) => ./feta16.720pk kdebug:search(feta-braces4.vf) => kdebug:search(feta-braces4.720pk) => ./feta-braces4.720pk kdebug:search(feta-braces4.vf) => kdebug:search(feta-braces4.300pk) => /var/lib/texmf/pk/cx/feta-braces4.300pk kdebug:search(feta-nummer8.vf) => kdebug:search(feta-nummer8.300pk) => /var/lib/texmf/pk/cx/feta-nummer8.300pk kdebug:search(feta16.vf) => kdebug:search(feta16.300pk) => /var/lib/texmf/pk/cx/feta16.300pk
Re: Persistent font problems
> You're correct. I just did a clean font. I viewed my example with xdvi > and tried "kpsewhich feta20.pk" again. No response again. Strange. > However I did notice that there is no font problem with xdvi (and the > rests are okay, they have also been a problem)...see the attached png. That's a good starting point! > > xdvi -v > xdvi version 22.05d-k Should be OK! > It seems the problem is the conversion from dvi to postscript. Perhaps I > am not using the correct tools to convert to postscript? > > If I use dvips to convert to ps I get the attached png > (badfont_dvips.png). A real mess. > > > dvips -v > This is dvips(k) 5.86 Copyright 1999 Radical Eye Software > > My example with just the rests and numbers broken in the previous email > used "ly2dvi -P -s papersize="letter" $^". > > Which tool should I be using? Evidently both ly2dvi and dvips are broken > somehow (or I'm not using them correctly). ly2dvi uses dvips. Try the following: export KPATHSEA_DEBUG=32 dvips yourfile.dvi 2>&1 | grep '=>' | grep feta > dvipslist xdvi yourfile.dvi 2>&1 | grep '=>' | grep feta > xdvilist This will give you two log files with paths to the font files that dvips and xdvi use. Normally, the same fonts should be used by both dvips and xdvi. By the way, have you tried to print the PS file generated by dvips. Some month ago, one guy on the list experienced font problems when viewing the PS file in gv/ghostview/... but they printed nicely on paper and when he sent an example file, it looked completely normal here. /Mats ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
