Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-04 Thread Johannes Gebauer
David W. Fenton wrote:
My point is that simple optimization (i.e., removing blank staves 
from a systen) should happen automatically if you have optimization 
turned on for the passage of music represented on a system (while I 
understand that Johannes has a use for optimization being stored in 
absolute systems, I think that's a different kind of issue that comes 
about because of the way one is forced to create parts in Finale -- 
if they were all stored in the same file instead of in separate 
files, his issue would likely go away, since you'd have a score 
layout and a part layout, all stored in a single file; but that's 
another issue where I think Finale is confusing and less than ideal).
In my case this has nothing to do with parts at all. The reason I need 
to optimize out parts which have got music in them has to do with 
doubling parts. For instance, in some situations the first and second 
violins play identical parts, and for space reasons I just want to show 
one of them, but the other one needs to have the music in it both for 
later part extraction but also because the decision to optimize out the 
second violin part is made at a later stage and needs to be reversible.

Johannes
--
http://www.musikmanufaktur.com
http://www.camerata-berolinensis.de
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-04 Thread Johannes Gebauer
David,
Optimization in Finale allows to remove blank staves _and_ makes the
vertical spacing of each system independent from the global setting. It
has *all* to do with the vertical spacing.
You can optimize without removing empty staves.
Unless I am missing something here it is you who hasn't understood the
concept of optimization in Finale. The meaning of the word in this
particular context is pretty much besides the point.
But if anything to optimize means to make individual staves more
optimal, and that could well mean increasing the space between staves.
Johannes
David W. Fenton wrote:
On 3 Mar 2005 at 17:28, Mark D Lew wrote:

It's just that I would have worded it to say that removal of 
empty staves is what needs to be separated from optimization.

The meaning of the word optimization would then be associated with 
something that is not remotely related to the concept the word 
represents.

You optimize in Finale in order to optimize the usage of space on 
the page, by eliminating blank staves, so you can fit more systems in 
fewer pages. This has *zilch* to do with vertical positioning of 
staves within systems.

So, I think you have a completely backwards conception of what 
optimization actually is -- optimization *is* removing blank 
staves, and the part that you use of it is something else entirely 
that has nothing to do with optimizing space on the page (though you 
might reduce spacing between staves in order to fit more systems on 
one page; but you could also *increase* spacing in order to avoid 
overlap of extreme elements, and that is the opposite of optimizing).

--
http://www.musikmanufaktur.com
http://www.camerata-berolinensis.de
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


RE: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-04 Thread jeffery
I appreciate all the feedback and ideas, everyone, thank you. I've worked
with 2005 for the last day now, and already see many dramatic improvements,
and appreciated the returned control over the end product. So it is back to
Finale for me.

I've also written a blog entry on this topic (Finale vs. Sibelius) on my
website, would be interested in your feedback:

http://www.jefferycotton.net/info.asp?pgs=blogentryblbe=10

(The entry is entitled Sex in the Concert Hall -- which has nothing to do
with Finale, alas.)

Jeffery

-
Jeffery Cotton
President
Wired Musician, Inc.
http://www.wiredmusician.net
see my own website at
http://www.jefferycotton.net
-
-Original Message-


___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-04 Thread Christopher Smith
On Mar 4, 2005, at 5:32 AM, [EMAIL PROTECTED] wrote:
I've also written a blog entry on this topic (Finale vs. Sibelius) on 
my
website, would be interested in your feedback:

Very nicely put, but for my money (all 0$ of it!) I would have liked 
more detail than just hairpin openings, particularly any details that 
might pertain to the accurate and readable, and not much else crowd. 
These are the ones I have to convince when talking about notation 
programs.

BTW, in your second-last line in the blog, about getting out of Cassis, 
did you mean to write Maybe I can find that hansom cab driver again 
or did you really find him handsome? I wouldn't have been confused at 
all except for a previous line about Sibelius being the knockout 
bombshell in the tight dress  talk about your mixed messages! No 
complaints from my end either way  I am only interested in the idea 
that you want to express being clearly put across. 8-)

Christopher
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


RE: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-04 Thread jeffery
Thanks, Christopher -- I didn't want to go into too much detail about
Sibelius' inadequacies in the blog, but as I do have to complete one piece
I'm working on now in Sibelius (I'm too far along to start over now) it
might be worth keeping a list of these things and posting them later.

No, a hansom cab from Cassis to Marseille for 10 ten miles of southern
French mountains would NOT be a good solution. I'm afraid I meant handsome
(you can read the relevant blog entry here, and all will become clear:
http://www.jefferycotton.net/info.asp?pgs=blogentryblbe=8).

I didn't mean to cause confusion, but I doubt that the hot stud in leather
chaps who can't spell 'hairpin' would have been quite as clear in its
meaning -- to the majority anyway.

Jeffery


-
Jeffery Cotton
President
Wired Musician, Inc.
http://www.wiredmusician.net http://www.wiredmusician.net

see my own website at
http://www.jefferycotton.net http://www.jefferycotton.net
-



 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
 Of Christopher Smith
 Sent: Friday, March 04, 2005 1:45 PM
 To: finale@shsu.edu
 Subject: Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x
 comparison



 On Mar 4, 2005, at 5:32 AM, [EMAIL PROTECTED] wrote:
 
  I've also written a blog entry on this topic (Finale vs. Sibelius) on
  my
  website, would be interested in your feedback:
 

 Very nicely put, but for my money (all 0$ of it!) I would have liked
 more detail than just hairpin openings, particularly any details that
 might pertain to the accurate and readable, and not much else crowd.
 These are the ones I have to convince when talking about notation
 programs.

 BTW, in your second-last line in the blog, about getting out of Cassis,
 did you mean to write Maybe I can find that hansom cab driver again
 or did you really find him handsome? I wouldn't have been confused at
 all except for a previous line about Sibelius being the knockout
 bombshell in the tight dress  talk about your mixed messages! No
 complaints from my end either way  I am only interested in the idea
 that you want to express being clearly put across. 8-)

 Christopher


 ___
 Finale mailing list
 Finale@shsu.edu
 http://lists.shsu.edu/mailman/listinfo/finale




___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-04 Thread Jari Williamsson
[EMAIL PROTECTED] wrote:
I've also written a blog entry on this topic (Finale vs. Sibelius) on my
website, would be interested in your feedback:
http://www.jefferycotton.net/info.asp?pgs=blogentryblbe=10
I hope you've also found the Interviews on the Finale Tips site. Those 
should give you many other aspects of what Finale is today.

http://www.finaletips.nu/
Best regards,
Jari Williamsson
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-04 Thread David W. Fenton
On 3 Mar 2005 at 19:37, Mark D Lew wrote:

 On Mar 3, 2005, at 6:40 PM, David W. Fenton wrote:
 
  Do you currently have to define default vertical spacing for systems
  on a per-system basis? No, of course not -- there are default
  settings already. The default setting for the system I describe
  would be that the default vertical spacing for a measure would be
  equal to the system margins. If you reduced the vertical spacing for
  all the measures in a system, the system margins could then
  automatically contract. If you increased the vertical spacing for a
  selected block of measures, it would cause the system margins to
  expand to accommodate it.
 
 I don't understand this paragraph.  The default vertical spacing for
 any system is the global positions set up in scroll view (ie, what I
 think of as the unoptimized' spacing).  I have no idea what you mean
 by system margins.  Maybe I do things differently, or maybe this is
 another semantic thing.

We're talking past each other. I'm talking about system spacing and 
you're talking about spacing between staves within a system.

Both are pre-defined when you go into page view, so, there's no 
reason that measure margins would not also be pre-defined by the same 
mechanism as system margins.

  Say you had only one measure in a system that needed expanded
  vertical space. In the current situation, you adjust the vertical
  spacing for the system to accommodate the measure that is the
  extreme case. If that measure gets moved to another system, you have
  to start over, changing two systems. If, on the other hand, you set
  the vertical spacing for that one measure, if it got moved to
  another system, the target system would then expand accordingly, and
  the original system would contract back to the defaults (or to the
  next smallest setting in the measures in that system).
 
 OK, that makes sense.  I'm in the habit of doing all my layout 
 adjustments only after layout is set, so the change wouldn't really
 benefit me much, but I can see how it would be a great help to people
 who make large changes to a piece after layout has already been set.

You never change your mind?

I usually lay out a piece onscreen, then print it and then make 
adjustments to the layout because of problems I couldn't perceive 
onscreen.

 I doubt that Finale would want to have that AND the ability to adjust
 by system.  If so, and the change is made, then whenever I have
 page-specific adjustments I'd have to do them indirectly by simply
 selecting all the measures in that system and adjusting accordingly. 
 But that would be all right.  At that point, I won't be changing the
 layout anyway, so it all comes out the same.

I don't see why you couldn't have both.

  You have a very strange definition of the word. Optimization means
  REMOVING BLANK SYSTEMS. Read the optimization dialog box -- it says
  nothing about vertical spacing of staves within systems.
 
 I'm using Fin Mac 2k2.  My optimization dialog box says this:
 
  Optimizing can remove empty staves from Page View AND/OR make
 staves in specified systems independently adjustable. 
 
 In other words, Finale thinks that both functions are part of 
 optimization.  In fact, the AND/OR is not quite accurate.  While it
 is possible to optimize without removing empty staves, it is not
 possible to optimize without making staves independently adjustable.
 
 I've quoted verbatim from the dialog box.  If your version of Finale
 says something different, that could explain our disagreement about
 the meaning of the term.

The Windows dialog is the same, but there are no settings in the 
dialog that have anything whatsoever to do with vertical staff 
spacing -- all the settings have to do with showing/hiding systems.

The way I see it is that this is the tail wagging the dog, because 
without having grafted the vertical spacing feature onto 
optimization, there'd be no logical reason to have the ability to 
optimize without hiding systems.

That is, if as I suggest, all systems in page view had two handles 
(as happens currently after optimization), then there would no longer 
be any relationship between vertical staff spacing and the process of 
optimization, and the ability to uncheck Remove Empty Staves would 
then serve no function whatsoever, since right now, all it does is 
turn on the ability to space staves vertically (if it's unchecked).

I understand your point of view that changing inter-system spacing is 
part of optimizing your layout for the pages, but I think it's a 
mistake in the design of Finale, as it means that, in cases where you 
*don't* want staves hidden if empty, you have to turn on optimization 
before you can adjust vertical spacing. I think that's a ridiculous 
requirement.

  I believe this would satisfy both us, yes?
 
  Pretty much. But I still like the idea of vertical spacing
  travelling with the measure, not being permanently anchored to an
  absolute system position.
 
 I'd be OK with 

Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-04 Thread David W. Fenton
On 4 Mar 2005 at 9:50, Johannes Gebauer wrote:

 David W. Fenton wrote:
 
  My point is that simple optimization (i.e., removing blank staves
  from a systen) should happen automatically if you have optimization
  turned on for the passage of music represented on a system (while I
  understand that Johannes has a use for optimization being stored in
  absolute systems, I think that's a different kind of issue that
  comes about because of the way one is forced to create parts in
  Finale -- if they were all stored in the same file instead of in
  separate files, his issue would likely go away, since you'd have a
  score layout and a part layout, all stored in a single file; but
  that's another issue where I think Finale is confusing and less than
  ideal).
 
 In my case this has nothing to do with parts at all. The reason I need
 to optimize out parts which have got music in them has to do with
 doubling parts. For instance, in some situations the first and second
 violins play identical parts, and for space reasons I just want to
 show one of them, but the other one needs to have the music in it both
 for later part extraction but also because the decision to optimize
 out the second violin part is made at a later stage and needs to be
 reversible.

Well, again, if layout of score and parts all happened in a single 
score, both having settings that could be controlled independently 
(instead of parts inheriting all the settings from the score, with a 
few exceptions), then it wouldn't be a problem.

Again, I'm not advocating the removal of present functionality, just 
a rationalization of default behavior. As I just said in another 
message, in many aspects Finale seems to me to be designed more to 
handle the exceptions well than to do normal tasks easily.

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-04 Thread Mark D Lew
On Mar 4, 2005, at 12:22 PM, David W. Fenton wrote:
OK, that makes sense.  I'm in the habit of doing all my layout
adjustments only after layout is set, so the change wouldn't really
benefit me much, but I can see how it would be a great help to people
who make large changes to a piece after layout has already been set.
You never change your mind?
I usually lay out a piece onscreen, then print it and then make
adjustments to the layout because of problems I couldn't perceive
onscreen.
When I print a rough draft to visualize layout, it's generally before 
I've adjusted the spacing of staves within systems.  That is, I'm 
looking at a printout that has unoptimized systems (um, my definition 
of unoptimized, I mean) and I'm just visualizing what the spacing 
needs will be.  Later I'll make further adjustments, but it's rare that 
it includes changing any system breaks.

That is, if as I suggest, all systems in page view had two handles
(as happens currently after optimization), then there would no longer
be any relationship between vertical staff spacing and the process of
optimization, and the ability to uncheck Remove Empty Staves would
then serve no function whatsoever, since right now, all it does is
turn on the ability to space staves vertically (if it's unchecked).
As I mentioned before, I agree with you about separating the functions. 
 Our only difference is that I'm accustomed to using the word 
optimizing for the other half of the conjoined function.

I understand your point of view that changing inter-system spacing is
part of optimizing your layout for the pages, but I think it's a
mistake in the design of Finale, as it means that, in cases where you
*don't* want staves hidden if empty, you have to turn on optimization
before you can adjust vertical spacing. I think that's a ridiculous
requirement.
I personally have no use for a system with only one handle.  If there 
were a function that acted to restore any system to its scroll view 
defaults, that should pretty much take care of anyone who ever has use 
for the my-definition half of remove optimization.

There very well might be better conceptual ways to implement this
than what I've described, but I think my point is clear: the way
Finale works requires more work than it need have, as it requires you
to think of systems as empty slots that the music pours into, and
that the slots have their own characteristics (vertical spacing,
hidden staves) that are independent of what music is displayed in
them. Now, yes, we can all think of unusual situations where this can
actually be turned to advantage, but it is still antithetical to the
most obvious way of thinking about how it should happen (in my
opinion). Spacing of systems and hidden blank staves should be
determined by the content of the music, not by which system slot the
measures end up in.
Well, this is a larger matter than just splitting the two optimization 
functions or having vertical-spacing requirements attached to measures. 
 I think you can see how the numbered system as an item to which 
qualities are attached is pretty fundamental to its data structure, in 
terms of drawing the page and so forth.  I'm not saying that couldn't 
be changed, mind you, I'm just saying that it's a rather large 
reworking of Finale's definition that's going to be a lot more 
programming work with a lot more cans of worms opened along the way.

I agree that pouring into system slots sometimes makes things awkward, 
and I can see how those problems would be compounded for someone who 
makes system-based adjustments and then later makes a large addition or 
deletion which bumps a lot of music into different systems.  But at the 
same time, I don't think you can let go of systems as fundamental 
units, because many things really do depend on the system context and 
not just the music within its measures.  Changing divisis from one 
staff to two really does happen at a system break.  I really do decide 
whether to leave a blank vocal staff showing or remove it depending on 
the vertical density of the page as a whole.

There are certain decisions that can only be made within the context of 
the completely laid out page.

I still don't understand what you mean by system margins.
In Page View, click on the handle in the upper left of the system and
from the context menu choose EDIT MARGINS. That's what I'm talking
about -- the margins of the system.
Ah!  How funny.  I use that dialog all the time but somehow I never 
paid any attention to the name of it.  I leave that window open at all 
times, so that it automatically shows whenever I go to the Page Layout 
tool.

As I said above, you were talking about spacing between staves within
a system, I was talking about spacing between whole systems, and the
solution I described only solved that problem. I see no reason (other
than increasing complexity of UI and onscreen representation of the
margins) that my ideas couldn't be applied within between staves
within a 

Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-04 Thread Johannes Gebauer

David W. Fenton wrote:
In my case this has nothing to do with parts at all. The reason I need
to optimize out parts which have got music in them has to do with
doubling parts. For instance, in some situations the first and second
violins play identical parts, and for space reasons I just want to
show one of them, but the other one needs to have the music in it both
for later part extraction but also because the decision to optimize
out the second violin part is made at a later stage and needs to be
reversible.

Well, again, if layout of score and parts all happened in a single 
score, both having settings that could be controlled independently 
(instead of parts inheriting all the settings from the score, with a 
few exceptions), then it wouldn't be a problem.
I still don't see how parts-within-the-score would solve this problem.
But whatever the case I actually like the current idea of optimization. 
Yes, there could be more automatic updating, but I would like any 
development time here going into automatic vertical spacing. Whether 
this has to be invoked or is updated automatically is actually a pretty 
minor point in terms of time savings - at least for the way I do my work.

Johannes
--
http://www.musikmanufaktur.com
http://www.camerata-berolinensis.de
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-04 Thread Mark D Lew
On Mar 4, 2005, at 3:08 PM, Johannes Gebauer wrote:
Whether this has to be invoked or is updated automatically is actually 
a pretty minor point in terms of time savings - at least for the way I 
do my work.
Yep. Especially if all the systems are pre-optimized in the template.
mdl
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-03 Thread Darcy James Argue
Hi Johannes,
There's no reason why Finale couldn't have automatically updating 
optimization with the option to do a manual override.  You had to do a 
manual override anyway to hide staves containing notes.  It would be 
easy for Finale to keep track of which staves have been manually 
hidden/shown and leave those untouched when doing an automatic 
optimization update.

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
On 03 Mar 2005, at 2:44 AM, Johannes Gebauer wrote:
David W. Fenton wrote:
I also think that staff optimization should not be something that you 
have to remove and then re-apply. If you insert new measures, or 
insert data in previously empty measures (or you clear/hide 
previously populated measures), if you've got optimization turned on, 
it should automatically cause the system to re-optimize. I think it's 
crazy that the optimization information is stored with the absolute 
system rather than as a global setting that automatically updates the 
optimization when conditions change to warrant it.

Just for the record, I just had to optimize many parts out of the 
score, which weren't empty at all. This was possible because the 
optimization information is stored with the absolute system, and is in 
fact manually accessable. I do not wish this to be changed, simply 
because the way it works is ideal for the work I do.

Johannes
--
http://www.musikmanufaktur.com
http://www.camerata-berolinensis.de
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-03 Thread Johannes Gebauer
I was merely commenting to what David said: I think it's
crazy that the optimization information is stored with the absolute
system rather than as a global setting that automatically updates the
optimization when conditions change to warrant it.
It is precisely the fact that the optimization information is is stored 
with the absolute system rather than globally which makes it so flexible.

I am not against an automatic function with manual override, although I 
don't think I'd need or use it (because undoubtedly it will again slow 
down Finale, as most of these automatic update routines do).

Johannes
Darcy James Argue wrote:
Hi Johannes,
There's no reason why Finale couldn't have automatically updating 
optimization with the option to do a manual override.  You had to do a 
manual override anyway to hide staves containing notes.  It would be 
easy for Finale to keep track of which staves have been manually 
hidden/shown and leave those untouched when doing an automatic 
optimization update.

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
On 03 Mar 2005, at 2:44 AM, Johannes Gebauer wrote:
David W. Fenton wrote:
I also think that staff optimization should not be something that you 
have to remove and then re-apply. If you insert new measures, or 
insert data in previously empty measures (or you clear/hide 
previously populated measures), if you've got optimization turned on, 
it should automatically cause the system to re-optimize. I think it's 
crazy that the optimization information is stored with the absolute 
system rather than as a global setting that automatically updates the 
optimization when conditions change to warrant it.

Just for the record, I just had to optimize many parts out of the 
score, which weren't empty at all. This was possible because the 
optimization information is stored with the absolute system, and is in 
fact manually accessable. I do not wish this to be changed, simply 
because the way it works is ideal for the work I do.

Johannes
--
http://www.musikmanufaktur.com
http://www.camerata-berolinensis.de
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale
--
http://www.musikmanufaktur.com
http://www.camerata-berolinensis.de
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-03 Thread Christopher Smith
On Mar 2, 2005, at 10:35 PM, David W. Fenton wrote:
On 2 Mar 2005 at 20:18, Christopher Smith wrote:
disappearing measures,
I've never seen that. What is that? I have occasionally seen measures
APPEAR to vanish, but that is usually because I had a multi-measure
rest where I later entered notes, and forgot to turn off the rest.
Well, that does strike me as the kind of problem that no intelligent
application should allow to happen. Notes in measures should
automatically break multi-measure rests, without the user being
required to do anything.
I'm not sure I want ANOTHER automatic sweep through a subroutine 
slowing down the performance of the program, like Auto Update Layout, 
Auto Update Hyphens and Smart Word Extensions and the like. Especially 
given how often this problem (if it is one) would show up. I've only 
seen it myself a couple of times, and I am a heavy user who revises 
works constantly.


I also think that staff optimization should not be something that you
have to remove and then re-apply. If you insert new measures, or
insert data in previously empty measures (or you clear/hide
previously populated measures), if you've got optimization turned on,
it should automatically cause the system to re-optimize. I
Re-optimize to what parameters? There's a whole window of options there 
for that process. I don't want to be asked every time, and I don't want 
Finale choosing the parameters for me. I would rather do it myself.

Christopher
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


RE: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-03 Thread jeffery





  disappearing measures, 
  I've never seen that. What is that? I have occasionally seen measures 
  APPEAR to vanish, but that is usually because I had a multi-measure rest where 
  I later entered notes, and forgot to turn off the rest.
That 
was a typo (although I have seen the measures with music"hidden" inside a 
multiple rest before)— I should have said disappearing systems. A while 
back I was doing a string quartet score, for example, with two systems per page. 
After completing all the horizontal layout and editing,I set the top and 
bottom margins for all pages in an appropriate spot and the did Page 
Layout/Space Systems Evenly..., whereby Finale pushes the top system to 
the top of the page and the bottom system to the bottom of the page. What I 
discovered was that occasionally the bottom system would simply go missing, so 
page x would e.g. be system 10 and 11, page y would be system 12 with no bottom 
system, and page z would be sytem 14 and 15. So system 13 simply disappeared. If 
I looked in scroll view the music was still all there, just not in page view. 
Once I saw this I realized it was happening very frequently.

Again, 
this was Finale 2002.

Jeffery
www.jefferycotton.net
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-03 Thread Darcy James Argue
Jeremy,
Unless I've very much misunderstood your explanation, it sounds like 
something a simple Update Layout will fix.  You can even turn on 
Automatic Update Layout, if you like.

(BTW, since there has been discussion of the sluggishness caused by 
Automatic Update Layout, Automatic Word Extensions, etc -- in my 
opinion, it's ridiculous that Finale does not handle these simple tasks 
automatically *and* quickly, especially on today's hardware.  It's 
enormously frustrating that Finale seems to keep getting *slower* even 
as the hardware keeps getting faster.  Updating the layout 
automatically ought not to be a hugely processor-intensive task, and I 
really wish Coda would take a year off the constant upgrade cycle and 
work *exclusively* on making the program run more efficiently.)

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
On 03 Mar 2005, at 10:49 AM, [EMAIL PROTECTED] wrote:

disappearing measures,
 I've never seen that. What is that? I have occasionally seen measures 
APPEAR to vanish, but that is usually because I had a multi-measure 
rest where I later entered notes, and forgot to turn off the rest.


That was a typo (although I have seen the measures with musichidden 
inside a multiple rest before) I should have said disappearing 
systems. A while back I was doing a string quartet score, for example, 
with two systems per page. After completing all the horizontal layout 
and editing,I set the top and bottom margins for all pages in an 
appropriate spot and the did Page Layout/Space Systems Evenly..., 
whereby Finale pushes the top system to the top of the page and the 
bottom system to the bottom of the page. What I discovered was that 
occasionally the bottom system would simply go missing, so page x 
would e.g. be system 10 and 11, page y would be system 12 with no 
bottom system, and page z would be sytem 14 and 15. So system 13 
simply disappeared. If I looked in scroll view the music was still all 
there, just not in page view. Once I saw this I realized it was 
happening very frequently.

Again, this was Finale 2002.

Jeffery
www.jefferycotton.net
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-03 Thread David W. Fenton
On 3 Mar 2005 at 8:44, Johannes Gebauer wrote:

 David W. Fenton wrote:
 
  I also think that staff optimization should not be something that
  you have to remove and then re-apply. If you insert new measures, or
  insert data in previously empty measures (or you clear/hide
  previously populated measures), if you've got optimization turned
  on, it should automatically cause the system to re-optimize. I think
  it's crazy that the optimization information is stored with the
  absolute system rather than as a global setting that automatically
  updates the optimization when conditions change to warrant it.
 
 Just for the record, I just had to optimize many parts out of the
 score, which weren't empty at all. This was possible because the
 optimization information is stored with the absolute system, and is in
 fact manually accessable. I do not wish this to be changed, simply
 because the way it works is ideal for the work I do.

What if it were an option to do it the old way, or what I consider 
the common sense way (as I described)?

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-03 Thread David W. Fenton
On 3 Mar 2005 at 11:40, Johannes Gebauer wrote:

 I am not against an automatic function with manual override, although
 I don't think I'd need or use it (because undoubtedly it will again
 slow down Finale, as most of these automatic update routines do).

What if there were an option to set it to only update on Ctrl-U?

Keep in mind that it certainly wouldn't take anything like the 
processing power that automatic music spacing takes up, as there are 
not nearly as many objects to be calculated (you only need to check 
if the frames in a system are empty/holding only non-visible music). 
Also, automatic music spacing was such an annoyance because it caused 
the music to jump around while you were entering it. That simply 
couldn't happen, even if you were entering in page view, precisely 
because a frame that has been optimized out can't have data entered 
into it (it's not visible). And how many people do any major entry in 
page view, anyway (other than editing)?

I don't see it as a practical problem, even if it weren't settable to 
be part of the Ctrl-U update (which I'd probably prefer, myself).

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-03 Thread David W. Fenton
On 3 Mar 2005 at 7:06, Christopher Smith wrote:

 On Mar 2, 2005, at 10:35 PM, David W. Fenton wrote:
 
  On 2 Mar 2005 at 20:18, Christopher Smith wrote:
 
  disappearing measures,
 
  I've never seen that. What is that? I have occasionally seen
  measures APPEAR to vanish, but that is usually because I had a
  multi-measure rest where I later entered notes, and forgot to turn
  off the rest.
 
  Well, that does strike me as the kind of problem that no intelligent
  application should allow to happen. Notes in measures should
  automatically break multi-measure rests, without the user being
  required to do anything.
 
 I'm not sure I want ANOTHER automatic sweep through a subroutine
 slowing down the performance of the program, like Auto Update Layout,
 Auto Update Hyphens and Smart Word Extensions and the like. . . .

All of those can be turned off, right? So why do you assume that 
automatic breaking of multi-measure rests would not also have the 
option to turn it off? Or, as I suggested with automatic optimization 
in a response to Johannes, perhaps a setting to have it occur with 
Ctrl-U.

 . . . Especially
 given how often this problem (if it is one) would show up. I've only
 seen it myself a couple of times, and I am a heavy user who revises
 works constantly.

Multi-measure rests only appear in page view. Since you can see or 
edit the measures the multi-measure rests represent, the change of 
layout would happen when you switch from scroll view to page view. 
So, there wouldn't be any need for a process constantly running to 
check for multi-measure rests -- the code to do that would need to 
fire only at the point where you switch from scroll to page view. And 
it would be nice if it would fire with a Ctrl-U, as well, I think,  
especially for cases where you remove existing data and want rests 
combined. On the other hand, that raises some problems, and might be 
better left as a manual process because you probably wouldn't want it 
automatically combining two multi-measure rests (e.g., if you had an 
8-mm rest followed by a measure of music followed by another 8-mm 
rest -- you probably wouldn't want the two rests combined with the 
new empty measure into a 17-mm rest). You could have a behavior where 
if there's a multi-measure rest on *one* end of the measure you 
empty, that the empty measure would then automatically combine with 
the adjacent rest, but then there'd be different behaviors for 
different contexts, so that's probably not a good idea (at least not 
as a default behavior).

So, probably the creation of *new* multi-measure rests after music 
has been removed should probably not happen automatically while 
editing in page view, since there's too many cases where it will 
simply guess wrong because of all the ambiguities involved.

Overall, I'd think the multi-measure rest re-calculation should have 
a setting to turn it off, but then should be controllable where it 
fires. I think it should fire with the switch from scroll to page 
view and on Ctrl-U.

  I also think that staff optimization should not be something that
  you have to remove and then re-apply. If you insert new measures, or
  insert data in previously empty measures (or you clear/hide
  previously populated measures), if you've got optimization turned
  on, it should automatically cause the system to re-optimize. I
 
 Re-optimize to what parameters? There's a whole window of options
 there for that process. I don't want to be asked every time, and I
 don't want Finale choosing the parameters for me. I would rather do it
 myself.

Well, as in all these suggestions, I'm not suggesting that the 
behavior be changed by completely eliminating the old way. Others 
have already outlined how that could work.

Automatic optimization would happen according to the settings in the 
Staff System Optimization dialog box, just as they do now. It's just 
that you wouldn't have to invoke the dialog to make it happen, nor un-
optimize and re-optimize when you change the layout. And it would be 
nice to be able to lock optimizations to absolute systems, as 
Johannes suggested, which is rather similar to the way you can lock 
systems already (it's not too much of a different concept).

I still think these are two examples where Finale doesn't behave with 
common sense, and it's precisely these kinds of things that cause 
people to prefer programs like Sibelius, which behave according to 
one version of common sense but then prohibit you from making it 
behave any other way. If Finale retained user control, but also 
incorporated common sense by default, who could complain?

Honestly, I'd *never* need to know anything about the optimization 
dialog if Finale did it automatically, or much of anything about 
breaking/combining multi-measure rests (though I certainly do believe 
these should correspond to musical phrase divisions and large 
sectional boundaries, which isn't something that can happen 
automatically). Why should I need to 

Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-03 Thread Johannes Gebauer
Although I can see that it may be useful to some, it wouldn't be useful 
to me, so I am not interested (but I don't object).

However, something I'd much rather see is automatic vertical staff 
spacing. ;-)

Johannes
David W. Fenton wrote:
On 3 Mar 2005 at 11:40, Johannes Gebauer wrote:

I am not against an automatic function with manual override, although
I don't think I'd need or use it (because undoubtedly it will again
slow down Finale, as most of these automatic update routines do).

What if there were an option to set it to only update on Ctrl-U?
Keep in mind that it certainly wouldn't take anything like the 
processing power that automatic music spacing takes up, as there are 
not nearly as many objects to be calculated (you only need to check 
if the frames in a system are empty/holding only non-visible music). 
Also, automatic music spacing was such an annoyance because it caused 
the music to jump around while you were entering it. That simply 
couldn't happen, even if you were entering in page view, precisely 
because a frame that has been optimized out can't have data entered 
into it (it's not visible). And how many people do any major entry in 
page view, anyway (other than editing)?

I don't see it as a practical problem, even if it weren't settable to 
be part of the Ctrl-U update (which I'd probably prefer, myself).

--
http://www.musikmanufaktur.com
http://www.camerata-berolinensis.de
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-03 Thread Mark D Lew
On Mar 2, 2005, at 11:44 PM, Johannes Gebauer wrote:
Just for the record, I just had to optimize many parts out of the 
score, which weren't empty at all. This was possible because the 
optimization information is stored with the absolute system, and is in 
fact manually accessable. I do not wish this to be changed, simply 
because the way it works is ideal for the work I do.
For what it's worth, I also will occasionally choose to optimize out a 
system which has music in it.  I would be disappointed if this 
possibility were taken away.  I have no problem with some sort of 
warning or changeable default that helps newbies avoid getting confused 
by disappearing music without reducing the functionality for everyone 
else.

Some on this thread seem to be discussing optimization as if it were 
only the matter of making staves disappear in systems where they are 
empty.  I don't see how optimization can be separated from the matter 
of specifying vertical positions for staves which vary from system to 
system.  I use this constantly, because the vertical height of a piano 
accompaniment varies throughout the piece.  A constant distance from 
voice staff to piano-treble staff is unacceptable because I don't want 
markings running into the lyrics on some staves, but neither do I want 
large unnecessary gaps of white space on others.  Of course, this is 
layout-dependent, and if you later make changes to the piece which 
alter the layout, you're going to have to redo all the system 
optimization values.  This isn't a bug in the software; it's inherent 
in the nature of the task.

Maybe some day Finale will cook up a function to look for vertical 
collisions and provide vertical positions for staves accordingly, and 
perhaps it will even do a consistently good job of it.  Until that 
happens, I don't see how optimization can be taken away from the user 
and handed over to the software.

mdl
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-03 Thread David W. Fenton
On 3 Mar 2005 at 15:22, Mark D Lew wrote:

 On Mar 2, 2005, at 11:44 PM, Johannes Gebauer wrote:
 
  Just for the record, I just had to optimize many parts out of the
  score, which weren't empty at all. This was possible because the
  optimization information is stored with the absolute system, and is
  in fact manually accessable. I do not wish this to be changed,
  simply because the way it works is ideal for the work I do.
 
 For what it's worth, I also will occasionally choose to optimize out a
 system which has music in it.  I would be disappointed if this
 possibility were taken away.  I have no problem with some sort of
 warning or changeable default that helps newbies avoid getting
 confused by disappearing music without reducing the functionality
 for everyone else.

My point is that simple optimization (i.e., removing blank staves 
from a systen) should happen automatically if you have optimization 
turned on for the passage of music represented on a system (while I 
understand that Johannes has a use for optimization being stored in 
absolute systems, I think that's a different kind of issue that comes 
about because of the way one is forced to create parts in Finale -- 
if they were all stored in the same file instead of in separate 
files, his issue would likely go away, since you'd have a score 
layout and a part layout, all stored in a single file; but that's 
another issue where I think Finale is confusing and less than ideal).

My point is not that the way Finale does it now is wrong or 
unnecessary, but that it's not the common sense way it should work. 
Adding in the common sense approach in no way implies that you'd be 
forced to do it that way or that you'd lose the control you currently 
have over optimization. My common sense optimization would make a 
best guess and then you'd be able to tweak it to fit special needs. 
And if your particular pieces had characteristics that made my 
common sense optimization turn out wrong all the time, then you 
could simply turn off the common sense optimization and do it the 
way Finale has always done it.

 Some on this thread seem to be discussing optimization as if it were
 only the matter of making staves disappear in systems where they are
 empty.  I don't see how optimization can be separated from the matter
 of specifying vertical positions for staves which vary from system to
 system. . . .

I think it's wrong of Finale to *not* separate independent vertical 
positioning of staves within a system from optimization. Why should 
you need to optimize before you are allowed to move staves vertically 
within a system? Where's the logic there? It's not how lyrics work -- 
you don't have to do anything special to vertically reposition a 
system of lyrics.

And the reason for repositioning a staff within a single non-
optimized system is exactly the same as for lyrics -- to avoid 
collisions with other elements, most often notes that are in the 
ledger line stratosphere or basement, or to allow more room for 
things that project outside the regular vertical space of a staff.

Why shouldn't systems in page view just automatically always have two 
handles for dragging, rather than only when a system has been 
optimized?

 . . . I use this constantly, because the vertical height of a piano
 accompaniment varies throughout the piece.  A constant distance from
 voice staff to piano-treble staff is unacceptable because I don't want
 markings running into the lyrics on some staves, but neither do I want
 large unnecessary gaps of white space on others.  Of course, this is
 layout-dependent, and if you later make changes to the piece which
 alter the layout, you're going to have to redo all the system
 optimization values.  This isn't a bug in the software; it's inherent
 in the nature of the task.

No, it's not. If the vertical spacing requirements were stored with 
the frames, instead of with the system, then the vertical spacing 
could flow with the measures themselves, regardless of what system 
they end up on.

 Maybe some day Finale will cook up a function to look for vertical
 collisions and provide vertical positions for staves accordingly, and
 perhaps it will even do a consistently good job of it.  Until that
 happens, I don't see how optimization can be taken away from the
 user and handed over to the software.

Optimization and vertical spacing to allow for things that project 
outside the normal staff space are two separate issues that are 
intertwined not because of any conceptual necessity, but because 
that's the way Finale implements it.

I see no reason why page view couldn't add top and bottom margins for 
each measure, and for measures that needed more space, you'd simply 
increase the top or bottom margin (which would in turn automatically 
expand the system's top/bottom margin). Then you wouldn't have to 
worry about re-doing your vertical spacing if your system layout 
changed.

My point here is not really about any specific 

Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-03 Thread Mark D Lew
On Mar 3, 2005, at 3:49 PM, David W. Fenton wrote:
My point is that simple optimization (i.e., removing blank staves
from a systen) should happen automatically if you have optimization
turned on for the passage of music represented on a system
If I'm understanding you correctly, you are suggesting that any system 
which has been optimized with remove empty systems checked should be 
marked as such (perhaps it already is; I don't know), and then 
subsequent layout changes should be monitored so that if music is added 
to a removed staff in such a system, that staff will be reinstated in 
the page layout. (And similarly, I assume, if all music is deleted from 
a non-removed staff.)

I'm not sure exactly what events would need to trigger this check.  
Maybe it's sufficient just to do it with any Update Layout, rather than 
checking every time a frame is altered by Simple, Speedy, Mass Copy, 
etc..

If that's what you're suggesting, I think that's a fine idea -- so long 
as there is some sort of override that allows me to remove a non-empty 
staff when I want to.

(while I
understand that Johannes has a use for optimization being stored in
absolute systems, I think that's a different kind of issue that comes
about because of the way one is forced to create parts in Finale --
if they were all stored in the same file instead of in separate
files, his issue would likely go away, since you'd have a score
layout and a part layout, all stored in a single file; but that's
another issue where I think Finale is confusing and less than ideal).
I don't know what Johannes's needs are, but mine have nothing to do 
with score vs parts.  When I use optimization to remove non empty 
staves is in a large choral piece where the divisis change in such a 
way that it makes sense to display some sections with the two parts on 
a single staff and other sections with them on separate staves.

When I have a piece like this, it is often most convenient for me to 
create enough staves in score view that I have one for each part 
separate AND one for the parts combined.  When entering the music, I 
have a rough idea of where it makes sense to switch from combined to 
separate, but I don't know exactly where the system break is going to 
end up.  Typically, I'll have a few bars of overlap, where I enter both 
in score view.  Then that gives me the flexibility to twiddle around 
with it in page view, and once I have the layout settled, I remove the 
unnecessary staves from each system and it all reads smoothly.  There 
are other ways to achieve the same thing, of course, but I find that 
the ability to use optimization to remove a non-empty staff facilitates 
the process, and that's why I don't want that option removed.

And if your particular pieces had characteristics that made my
common sense optimization turn out wrong all the time, then you
could simply turn off the common sense optimization and do it the
way Finale has always done it.
That's fine with me.
I think it's wrong of Finale to *not* separate independent vertical
positioning of staves within a system from optimization. Why should
you need to optimize before you are allowed to move staves vertically
within a system? Where's the logic there?
OK, I think I understand now.  This is just a matter of semantics.  In 
my mind, the essence of optimization is the fact that an optimized 
system has its own definition for vertical positioning of staves and a 
non-optimized takes staff positioning from the scroll view default.  
From my view, asking why one should need to optimize in order to move 
staves vertically is nonsensical, since that's exactly what 
optimization is.  The ability to add or remove staves while adding 
optimization is just a side effect.

No doubt this is due to the different natures of our respective work.  
I mess with vertical position of staves all the time, whereas I rarely 
have need to remove an empty staff.  Indeed, when I apply optimization, 
I generally leave remove empty staves unchecked, unless I have a 
specific staff in mind to remove.

I actually agree with you that the two features may as well be 
separate.  It's just that I would have worded it to say that removal of 
empty staves is what needs to be separated from optimization.  When I 
read your messages about making optimization automatic, I thought you 
were arguing for the computer to apply vertical position of staves 
automatically.  That would be nifty if it could do a good job of it, 
but I think it's a big step MakeMusic isn't going to take any time 
soon. In any case, that's a separate discussion from the matter of 
removing empty staves from page view.

And the reason for repositioning a staff within a single non-
optimized system is exactly the same as [...]
Again, to my ear this sentence is meaningless.  If you're repositioning 
a staff, the system if optimized by definition.

Why shouldn't systems in page view just automatically always have two
handles for dragging, rather than only 

Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-03 Thread Mark D Lew
On Mar 3, 2005, at 3:49 PM, David W. Fenton wrote:
My point is that simple optimization (i.e., removing blank staves
from a systen) should happen automatically if you have optimization
turned on for the passage of music represented on a system
If I'm understanding you correctly, you are suggesting that any system 
which has been optimized with remove empty systems checked should be 
marked as such (perhaps it already is; I don't know), and then 
subsequent layout changes should be monitored so that if music is added 
to a removed staff in such a system, that staff will be reinstated in 
the page layout. (And similarly, I assume, if all music is deleted from 
a non-removed staff.)

I'm not sure exactly what events would need to trigger this check.  
Maybe it's sufficient just to do it with any Update Layout, rather than 
checking every time a frame is altered by Simple, Speedy, Mass Copy, 
etc..

If that's what you're suggesting, I think that's a fine idea -- so long 
as there is some sort of override that allows me to remove a non-empty 
staff when I want to.

(while I
understand that Johannes has a use for optimization being stored in
absolute systems, I think that's a different kind of issue that comes
about because of the way one is forced to create parts in Finale --
if they were all stored in the same file instead of in separate
files, his issue would likely go away, since you'd have a score
layout and a part layout, all stored in a single file; but that's
another issue where I think Finale is confusing and less than ideal).
I don't know what Johannes's needs are, but mine have nothing to do 
with score vs parts.  When I use optimization to remove non empty 
staves is in a large choral piece where the divisis change in such a 
way that it makes sense to display some sections with the two parts on 
a single staff and other sections with them on separate staves.

When I have a piece like this, it is often most convenient for me to 
create enough staves in score view that I have one for each part 
separate AND one for the parts combined.  When entering the music, I 
have a rough idea of where it makes sense to switch from combined to 
separate, but I don't know exactly where the system break is going to 
end up.  Typically, I'll have a few bars of overlap, where I enter both 
in score view.  Then that gives me the flexibility to twiddle around 
with it in page view, and once I have the layout settled, I remove the 
unnecessary staves from each system and it all reads smoothly.  There 
are other ways to achieve the same thing, of course, but I find that 
the ability to use optimization to remove a non-empty staff facilitates 
the process, and that's why I don't want that option removed.

And if your particular pieces had characteristics that made my
common sense optimization turn out wrong all the time, then you
could simply turn off the common sense optimization and do it the
way Finale has always done it.
That's fine with me.
I think it's wrong of Finale to *not* separate independent vertical
positioning of staves within a system from optimization. Why should
you need to optimize before you are allowed to move staves vertically
within a system? Where's the logic there?
OK, I think I understand now.  This is just a matter of semantics.  In 
my mind, the essence of optimization is the fact that an optimized 
system has its own definition for vertical positioning of staves and a 
non-optimized takes staff positioning from the scroll view default.  
From my view, asking why one should need to optimize in order to move 
staves vertically is nonsensical, since that's exactly what 
optimization is.  The ability to add or remove staves while adding 
optimization is just a side effect.

No doubt this is due to the different natures of our respective work.  
I mess with vertical position of staves all the time, whereas I rarely 
have need to remove an empty staff.  Indeed, when I apply optimization, 
I generally leave remove empty staves unchecked, unless I have a 
specific staff in mind to remove.

I actually agree with you that the two features may as well be 
separate.  It's just that I would have worded it to say that removal of 
empty staves is what needs to be separated from optimization.  When I 
read your messages about making optimization automatic, I thought you 
were arguing for the computer to apply vertical position of staves 
automatically.  That would be nifty if it could do a good job of it, 
but I think it's a big step MakeMusic isn't going to take any time 
soon. In any case, that's a separate discussion from the matter of 
removing empty staves from page view.

And the reason for repositioning a staff within a single non-
optimized system is exactly the same as [...]
Again, to my ear this sentence is meaningless.  If you're repositioning 
a staff, the system if optimized by definition.

Why shouldn't systems in page view just automatically always have two
handles for dragging, rather than only 

Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-03 Thread David W. Fenton
On 3 Mar 2005 at 17:28, Mark D Lew wrote:

 It's just that I would have worded it to say that removal of 
 empty staves is what needs to be separated from optimization.

The meaning of the word optimization would then be associated with 
something that is not remotely related to the concept the word 
represents.

You optimize in Finale in order to optimize the usage of space on 
the page, by eliminating blank staves, so you can fit more systems in 
fewer pages. This has *zilch* to do with vertical positioning of 
staves within systems.

So, I think you have a completely backwards conception of what 
optimization actually is -- optimization *is* removing blank 
staves, and the part that you use of it is something else entirely 
that has nothing to do with optimizing space on the page (though you 
might reduce spacing between staves in order to fit more systems on 
one page; but you could also *increase* spacing in order to avoid 
overlap of extreme elements, and that is the opposite of optimizing).

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-03 Thread David W. Fenton
On 3 Mar 2005 at 17:28, Mark D Lew wrote:

 On Mar 3, 2005, at 3:49 PM, David W. Fenton wrote:

[]

  . . . I use this constantly, because the vertical height of a piano
  accompaniment varies throughout the piece.  A constant distance
  from voice staff to piano-treble staff is unacceptable because I
  don't want markings running into the lyrics on some staves, but
  neither do I want large unnecessary gaps of white space on others. 
  Of course, this is layout-dependent, and if you later make changes
  to the piece which alter the layout, you're going to have to redo
  all the system optimization values.  This isn't a bug in the
  software; it's inherent in the nature of the task.
 
  No, it's not. If the vertical spacing requirements were stored with
  the frames, instead of with the system, then the vertical spacing
  could flow with the measures themselves, regardless of what system
  they end up on.
 
 But then I'd have to define my vertical spacing requirements on a
 measure-per-measure basis. . . .

Do you currently have to define default vertical spacing for systems 
on a per-system basis? No, of course not -- there are default 
settings already. The default setting for the system I describe would 
be that the default vertical spacing for a measure would be equal to 
the system margins. If you reduced the vertical spacing for all the 
measures in a system, the system margins could then automatically 
contract. If you increased the vertical spacing for a selected block 
of measures, it would cause the system margins to expand to 
accommodate it.

And since it was defined per measure, it would travel to any system 
that this measure migrated to.

Say you had only one measure in a system that needed expanded 
vertical space. In the current situation, you adjust the vertical 
spacing for the system to accommodate the measure that is the extreme 
case. If that measure gets moved to another system, you have to start 
over, changing two systems. If, on the other hand, you set the 
vertical spacing for that one measure, if it got moved to another 
system, the target system would then expand accordingly, and the 
original system would contract back to the defaults (or to the next 
smallest setting in the measures in that system).

 . . . I don't want to do that. . . .

As I just explained above, you wouldn't have to, any more than you 
have to manually set system or page margins in Finale right now.

 . . . How I choose to
 space a system vertically is dependent on information that is specific
 to the system, not the measure.  For example, if an entire page is
 crowded vertically, I'm going to be more inclined to tighten each
 individual system than I would be otherwise.  That's layout-dependent,
 not frame-dependent.  If a hairpin continues from m.10 to m.12 and
 there are high LH notes in m.10 and low RH notes in m.12, then it's
 going to need more space if m.10 and m.12 are on the same system than
 it will if the hairpin is split over a system break and I can move
 half to a different vertical position.  That's layout-dependent, not
 frame-dependent.

Well, I'm not advocating eliminating system-oriented spacing 
adjustments -- I'm just suggesting allowing the storing of spacing 
requirements connected to measures, which would be much more useful 
to *me*.

  Optimization and vertical spacing to allow for things that project
  outside the normal staff space are two separate issues that are
  intertwined not because of any conceptual necessity, but because
  that's the way Finale implements it.
 
 Substitute removing empty systems from page view for optimization
 and I agree.

You have a very strange definition of the word. Optimization means 
REMOVING BLANK SYSTEMS. Read the optimization dialog box -- it says 
nothing about vertical spacing of staves within systems.

 I suppose my recommendations along these lines would be this:
 
 1. Every system has a value that specifies staves are movable (ie, use
 independent vertical values) or unmovable (ie, use vertical values
 from scroll view).  A global setting specifies whether new systems
 added will be movable or unmovable.  Various means in the UI allow the
 user to change the movable/unmovable value for any individual system,
 or for all systems at once.
 
 2. The standard default documents have all systems defined as movable.
  The setting for new systems defaults to movable.

That would be just like lyrics.

 3. Every systemstaff has a value that specifies does or doesn't show
 in the page view.  Various means in the UI allow the user to change
 the show/don't show value for any individual systemstaff, or all
 systems at once.
 
 4. A global setting tells whether the Update Layout procedure should
 include a check to set any empty systemstaff to don't show and set
 any non-empty systemstaff to show.  By default, this setting will
 be on.

Well, it would be nice to allow overrides for specific systems 
(though I'd want it to be measure-specific).

 5. 

Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-03 Thread Mark D Lew
On Mar 3, 2005, at 6:25 PM, David W. Fenton wrote:
The meaning of the word optimization would then be associated with
something that is not remotely related to the concept the word
represents.
You optimize in Finale in order to optimize the usage of space on
the page, by eliminating blank staves, so you can fit more systems in
fewer pages. This has *zilch* to do with vertical positioning of
staves within systems.
In the loosest sense, anything that improves your document makes it 
more optimal, but it's such a vague term that it's meaningless in 
Finale, except by association with what the function actually does.  
What the function actually does is make staves vertically adjustable 
within a system.  It may or may not also remove blank staves from page 
view.  As we've already noted, you can have an optimized system which 
does not have the blank staves removed.

So, I think you have a completely backwards conception of what
optimization actually is --
Right, and I think the same of you.  Like I said, our only real 
disagreement here is just semantics.

optimization *is* removing blank
staves, and the part that you use of it is something else entirely 
[...]
If Optimization is equivalent to removing blank staves, then how come 
Remove Empty Staves is an optional checkbox within the Optimization 
dialog box?  So that you have the option of optimizing without 
optimizing?

mdl
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-03 Thread David W. Fenton
On 3 Mar 2005 at 18:51, Mark D Lew wrote:

 On Mar 3, 2005, at 6:25 PM, David W. Fenton wrote:
 
  The meaning of the word optimization would then be associated with
  something that is not remotely related to the concept the word
  represents.
 
  You optimize in Finale in order to optimize the usage of space on
  the page, by eliminating blank staves, so you can fit more systems
  in fewer pages. This has *zilch* to do with vertical positioning of
  staves within systems.
 
 In the loosest sense, anything that improves your document makes it
 more optimal, but it's such a vague term that it's meaningless in
 Finale, except by association with what the function actually does. 

The function is available only in page view, so, you're obviously 
optimizing the pages in your score. Seems transparent and obvious to 
me.

 What the function actually does is make staves vertically adjustable
 within a system.  It may or may not also remove blank staves from page
 view.  As we've already noted, you can have an optimized system
 which does not have the blank staves removed.

Removing blank staves returns a lot more usable space than vertically 
adjusting spacing within a staff.

Look at the optimization dialog box -- there is absolutely nothing 
there except options that control removal or inclusion of blank 
staves.

Seems pretty definitive and clear to me!

  So, I think you have a completely backwards conception of what
  optimization actually is --
 
 Right, and I think the same of you.  Like I said, our only real 
 disagreement here is just semantics.
 
  optimization *is* removing blank
  staves, and the part that you use of it is something else entirely
  [...]
 
 If Optimization is equivalent to removing blank staves, then how
 come Remove Empty Staves is an optional checkbox within the
 Optimization dialog box?  So that you have the option of optimizing
 without optimizing?

Tell me: what are the defaults?

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-03 Thread Mark D Lew
On Mar 3, 2005, at 6:40 PM, David W. Fenton wrote:
Do you currently have to define default vertical spacing for systems
on a per-system basis? No, of course not -- there are default
settings already. The default setting for the system I describe would
be that the default vertical spacing for a measure would be equal to
the system margins. If you reduced the vertical spacing for all the
measures in a system, the system margins could then automatically
contract. If you increased the vertical spacing for a selected block
of measures, it would cause the system margins to expand to
accommodate it.
I don't understand this paragraph.  The default vertical spacing for 
any system is the global positions set up in scroll view (ie, what I 
think of as the unoptimized' spacing).  I have no idea what you mean 
by system margins.  Maybe I do things differently, or maybe this is 
another semantic thing.

Say you had only one measure in a system that needed expanded
vertical space. In the current situation, you adjust the vertical
spacing for the system to accommodate the measure that is the extreme
case. If that measure gets moved to another system, you have to start
over, changing two systems. If, on the other hand, you set the
vertical spacing for that one measure, if it got moved to another
system, the target system would then expand accordingly, and the
original system would contract back to the defaults (or to the next
smallest setting in the measures in that system).
OK, that makes sense.  I'm in the habit of doing all my layout 
adjustments only after layout is set, so the change wouldn't really 
benefit me much, but I can see how it would be a great help to people 
who make large changes to a piece after layout has already been set.

I doubt that Finale would want to have that AND the ability to adjust 
by system.  If so, and the change is made, then whenever I have 
page-specific adjustments I'd have to do them indirectly by simply 
selecting all the measures in that system and adjusting accordingly.  
But that would be all right.  At that point, I won't be changing the 
layout anyway, so it all comes out the same.

You have a very strange definition of the word. Optimization means
REMOVING BLANK SYSTEMS. Read the optimization dialog box -- it says
nothing about vertical spacing of staves within systems.
I'm using Fin Mac 2k2.  My optimization dialog box says this:
 Optimizing can remove empty staves from Page View AND/OR make staves 
in specified systems independently adjustable. 

In other words, Finale thinks that both functions are part of 
optimization.  In fact, the AND/OR is not quite accurate.  While it 
is possible to optimize without removing empty staves, it is not 
possible to optimize without making staves independently adjustable.

I've quoted verbatim from the dialog box.  If your version of Finale 
says something different, that could explain our disagreement about the 
meaning of the term.

I believe this would satisfy both us, yes?
Pretty much. But I still like the idea of vertical spacing travelling
with the measure, not being permanently anchored to an absolute
system position.
I'd be OK with that.  Aside from the matter of what to call it, it 
looks like you and I are in agreement on this.

I just don't see why it is conceptually any different than what we
have now with the way system margins live inside page margins.
I still don't understand what you mean by system margins.
. . . Then again, I don't trust Finale to do a decent
job of horizontal spacing for any music that includes lyrics, either,
which is why I'm always tweaking them. . . .
Does it do an OK job for music *without* lyrics? I don't do lyrics
all that often, so defaults that got it right on the first try
without lyrics would greatly speed up my work.
I've got a lot of little minor complaints, but on the general question 
of how beat spacing lays out the beat chart, I'm mostly pretty happy.  
I'll occasionally tweak a measure here and there, but most of the time 
I'm reasonably satisfied with the default music spacing in all but 
exceptional cases.

That's not the case with lyrics, where I find that unattractive spacing 
is the rule rather than the exception.  Unless the accompaniment is 
consistently denser than the syllables, or the entire layout ends up 
loose, I just assume that I'm going to end up tweaking a whole lot of 
beat charts.

Mind you, I don't mean this as a criticism of Finale.  I think that 
good spacing of music with lyrics just doesn't lend itself nicely to 
algorithmic treatment.  The TG plug-in makes a good run at it, and it's 
definitely an improvement over Finale's default, but it still fails to 
deliver spacing I would consider particularly good.

Why would I *ever* suggest taking away the fine control that Finale
has always offered?
I know you well enough to know that you wouldn't want that.  But you 
did say:

I think it's
crazy that the optimization information is stored with the absolute
system 

Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-03 Thread Mark D Lew
On Mar 3, 2005, at 7:10 PM, David W. Fenton wrote:
Removing blank staves returns a lot more usable space than vertically
adjusting spacing within a staff.
Taking up space is not the only criterion.  An attractively spaced page 
is more optimal than one in which every system is cramped.

To offer a real life example, suppose I've got a piano-vocal piece 
which normally fits four systems on a page.  If there's a system where 
the voice part is blank, I can either remove the staff or not.  If 
removing it lets me fit five systems, or if the piano part is so thick 
that even four systems make for a cramped page, then I'll welcome the 
opportunity to remove the system and improve the page.  If, on the 
other hand, I can only fit four systems in any case but the page is 
otherwise fairly loose, then it looks stupid to take out the blank 
voice staff just to have even more white space between the systems. In 
that case I'd rather leave it in place.

My point is that removing a blank system is not necessarily always the 
optimal thing to do.

Tell me: what are the defaults?
Defaults are Remove Empty Staves, Keep At Least One Staff, and 
Whole Document.  Note that removing empty staves is an option which 
can be turned off.  Making staves independently adjustable happens 
regardless of what options you choose.

mdl
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


[Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-02 Thread jeffery



Greetings 
all,

mailing list newbie 
here. Glad to have found this.

The latest 
version of Finale I am familiar with is 2002, having refused to upgrade beyond 
that until they fixed some of the basic notational problems in Finale that 
always seemed to get overlooked -- the eternal problems with tuplet placement, 
hairpins, disappearing measures, etc --in favor of "composer's assistant" 
nonsense. As someone who looks at these programs largely as notational tools, I 
got frustrated. In any case, I stuck it out with 2002 until recently, 
when I was finally convinced by friends to try Sibelius. 
I've been working with version 3.1.3 for about 2 months. 


Certainly 
things are superior in Sibelius when it comes to the user interface and certain 
formatting issues (at least in comparison to Finale 2002). But at the end of the 
day I am most concerned about what comes out of my printer, and Sibelius doesn't 
even begin to approach the professional look that I can get(after much 
hair-pulling) out of Finale. And I am frustrated again, because the response in 
the Sibelius forums is constantly "no, you can't do that 
(yet)."

Anyway: I'm 
wondering if I can get some feedback on where things stand with Finale 2005 as 
regards the many problems I am familiar with in F2002, and I'm wondering what 
the NEW frustrations might be with 2005 (again, as regards notation -- I do not 
use these programs' composing tools orsound-file generating 
tools.)At this point I'd considering upgrading if I thought that 2005 was 
honestly better than 2002.

If there is 
somewhere on the internet where someone has actually documented these things, 
that would certainly suffice. I don't want to take up too much bandwidth here! 
;-)

Thanks,

Jeffery
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-02 Thread Noel Stoutenburg
[EMAIL PROTECTED] wrote:
Anyway: I'm wondering if I can get some feedback on where things stand 
with Finale 2005 as regards the many problems I am familiar with in 
F2002, and I'm wondering what the NEW frustrations might be with 2005 
(again, as regards notation -- I do not use these programs' composing 
tools or sound-file generating tools.) At this point I'd considering 
upgrading if I thought that 2005 was honestly better than 2002.
 
If there is somewhere on the internet where someone has actually 
documented these things, that would certainly suffice. I don't want to 
take up too much bandwidth here! ;-)
I have no interest in S~ myself, exactly because of the you can't do 
that in S~ responses I've seen in various forums over the years which I 
have been able to do trivially in Finale, so I don't look often.  In 
response to a question about comparisons of Sibelius and Finale, I 
discovered recently that the MakeMusic! website does show a direct, 
feature by feature comparison with and unnamed leading competitor, but 
that Sibelius does  not see any particular value of providing the same 
objective data, instead, seeming to prefer unsubstantiated testimonials. 

Tuplets and expressions were dramatically redesigned in 2004 and 2005, 
but beyonhd that, I'd suggest that you prepare a list of questions about 
areas you formerly found problematical, and post that to this list; it 
will in no way (at least not to me) be a waste of bandwidth.

ns
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-02 Thread Jari Williamsson
[EMAIL PROTECTED] wrote:
If there is somewhere on the internet where someone has actually 
documented these things, that would certainly suffice. 
Go to the Finale tips site, click on Other Texts. There you have 
in-depth reviews of Finale 2002, Finale 2003, Finale 2004  Finale 2005.

Best regards,
Jari Williamsson
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-02 Thread Owain Sutton

[EMAIL PROTECTED] wrote:
Greetings all,
 
mailing list newbie here. Glad to have found this.
 
The latest version of Finale I am familiar with is 2002, having refused 
to upgrade beyond that until they fixed some of the basic notational 
problems in Finale that always seemed to get overlooked -- the eternal 
problems with tuplet placement, hairpins, disappearing measures, etc 
-- in favor of composer's assistant nonsense. As someone who looks at 
these programs largely as notational tools, I got frustrated. In any 
case, I stuck it out with 2002 until recently, when I was finally 
convinced by friends to try Sibelius. I've been working with version 
3.1.3 for about 2 months.
 ...
 
Anyway: I'm wondering if I can get some feedback on where things stand 
with Finale 2005 as regards the many problems I am familiar with in 
F2002, and I'm wondering what the NEW frustrations might be with 2005 
(again, as regards notation -- I do not use these programs' composing 
tools or sound-file generating tools.) At this point I'd considering 
upgrading if I thought that 2005 was honestly better than 2002.
 
I'm in a position similar to you, regarding my requirements.  I use 
Finale as a tool to created scores, and only that.  Playback et al is of 
no interest to me.

If 2002 is the last version you've tried, you'll find some important 
improvements - in particular tuplets are better (but still not great). 
Browsing this list will show up particular gripes with other tools, such 
as text blocks etc.  The improved Expression tool in 2005 is saving me 
huge amounts of time - alignments of expressions are now automated (and 
that automation is fully adjustable), so things that I used to waste 
time on getting looking 'just so' can now be predetermined.

I guess the problem that we 'serious notators' face is that we're a tiny 
minority of Finale users, and Finale users are one small section of the 
market for notation software.  For MakeMusic to spend time sorting the 
things we'd like to see improved means taking time away from the 
development of what appear to us to be frivolous extras, but actually 
function as selling-points for the software.
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-02 Thread Robert Patterson
An often-overlooked area of improvement in Finale versions is the 
interface for plugins. Both Finale 2003 and Finale 2004 included 
significant improvements that greatly expanded the power of plugins. 
Finale 2003 allowed plugins to detect and operate on multiple open 
documents. Finale 2004 offered more accurate means for a plugin to 
activate Finale's menu commands. This, for example, greatly improved 
some of TGTools plugins. My biggest reason for moving to Fin03 from 
Fin02 was plugin power. I can't imagine going back now.

A possible *deterrent* to adopting any version of Finale after Fin03 is 
the copy protection scheme. Mild compared some, it does nevertheless 
require you to contact Makemusic to register, which will be a problem if 
Makemusic is no longer there in the future.

--
Robert Patterson
http://RobertGPatterson.com
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-02 Thread Christopher Smith

On Mar 2, 2005, at 4:26 PM, [EMAIL PROTECTED] wrote:

Greetings all,
 
mailing list newbie here. Glad to have found this.
 
The latest version of Finale I am familiar with is 2002, having refused to upgrade beyond that until they fixed some of the basic notational problems in Finale that always seemed to get overlooked -- the eternal problems with tuplet placement, 

Tuplets are greatly improved with 2005. Still a couple of small issues with the number placement, especially with large intervals under the tuplet, but tuplets that start with a rest or a low note align WAY better than before.


hairpins, 

What did you see wrong with the hairpins? They behave perfectly well as far as I can see. I use TG Tools plugins to help align everything, so maybe I'm spoiled. Automatic expression placement is new and fantastic as well.


disappearing measures, 

I've never seen that. What is that? I have occasionally seen measures APPEAR to vanish, but that is usually because I had a multi-measure rest where I later entered notes, and forgot to turn off the rest.


etc -- in favor of composer's assistant nonsense. As someone who looks at these programs largely as notational tools, I got frustrated. In any case, I stuck it out with 2002 until recently,  when I was finally convinced by friends to try Sibelius. I've been working with version 3.1.3 for about 2 months.
  
Certainly things are superior in Sibelius when it comes to the user interface and certain formatting issues (at least in comparison to Finale 2002). But at the end of the day I am most concerned about what comes out of my printer, and Sibelius doesn't even begin to approach the professional look that I can get (after much hair-pulling) out of Finale. And I am frustrated again, because the response in the Sibelius forums is constantly no, you can't do that (yet).
 
Anyway: I'm wondering if I can get some feedback on where things stand with Finale 2005 as regards the many problems I am familiar with in F2002, and I'm wondering what the NEW frustrations might be with 2005 (again, as regards notation -- I do not use these programs' composing tools or sound-file generating tools.) At this point I'd considering upgrading if I thought that 2005 was honestly better than 2002.


You sound like a fairly serious user. Many of the issues with Finale's built-in functionality are addressed with 3rd-party plugins, some of which will no doubt make you clap your hands and giggle like a child when you first use them (that was my reaction, in any case). They are definitely worth the shareware price, and the time it will take to learn them, though you can try them out first for free. This list is a great resource as well. Many times when I have been frustrated by some seeming lack of functionality, someone on this list has just the trick to make it doable.

If you have specific questions, we can answer them.

Christopher


___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-02 Thread David W. Fenton
On 2 Mar 2005 at 20:18, Christopher Smith wrote:

  disappearing measures,
 
 I've never seen that. What is that? I have occasionally seen measures
 APPEAR to vanish, but that is usually because I had a multi-measure
 rest where I later entered notes, and forgot to turn off the rest.

Well, that does strike me as the kind of problem that no intelligent 
application should allow to happen. Notes in measures should 
automatically break multi-measure rests, without the user being 
required to do anything.

I also think that staff optimization should not be something that you 
have to remove and then re-apply. If you insert new measures, or 
insert data in previously empty measures (or you clear/hide 
previously populated measures), if you've got optimization turned on, 
it should automatically cause the system to re-optimize. I think it's 
crazy that the optimization information is stored with the absolute 
system rather than as a global setting that automatically updates the 
optimization when conditions change to warrant it.

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Re: [Finale] Finale/Sibelius and Finale 2005/Finale 200x comparison

2005-03-02 Thread Johannes Gebauer
David W. Fenton wrote:
I also think that staff optimization should not be something that you 
have to remove and then re-apply. If you insert new measures, or 
insert data in previously empty measures (or you clear/hide 
previously populated measures), if you've got optimization turned on, 
it should automatically cause the system to re-optimize. I think it's 
crazy that the optimization information is stored with the absolute 
system rather than as a global setting that automatically updates the 
optimization when conditions change to warrant it.

Just for the record, I just had to optimize many parts out of the score, 
which weren't empty at all. This was possible because the optimization 
information is stored with the absolute system, and is in fact manually 
accessable. I do not wish this to be changed, simply because the way it 
works is ideal for the work I do.

Johannes
--
http://www.musikmanufaktur.com
http://www.camerata-berolinensis.de
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale