Re: pmx puzzler

2000-01-24 Thread Werner Icking

 Date: Fri, 21 Jan 2000 15:14:06 +
 From: David Bobroff [EMAIL PROTECTED]

[...]
 %%%PMX FILE%%%
 % Canzon V (1615)
 7 7 4 4 4 4 0 0
 4 12 16 .1
 Trumpet 7
[...]

The first line of the PMX file is already dangerous, if you want to
use scor2prt with this PMX-file.

If scor2prt detects "%%" at the beginning of a line it eats the next line.

So if you want to feed a PMX-file to scor2prt don't start any line 
with "%%", "%!" or "%i" where i is any integer from 0 to infinite :-)

The exception from this rule is if you do it intentionally!

This brings you to the sure side.

-- Werner




Re: pmx puzzler

2000-01-22 Thread Rose A Pruiksma


Mr. Bobroff--

The problem you describe has been covered on this list several times; the
phantom figure, in this case, just toggles pmx (as far as I understand)
between different vertical spacing calculations, one of which gives the
'wrong' result.

To keep pmx from calculating 'bad' values for staff spacing on alternate
pages, add the inline tex beginning \\let near the beginning of the file
as

Giovanni Gabrieli
%Ar K+3-1
\\let\interstaffsav\interstaff\def\interstaff#1{}\interstaffsav{8}\
rp rp rp g43 g8 g g2 /
rp rp rp rp /

You may want to adjust the parameter to \interstaffsav, or add the special
scor2prt quasi-comment characters to get a result you like.  This gave a
pleasing layout on my machine (A4 paper, PMX 2.0, Linux).

:laird pruiksma



RE: pmx puzzler

2000-01-22 Thread Simons, Don

:laird Pruiksma wrote

To keep pmx from calculating 'bad' values for staff spacing on alternate
pages, add the inline tex beginning \\let near the beginning of the file
as

Giovanni Gabrieli
%Ar K+3-1
\\let\interstaffsav\interstaff\def\interstaff#1{}\interstaffsav{8}\
rp rp rp g43 g8 g g2 /
rp rp rp rp /

This is a possible solution but there's another one which, IMHO, is better
simply because it does not require inline TeX.  Recognizing the weakness of
PMX's vertical spacing algorithms, a while ago I introduced the pmx command
"AI[decimal number]", and that's the way to go here.  Zap the extra "-", put
"AI.95" before the first input block, and there you go.

Details, for those who care: In PMX the critical adjustable parameter for
vertical spacing in \interstaff, which controls the vertical distance from
one staff to the next within a system. (\stafftopmarg and \staffbotmarg are
always set to 0 when there is more than one staff per system, and more than
some minimum number of systems per page). By issuing \eject at the end of
each page, the left-over available vertical space is distributed between the
systems.  There should always be some left-over vertical space, but PMX
sometimes falls down, computing a value of \interstaff that is too big to
leave any.  When that happens, the last system will spill over onto an added
page. Apparently, the extra "-" makes PMX think there are figures in the
score, even though it's not in staff #1 (?!).  Anyhow, what this does is
reserve some extra vertical space for every system, causing \interstaff to
be set to a smaller value than otherwise.  Without the "-", \interstaff is
larger, enough so that the last system on a page rolls over to the next.
The "AI" command lets the use specify a factor to be applied to \interstaff.
By reducing the internally computed \interstaff this way, you can squeeze
things back together so they fit on pages as you want.

--Don Simons



Re: pmx puzzler

2000-01-21 Thread Christian Mondrup

David Bobroff wrote:

 Greetings,

 I have a very strange thing happening with a .pmx file.  I have coded a
 Gabrieli Canzon for transposition for a trumpet ensemble.  As usual there
 were some typos and I processed the file after every block of input to sort
 out most of them.  One mistake did not make its presence known until I had
 run scor2prt.  At that point one of the parts showed an extraneous small
 flat sign near a note head.  I tracked it down and it was being caused by a
 dash (-) where there should not have been one.  When I went back to the
 full score *.pmx file to eliminate it I got strange behavior in the output.

 If I don't have this extra dash then the page layout goes crazy.  I have
 npages set to 4 and nsyst set to 12 which should give me three systems per
 page.  It does so BUT ONLY IF I HAVE THIS EXTRA DASH.  If I remove it I get
 no more than two systems per page and it spreads out over eight pages.
 This is reproducable behavior.  I can remove the dash and the layout goes
 haywire.  If I then put it back, all is well.

 I'm running the *nix 2.0.0 version on a RedHat 6.0 system.

 The pmx input file follows.  Look in the input block marked % bar 5-8.
 There is a double line of %%%.  In the first line of %% it says "the
 dash below this gap" and there is a gap just under that text between a pair
 of  .  The dash is just below that gap.

 What's going on?

 % bar 1-4
 Tt
 CANZON V
 (1615)
 Tc
 Giovanni Gabrieli
 %Ar K+3-1
 rp rp rp g43 g8 g g2 /
 rp rp rp rp
 /
 rp rp r2 g44 g8 g g2 r2 /
 rp rp g44 g8 g g2 r2 g4 g8 g /
 c45 c8 c c2 r8 c
 b e d c b a g f e d [ cd d1 ed8 f1 ] g4 d e d /
 rp r2 g45 g8 g g2 r8 c- b e
 d c b a gd a1 b c d b /

you have a surplus 16'th note in the last voice 


 r2 g45 g8 g g4 r8 c- b e d c b a g f e4 r8 c+ b e d
 c b a g4 /
 % bar 5-8
 r2 r8 c b e d c b a g f e d [ cd d1 ed8 f1 ] gd4 c8-
 g+ c b e d c b a /
 %%the dash below this gap%%
 %%
 %%
 c44 c8 c c4 r8 c b e d c b a g f [ e d cd d1 ] ed8 f1 g4 s
 -  g8 s c- g+ c b e d c /
 g4 g8 g g2 s g s r4 r8 d e f g4 e r g g8 g g4 r
 /
 g2 r4 r1 g g a b8 g r4 r2 r2 g4 g8 g g2 r4 r1 g g a /
 c2  r1 g1+ g a b8 g
 r1 g g a b8 c d d- e f g4 e r8 c+ b e d1 g- g a b8 c d g- r4 /
 c45 r1 c c d
 e8 c r4 r8 g+ g g g2 r8 g g g g4 r8 c- b e d1 g- g a b8 g g4+ s /
 r1 c1 c d
 e8 c r g+ g g g2 r8 g g g g4 r8 c8- b e d1 g- g a b8 g r4 r1 g g a b8 c /
 %

I can't say for sure whether the above mentioned extra note is the cause of
your problem, maybe it is. But if you have more than one measure per input
block I would HIGHLY recommend using barlines ! It is terribly difficult
keeping the survey over the music without them, and you risk - as in this case
- to enter erroneous notes.

If you quote larger portions of code directly in your email you can't be sure
of how the line breaks come out at the receivers. You should compact you code
(e.g. using zip) and attach it instead. Then it's much easier for the receivers
to handle it.

Regards
--
Christian Mondrup, Computer Programmer
Scandiatransplant, Skejby Hospital, University Hospital of Aarhus
Brendstrupgaardsvej, DK 8200 Aarhus N, Denmark
Phone: +45 89 49 53 01




RE: pmx puzzler

2000-01-21 Thread Simons, Don

Christian Mondrup wrote

David Bobroff wrote:
One mistake did not make its presence known until I had
 run scor2prt.  At that point one of the parts showed an extraneous small
 flat sign near a note head.  I tracked it down and it was being caused by
a
 dash (-) where there should not have been one.  When I went back to the
 full score *.pmx file to eliminate it I got strange behavior in the
output.

 If I don't have this extra dash then the page layout goes crazy.

Because of the line-folding that did occur in the original posting, I'd
rather not spend time trying to untangle the pmx file at this point. But a
"-" alone in staff #1 will cause a "flat" as a figure below the  staff. And,
if there are any figures at all in the score, PMX uses a different algorithm
for calculating vertical spacing.  So if the extraneous "-" was the only
figure in the score, it is not a surprise that the page layout changes when
it is removed. 

If you quote larger portions of code directly in your email you can't be
sure
of how the line breaks come out at the receivers. You should compact you
code
(e.g. using zip) and attach it instead. Then it's much easier for the
receivers
to handle it.

I cannot recall the policy on attachments in the mutex list, but some
mailing lists discourage them.  In case Werner tells us not to include
attachments in postings, there are two other possible approaches I would
recommend for transmitting pmx files:

1. (Always best) Try to distill the pmx file down to the absolute minimum
that still exhibits the problem. This could greatly ease the analysis, as I
often have to do that myself to isolate the problem.  It's then OK to
include the reduced file in a posting, but do be very sure there are no
lines longer than about 60 characters.

2. If there's a good reason to include a longer file, put it on an anonymous
FTP site somewhere, or mail it privately.

So if you're still having trouble with this particular file, I'll be glad to
help; please use one of the suggested methods for transmitting it.

--Don Simons