subject:"\[Finale\] Finale vs. Sibelius"

At 7:21 PM -0700 6/05/04, Mark D Lew wrote:
On Jun 5, 2004, at 12:22 PM, Christopher BJ Smith wrote:
 And how do you shift syllables for the second verse without 
messing up the first verse? It's true that it is better than it 
was, but one still has to be careful, or major screw-ups can occur.
Wow, I've never even heard of this problem with shift lyrics.  I use 
shift lyrics all the time, and it never affects another verse.  Must 
be something to do with how your verses are set up.

I just tried to reproduce my problem in 2003, and wasn't able to. I 
remember this from a  while ago, and it might be something that was 
fixed, or some sort of corruption in my file at the time. There are a 
lot of funny things that happen sometimes that get cured with a 
re-boot.

So take that one off the list!
Christopher
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: Lyrics (was Re: [Finale] Finale vs. Sibelius ...)

2004-06-05 Thread Noel Stoutenburg

Christopher BJ Smith wrote, part:
And how do you shift syllables for the second verse without messing up 
the first verse?

This is one of the places I'd use the edit lyric's dialog box.  It is my 
experience that as long as the first syllable of the  line of lyric 
attached to each staff stays in the same place when measured by syllable 
count, relative to the first syllable in the block, one can change the 
order of blocks assigned to a staff.  So, if I needed to shift syllables 
to the right, I'd find the next open note to which I wanted the 
syllables shifted, and assign to it some obvious character, like "ß" 
using type into score.  I would then go into the lyrics dialog box for 
the appropriate lyric segment, find the ß, highlight both that character 
and the space immediately before it, and cut it, characters out.  I 
would then move to the first syllable I wanted to shift, and paste the 
space and ß cut just before that syllable.  I would then return to type 
into score, and delete the ß.  An essential key to the success of this 
method is not to change the syllable count between the first syllable of 
the second verse, and the first syllable of the third verse, while in 
"edit lyrics mode".

Mark D Lew wrote:
I think of shift lyrics as an Edit Lyrics type function, the natural 
companion to opt-Click Assign.  I'm not sure why one would need it 
with Type in Score.
I need shift lyrics because even in type into score mode, I sometimes 
find that I have assigned a series of sylllabls to the wrong pitches, 
and shifting is easier than retyping. 

ns
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: Lyrics [was Re: [Finale] Finale vs. Sibelius ...]

2004-06-06 Thread Mark D Lew

On Jun 5, 2004, at 8:18 PM, Noel Stoutenburg wrote:
[responding to David Fenton's suggestion]
 DON'T USE TYPE INTO SCORE
Once you figure that out, it's pretty easy to use.
which I must say, does not match my experience at all.  After several 
years of creating choral music in various layout patterns, I find that 
for initial entry of simple lyrics, and for editing which changes the 
total number of syllables assigned to notes contained in a particular 
staff, type into score is works quite well.
I still say that either system is mostly fine on it's own, and mixing 
the two is was leads to trouble.  That's why users of either thinks the 
problem is with the other.

In your case, Noel, you say that you are fine working with both, but in 
your other post you talk about kludgy techniques like typing in a dummy 
character in the score and then deleting that same character from Edit 
Lyrics.  In other words, you have an idea of how the system works and 
can manipulate accordingly.  Fine, so can I, but that isn't what I'd 
expect from a system that "works quite well".  Someone less experienced 
or knowledgeable can get in quite a mess if he enters and edits lyrics 
in an unusual or haphazard order.

The real problem with the lyrics system, in my view, (and this is 
probably true of other systems, as well) is the fact that there is no 
place where the details of how the system actually works are provided, 
and there should be.
I too would love to have specific technical information of exactly how 
Finale arranges syllables entered or edited with Type in Score.  It's 
still something of a mystery to me.  It's obviously making some effort 
to re-order your syllables for you, but at the same time it doesn't 
quite do a complete job of it -- probably with good reason, because 
they don't dare overthink your work for you and end up canceling out 
something you did on purpose.

What I think would improve the system, without totally overhauling it, 
is to add a function called something like "reorganize lyric data".  
This would be an algorithm that goes through the whole piece, looking 
at where you've got syllables assigned and making sense of it, and then 
it would clean out all the lyric data and rewrite it fresh in a logical 
order and reassign syllables so that it still reads the same as you had 
it, but the underlying data is better organized now.

The point of this would be as an emergency cleanup for when someone 
gets in trouble.  If you've got one of those situations where you try 
to fix one thing but it just screws up somewhere else, or a lost 
syllable leading to extra hyphens strung across the page, the 
"reorganize lyric data" would clean that up, so that you could then 
proceed to make your edits without it going wacko on you.

Naturally, users will have different preferences about various things, 
so there will be a panel of options for Reorganize Lyric Data, just as 
there is for Music Spacing.  This would be things like whether to 
delete unassigned syllables, whether to write duplicates for syllables 
multiply assigned, whether to sort your verses from top to bottom, etc. 
 You could turn things off or on according to your preference.

Now then, also analogous with Music Spacing, there should be a switch 
for "Automatic Lyric Reorganizing".  If you have that turned on then it 
will do this on the fly as you enter your data.  In other words, what 
Type in Score already half does, but more thoroughly and more 
logically, since it'll be looking at the whole document. (And like its 
fellow "Automatic" options, it'll probably slow down the program)

The information should also be there that this order can be 
over-ridden by using "click into score", as it is possible to write 
the syllables of any text in reverse order (back to front) and have 
the syllable appear in proper order in the score (front to back).  It 
is also possible using "click into score" to have syllables in the 
lyric box which do not ordinarily appear in the score, to assign 
multiple syllables to the same word, and assign multiple words to the 
same syllable.
All of which are things that are asking for trouble, if you ask me.  
Sure you can click-assign your syllables in reverse order of how they 
are in the lyric data.  But why?  For starters, it mucks up all your 
hyphens.  If your lyric data says, "you! to day birth- py Hap-" and you 
click-assign them into the score backward, hoping to get "Hap-py 
birth-day to you!", you'll actually get two strings of hyphens running 
off to the end of the system. (And heaven forbid you try a Shift 
Syllables on that!)

Similarly, if you're assigning multiple syllabes to the same note -- I 
assume you mean "note" instead of "word" in that last sentence, right? 
-- why wouldn't you want them to be in separate verses?  One voice 
isn't going to sing two syllables simultaneously, so the two syllables 
must be separate at some level, different voices, 1st vs 2nd repeat, 
original language vs tran

[Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-03 Thread Arkady

I wonder how accurate this review is in terms of speed issues. I don't work
with large scores, so it's hard for me to tell.

For the 1st time buyers, Macworld endorses Sibelius. For long time users of
Finale, they don't see a compelling reason for switching to Sibelius, not
that I was even considering that.

For me Mic Notator is important, and it doesn't exist in Sibelius.

Hope Finale fathers can find some new slick stuff up their sleeves, and
slick pr moves, as they compete with Sibelius.

Between the delay in F2004 for Mac release, and initial PDF issues, that
were solved with 2004B, I was quite concerned about Finale's future.

Hope that Finale is around forever! I simply don't want to learn another
program.  

 Arkady 
web site: http://www.arkady.com
Powerbook 17 1.33 MHz, Mac OS 10.3.4, Finale 2004B 


___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004Issue

2004-06-05 Thread Richard Yates

Tools -- options -- Spelling and grammar (and other tabs in this db)

RY

- Original Message - 
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, June 05, 2004 4:20 PM
Subject: Re: [Finale] Finale vs. Sibelius - Review in Macworld July
2004Issue


> >  >For example, I HATE the way Microsoft Word
> >  >makes assumptions about what I want done with my typing, like
> >  >"correcting" my spelling without telling me, or putting bullets or
> >  >numbers when I hit carriage return.
> >
> > You know you can turn all of that off, right?
> >
> > Aaron.
>
>
>  Hey, Aaron, I second and third and fourth what you wrote. Would
you
> please tell me the secret to turning off stuff in MS Word? No one in my
> church office seems to know.
>
> Eddy Wilson
> Landmark Church of God
> Statesville, NC
>
> ___
> Finale mailing list
> [EMAIL PROTECTED]
> http://lists.shsu.edu/mailman/listinfo/finale

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004Issue

2004-06-05 Thread Mark D Lew

On Jun 5, 2004, at 5:11 PM, Richard Yates wrote:
[answering Eddy Wilson]
 Hey, Aaron, I second and third and fourth what you wrote. 
Would
you
please tell me the secret to turning off stuff in MS Word? No one in 
my
church office seems to know.

Tools -- options -- Spelling and grammar (and other tabs in this db)
On MS Word for Mac OS X this stuff is under Tools -> AutoCorrect.  (For 
us, "Spelling and grammar" gives the spell checker and grammar 
checker.)

mdl
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

RE: [Finale] Finale vs. Sibelius - Review in Macworld July 2004Issue

2004-06-07 Thread Fisher, Allen

>>DON'T USE TYPE INTO SCORE<<

Why? In your entire rant about not using type into score, I didn't see a
clear reason why.

Allen

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

RE: [Finale] Finale vs. Sibelius - Review in Macworld July 2004Issue

On 7 Jun 2004 at 12:03, Fisher, Allen wrote:

> >>DON'T USE TYPE INTO SCORE<<
> 
> Why? In your entire rant about not using type into score, I didn't see
> a clear reason why.

Rant?

The reason not to use type in score is that it creates a text stream 
that doesn't really match the real text being set *unless* you have 
very carefully ordered your typing in a way that will create a 
comprehensible text in the actual data store.

With click assignment, you always know what the relationship is 
between the two. You can have a human readable ordered version of the 
text in Edit Lyrics and assign as needed with click assignment.

Yes, there are problems with the UI, and, oddly enough, they are 
really minor problems that ought to be very easily correctable (and 
should have been corrected 5 or more years ago) -- making the Edit 
Lyrics dialog resizable and having a ZOOM setting for one, and 
secondly, making the click assignment dialog resizable (or, at the 
very least, having a much more sensible default size -- as it is, the 
size would be small on 640x489!).

Type into score *ought* to be easier, but in the end, I found that 
it's much, much easier to type in the text once, click assign it, and 
add variants to the lyrics as needed.

I have also found it very useful because correcting spelling errors 
or adjusting syllable breaks (not adding syllable breaks -- changing 
from syll-a-lle to syl-la-ble) is much easier with a single text 
stream used in multiple locations than it is with multiple instances 
typed into the score.

However, Hal did say that with homophonic music, typing into one part 
then cloning to the others is very easy. I'll have to remember that, 
though I'll click assign the first part, and then clone the lyrics 
for the other parts.

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

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004Issue

David W. Fenton wrote:
The reason not to use type in score is that it creates a text stream
that doesn't really match the real text being set *unless* you have
very carefully ordered your typing in a way that will create a
comprehensible text in the actual data store. With click assignment, you always know what the relationship is between the two. You can have a human readable ordered version of the text in Edit Lyrics

Well, this does not match my experience. I have found that type into
score adds since WINFIN 2k creates the lyrics area of the data file by
placing the syllables sequentially, that the syllables are in the order
in which they appear in the score, and the syllables attached to the
various staves are in the order in which the respective first syllables
of each stave were entered. If among the four staves of a work, the
first syllable of each line were entered in the order "Alto, bass,
tenor, soprano", it is my experience that this is the order that the
syllables of each line appear in the lyrics data section of the file.

I am curious to know, though, David, when your experience with type into
score occurred. I know I have seen files where the lyrics appear
differently than I expect, but at the moment I do not recall if these
were Encore files imported into Finale (which I have done a few times),
or whether they were files created by early versions.

ns
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004Issue

On 7 Jun 2004 at 15:02, Noel Stoutenburg wrote:

> David W. Fenton wrote:
> 
> >The reason not to use type in score is that it creates a text stream
> >that doesn't really match the real text being set *unless* you have
> >very carefully ordered your typing in a way that will create a
> >comprehensible text in the actual data store.  With click assignment,
> >you always know what the relationship is between the two. You can
> >have a human readable ordered version of the  text in Edit Lyrics 
>
> Well, this does not match my experience.  I have found that type into
> score adds since WINFIN 2k creates the lyrics area of the data file by
> placing the syllables sequentially, that the syllables are in the
> order in which they appear in the score, and the syllables attached to
> the various staves are in the order in which the respective first
> syllables of each stave were entered.  If among the four staves of a
> work, the first syllable of each line were entered in the order "Alto,
> bass, tenor, soprano", it is my experience that this is the order that
> the syllables of each line appear in the lyrics data section of the
> file.

But you have to do the entry in the correct order to get the lyrics 
to come out comprehensibly. And you have to put in non-printing text 
to keep track of where you are. Why should you need to do that? 
Because the mechanism itself isn't good enough without your 
workarounds.

I don't need those extras when using click assignment, because I 
don't *need* separate text for the different voices.

> I am curious to know, though, David, when your experience with type
> into score occurred. . . .

August of 2002, my first project using WinFin2K3.

> . . . I know I have seen files where the lyrics appear
> differently than I expect, but at the moment I do not recall if these
> were Encore files imported into Finale (which I have done a few
> times), or whether they were files created by early versions.

Type in Score produced gibberish in Edit Lyrics, and there was no way 
to straighten it all out once it got messed up.

Since then, I've not used Type in Score at all and been able to fully 
control everything I wanted to do with lyrics.

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

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004Issue

Where David W. Fenton writes:
But [using type into score] you have to do the entry in the correct order to get the lyrics to come out comprehensibly.

I would suggest instead, that one merely needs to understand how Finale
places syllables in the lyrics area of the data file, in order to be
able to comprehend the lyrics. Finale does places the data here in a
predictable way, but the documentation specialists have either neglected
to, or decided not to tell us exactly what that way is. If one knows
what the way is, then the knowledge provides a set of tools to do other
things.

And you have to put in non-printing text to keep track of where you are. Why should you need to do that? Because the mechanism itself isn't good enough without your
workarounds.

I don't need those extras when using click assignment, because I
don't *need* separate text for the different voices.

Well, again, if I were adopting your work habits, I would still use
those extras. It's not that finale needs them to work correctly, nor do
I need them, but I find they do save a lot of time, especially if I need
to revisit old work, by clarifying exactly where (to borrow your
method) a lyric variant is used. My way of viewing these is to consider
them to be a kind of marginal comments, or perhaps more aptly, a
bookmark made from a post-it note [Just looking, I see four of these
post-it (R) bookmarks in my copy of Ross' book, two in Stone's, and too
many in Read's to count]. I could certainly find the information
without the post-it, but when I need the information, it's a whole lot
faster to use the post-it to take me right to the desired page quickly.

The tags I use are not the only way to do this; I could easily invent
other methods of achieving the same end without using tags. My choice
of using tags grew out of my desire to understand (when confronted with
things I didn't understand in the lyrics system) just how that system
worked, and I found them so useful I've just continued to use them.

ns
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-03 Thread Eric Dannewitz

The thing they should work on is linking parts to a score. It's a pain 
in the ass to work on something, and have to remember to change the 
score and other parts. It would be great to have them linked (if you 
wanted) to a score, so, a change in a part would be reflected in the 
score, and vice versa.


Arkady wrote:
I wonder how accurate this review is in terms of speed issues. I don't work
with large scores, so it's hard for me to tell.
For the 1st time buyers, Macworld endorses Sibelius. For long time users of
Finale, they don't see a compelling reason for switching to Sibelius, not
that I was even considering that.
For me Mic Notator is important, and it doesn't exist in Sibelius.
Hope Finale fathers can find some new slick stuff up their sleeves, and
slick pr moves, as they compete with Sibelius.
Between the delay in F2004 for Mac release, and initial PDF issues, that
were solved with 2004B, I was quite concerned about Finale's future.
Hope that Finale is around forever! I simply don't want to learn another
program.  

• Arkady 
web site: http://www.arkady.com
Powerbook 17 1.33 MHz, Mac OS 10.3.4, Finale 2004B 

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale
 

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-04 Thread Johannes Gebauer

On 04.06.2004 7:36 Uhr, Arkady wrote

> For me Mic Notator is important, and it doesn't exist in Sibelius.

REally? This is the first time I hear of anyone using this. Do you really
input your music with MicNotator successfully?

Johannes
-- 
http://www.musikmanufaktur.com
http://www.camerata-berolinensis.de

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

At 10:42 PM -0700 6/03/04, Eric Dannewitz wrote:
The thing they should work on is linking parts to a score. It's a 
pain in the ass to work on something, and have to remember to change 
the score and other parts. It would be great to have them linked (if 
you wanted) to a score, so, a change in a part would be reflected in 
the score, and vice versa.


This issue has come up before on this list, and there were a whole 
bunch of things discussed that I couldn't understand because I have 
little programming experience, but here is my main objection:

What would happen to the layout of the parts when you made a change 
to the score, if parts inherited changes automatically? For instance, 
what if you changed a former eight-measure rest in one part (takes up 
about 2 inches of a system) to eight bars of sixteenth notes (takes 
up 2 or 3 systems?) What about time signature changes? The only 
possible way to manage this is to have all system adjustments and 
page breaks in the parts disappear when you make a change, and this 
is exactly the same as re-extracting the part. What about the myriad 
things that are placed in one way in the score, but have to be nudged 
in the parts to avoid collisions? Would parts inherit nudges made in 
the score? That would be a pain. WOuld the score inherit nudges made 
in the parts? If not, it's exactly like it is now,and you would have 
to make nudges in BOTH, which is what you are trying to avoid.

BUT, IMHO, there is no real way to avoid different things in parts 
and score, as the criteria are different. For example, I often use 
beat spacing in scores, but note spacing in parts. This changes the 
placement of all kinds of things, and how could you expect the parts 
to logically inherit any placement changes you made to the score?

Christopher
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

Christopher BJ Smith wrote:
This issue has come up before on this list, and there were a whole 
bunch of things discussed that I couldn't understand because I have 
little programming experience, but here is my main objection:

What would happen to the layout of the parts when you made a change to 
the score, if parts inherited changes automatically? For instance, 
what if you changed a former eight-measure rest in one part (takes up 
about 2 inches of a system) to eight bars of sixteenth notes (takes up 
2 or 3 systems?) What about time signature changes? The only possible 
way to manage this is to have all system adjustments and page breaks 
in the parts disappear when you make a change, and this is exactly the 
same as re-extracting the part. What about the myriad things that are 
placed in one way in the score, but have to be nudged in the parts to 
avoid collisions? Would parts inherit nudges made in the score? That 
would be a pain. WOuld the score inherit nudges made in the parts? If 
not, it's exactly like it is now,and you would have to make nudges in 
BOTH, which is what you are trying to avoid.

I'd say that the linking would be strictly for notes. If you change the 
time signature, then yes it should change all the related parts. And it 
probably would change the layout.

How often do you have to nudge things in the score only? Last couple of 
scores I did I haven't had to do that.

BUT, IMHO, there is no real way to avoid different things in parts and 
score, as the criteria are different. For example, I often use beat 
spacing in scores, but note spacing in parts. This changes the 
placement of all kinds of things, and how could you expect the parts 
to logically inherit any placement changes you made to the score?
No, I think a linking of certain items would be great. Kind of like how 
Dynamics are now, you can individually place them, or have them be all 
the same. If you could decide what you want to be linked that would be 
cool. I'm mainly concerned with notes.

Someone mentioned that SCORE did this. Maybe they can explain how it 
works with that program and if it is a useful feature or not.  
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

At 11:17 AM -0700 6/04/04, Eric Dannewitz wrote:
Christopher BJ Smith wrote:
This issue has come up before on this list, and there were a whole 
bunch of things discussed that I couldn't understand because I have 
little programming experience, but here is my main objection:

What would happen to the layout of the parts when you made a change 
to the score, if parts inherited changes automatically? For 
instance, what if you changed a former eight-measure rest in one 
part (takes up about 2 inches of a system) to eight bars of 
sixteenth notes (takes up 2 or 3 systems?) What about time 
signature changes? The only possible way to manage this is to have 
all system adjustments and page breaks in the parts disappear when 
you make a change, and this is exactly the same as re-extracting 
the part. What about the myriad things that are placed in one way 
in the score, but have to be nudged in the parts to avoid 
collisions? Would parts inherit nudges made in the score? That 
would be a pain. WOuld the score inherit nudges made in the parts? 
If not, it's exactly like it is now,and you would have to make 
nudges in BOTH, which is what you are trying to avoid.

I'd say that the linking would be strictly for notes. If you change 
the time signature, then yes it should change all the related parts. 
And it probably would change the layout.

I'm still not getting it. If the layout has to change, then why not 
re-extract the part? If you are using Finale's default layout, then 
you should be happy, as it is all done automatically. If you are in 
the habit of changing the default layout on extracted parts, then you 
won't be happy with how it looks after you have changed some 
passages, and you will have to re-do the layout anyway, so why not 
just re-extract the part? And how does Finale decide when to clear 
your layout changes, and when to keep them?


How often do you have to nudge things in the score only? Last couple 
of scores I did I haven't had to do that.

Actually, I usually place things in the score so that I don't have to 
nudge them on the extracted parts, which looks really stupid on the 
score most often. Then after the parts are done, I go back and nudge 
the score, save it under a different name (Mytune print score or 
something like that) and print it. That way I only nudge an item 
once, on the score, rather than twenty times on the extracted parts.



BUT, IMHO, there is no real way to avoid different things in parts 
and score, as the criteria are different. For example, I often use 
beat spacing in scores, but note spacing in parts. This changes the 
placement of all kinds of things, and how could you expect the 
parts to logically inherit any placement changes you made to the 
score?
No, I think a linking of certain items would be great. Kind of like 
how Dynamics are now, you can individually place them, or have them 
be all the same. If you could decide what you want to be linked that 
would be cool. I'm mainly concerned with notes.

If you have only changed a few pitches, or added a few dynamics (as 
NOTE-attached expressions), chord symbols, or articulations, then you 
can update the parts pretty easily (ten minutes for a 20-staff score) 
with this procedure.

Open the revised score, click on the first staff's clef (let's say 
flute) to select the entire staff, command-C to copy.

Open the first flute part, lock the layout, select all, hit Delete 
(on the Mac, don't know the PC key to clear items.) Then hit 
command-V to paste all the notes, articulations, chord symbols, and 
note-attached expressions into the part.

Hit 4 to note-space. Update layout. Save it and/or print it. Repeat 
for the other instrument parts.

This will not work if you have changed keys, time signature, number 
of measures, page-attached text blocks, or staff-attached 
expressions. But then, aren't these the things that you don't want 
linked?


Someone mentioned that SCORE did this. Maybe they can explain how it 
works with that program and if it is a useful feature or not.

I'd like to hear about that too.
Christopher
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-04 Thread Aaron Sherber

At 03:47 PM 06/04/2004, Christopher BJ Smith wrote:
>I'm still not getting it. If the layout has to change, then why not
>re-extract the part?
This is probably one of those things that comes down to each person's 
working habits, but since you asked

When I extract parts, even with Page Layout for Parts set just the way I 
want it, there's quite a bit of manual tweaking I do. For example, I like 
to have the instrument name in the page header. I also check page breaks, 
indent the beginnings of new movements, verify that text expressions are in 
the right place, etc. If I go back to a finished piece and make some 
changes, most often I'm just fixing wrong notes; this usually doesn't take 
any layout adjustment in the parts, so having the change automatically 
propagate from score to parts is great. Even if I have to add a few 
measures, or change something that does require part layout adjustment, I 
would bet that re-extracting the part isn't worth it, because I would have 
to go back and do all the large-scale fixes again -- the "fixed costs" of 
part extraction.

My current process is to make the change in the score, then make the same 
change in the part, and then tweak the part if needed. Linkage between 
score and parts would make teh second step unnecessary -- I would never 
have to worry that my parts have fallen out of sync with my score.

>And how does Finale decide when to clear
>your layout changes, and when to keep them?
Personally, I think the linkage should be such that Finale never alters the 
layout of an already-extracted part -- it just makes the changes and leaves 
the layout up to me. In other words, the linkage is sort of between the 
Scroll Views of score and parts, not Page View.

>This will not work if you have changed keys, time signature, number
>of measures, page-attached text blocks, or staff-attached
>expressions. But then, aren't these the things that you don't want
>linked?
Of the things you mentioned, I think only page-attached blocks wouldn't be 
linked.

>>Someone mentioned that SCORE did this. Maybe they can explain how it
>>works with that program and if it is a useful feature or not.
>
>I'd like to hear about that too.
And Igor, I think.
Aaron.
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

Christopher BJ Smith wrote:
I'm still not getting it. If the layout has to change, then why not 
re-extract the part? If you are using Finale's default layout, then 
you should be happy, as it is all done automatically. If you are in 
the habit of changing the default layout on extracted parts, then you 
won't be happy with how it looks after you have changed some passages, 
and you will have to re-do the layout anyway, so why not just 
re-extract the part? And how does Finale decide when to clear your 
layout changes, and when to keep them?

I think it would be just for notes, not layout. Finale's default layout 
and happy in the same sentance? Not. I've never used the default 
layouts. Never.

Layout would probably NOT be linked, but NOTES would. Does that make 
sense? I can't count how many times I've changed something in a score 
and FORGOT to update it in a part. Re extracting the part would be way 
more time consuming. The placement of titles, etc, etc. I'd just like to 
have the note DATA updated throughout a piece. Each part's layout is 
different on the stuff I do.

Actually, I usually place things in the score so that I don't have to 
nudge them on the extracted parts, which looks really stupid on the 
score most often. Then after the parts are done, I go back and nudge 
the score, save it under a different name (Mytune print score or 
something like that) and print it. That way I only nudge an item once, 
on the score, rather than twenty times on the extracted parts.

Hmm, I haven't had any problems like. I'm usually happy with the 
placement of dynamics and such. TGTools is a great thing to align items.

If you have only changed a few pitches, or added a few dynamics (as 
NOTE-attached expressions), chord symbols, or articulations, then you 
can update the parts pretty easily (ten minutes for a 20-staff score) 
with this procedure.

Open the revised score, click on the first staff's clef (let's say 
flute) to select the entire staff, command-C to copy.

Open the first flute part, lock the layout, select all, hit Delete (on 
the Mac, don't know the PC key to clear items.) Then hit command-V to 
paste all the notes, articulations, chord symbols, and note-attached 
expressions into the part.

Hit 4 to note-space. Update layout. Save it and/or print it. Repeat 
for the other instrument parts.

This will not work if you have changed keys, time signature, number of 
measures, page-attached text blocks, or staff-attached expressions. 
But then, aren't these the things that you don't want linked?
Key and time signature would be linked, as number of measures. I think 
kind of what http://www.noteheads.com/igor/igor.html Igor does. Where 
you can have separate layouts for parts, and tell the program what you 
want linked, but it will update major changes (IE: Keys, time 
signatures, notes, etc).

I know that it would save ME time, and others that I know. That's the 
one pain in the butt part with Finale, extracting parts.

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

At 2:00 PM -0700 6/04/04, Eric Dannewitz wrote:
Layout would probably NOT be linked, but NOTES would. Does that make 
sense? I can't count how many times I've changed something in a 
score and FORGOT to update it in a part. Re extracting the part 
would be way more time consuming. The placement of titles, etc, etc. 
I'd just like to have the note DATA updated throughout a piece. Each 
part's layout is different on the stuff I do.

Once again, my little copying routine that I noted is so easy, that I 
can hardly imagine justifying the kind of rewriting it would take to 
accomplish linking ONLY notes in Finale. And doesn't anyone edit 
anything else?


Key and time signature would be linked, as number of measures. I 
think kind of what http://www.noteheads.com/igor/igor.html Igor 
does. Where you can have separate layouts for parts, and tell the 
program what you want linked, but it will update major changes (IE: 
Keys, time signatures, notes, etc).

Hmm, it looks like kind of the same case as with Sibelius, that you 
are more or less stuck with the default placements, unless you want 
your score inheriting the adjustments you make to your parts.

I suppose this amounts to a different philosophy about what I want my 
notation program to do. For example, I HATE the way Microsoft Word 
makes assumptions about what I want done with my typing, like 
"correcting" my spelling without telling me, or putting bullets or 
numbers when I hit carriage return. And I STILL haven't worked out 
the formatting! I use AppleWorks instead, because it does what I tell 
it to. It would probably bug me to have Finale getting too big for 
its britches, writing changes to files that I didn't tell it to.

Christopher
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-04 Thread David W. Fenton

On 4 Jun 2004 at 18:55, Christopher BJ Smith wrote:

> I suppose this amounts to a different philosophy about what I want my
> notation program to do.

You seem to assume a number of things:

1. layout in the linked part would not be as fully adjustable as 
layout in an extracted part.

2. the implementation of such a feature would be accompanied by the 
removal of the current part extraction capability.

Why is it that whenever someone proposes what are obvious changes to 
Finale that would make it much, much easier to use that so many 
people argue against the change on the grounds that it would be 
implemented in the most stupid fashion imaginable?

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

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-04 Thread Aaron Sherber

At 06:55 PM 06/04/2004, Christopher BJ Smith wrote:
>For example, I HATE the way Microsoft Word
>makes assumptions about what I want done with my typing, like
>"correcting" my spelling without telling me, or putting bullets or
>numbers when I hit carriage return.
You know you can turn all of that off, right?
Aaron.
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

Christopher BJ Smith wrote:
Once again, my little copying routine that I noted is so easy, that I 
can hardly imagine justifying the kind of rewriting it would take to 
accomplish linking ONLY notes in Finale. And doesn't anyone edit 
anything else?

But if you find yourself doing this a LOT, wouldn't you think that there 
ought to be an easier way to do it? And yes, people do edit other 
things, but if this linking was done right it would  be slick.

Hmm, it looks like kind of the same case as with Sibelius, that you 
are more or less stuck with the default placements, unless you want 
your score inheriting the adjustments you make to your parts.

I suppose this amounts to a different philosophy about what I want my 
notation program to do. For example, I HATE the way Microsoft Word 
makes assumptions about what I want done with my typing, like 
"correcting" my spelling without telling me, or putting bullets or 
numbers when I hit carriage return. And I STILL haven't worked out the 
formatting! I use AppleWorks instead, because it does what I tell it 
to. It would probably bug me to have Finale getting too big for its 
britches, writing changes to files that I didn't tell it to.
No, I'm not saying for Finale to start TELLING you what to do. I hate 
that as well, but it would make a lot of sense to be able to have a 
score with related parts that are linked at a user defined degree. Think 
of it like a relational database. You might think an Excel datasheet 
works for everything, and when someone proposes to "relationalize" your 
data, you might think "what's the point", but in the bigger picture it 
makes a whole lot more sense, and I think the next step in Finale would 
be to do this.
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-04 Thread dhbailey

David W. Fenton wrote:
On 4 Jun 2004 at 18:55, Christopher BJ Smith wrote:

I suppose this amounts to a different philosophy about what I want my
notation program to do.

You seem to assume a number of things:
1. layout in the linked part would not be as fully adjustable as 
layout in an extracted part.

2. the implementation of such a feature would be accompanied by the 
removal of the current part extraction capability.

Why is it that whenever someone proposes what are obvious changes to 
Finale that would make it much, much easier to use that so many 
people argue against the change on the grounds that it would be 
implemented in the most stupid fashion imaginable?

Because of features such as MicNotator and MidiScan and Hyperscribe and 
the Tempo Tool you were just complaining about, and on and on and on.

It seems nothing gets implemented these days in Finale without being 
totally backwards or inefficient.  Human Playback where we can edit LOTS 
of stuff EXCEPT the important things such as trills and other ornaments.

The only thing which has been implemented properly, recently, in my 
opinion, has been staff styles.  THEY were/are a stroke of genius and 
are implemented properly.  I suppose if MakeMusic were to reconstruct 
the development team that produced staff styles they might have a shot 
at a logical and actually helpful implementation of part/score linking.

But we are several versions away from the introduction of staff styles 
and each new version has produced bloat without productivity increases.


--
David H. Bailey
[EMAIL PROTECTED]
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-04 Thread David W. Fenton

On 4 Jun 2004 at 20:36, dhbailey wrote:

> David W. Fenton wrote:
> 
> > On 4 Jun 2004 at 18:55, Christopher BJ Smith wrote:
> > 
> >>I suppose this amounts to a different philosophy about what I want
> >>my notation program to do.
> > 
> > 
> > You seem to assume a number of things:
> > 
> > 1. layout in the linked part would not be as fully adjustable as
> > layout in an extracted part.
> > 
> > 2. the implementation of such a feature would be accompanied by the
> > removal of the current part extraction capability.
> > 
> > Why is it that whenever someone proposes what are obvious changes to
> > Finale that would make it much, much easier to use that so many
> > people argue against the change on the grounds that it would be
> > implemented in the most stupid fashion imaginable?
> > 
> 
> Because of features such as MicNotator and MidiScan and Hyperscribe
> and the Tempo Tool you were just complaining about, and on and on and
> on.

The first two there were added in and did not change in any way the 
behavior of the rest of Finale.

Hyperscribe and the Tempo Tool seem to me to be relatively unchanged 
from my memory of them in the earliest version of Finale I used, 
2.01. Hyperscribe was clearly useless, and I concluded the same thing 
about the Tempo Tool, since I didn't know there was a way to make 
tempo changes be saved to MIDI files.

> It seems nothing gets implemented these days in Finale without being
> totally backwards or inefficient.  Human Playback where we can edit
> LOTS of stuff EXCEPT the important things such as trills and other
> ornaments.

But you can turn it off and still use all the playback tools Finale 
always had, right?

> The only thing which has been implemented properly, recently, in my
> opinion, has been staff styles. . . . 

Well, except for spacing of blank notation. . .

> . . . THEY were/are a stroke of genius and
> are implemented properly.  I suppose if MakeMusic were to reconstruct
> the development team that produced staff styles they might have a shot
> at a logical and actually helpful implementation of part/score
> linking.

When I was trying to get Winsupport to understand that blank notation 
spacing was broken in a way that had no rational justification, I was 
told that they consulted with the people who implemented staff 
styles, so those people are apparently still working at Coda.

> But we are several versions away from the introduction of staff styles
> and each new version has produced bloat without productivity
> increases.

Yes, and old things continue to have terrible problems.

I've been saying for more than five years that Finale needs to be 
redesigned in major ways to correct many of the underlying flaws.

But it's not going to happen.

And I predict I won't be using Finale 5 years from now.

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

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

At 7:50 PM -0400 6/04/04, Aaron Sherber wrote:
At 06:55 PM 06/04/2004, Christopher BJ Smith wrote:
For example, I HATE the way Microsoft Word
makes assumptions about what I want done with my typing, like
"correcting" my spelling without telling me, or putting bullets or
numbers when I hit carriage return.
You know you can turn all of that off, right?
Aaron.
Yes, I heard that I could. Unfortunately, my wife likes it that way, 
and I use AppleWorks, so I avoid the whole issue.
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

At 7:50 PM -0400 6/04/04, David W. Fenton wrote:
On 4 Jun 2004 at 18:55, Christopher BJ Smith wrote:
 I suppose this amounts to a different philosophy about what I want my
 notation program to do.
You seem to assume a number of things:
1. layout in the linked part would not be as fully adjustable as
layout in an extracted part.

I didn't assume that at all (except in the case of Sibelius, where 
parts inherit score layout, and possibly in the case of Igor, where I 
read between the lines from the presentation on the website).

I just think that if you are going to have to re-jig almost every 
aspect of your part layout once you change something, why not just 
re-extract parts again?


2. the implementation of such a feature would be accompanied by the
removal of the current part extraction capability.

Actually, we kind of have that feature already. I don't use it, and 
neither does anyone else I know, possibly because it IS implemented 
in a stupid fashion (or at least a not-very-useful fashion). In a 
score with the Staff tool selected, click on a clef to select the 
staff, then go to the Edit menu and check Special Part Extraction. In 
scroll view, nothing happens, you still see the whole score. In Page 
view, the staff is alone and extracted. No new file, all changes to 
the part are immediately reflected in the score  and vice versa (just 
turn off Special Part Extraction or else go to Scroll View to see the 
whole score.)  PRint as you like, change staves to go to another 
part. I don't see the use of this feature, for most of the reasons I 
have already stated.


Why is it that whenever someone proposes what are obvious changes to
Finale that would make it much, much easier to use that so many
people argue against the change on the grounds that it would be
implemented in the most stupid fashion imaginable?

I dunno, previous experience? (Lyric Tool, Ossia Tool, Midi Tool, 
certain aspects of the Repeat Tool, to name a few.)

Christopher
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

At 5:35 PM -0700 6/04/04, Eric Dannewitz wrote:
Christopher BJ Smith wrote:
Once again, my little copying routine that I noted is so easy, that 
I can hardly imagine justifying the kind of rewriting it would take 
to accomplish linking ONLY notes in Finale. And doesn't anyone edit 
anything else?

But if you find yourself doing this a LOT, wouldn't you think that 
there ought to be an easier way to do it? And yes, people do edit 
other things, but if this linking was done right it would  be slick.

Well, I have a couple of macros to accomplish it. Mostly I want to 
keep control. I re-extract when I see the need, and use the routine I 
outlined when it would create less work.


No, I'm not saying for Finale to start TELLING you what to do. I 
hate that as well, but it would make a lot of sense to be able to 
have a score with related parts that are linked at a user defined 
degree. Think of it like a relational database. You might think an 
Excel datasheet works for everything, and when someone proposes to 
"relationalize" your data, you might think "what's the point", but 
in the bigger picture it makes a whole lot more sense, and I think 
the next step in Finale would be to do this.

You know, this is what I was referring to when I mentioned 
experienced programmers seeming to see things that I don't. I don't 
understand the term "relational database." Maybe if I did, I would 
"get" what all you guys want out of Finale.

Christopher
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

Christopher BJ Smith wrote:
At 7:50 PM -0400 6/04/04, David W. Fenton wrote:
On 4 Jun 2004 at 18:55, Christopher BJ Smith wrote:
 I suppose this amounts to a different philosophy about what I want my
 notation program to do.

You seem to assume a number of things:
1. layout in the linked part would not be as fully adjustable as
layout in an extracted part.

I didn't assume that at all (except in the case of Sibelius, where 
parts inherit score layout, and possibly in the case of Igor, where I 
read between the lines from the presentation on the website).

I just think that if you are going to have to re-jig almost every 
aspect of your part layout once you change something, why not just 
re-extract parts again?
Why do you think that? Say you change 8 measures of music, is that going 
to screw up the whole page format? no. But it would be a pain in the ass 
to update all the extracted parts, etc, etc. If they were linked 
together, boom, it's done.

Actually, we kind of have that feature already. I don't use it, and 
neither does anyone else I know, possibly because it IS implemented in 
a stupid fashion (or at least a not-very-useful fashion). In a score 
with the Staff tool selected, click on a clef to select the staff, 
then go to the Edit menu and check Special Part Extraction. In scroll 
view, nothing happens, you still see the whole score. In Page view, 
the staff is alone and extracted. No new file, all changes to the part 
are immediately reflected in the score  and vice versa (just turn off 
Special Part Extraction or else go to Scroll View to see the whole 
score.)  PRint as you like, change staves to go to another part. I 
don't see the use of this feature, for most of the reasons I have 
already stated.
Thats like letting Finale print the parts for you. I can't ever remember 
doing that and liking the results. It would be great to keep a score and 
the parts together in ONE file, and have separate layouts for each. Then 
you can change the music, but you have to go through and redo all the 
page layouts.


I dunno, previous experience? (Lyric Tool, Ossia Tool, Midi Tool, 
certain aspects of the Repeat Tool, to name a few.)
Lyric tool works well. Repeat Tool too. Haven't needed to dabble with 
the Ossia tool in eons.
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

Christopher BJ Smith wrote:
You know, this is what I was referring to when I mentioned experienced 
programmers seeming to see things that I don't. I don't understand the 
term "relational database." Maybe if I did, I would "get" what all you 
guys want out of Finale.

Relational databases. See 
http://searchdatabase.techtarget.com/sDefinition/0%2C%2Csid13_gci212885%2C00.html
Basically, you split things into parts and link them together. Like test 
scores. You would have a name, their answers, the answer key all in 
separate tables linked together. You could put them all FLAT together, 
like a spreadsheet. But there is so much more you can do with data 
relationalized. Finale is like a spreadsheet. If it was more like a 
relational database, you could do a lot more with it.
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-04 Thread Mark D Lew

On Jun 4, 2004, at 9:29 PM, Eric Dannewitz wrote:
Lyric tool works well.
Really?  Lyric tool works well if you know what you're doing, or if you 
never do anything complicated, but it has lots of pit-traps that the 
unwray can fall into.  And there are failings, too, such as control 
over hyphen behavior.

mdl
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

At 9:29 PM -0700 6/04/04, Eric Dannewitz wrote:
Christopher BJ Smith wrote:
I just think that if you are going to have to re-jig almost every 
aspect of your part layout once you change something, why not just 
re-extract parts again?
Why do you think that? Say you change 8 measures of music, is that 
going to screw up the whole page format?

Yes! If you have added notes where they had rests before! Or added 
8ths where they had whole notes, etc. Especially if it's the FIRST 8 
bars. Nothing to do but reformat.



Actually, we kind of have that feature already. (snip)
Thats like letting Finale print the parts for you. I can't ever 
remember doing that and liking the results. It would be great to 
keep a score and the parts together in ONE file, and have separate 
layouts for each. Then you can change the music, but you have to go 
through and redo all the page layouts.

As was mentioned a message or two ago, you can set the page layout, 
and adjust items but NOT separately for each part. That's the "kind 
of" I was talking about. Maybe a better implementation would make it 
more usable for me.



I dunno, previous experience? (Lyric Tool, Ossia Tool, Midi Tool, 
certain aspects of the Repeat Tool, to name a few.)
Lyric tool works well.

Try adding or copying lyrics when a word has two syllables across a 
barline. And how do you shift syllables for the second verse without 
messing up the first verse? It's true that it is better than it was, 
but one still has to be careful, or major screw-ups can occur.


Repeat Tool too.

Not the repeat symbols, like the $ or the coda target. They never 
stay where you put them (up to version 2003). This has not changed 
much since 3.2.

Christopher
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

At 9:29 PM -0700 6/04/04, Eric Dannewitz wrote:

Thats like letting Finale print the parts for you. I can't ever 
remember doing that and liking the results. It would be great to 
keep a score and the parts together in ONE file, and have separate 
layouts for each. Then you can change the music, but you have to go 
through and redo all the page layouts.

OK, I read your link about relational databases. Thank you for the 
easy-to-understand link. I think I get it now. For this to work in 
Finale, we would want to be able to click on Special Part Extraction, 
and have:

control over system breaks for each staff, OR apply the same ones to 
another staff, as we wish. Also, (kind of like Mirrors) we should be 
able to stay linked to another part, or break away, as we wish.

Have the titles in the upper left corner of Page 1 and in a  defined 
text block on successive pages inherit the name of the staff, 
editable without destroying the name on the score if we don't want it 
to be changed.

have all staff expressions, articulations, etc., have two states, 
their score position, and their adjusted position in the part, if 
needed. Be able to make parts inherit changes made to positioning in 
the score. I'm a little foggy on this last one, should it be absolute 
positioning, or relative to the previous position? Maybe selecting an 
item and hitting Clear (Mac) would make it revert to default 
positioning, as some items do already.

Likewise for Smart Shapes, Lyrics, Chords, umm, am I missing anything?
Maybe we would like to be able to save the view in an easily 
retrievable format. Clicking the staff and then going into a menu is 
one mouse movement too much for me. Perhaps a keyboard shortcut would 
solve it.

Now comes the hard part: How far away is Finale's structure from a 
relational database to be able to accomplish this in a reasonable 
number of programmer hours?

Christopher
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On 5 Jun 2004 at 0:11, Christopher BJ Smith wrote:

> At 7:50 PM -0400 6/04/04, David W. Fenton wrote:
> >On 4 Jun 2004 at 18:55, Christopher BJ Smith wrote:
> >
> >>  I suppose this amounts to a different philosophy about what I want
> >>  my notation program to do.
> >
> >You seem to assume a number of things:
> >
> >1. layout in the linked part would not be as fully adjustable as
> >layout in an extracted part.
> 
> 
> I didn't assume that at all (except in the case of Sibelius, where
> parts inherit score layout, and possibly in the case of Igor, where I
> read between the lines from the presentation on the website).
> 
> I just think that if you are going to have to re-jig almost every
> aspect of your part layout once you change something, why not just
> re-extract parts again?

But that's a big *if*. Most of the changes I've found at that point 
is just different notes, changed bowings (in the case of string 
parts), and perhaps altered dynamics.

If you're re-writing huge sections, then, yes, you might have to redo 
the layout.

But that would be the case with extracted parts, so the advantage of 
being able to make many other kinds of much more common changes 
*without* having to redo the layout seems quite worth having.

> >2. the implementation of such a feature would be accompanied by the
> >removal of the current part extraction capability.
> 
> Actually, we kind of have that feature already. I don't use it, and
> neither does anyone else I know, possibly because it IS implemented in
> a stupid fashion (or at least a not-very-useful fashion). In a score
> with the Staff tool selected, click on a clef to select the staff,
> then go to the Edit menu and check Special Part Extraction. In scroll
> view, nothing happens, you still see the whole score. In Page view,
> the staff is alone and extracted. No new file, all changes to the part
> are immediately reflected in the score  and vice versa (just turn off
> Special Part Extraction or else go to Scroll View to see the whole
> score.)  PRint as you like, change staves to go to another part. I
> don't see the use of this feature, for most of the reasons I have
> already stated.

The reason why special part extraction is useless to me is that you 
can't *save* the layout changes for the parts. There is absolutely no 
reason why there couldn't be two sets of layout information, one for 
score view and one for part view. Yes, of course, it would require 
alterations to the file format. But it would simply be another area 
where object-oriented thinking (with subclassing, inheritance and 
polymorphism) would be of great benefit (I've been arguing for that 
for years and years).

Indeed, properly it should be implemented like stylesheets for web 
pages. You can change the entire look of a web page (not just colors 
and fonts) by changing to a different stylesheet. If Finale files 
stored a score layout that defined systems and page layout, and a 
separate part layout, and also allowed you to save individual tweaks 
to particular parts, it would be perfect.

Yes, if you added 10 measures in the middle, it would break the 
existing layouts, but that's the case today, as well.

> >Why is it that whenever someone proposes what are obvious changes to
> >Finale that would make it much, much easier to use that so many
> >people argue against the change on the grounds that it would be
> >implemented in the most stupid fashion imaginable?
> 
> I dunno, previous experience? (Lyric Tool, Ossia Tool, Midi Tool,
> certain aspects of the Repeat Tool, to name a few.)

I didn't use the Lyrics Tool before it's revision, so I don't know 
what was broken. What, specifically, are you speaking of there?

As to the other tools, I don't see any changes in them -- they 
basically behave the way they have as long as I've used Finale.

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

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On 5 Jun 2004 at 0:17, Christopher BJ Smith wrote:

> At 5:35 PM -0700 6/04/04, Eric Dannewitz wrote:
> >Christopher BJ Smith wrote:
> >
> >>Once again, my little copying routine that I noted is so easy, that
> >>I can hardly imagine justifying the kind of rewriting it would take
> >>to accomplish linking ONLY notes in Finale. And doesn't anyone edit
> >>anything else?
> >>
> >But if you find yourself doing this a LOT, wouldn't you think that
> >there ought to be an easier way to do it? And yes, people do edit
> >other things, but if this linking was done right it would  be slick.
> 
> Well, I have a couple of macros to accomplish it. Mostly I want to
> keep control. I re-extract when I see the need, and use the routine I
> outlined when it would create less work.

But why do you simply *assume* that linked parts would take away 
control and prevent you from using your present routine?

I don't see anyone who wants linked parts advocating the removal of 
the present part extraction methods.

> >No, I'm not saying for Finale to start TELLING you what to do. I hate
> >that as well, but it would make a lot of sense to be able to have a
> >score with related parts that are linked at a user defined degree.
> >Think of it like a relational database. You might think an Excel
> >datasheet works for everything, and when someone proposes to
> >"relationalize" your data, you might think "what's the point", but in
> >the bigger picture it makes a whole lot more sense, and I think the
> >next step in Finale would be to do this.
> 
> You know, this is what I was referring to when I mentioned 
> experienced programmers seeming to see things that I don't. I don't
> understand the term "relational database." Maybe if I did, I would
> "get" what all you guys want out of Finale.

The key distinction between data stored in a spreadsheet and data 
stored in a relational database is that the latter separates data 
storage from data presentation, whereas in a spreadsheet, the place 
where you store the data is the same place used for printing -- there 
is no separation between data layout and print layout in a 
spreadsheet (though that's not entirely true -- certain kinds of 
features do allow multiple presentations of the same data from one 
worksheet).

In a relational database, the data is stored in objects that are 
designed to represent the characteristics of the data itself, with no 
concern for printout or presentation. In a relational database, a 
report can be used to draw data from multiple related data tables and 
present it in any number of different ways, each specific to the 
purpose of the individual report, hiding certain things, revealing 
certain others.

For example:

  http://www.bway.net/~dfassoc/Park/Reports.html

There are a couple dozen reports, presenting data mostly from a 
handful of data tables. In a spreadsheet, each of those reports would 
require its own spreadsheet page (or, perhaps, in the case of closely 
related reports, editing of a single spreadsheet page to produce two 
slighly different printouts), but in a relational database, the 
report layout is defined entirely separately from the data, allowing 
an infinite number of presentations, without requiring re-arrangement 
of the underlying data.

A score printout and a part printout ought to be defined at the same 
level, as something cosmetic that is independent of the underlying 
music represented in it. Then you could have as many different 
presentations as you wanted, and changes to the music would flow 
through into all the various printed versions.

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

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On 4 Jun 2004 at 22:17, Mark D Lew wrote:

> On Jun 4, 2004, at 9:29 PM, Eric Dannewitz wrote:
> 
> > Lyric tool works well.
> 
> Really?  Lyric tool works well if you know what you're doing, or if
> you never do anything complicated, but it has lots of pit-traps that
> the unwray can fall into.  And there are failings, too, such as
> control over hyphen behavior.

Well, as much as I complained about lyrics in my first big project 
with them (in August 2002), now that I learned from all the gurus 
here on the list, I find it pretty darned easy to use. The main 
point:

  DON'T USE TYPE INTO SCORE

Once you figure that out, it's pretty easy to use.

But, of course, I thought we were discussing examples of 
subcomponents of Finale that were majorly overhauled and then never 
worked right any more. When has the Lyrics subsystem been overhauled 
and exactly what ended up badly broken?

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

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On 5 Jun 2004 at 1:34, Christopher BJ Smith wrote:

> At 9:29 PM -0700 6/04/04, Eric Dannewitz wrote:
> >Christopher BJ Smith wrote:
> >>
> >>I just think that if you are going to have to re-jig almost every
> >>aspect of your part layout once you change something, why not just
> >>re-extract parts again?
> >
> >Why do you think that? Say you change 8 measures of music, is that
> >going to screw up the whole page format?
> 
> Yes! If you have added notes where they had rests before! Or added
> 8ths where they had whole notes, etc. Especially if it's the FIRST 8
> bars. Nothing to do but reformat.

But you'd have to redo it with extracted parts, too, so on this kind 
of change the two approaches are equivalent.

But on less drastic changes, such as fixing wrong notes, tweaking 
dynamics, changing bowings after a read-through, and so forth, linked 
parts would be substantially less work.

Why discard the advantages of linked parts just because they wouldn't 
cook your breakfast for you every morning?

> >>Actually, we kind of have that feature already. (snip)
> >
> >Thats like letting Finale print the parts for you. I can't ever
> >remember doing that and liking the results. It would be great to keep
> >a score and the parts together in ONE file, and have separate layouts
> >for each. Then you can change the music, but you have to go through
> >and redo all the page layouts.
> 
> As was mentioned a message or two ago, you can set the page layout,
> and adjust items but NOT separately for each part. That's the "kind
> of" I was talking about. Maybe a better implementation would make it
> more usable for me.

That's why I don't use special part extraction except when I need to 
extract more than one staff to a part. Even then, it annoys me that I 
have to initiate a separate file. If special part extraction kept its 
layout settings separate for each part and separate from the full 
score, it would provide the linked parts capability I'd like to see.

But it doesn't do that.

> >>I dunno, previous experience? (Lyric Tool, Ossia Tool, Midi Tool,
> >>certain aspects of the Repeat Tool, to name a few.)
> >
> >Lyric tool works well.
> 
> Try adding or copying lyrics when a word has two syllables across a
> barline. And how do you shift syllables for the second verse without
> messing up the first verse? It's true that it is better than it was,
> but one still has to be careful, or major screw-ups can occur.

It has improved?

You brought up lyrics in response to my suggestion that you are 
assuming that a major overhaul is going to break things that already 
work. Here you're admitting that lyrics are, in fact, better than 
they used to be.

> >Repeat Tool too.
> 
> Not the repeat symbols, like the $ or the coda target. They never stay
> where you put them (up to version 2003). This has not changed much
> since 3.2.

Again, this is just one of many old bugs that have been hanging 
around.

I can see arguing that those should be fixed before embarking on 
major overhauls to parts of Finale that are already usable.

But I don't think it's at all valid to use those long-persisting bugs 
as an argument against no major overhauls.

What if Coda had fixed these bugs of yours instead of re-doing the 
text tool back in Finale 3.x? Isn't the huge improvement in usability 
of the text tool much more of a productivity improvement than the 
fixing of any one of those tiny bugs? What about the improvements in 
page layout in Finale 98 (or was it 2K1?)? Should those have been 
left out to fix a number of small bugs, instead?

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

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On 5 Jun 2004 at 1:55, Christopher BJ Smith wrote:

> Now comes the hard part: How far away is Finale's structure from a
> relational database to be able to accomplish this in a reasonable
> number of programmer hours?

Finale's data is already stored in a database.

Whether it's truly relational or not isn't really the point.

The point is that page layout information is stored separately from 
the music data.

I'm not saying it would be easy to do this -- indeed, it would 
probably be quite difficult -- but there is nothing inherent to the 
way Finale stores its data (so far as I understand it) that would 
make it impossible. It should only require an extension to the file 
format to store the additional layout information and changes to the 
program to allow the application of that additional layout 
information to the appropriate contexts.

You described the feature set just about perfectly, actually.

Programming difficulties aside, wouldn't you *want* those features if 
Coda implemented them? Wouldn't they greatly improve your 
productivity?

If find that extracting parts is one of the most unpleasant parts of 
Finale -- I put it off and put it off, especially because after 
proofing the first run of them, I always have to go back and alter 
the score, and in many cases the changes are numerous enough that I 
feel that I need to re-extract the parts (instead of making the 
changes in two locations).

While linked parts wouldn't completely eliminate the work it would 
take to prepare parts the first time, it would vastly reduce the 
amount of work it takes to implement revisions to the parts once they 
are laid out the first time.

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

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

At 2:49 PM -0400 6/05/04, David W. Fenton wrote:
On 5 Jun 2004 at 0:17, Christopher BJ Smith wrote:
 > Well, I have a couple of macros to accomplish it. Mostly I want to
 keep control. I re-extract when I see the need, and use the routine I
 outlined when it would create less work.
But why do you simply *assume* that linked parts would take away
control and prevent you from using your present routine?

I think you may have misread my intent. I wasn't afraid that linked 
parts would take away my present work method, I was just explaining 
why linked parts aren't important to me. However, now that I have 
checked out a bit what advantages might be involved, I think I am 
coming around.

What I AM afraid of is new features taking time away from working out 
the bugs in the features that are already there, or creating a 
program that is so bloated that it won't run at a usable speed except 
on the newest hardware.

 > You know, this is what I was referring to when I mentioned
 experienced programmers seeming to see things that I don't. I don't
 understand the term "relational database." Maybe if I did, I would
 "get" what all you guys want out of Finale.
The key distinction between data stored in a spreadsheet and data
stored in a relational database
(good stuff snipped)
A score printout and a part printout ought to be defined at the same
level, as something cosmetic that is independent of the underlying
music represented in it. Then you could have as many different
presentations as you wanted, and changes to the music would flow
through into all the various printed versions.

I had gathered as much from some other explanations that came my way 
since I confessed ignorance. This looks actually quite interesting. 
Did you see my reply enumerating what I thought such a architecture 
should contain? Do you see anything missing?

Christopher
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On 5 Jun 2004 at 14:59, Christopher BJ Smith wrote:

> Did you see my reply enumerating what I thought such a architecture
> should contain? Do you see anything missing?

Yes -- I replied to your earlier messages before reading that.

You described it quite well, I thought.

I'd *love* to have the capabilities you described.

Of course, I'd also like to have subclassing of expressions and 
articulations, so that you could override the behavior of individual 
instances, rather than having to create multiple visually 
indistinguishable versions of the same expression/articulation for 
various purposes.

Also, I'd like to have the ability to define non-printing expressions 
without having to use the , as with non-printing 
articulations. And I'd like the display of the non-printing ones to 
be distinct from the printing ones.

My reasons for this:

1. Most of my Finale work is transcribing original 
manuscripts/editions, and I want to retain as much of the original in 
my transcription.

2. But, I also want to create editions from these. At present I add 
non-printing expressions/articulations for creating my MIDI 
performances. When it comes time to produce and edition, some of 
these I will convert to printed editorial suggestions, distinct in 
appearance from the ones in the original source. 

Right now all I have to do is alter the expression/articulation to 
have a distinct appearance and then make it printable. But in the 
case of articulations, it's annoying to not be able to tell onscreen 
which is which (it's clear with expressions).

And if the subclassing I'd like were implemented, none of this would 
be necessary. Instead, you'd insert the expression/articulation 
intended, and then right click it and mark that particular instance 
non-printing. And maybe you'd change the definition of the way that 
instance affects performance (maybe add 15 to the key velocity), and 
perhaps you could change the font that this particular instance uses 
(make it 20 points instead of 24).

In Finale today, I'd need to create a new expression/articulation for 
each case where I wanted a unique set of appearance, printing/non-
printing and performance effect. This makes your file littered with 
multiple hard-to-distinguish definitions.

I seem to remember that Finale2K4 adds the ability to annotate them 
and that these annotations appears in the selection dialogs. But 
that's a kludge to get around the base problem, that you're forced to 
create multiple copies of the same thing because they aren't related 
to each other.

I just wish all of this was implemented like Word's style 
definitions, where a new style can be based on an old style, 
inheriting all of the old styles characteristics, but allowing you to 
override individual aspects in your new style.

Yes, staff styles are a first implementation of something like this, 
but don't seem to be sufficiently cascaded to be useful. Were it not 
for blank notation, I wouldn't use any staff styles at all, myself.

But I'd find it much more useful to be able to have 
expression/articulation definitions based on each other, or have the 
ability to over-ride behavior/appearance for individual instances.

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

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

At 2:52 PM -0400 6/05/04, David W. Fenton wrote:
But, of course, I thought we were discussing examples of
subcomponents of Finale that were majorly overhauled and then never
worked right any more. When has the Lyrics subsystem been overhauled
and exactly what ended up badly broken?
Auto word extensions slow down the Mac version of 2004 something 
awful. Taking lyrics into account for music spacing (this has been 
part of Finale for a long time, I admit) sometimes gives really odd 
results, like if you have a long syllable like "through" on an eighth 
note it makes the whole measure take up way too much room. The 
structuring of the Lyric tool is still pretty bad, even after the 
changes (I think it was about 2002 or 2003, wasn't it?). You can 
"lose" the syllable after a hyphen, causing endless hyphens for the 
rest of the piece. Click Into Score often causes repeated syllables 
when you use it all the way to the last measure of a piece. Avoiding 
Type Into Score keeps you from the bulk of the structure problems, 
but why doesn't it work predictably yet?

As for some other tools that got overhauled, Engraver Slurs sometimes 
gave wild arcs (though I admit they tackled this one and almost tamed 
it.) Avoiding seconds in different layers (when there was more than 
one note in each layer, and especially if they had accidentals) was 
broken for several versions, and I didn't check to see if it was 
fixed in 2004. The Micnotator thingie is another example, though 
someone posted here a few days ago claiming it worked great for him. 
Chromatic Transposition (for transposing instruments without key 
signatures) was an excellent and badly-needed innovation, but it 
didn't treat accidentals properly for a couple of versions, and STILL 
doesn't transpose chord symbols correctly. Human Playback (though I 
never use it) has some issues. Staff Styles has some outstanding 
issues still (weren't you the one complaining about spacing of hidden 
layers?)

In Speedy Entry, there is no Cancel option when you get the message 
"There are too many beats in this measure..." I generally use the 
"move to next measure" option to create ties over barlines (I know I 
don't have to do this any more, but I'm used to it) and Finale 
doesn't realise I still am holding the MIDI key down when I hit the 
next note value, so I get a rest instead of a note if I wanted a 
repeated pitch. This was a fresh problem with teh Speedy overhaul. 
Finale also doesn't lay out the previous measure correctly when I 
"move to next measure".

Anyway, I manage to work around most of the problems (in the case of 
the slowness of 2004, I work around it by never using it.) I hate to 
come off negatively, but once I learn to be fast on something, I hate 
for it to go away, and this has happened with depressing regularity 
so far.

Christopher
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

At 2:58 PM -0400 6/05/04, David W. Fenton wrote:
On 5 Jun 2004 at 1:34, Christopher BJ Smith wrote:
 > At 9:29 PM -0700 6/04/04, Eric Dannewitz wrote:
 > >Why do you think that? Say you change 8 measures of music, is that
 >going to screw up the whole page format?
 Yes! If you have added notes where they had rests before! Or added
 8ths where they had whole notes, etc. Especially if it's the FIRST 8
 bars. Nothing to do but reformat.
But you'd have to redo it with extracted parts, too, so on this kind
of change the two approaches are equivalent.

My point exactly.

But on less drastic changes, such as fixing wrong notes, tweaking
dynamics, changing bowings after a read-through, and so forth, linked
parts would be substantially less work.
Why discard the advantages of linked parts just because they wouldn't
cook your breakfast for you every morning?

Program bloat. Lack of attention to other more pressing (for me!) issues.

If special part extraction kept its
layout settings separate for each part and separate from the full
score, it would provide the linked parts capability I'd like to see.
But it doesn't do that.

Aha! Feature request!
 You are right, that would make the Special Part Extraction all worth it.

But I don't think it's at all valid to use those long-persisting bugs
as an argument against no major overhauls.
What if Coda had fixed these bugs of yours instead of re-doing the
text tool back in Finale 3.x? Isn't the huge improvement in usability
of the text tool much more of a productivity improvement than the
fixing of any one of those tiny bugs?

Well, if you asking me personally, I would say no. I don't use text 
all that often. But hey, don't do anything special for ME, the others 
might like it that way!

What about the improvements in
page layout in Finale 98 (or was it 2K1?)? Should those have been
left out to fix a number of small bugs, instead?

No, in that case, but I WOULD have sacrificed MicNotator, Optical 
Music recognition, whatever it's called, and Human Playback, and Auto 
Word Extensions (as TG Tools had a good method for me), well, you get 
the idea, I'm sure.

Christopher
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

At 3:04 PM -0400 6/05/04, David W. Fenton wrote:
On 5 Jun 2004 at 1:55, Christopher BJ Smith wrote:
 Now comes the hard part: How far away is Finale's structure from a
 relational database to be able to accomplish this in a reasonable
 number of programmer hours?
Finale's data is already stored in a database.

That's a relief.

You described the feature set just about perfectly, actually.

Thank you! But I am pretty much certain I missed some things. No 
doubt we will all be clamouring for them to be fixed NOW DAMMIT once 
it is implemented.


Programming difficulties aside, wouldn't you *want* those features if
Coda implemented them? Wouldn't they greatly improve your
productivity?

Yes, I would, if they were implemented. A halfway feature like the 
present Special Part Extraction won't help much.


If find that extracting parts is one of the most unpleasant parts of
Finale -- I put it off and put it off, especially because after
proofing the first run of them, I always have to go back and alter
the score, and in many cases the changes are numerous enough that I
feel that I need to re-extract the parts (instead of making the
changes in two locations).

If the rhythmic content of the measures is not too different, try my 
method for copying changes. It really is fast. A whole big band chart 
in about ten minutes, I kid you not.

christopher
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On 5 Jun 2004 at 15:38, Christopher BJ Smith wrote:

> At 3:04 PM -0400 6/05/04, David W. Fenton wrote:

> >If find that extracting parts is one of the most unpleasant parts of
> >Finale -- I put it off and put it off, especially because after
> >proofing the first run of them, I always have to go back and alter
> >the score, and in many cases the changes are numerous enough that I
> >feel that I need to re-extract the parts (instead of making the
> >changes in two locations).
> 
> If the rhythmic content of the measures is not too different, try my
> method for copying changes. It really is fast. A whole big band chart
> in about ten minutes, I kid you not.

Well, that will work fine if you don't have multiple layers without 
fully filled rests in all frames. But if you're copying a measure 
with, say, a quarter note and no rests in layer 2, you can end up 
with all your subsequent layer 2 shifted to the left by some 
arbitrary amount. This happened to me a few days ago, and it was an 
absolute disaster to unravel.

So, I don't do much of any copying and pasting between files -- it's 
way too unreliable.

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

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-05 Thread Eric Dannewitz

Thank you! That is what I have been hinting at.
David W. Fenton wrote:
The key distinction between data stored in a spreadsheet and data 
stored in a relational database is that the latter separates data 
storage from data presentation, whereas in a spreadsheet, the place 
where you store the data is the same place used for printing -- there 
is no separation between data layout and print layout in a 
spreadsheet (though that's not entirely true -- certain kinds of 
features do allow multiple presentations of the same data from one 
worksheet).

In a relational database, the data is stored in objects that are 
designed to represent the characteristics of the data itself, with no 
concern for printout or presentation. In a relational database, a 
report can be used to draw data from multiple related data tables and 
present it in any number of different ways, each specific to the 
purpose of the individual report, hiding certain things, revealing 
certain others.

For example:
 http://www.bway.net/~dfassoc/Park/Reports.html
There are a couple dozen reports, presenting data mostly from a 
handful of data tables. In a spreadsheet, each of those reports would 
require its own spreadsheet page (or, perhaps, in the case of closely 
related reports, editing of a single spreadsheet page to produce two 
slighly different printouts), but in a relational database, the 
report layout is defined entirely separately from the data, allowing 
an infinite number of presentations, without requiring re-arrangement 
of the underlying data.

A score printout and a part printout ought to be defined at the same 
level, as something cosmetic that is independent of the underlying 
music represented in it. Then you could have as many different 
presentations as you wanted, and changes to the music would flow 
through into all the various printed versions.

 

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

At 4:22 PM -0400 6/05/04, David W. Fenton wrote:
On 5 Jun 2004 at 15:38, Christopher BJ Smith wrote:
 > If the rhythmic content of the measures is not too different, try my
 method for copying changes. It really is fast. A whole big band chart
 in about ten minutes, I kid you not.
Well, that will work fine if you don't have multiple layers without
fully filled rests in all frames. But if you're copying a measure
with, say, a quarter note and no rests in layer 2, you can end up
with all your subsequent layer 2 shifted to the left by some
arbitrary amount. This happened to me a few days ago, and it was an
absolute disaster to unravel.

Wow, I was completely unaware of this behaviour! I usually have Auto 
Fill With Rests turned on, and I elect to hide any extra rests using 
the letter O, so I guess this is why this particular bug never bit me.

Christopher
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-05 Thread musicminister

>  >For example, I HATE the way Microsoft Word
>  >makes assumptions about what I want done with my typing, like
>  >"correcting" my spelling without telling me, or putting bullets or
>  >numbers when I hit carriage return.
>
> You know you can turn all of that off, right?
>
> Aaron.


 Hey, Aaron, I second and third and fourth what you wrote. Would you
please tell me the secret to turning off stuff in MS Word? No one in my
church office seems to know.

Eddy Wilson
Landmark Church of God
Statesville, NC

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-06 Thread dhbailey

David W. Fenton wrote:
[snip]>
Indeed, properly it should be implemented like stylesheets for web 
pages. You can change the entire look of a web page (not just colors 
and fonts) by changing to a different stylesheet. If Finale files 
stored a score layout that defined systems and page layout, and a 
separate part layout, and also allowed you to save individual tweaks 
to particular parts, it would be perfect.

[snip]
Style sheets would be a fantastic addition to Finale!  That way we could 
create a sort of universal layout for parts that would be like want it 
most of the time for one type of part extraction and simply call that 
up.  I like that concept, IF it would be implemented as you suggest, 
like style-sheets for web-pages.  Change the setting in the style-sheet 
and all parts which were extracted using that style-sheet would be 
similarly adjusted the next time they were opened.  That would be 
terrific, and linking back to the score in that manner would be fine 
with me, too. As you say, adding a new block of measures would be no 
different in the linked version as it is now without part/score linking: 
  We'd still have to rejig the layout of the parts (style sheets could 
go a LONG way to making that easier as any new pages added to the end of 
existing parts would be setup the same as existing pages, using the 
style-sheet settings).  But simple note changing, expression changing, 
and other alterations but not addition/subtraction would automatically 
be reflected in the parts.

Do you envision this as a menu option (Adjust all linked parts to 
reflect changes NOW) or as an automatic option with the concurrent 
performance hit as all the parts for the score are altered with each 
alteration to the score?


I dunno, previous experience? (Lyric Tool, Ossia Tool, Midi Tool,
certain aspects of the Repeat Tool, to name a few.)

I didn't use the Lyrics Tool before it's revision, so I don't know 
what was broken. What, specifically, are you speaking of there?

As to the other tools, I don't see any changes in them -- they 
basically behave the way they have as long as I've used Finale.

These may not have ever changed but that is the point in bringing these 
up in answer to your statement concerning why do people automatically 
assume new things will be implemented in foolish ways [not your exact 
words but I can't remember the exact quote] -- these are things which 
were implemented in foolish ways which are quirky to use and often don't 
make sense.  MakeMusic has proven itself quite capable of implementing 
tools in ass-backward ways, which we were just trying to point out to 
you as to why we aren't sure these new suggestions will be properly 
implemented.

But your style-sheets suggestion (I know, you've made this suggestion 
before and it has always intrigued me) is a great one and is one that I 
will send to [EMAIL PROTECTED]  But as always, suggesting that 
it be a user configurable and switchable option.

--
David H. Bailey
[EMAIL PROTECTED]
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-06 Thread dhbailey

David W. Fenton wrote:
On 4 Jun 2004 at 22:17, Mark D Lew wrote:

On Jun 4, 2004, at 9:29 PM, Eric Dannewitz wrote:

Lyric tool works well.
Really?  Lyric tool works well if you know what you're doing, or if
you never do anything complicated, but it has lots of pit-traps that
the unwray can fall into.  And there are failings, too, such as
control over hyphen behavior.

Well, as much as I complained about lyrics in my first big project 
with them (in August 2002), now that I learned from all the gurus 
here on the list, I find it pretty darned easy to use. The main 
point:

  DON'T USE TYPE INTO SCORE
Once you figure that out, it's pretty easy to use.
But, of course, I thought we were discussing examples of 
subcomponents of Finale that were majorly overhauled and then never 
worked right any more. When has the Lyrics subsystem been overhauled 
and exactly what ended up badly broken?

It hasn't been overhauled, but the point in bringing it up was that it 
was implemented so poorly that a very major and to many people a very 
useful aspect can't be used -- Type Into Score was not properly 
implemented, is extremely quirky to use and very frustrating until you 
learn DON'T USE IT.

We're just afraid that the parts/score linking might well be implemented 
in a similarly stupid way that would never be fixed once it was 
implemented. Who wants valuable development time spent on a feature that 
we then have to tell newbies not to use, as we have to do with Type Into 
Score?

Who wants a score/parts linking that would force people to leave it 
turned off because every time we change something in the score the 
layout for parts changes even if we are just experimenting?  As long as 
it was user-selectable or a ctrl-l sort of thing such as screen redraw 
or saving feature or update-layout thing that would only be done when we 
tell the program to do so.

We're not saying that it would definitely be implemented in the most 
stupid way possible, merely pointing out that MakeMusic has shown itself 
capable of doing so and we want to be sure it will be implemented in a 
useful way.

--
David H. Bailey
[EMAIL PROTECTED]
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-06 Thread Noel Stoutenburg

David Fenton wrote:
Well, as much as I complained about lyrics in my first big project 
with them (in August 2002), now that I learned from all the gurus here 
on the list, I find it pretty darned easy to use. The main point:

  DON'T USE TYPE INTO SCORE
Once you figure that out, it's pretty easy to use. 
to which David Bailey added
[The lyrics subsystem] hasn't been overhauled, but the point in 
bringing it up was that it was implemented so poorly that a very major 
and to many people a very useful aspect can't be used -- Type Into 
Score was not properly implemented, is extremely quirky to use and 
very frustrating until you learn DON'T USE IT. 
and I'd ask some examples to explain this "quirky" behavior, as type 
into score seems pretty straightforward to me, Select a lyric type 
(verse, chorus, section), and number, and type the syllable below the 
note to which it is to be sung.  Wrong syllable typed to the wrong 
note?  Just backspace away the characters in the syllable, and once all 
of the characters in a particular syllable are removed, it automatically 
progresses back to the previous syllable. 

If the allegedly quirky behaviour is that when one uses the massmover 
copy function to copy a selection of music to which lyrics are attached, 
and they wind up in an unexpected place, it would seem to me that this 
is a problem of either the copy function, and / or the documentation, 
not the type into score portion of the lyrics subsystem..

ns
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-06 Thread dhbailey

Noel Stoutenburg wrote:
David Fenton wrote:
Well, as much as I complained about lyrics in my first big project 
with them (in August 2002), now that I learned from all the gurus here 
on the list, I find it pretty darned easy to use. The main point:

  DON'T USE TYPE INTO SCORE
Once you figure that out, it's pretty easy to use. 

to which David Bailey added
[The lyrics subsystem] hasn't been overhauled, but the point in 
bringing it up was that it was implemented so poorly that a very major 
and to many people a very useful aspect can't be used -- Type Into 
Score was not properly implemented, is extremely quirky to use and 
very frustrating until you learn DON'T USE IT. 

and I'd ask some examples to explain this "quirky" behavior, as type 
into score seems pretty straightforward to me, Select a lyric type 
(verse, chorus, section), and number, and type the syllable below the 
note to which it is to be sung.  Wrong syllable typed to the wrong 
note?  Just backspace away the characters in the syllable, and once all 
of the characters in a particular syllable are removed, it automatically 
progresses back to the previous syllable.
If the allegedly quirky behaviour is that when one uses the massmover 
copy function to copy a selection of music to which lyrics are attached, 
and they wind up in an unexpected place, it would seem to me that this 
is a problem of either the copy function, and / or the documentation, 
not the type into score portion of the lyrics subsystem..

I know that when I have used type into score I have run into problems in 
editing the lyrics afterwards and in repairing mistakes I have made.  I 
stopped using it after repeatedly trying to use it and not being able to 
make it work correctly.  I simply use the Edit Lyrics and Click Assign 
and have never had another problem.

And whenever anybody has run into problems with type into score, as soon 
as I have suggested that they use the Edit Lyrics dialogue to enter the 
lyrics and then use click assign to place them they haven't had any 
problems.

If you've never had a problem with type-into-score, that's fine.  that 
means you've found a way of making it work.

But it doesn't work easily for everybody and that was the point -- 
Finale's developers don't always implement things in ways that all users 
can make work.

--
David H. Bailey
[EMAIL PROTECTED]
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-06 Thread Noel Stoutenburg

David Bailey wrote:
I know that when I have used type into score I have run into problems 
in editing the lyrics afterwards and in repairing mistakes I have 
made.  I stopped using it after repeatedly trying to use it and not 
being able to make it work correctly.  I simply use the Edit Lyrics 
and Click Assign and have never had another problem. 
OK, but the problem is not with type into score, it is with the edit 
dialog box, which does not properly adjust syllable assignments when one 
uses the edit dialog box in a manner which changes the total syllable 
count.  I suspect that, since both type into score, and edit lyrics / 
click assignment both appear to create a link between a specific note 
and a specific syllable, that if you opened a copy of a score in which 
you assigned the lyrics with your preferred method, and attempted to use 
the edit lyrics dialog box in a way that changed the syllable count, 
that you would find exactly the same problems as you found when you 
attempted to edit lyrics when you used type into score.

But it doesn't work easily for everybody and that was the point -- 
Finale's developers don't always implement things in ways that all 
users can make work. 
I would suggest instead that Finale's documentation specialists have not 
done a good job in explaining just how the developers implemented 
certain features, making it difficult for a user to know how something 
is done, so that it can be more easily corrected when something goes wrong.

ns
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-06 Thread John Howell

At 6:55 PM -0400 6/4/04, Christopher BJ Smith wrote:
At 2:00 PM -0700 6/04/04, Eric Dannewitz wrote:
Layout would probably NOT be linked, but NOTES would. Does that 
make sense? I can't count how many times I've changed something in 
a score and FORGOT to update it in a part. Re extracting the part 
would be way more time consuming. The placement of titles, etc, 
etc. I'd just like to have the note DATA updated throughout a 
piece. Each part's layout is different on the stuff I do.

Once again, my little copying routine that I noted is so easy, that 
I can hardly imagine justifying the kind of rewriting it would take 
to accomplish linking ONLY notes in Finale. And doesn't anyone edit 
anything else?
I believe that those of us who have used Mosaic need to comment on 
this.  In Mosaic, score and parts are always interlinked.  Well, sort 
of!  You do your note entry in Galley View.  You then have to lay out 
each score page and each part page.  It isn't so much extracting them 
as creating them.  (Yes, you can simply use Mosaic's defaults for the 
score and parts pages, but you MAY alter them to improve your page 
design and layout.  The key here is that you MUST go through the page 
layout process.)

Galley, score pages, and parts pages are all part of the same file. 
Any note changes, accidental changes, slurs or ties added or deleted, 
and expressions added or deleted in any view are automatically linked 
from score to part, from part to score, and from either to Galley.

However, note spacing is NOT linked.  Changing note spacing, number 
of bars/line, etc. in the score and parts pages does not 
automatically transfer from one to the other, or from either to 
Galley View.

The advantage of this should be obvious; you can't mess up and not 
change one or the other by accident.  However, there's a 
concommittent disadvantage:  if you make an error in a part or in a 
score page, it appears incorrectly in the other and in the Galley 
View as well.  Thus, checking the score against a questionable part 
in rehearsal does no good, because they will show the same error.

So think about how you actually want to use the feature before asking 
for it.  Obviously it can be done, and Mosaic is not exactly a 
sophisticated program so it can't be all that difficult to do it. 
I'll leave it to better minds than mine to work out an ideal 
situation to recommend.

(N.b.  Lyric entry in Mosaic has always worked well.  It isn't 
intuitive, it has to be learned, and it can be frustrating at times 
because a single keystroke can mess you up until you find and fix it, 
but it works.  Finale could learn from this.)

John
--
John & Susie Howell
Virginia Tech Department of Music
Blacksburg, Virginia, U.S.A 24061-0240
Vox (540) 231-8411  Fax (540) 231-5034
(mailto:[EMAIL PROTECTED])
http://www.music.vt.edu/faculty/howell/howell.html
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-06 Thread Mark D Lew

On Jun 6, 2004, at 6:14 AM, dhbailey wrote:
[answering Noel Stoutenberg, regarding Type in Score entry of lyrics]
and I'd ask some examples to explain this "quirky" behavior, as type 
into score seems pretty straightforward to me, Select a lyric type 
(verse, chorus, section), and number, and type the syllable below the 
note to which it is to be sung.

I know that when I have used type into score I have run into problems 
in editing the lyrics afterwards and in repairing mistakes I have 
made. [...]
Bingo.  Your problem came when you used Type in Score and then tried to 
edit with Edit Lyrics afterward.  The "quirky behavior" results from 
combining the two.  It is not a problem in Type in Score alone.

--
On Jun 6, 2004, at 1:16 PM, Noel Stoutenburg wrote:
OK, but the problem is not with type into score, it is with the edit 
dialog box, which does not properly adjust syllable assignments when 
one uses the edit dialog box in a manner which changes the total 
syllable count.
Correct, except for your word "properly".  The Edit Lyrics box 
SHOULDN'T adjust syllable assignments when one changes the syllable 
count, because as often as not when one changes the syllable count in 
the Edit Lyrics box it is intentional. (Say, if a hyphen was left out 
of a two-syllable word.)  For Edit Lyrics to "correct" this by 
reassigning all the syllables would be a disaster because it would mean 
if you opt-click-assigned an entire verse with a typo in the text, 
you'd have to undo the whole thing and start from scratch instead of 
just fixing the typo in the Edit Lyric data.

In other words, not reassigning syllables is as essential to the Edit 
Lyrics/Click Assign method of working as reassigning syllables is to 
the Type in Score method.  It is a fundamental difference between the 
two, which in some cases becomes a fundamental incompatibility.  That's 
why moving back and forth between the two can cause unwanted results if 
one doesn't know enough to take precautions.

mdl
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-06 Thread Mark D Lew

On Jun 6, 2004, at 5:01 AM, dhbailey wrote:
Style sheets would be a fantastic addition to Finale!
I could be wrong, but my sense is that incorporating style sheets 
directly into Finale is too impractical to even consider as a feature 
request to MakeMusic.

What is less impractical, I think, is to achieve more or less the same 
thing with an auxiliary program operating on the XML data, sort of in 
the manner of Recordare's Dolet program.

As I understand it, the information captured in the XML data 
corresponds pretty closely to the basic information which we would 
expect to be preserved under any style -- the notes, markings, etc. -- 
whereas the information which is NOT included in the XML data 
corresponds pretty closely to the sort of information which we would 
expect to be adjusted following the style sheet -- size, font, layout, 
etc.

The auxiliary program, then, would have define a data structure for the 
style sheet itself -- size and font specs, various layout preferences, 
etc. -- along with an interface that allows the user to edit and save 
style sheets.  Then there is a function which takes an XML file as 
input, combines it with a style sheet chosen by the user, and outputs a 
Finale file which will display the music according to the style 
definition.

In my opinion, an approach like that is much more practical than hoping 
that Coda is going to somehow implement style sheets directly into the 
Finale program, and it would be just as useful.  I'm sure it could be 
written, it's just a question of whether there's enough demand for it 
to make it worth someone's while to do all the work.

My feeling is that this sort of definition of printed music is the way 
of a future.  That is, the essence of your file is not a "Finale file" 
at all, but rather the basic XML file, combined with a style definition 
that tells how to display it. Finale is not the creator nor definer of 
the file, but rather a vehicle for displaying it or manipulating it.  
The new program I am describing serves a function analogous to that of 
a Web browser, with Finale being its output device. (Well, sort of. I 
realize the analogy isn't quite perfect.)

But I don't think that future is here quite yet.
mdl
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-06 Thread John Howell

At 7:50 PM -0400 6/4/04, Aaron Sherber wrote:
At 06:55 PM 06/04/2004, Christopher BJ Smith wrote:
For example, I HATE the way Microsoft Word
makes assumptions about what I want done with my typing, like
"correcting" my spelling without telling me, or putting bullets or
numbers when I hit carriage return.
You know you can turn all of that off, right?
Aaron.
Where?  How!?  That might make it almost useable!!!
John
--
John & Susie Howell
Virginia Tech Department of Music
Blacksburg, Virginia, U.S.A 24061-0240
Vox (540) 231-8411  Fax (540) 231-5034
(mailto:[EMAIL PROTECTED])
http://www.music.vt.edu/faculty/howell/howell.html
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-06 Thread Aaron Sherber

At 09:13 PM 6/6/2004, John Howell wrote:
>Where?  How!?  That might make it almost useable!!!
Spelling is under Tools | Options | Spelling & Grammar -- uncheck "Check 
Spelling as You Type". Most other auto things are under Tools | 
AutoCorrect. This is Word 2000 on Win; YMMV on other platforms or versions.

Aaron.
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-06 Thread Noel Stoutenburg

I wrote:
OK, but the problem is not with type into score, it is with the edit 
dialog box, which does not properly adjust syllable assignments when 
one uses the edit dialog box in a manner which changes the total 
syllable count. 
to which Mark replied
Correct, except for your word "properly".  The Edit Lyrics box 
SHOULDN'T adjust syllable assignments when one changes the syllable 
count, because as often as not when one changes the syllable count in 
the Edit Lyrics box it is intentional. 
If I have correctly deduced how Finale deals with lyrics, when a 
syllable is assigned to a note, the note to which it is assigned is 
given an attribute which is a number of syllables by which the syllable 
is offset from the first one.  Now, imagine that the fifteenth lyric 
syllable has been assigned to beat one of particular measure of music, 
and the sixteenth syllable has been assigned to beat three of the same 
measure.  Now, imagine that one decides to add a syllable on beat two, 
between the fifteenth and sixteenth measures, either to an already 
existing note, or by creating a new note, as one would if one changed an 
existing half note on beat one to a quarter note, and added a "new" 
quarter note on beat 2.  At present, the syllables pointed to by the 
offset on the two original notes, on beats one and three, still point to 
the fifteenth and sixteenth syllables.  Now, if one adds a syllable to 
the new note on beat two using type into score, the new note is given an 
appropriate attribute pointing to the new syllable, and it appears to me 
that Finale audits the syllable assignments for the rest of the notes in 
the system, and adjusts the values there accordingly.  In the opposite 
manner, if one decides to change two quarter notes to a halt note, the 
offsets on the succeeding notes are adjusted so that the offset now 
points to the proper position of the syllable. 

If, on the other hand, one changes the half note to two quarters, and 
then uses the edit lyrics box to insert the proper syllable for the new 
note in the proper place, it appears that Finale makes no adjustment of 
the syllable counts of any of the syllables, so that the note which 
formerly had an offset to the fifteenth syllable still has an offset to 
the fifteenth syllable, and the note which formerly had an offset to the 
sixteenth syllable, still has an offset to the sixteenth syllable.  
However, the sixteenth and succeeding syllables are no longer the 
syllables originally assigned.  Complicating this matter is the fact 
that when one attempts to shift lyrics, there is ordinarily a guard 
mechanism which prevents a syllable from one staff form being shifted 
onto a different staff, but when one changes the syllable counts using 
the edit edit lyrics dialog, this guard mechanism is bypassed, so that 
if a syllable is being added, the last syllable is shifted into the 
first position on the next staff, or if a syllable is being deleted, the 
first syllable of the next staff is associated with the last note of the 
current one.  This cannot be undone using shift lyrics, because the 
shift lyrics system invokes the guard.mechanism.  I suspect that the 
reason Finale doesn't adjust the assignment of notes to syllables when 
changes are made using the edit lyrics dialog box, is because the 
program does not keep track of where the edit is being made relative to 
the beginning of the lyrics block, so the information is not available 
to permit this. 

But all of this is a preface to saying that I used the word "properly", 
in my original post in the sense of "accurately", rather than making a 
judgement on whether or not it was desirable for changes in the edit 
lyrics dialog box to be reflected in syllable assignments.

ns
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On Jun 6, 2004, at 6:54 PM, Noel Stoutenburg wrote:
If I have correctly deduced how Finale deals with lyrics, when a 
syllable is assigned to a note, the note to which it is assigned is 
given an attribute which is a number of syllables by which the 
syllable is offset from the first one.  Now, imagine that the 
fifteenth lyric syllable has been assigned to beat one of particular 
measure of music, and the sixteenth syllable has been assigned to beat 
three of the same measure.  Now, imagine that one decides to add a 
syllable on beat two, between the fifteenth and sixteenth measures, 
either to an already existing note, or by creating a new note, as one 
would if one changed an existing half note on beat one to a quarter 
note, and added a "new" quarter note on beat 2.  At present, the 
syllables pointed to by the offset on the two original notes, on beats 
one and three, still point to the fifteenth and sixteenth syllables.  
Now, if one adds a syllable to the new note on beat two using type 
into score, the new note is given an appropriate attribute pointing to 
the new syllable, and it appears to me that Finale audits the syllable 
assignments for the rest of the notes in the system, and adjusts the 
values there accordingly.  In the opposite manner, if one decides to 
change two quarter notes to a halt note, the offsets on the succeeding 
notes are adjusted so that the offset now points to the proper 
position of the syllable.
In other words, you think in Type-in-Score terms.  OK.
If, on the other hand, one changes the half note to two quarters, and 
then uses the edit lyrics box to insert the proper syllable for the 
new note in the proper place, it appears that Finale makes no 
adjustment of the syllable counts of any of the syllables, so that the 
note which formerly had an offset to the fifteenth syllable still has 
an offset to the fifteenth syllable, and the note which formerly had 
an offset to the sixteenth syllable, still has an offset to the 
sixteenth syllable.  However, the sixteenth and succeeding syllables 
are no longer the syllables originally assigned.  Complicating this 
matter is the fact that when one attempts to shift lyrics, there is 
ordinarily a guard mechanism which prevents a syllable from one staff 
form being shifted onto a different staff, but when one changes the 
syllable counts using the edit edit lyrics dialog, this guard 
mechanism is bypassed, so that if a syllable is being added, the last 
syllable is shifted into the first position on the next staff, or if a 
syllable is being deleted, the first syllable of the next staff is 
associated with the last note of the current one.  This cannot be 
undone using shift lyrics, because the shift lyrics system invokes the 
guard.mechanism.  I suspect that the reason Finale doesn't adjust the 
assignment of notes to syllables when changes are made using the edit 
lyrics dialog box, is because the program does not keep track of where 
the edit is being made relative to the beginning of the lyrics block, 
so the information is not available to permit this.
No, the reason Finale doesn't adjust the assignment of notes to 
syllables when changes are made using the Edit Lyrics dialog box, is 
because Finale correctly assumes that the Edit Lyrics user doesn't want 
them adjusted.  The sort of user who uses Edit Lyrics doesn't make that 
sort of insertion.  Of if he does, he does it with Type-in-Score 
because he realizes that it's a Type-in-Score sort of thing to do.

Here is how an Edit Lyrics user is likely to "insert a syllable":
First, he types out, "I am the very mod-el of a mod-ern 
Ma-jor-Gen-er-al;
I’ve in-for-ma-tion veg-e-ta-ble, an-i-mal, and min-er-al:" and so on 
to the end of the verse.

Then he goes opt-click-assign and watches the whole text flash across 
the screen.

Then he notices that something isn't lined up right, and after a quick 
investigation realizes that there is a hyphen missing in "very".  So he 
goes into the Edit Lyrics box and adds that hyphen. By adding that 
hyphen he has "inserted a syllable".  If Edit Lyrics were to behave 
like Type-in-Score, as you seem to be suggesting it might, the 
syllables would all be reassigned so that they remain in the same place 
on the page, but that is exactly what the user does NOT want in this 
case.

That's why I disputed your characterization of "properly".  It's not 
proper, and it's not accurate.  It is an attempt to guess the desire of 
the user, and it guesses wrong.

But all of this is a preface to saying that I used the word 
"properly", in my original post in the sense of "accurately", rather 
than making a judgement on whether or not it was desirable for changes 
in the edit lyrics dialog box to be reflected in syllable assignments.
mdl
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-07 Thread dhbailey

Mark D Lew wrote:
On Jun 6, 2004, at 5:01 AM, dhbailey wrote:
Style sheets would be a fantastic addition to Finale!

I could be wrong, but my sense is that incorporating style sheets 
directly into Finale is too impractical to even consider as a feature 
request to MakeMusic.

Finale stores page data and layout data somewhere.  You adjust the page 
settings, the layout definitions and everytime you open the file those 
definitions are the same as when you saved the program so it obviously 
has stored them somewhere.

Style sheets would require the gathering of that data into a single 
place (or it might be possible to simply gather pointers to the places 
where that data is already stored, requiring no change in current 
storage of that data) and proper organization, so that things like fonts 
and sizes, placements, alignments, etc. would then be easily changed. 
And it would mean the addition of a new data area where the same issues 
for extracted parts would be gathered.  As part extraction occurs, there 
would be a link placed in the parts to the original file so that each 
time the part was opened it would get its layout data from the score 
file.  If the score file were renamed or deleted, the part would open 
with its most recent layout as it was the last time the part was opened.

So it would still be possible to override things in each part if you 
desired to do so, and if a part were orphaned you would still be able to 
adjust everything, BUT you could make adjustments in the score to the 
layout of the parts (sort of like you can do now in Special Part 
Extraction, only that layout would be saved to be used again rather than 
being lost as it is now when you go back to looking at the whole score 
and readjust things from how you had them when you used SPE to look at 
or print a single part) and those adjustments would then be reflected in 
each extracted part when they were extracted AND each subsequent time 
you opened the extracted parts.  Change it once in the score, and the 
copyright notice would then be changed in all 32 already-extracted parts 
as you opened them OR simply reprinted them with some new "print all the 
files in this folder" command without opening each file.

I don't think it would be so difficult to implement, but then I have no 
clue about it from a programming point of view, so maybe it's impossible.

But if it's possible in web-sites with html programming, it can't be 
that difficult to implement.

--
David H. Bailey
[EMAIL PROTECTED]
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

Mark D Lew wrote:
 If Edit Lyrics were to behave like Type-in-Score, as you seem to be 
suggesting it might, the syllables would all be reassigned so that 
they remain in the same place on the page, but that is exactly what 
the user does NOT want in this case. 
I do tend to use type into score more than edit lyrics, but partly this 
is because about half or so of what I enter has melismatic passages 
which gums up the automatic assignment mechanism, and partly because I 
tend to omit too many hyphens, or type an equals sign instead, and type 
into score lets me find these typographical errors more quickly.  
However, when it is more appropriate for my purpose, I can and do easily 
use edit lyrics / click assign  as necessary, when it is useful for 
exploiting design features of that subsystem.  Further, it doesn't 
bother me that the two systems work differently (though I consider it a 
design flaw that when syllable counts are changed in the edit lyrics 
box, syllables shift from the current system to the next one, or from 
the next system to the current one, depending upon whether the syllable 
count is increased or decreased; I would like to see the guard system 
that protects against this in the shift lyrics system implemented in the 
edit lyrics box, but this has become merely and irritation for me these 
days).  What I object to is the fact that the information about how 
these sytems work is not available for the benefit of people who are 
today having the lyrics problems I had several years ago.

ns
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-07 Thread Christopher BJ Smith

At 6:14 AM -0400 6/07/04, dhbailey wrote:
So it would still be possible to override things in each part if you 
desired to do so, and if a part were orphaned you would still be 
able to adjust everything, BUT you could make adjustments in the 
score to the layout of the parts (sort of like you can do now in 
Special Part Extraction, only that layout would be saved to be used 
again rather than being lost as it is now when you go back to 
looking at the whole score and readjust things from how you had them 
when you used SPE to look at or print a single part) and those 
adjustments would then be reflected in each extracted part when they 
were extracted AND each subsequent time you opened the extracted 
parts.

When I tried out Brian's part method yesterday, I was more than a 
little surprised (why, I ask myself now) that when you invoke Special 
Part Extraction that it DOESN'T use the page layout that you chose in 
Page Layout for Parts (it still uses the Page Layout for Score). I 
suppose that if we ever get linked parts, then we will have to have 
different settings available for EVERY part separately (or optionally 
linked.)

The way I used to accomplish this (in regular Extract Parts) is to 
extract all the parts that have the SAME page layout (most of the 
parts), then change the Page Format for Parts (for piano, chorus, 
harp, etc.) to what I want for the OTHER parts, and extract those. I 
guess I can still do that, but it might be nice to be able to set it 
and never worry about it again.

Christopher
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On 6 Jun 2004 at 8:01, dhbailey wrote:

> David W. Fenton wrote:
> 
> [snip]>
> > Indeed, properly it should be implemented like stylesheets for web
> > pages. You can change the entire look of a web page (not just colors
> > and fonts) by changing to a different stylesheet. If Finale files
> > stored a score layout that defined systems and page layout, and a
> > separate part layout, and also allowed you to save individual tweaks
> > to particular parts, it would be perfect.
> > 
> [snip]
> 
> Style sheets would be a fantastic addition to Finale!  That way we
> could create a sort of universal layout for parts that would be like
> want it most of the time for one type of part extraction and simply
> call that up.  I like that concept, IF it would be implemented as you
> suggest, like style-sheets for web-pages.  Change the setting in the
> style-sheet and all parts which were extracted using that style-sheet
> would be similarly adjusted the next time they were opened.  That
> would be terrific, and linking back to the score in that manner would
> be fine with me, too. As you say, adding a new block of measures would
> be no different in the linked version as it is now without part/score
> linking: 
>We'd still have to rejig the layout of the parts (style sheets
> could go a LONG way to making that easier as any new pages added to
> the end of existing parts would be setup the same as existing pages,
> using the style-sheet settings).  But simple note changing, expression
> changing, and other alterations but not addition/subtraction would
> automatically be reflected in the parts. 

Well, you've actually taken it further than what I was thinking, into 
cascading templates. If you've ever uses Word's templates, they work 
similarly to the way I described Word styles -- the file inherits the 
template's settings on creation (because it's a copy of it), but 
retains a link to its parent, with the ability to pull in changes to 
the template after the child document has been created (and also the 
ability to have such changes pulled in automatically). You can also 
copy individual styles from the child into the template.

This is the kind of thing I'd like to see for all the libraries -- 
the template would be linked to a library, which could be edited 
separately. Then you could add things to your 
expressions/articulations within a document that were specific to the 
document, or you could choose to copy those back into the template, 
so other files could use the same new definition.

> Do you envision this as a menu option (Adjust all linked parts to
> reflect changes NOW) or as an automatic option with the concurrent
> performance hit as all the parts for the score are altered with each
> alteration to the score?

I was envisioning the style sheet for layout thing as just applying 
within a particular file. You'd edit the layouts in your template, 
then create your new file based on that. Changes to the layout of 
individual parts based on that original style sheet would then be 
saved within that file, not in an external stylesheet.

The issue here is seeing individual items as specific instances of a 
class. All FORTE markings are the same thing, but in various 
contexts, you want individual instances of it to behave differently 
(apparance, playback, etc.). So, each instance would inherit a set of 
basic properties derived from the parent object, and then individual 
instances would have the ability to override those properties 
selectively (or maybe even add other properties?).

> >>I dunno, previous experience? (Lyric Tool, Ossia Tool, Midi Tool,
> >>certain aspects of the Repeat Tool, to name a few.)
> > 
> > I didn't use the Lyrics Tool before it's revision, so I don't know
> > what was broken. What, specifically, are you speaking of there?
> > 
> > As to the other tools, I don't see any changes in them -- they
> > basically behave the way they have as long as I've used Finale.
> 
> These may not have ever changed but that is the point in bringing
> these up in answer to your statement concerning why do people
> automatically assume new things will be implemented in foolish ways
> [not your exact words but I can't remember the exact quote] -- these
> are things which were implemented in foolish ways which are quirky to
> use and often don't make sense.  MakeMusic has proven itself quite
> capable of implementing tools in ass-backward ways, which we were just
> trying to point out to you as to why we aren't sure these new
> suggestions will be properly implemented.

But it seems to me that all of your examples go way, way back to the 
original versions of Finale. Many of the problems are legacies of the 
original platform's limitations, and of the hardware and software 
limitations of the time.

Yes, I'd agree that all of those tools have problems that would 
benefit from re-thinking and re-implementing. This is exactly what 
happened with my two examples of what seem to me to have been 
success

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On 6 Jun 2004 at 8:13, dhbailey wrote:

> David W. Fenton wrote:
> 
> > On 4 Jun 2004 at 22:17, Mark D Lew wrote:
> > 
> > 
> >>On Jun 4, 2004, at 9:29 PM, Eric Dannewitz wrote:
> >>
> >>
> >>>Lyric tool works well.
> >>
> >>Really?  Lyric tool works well if you know what you're doing, or if
> >>you never do anything complicated, but it has lots of pit-traps that
> >>the unwray can fall into.  And there are failings, too, such as
> >>control over hyphen behavior.
> > 
> > 
> > Well, as much as I complained about lyrics in my first big project
> > with them (in August 2002), now that I learned from all the gurus
> > here on the list, I find it pretty darned easy to use. The main
> > point:
> > 
> >   DON'T USE TYPE INTO SCORE
> > 
> > Once you figure that out, it's pretty easy to use.
> > 
> > But, of course, I thought we were discussing examples of 
> > subcomponents of Finale that were majorly overhauled and then never
> > worked right any more. When has the Lyrics subsystem been overhauled
> > and exactly what ended up badly broken?
> > 
> 
> It hasn't been overhauled, but the point in bringing it up was that it
> was implemented so poorly that a very major and to many people a very
> useful aspect can't be used -- Type Into Score was not properly
> implemented, is extremely quirky to use and very frustrating until you
> learn DON'T USE IT.
> 
> We're just afraid that the parts/score linking might well be
> implemented in a similarly stupid way that would never be fixed once
> it was implemented. Who wants valuable development time spent on a
> feature that we then have to tell newbies not to use, as we have to do
> with Type Into Score?

Seems to me that Lyrics got the way it is because it is an *old* 
subsystem, dating back to very early versions of Finale, and the 
changes to it have been bolted on the sides over time, making it 
rather baroque and nearly impossible to figure out. And the problem 
is that the basic system on which it is all built does not have the 
best architecture to support all these additional features.

It is exactly the kind of component that appears to me to need a 
major rewrite, from the ground up, so that the basic architecture 
could be altered so that all the parts that have been bolted on could 
be integrated into the basic structure, instead of having this kludgy 
afterthought feel to them.

Indeed, a lot of very small changes could make Lyrics much more 
usable (like allowing resizing of the click assignment dialog -- 
geez, how frigging hard would *that* be?), but the basic underlying 
problem of the Lyrics tool, that the visual representation of the 
data and the actual underlying data do not have a clear relationship 
to each other (and, secondarily, that the UIs involved require you to 
understand the relationship between the displayed data and the stored 
data), could, I think, only be rectified by a ground-up rewrite of 
the whole thing.

> Who wants a score/parts linking that would force people to leave it
> turned off because every time we change something in the score the
> layout for parts changes even if we are just experimenting?  As long
> as it was user-selectable or a ctrl-l sort of thing such as screen
> redraw or saving feature or update-layout thing that would only be
> done when we tell the program to do so.

Yes, you're certainly right that Coda could screw it up, but they 
could also screw up any bug fix they implemented, as well. So I just 
don't see the point of bringing it up when evaluating new features. 
It's only relevant when the new feature has neglible benefit in 
comparison to the amount of effort required.

I don't really think that's the case for linked parts.

> We're not saying that it would definitely be implemented in the most
> stupid way possible, merely pointing out that MakeMusic has shown
> itself capable of doing so and we want to be sure it will be
> implemented in a useful way.

There are many aspects of Finale where there are two ways to do 
things (e.g., Speedy vs. Simple). Many of us wouldn't touch one of 
those two ways (I'd never bother with Simple Entry). What I'm 
suggesting is adding another part extraction method (or altering SPE 
to store information about individual part layouts), while leaving 
the original method unchanged. Some people would migrate to the new 
method, some people would stay with the old, just as some people 
still use Simple Entry.

I don't see the issue.

And I think it would be the kind of change that would serve to keep 
Finale competitive with Sibelius.

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

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On 6 Jun 2004 at 15:39, Mark D Lew wrote:

> 
> On Jun 6, 2004, at 6:14 AM, dhbailey wrote:
> 
> [answering Noel Stoutenberg, regarding Type in Score entry of lyrics]
> 
> >> and I'd ask some examples to explain this "quirky" behavior, as
> >> type into score seems pretty straightforward to me, Select a lyric
> >> type (verse, chorus, section), and number, and type the syllable
> >> below the note to which it is to be sung.
> 
> > I know that when I have used type into score I have run into
> > problems in editing the lyrics afterwards and in repairing mistakes
> > I have made. [...]
> 
> Bingo.  Your problem came when you used Type in Score and then tried
> to edit with Edit Lyrics afterward.  The "quirky behavior" results
> from combining the two.  It is not a problem in Type in Score alone.

Yes, it *is* a problem with Type in Score, since certain kinds of 
problems that pop up in Type in Score can only be figured out by 
going to Edit Lyrics. I can't remember a specific example, but with 
my Requiem example, that was where I got in trouble. I was happily 
using type in score, and did not realize that the default for copying 
was not to create *new* lyrics, but to link to the original. Well, 
the lyrics in the copied version were supposed to be different, and I 
started changing them with Type in Score, and, naturally, this 
screwed up the original part. And I could only work out what had gone 
wrong was to go to Edit Lyrics. That's when I realized what an 
incredible unmanageable mess Type in Score had allowed me to create.

And, eventually, I stripped out all of it and redid it all with click 
assignment.

And I've never looked back -- you couldn't pay me enough to use Type 
in Score.

The only way I can imagine that anyone could get by with it would be 
if:

1. no text repeats anywhere.

2. different parts have completely different texts.

What I like about click assignment is that I have to type the text 
only once (and add in appropriate variants of individual words, 
usually for punctuation and capitalization). And if I make a spelling 
error or put a syllable break in the wrong place, I have to change it 
only once, in Edit Lyrics.

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

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On 6 Jun 2004 at 15:56, Mark D Lew wrote:

> On Jun 6, 2004, at 5:01 AM, dhbailey wrote:
> 
> > Style sheets would be a fantastic addition to Finale!
> 
> I could be wrong, but my sense is that incorporating style sheets
> directly into Finale is too impractical to even consider as a feature
> request to MakeMusic.

It's not specifically style sheets that ought to be implemented, but 
the concept behind them: the appearance of the final result should be 
indpendent of the underlying data represented in the final printout.

Style and presentation should be separated as much as possible.

For linked parts, this would really only apply to frames and higher. 
That is, you wouldn't really want to control things within a frame 
from a common style.

So what is really being described here is layout flow -- how the 
frames get flowed into systems and pages for printing. 

Obviously, individual parts would need different spacing within 
frames, as well, and that would need to be stored, but it wouldn't be 
stored in the style sheet, just in the data about the particular 
part.

Cascading templates implemented the way Word implements them would 
probably give the capabilities that CSS in HTML gives you.

But seems to me that any linked parts implementation would have to 
have a source for the information about the default layout of 
pages/systems for score and parts, just as you today have a template 
for parts when you extract parts.

But that's not really cascading style sheets -- that's just 
maintaining different default page layouts.

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

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On 6 Jun 2004 at 21:13, John Howell wrote:

> At 7:50 PM -0400 6/4/04, Aaron Sherber wrote:
> >At 06:55 PM 06/04/2004, Christopher BJ Smith wrote:
> >>For example, I HATE the way Microsoft Word
> >>makes assumptions about what I want done with my typing, like
> >>"correcting" my spelling without telling me, or putting bullets or
> >>numbers when I hit carriage return.
> >
> >You know you can turn all of that off, right?
> 
> Where?  How!?  That might make it almost useable!!!

Don't you folks always explore the menus of programs when you start 
using them? With Microsoft programs on Windows, user controllable 
options are stored on the Tools menu, under OPTIONS. Word also has 
separate menu entries for Autocorrect. I don't if MS's Mac versions 
put it under EDIT | PREFERENCES, but the point is -- you should 
explore these menus and try out the settings. Read the help and check 
out what the settings do. 

A few minutes spent exploring can save hours of annoyance.

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

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On 7 Jun 2004 at 6:14, dhbailey wrote:

> But if it's possible in web-sites with html programming, it can't be
> that difficult to implement.

I agreed with everything you wrote up to this point.

You can't compare implementation across different domains.

HTML was designed from the very beginning to keep data separate from 
layout. Then a bunch of things were added to HTML that control 
appearance, and it became obvious that this was not consistent with 
the underlying design of HTML, so Cascading Style Sheets were 
conceptualized and implemented to get this.

And HTML styles use vaguely object-oriented terminology, in that you 
control the style of individual tags by giving them class names, so 
they inherit the characteristics of the class you designated them to 
be (and you can use multiple classes, in fact).

But it works entirely because of the basic structure of HTML in that 
HTML itself (mostly) doesn't indicate presentation.

I think that the stylesheet concept is the wrong one, though. What 
you're really writing about is cascading templates, like MS Word.

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

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On 7 Jun 2004 at 8:37, Christopher BJ Smith wrote:

> At 6:14 AM -0400 6/07/04, dhbailey wrote:
> >
> >So it would still be possible to override things in each part if you
> >desired to do so, and if a part were orphaned you would still be able
> >to adjust everything, BUT you could make adjustments in the score to
> >the layout of the parts (sort of like you can do now in Special Part
> >Extraction, only that layout would be saved to be used again rather
> >than being lost as it is now when you go back to looking at the whole
> >score and readjust things from how you had them when you used SPE to
> >look at or print a single part) and those adjustments would then be
> >reflected in each extracted part when they were extracted AND each
> >subsequent time you opened the extracted parts.
> 
> When I tried out Brian's part method yesterday, I was more than a
> little surprised (why, I ask myself now) that when you invoke Special
> Part Extraction that it DOESN'T use the page layout that you chose in
> Page Layout for Parts (it still uses the Page Layout for Score). I
> suppose that if we ever get linked parts, then we will have to have
> different settings available for EVERY part separately (or optionally
> linked.)
> 
> The way I used to accomplish this (in regular Extract Parts) is to
> extract all the parts that have the SAME page layout (most of the
> parts), then change the Page Format for Parts (for piano, chorus,
> harp, etc.) to what I want for the OTHER parts, and extract those. I
> guess I can still do that, but it might be nice to be able to set it
> and never worry about it again.

In extracting parts the normal way, isn't there a choice of what 
template to use? Oops, I guess not!

The easiset way to implement this, without having linked templates, 
would be to allow you to designate the template for generating each 
part. You would then extract in groups that used the same layout 
(drawn from the same template).

If special part extraction could record and retain this information 
for each part, then you would have to do it only once for each part 
in your score. Better yet would be if you could create templates that 
already had this pre-defined, so the string parts knew which 
template, and the piano part etc.

Fundamentally, all that's needed here is the mechanism for storing 
the data about the base template for each part, and then a second 
mechanism for storing your alterations to the layouts inherited from 
those templates.

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

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On Jun 7, 2004, at 10:47 AM, David W. Fenton wrote:
Seems to me that Lyrics got the way it is because it is an *old*
subsystem, dating back to very early versions of Finale, and the
changes to it have been bolted on the sides over time, making it
rather baroque and nearly impossible to figure out. And the problem
is that the basic system on which it is all built does not have the
best architecture to support all these additional features.
It is exactly the kind of component that appears to me to need a
major rewrite, from the ground up, so that the basic architecture
could be altered so that all the parts that have been bolted on could
be integrated into the basic structure, instead of having this kludgy
afterthought feel to them.
I think you're exactly right on that.
As far as I can tell, the underlying structure of Lyrics is modeled on 
that of Expressions.  That is, your lyric data is really like a 
gigantic expressions list, so when you attach the syllable "of" to a 
note, you're adding the word "of" to the list and attaching a pointer 
to it to the note.

There's a certain logic to that approach with regard to expressions, 
where it really does make sense to think of every "ritard" as a single 
definition which might appear numerous times, but there's very little 
to gain from it with respect to lyrics.  It's pretty rare that you'd 
want multiple assignments for the same lyric at all.  Even if "of" 
appears several times in your lyric, you're still going to have it 
appear multiple times in the list, so what's the point of using 
indirection here?

In that respect, it seems like it would be more logical if there is no 
syllable list and each syllable is simple in and of itself an attribute 
of the note, as it is in other engraving programs.  That sort of 
structure would be a natural fit with the Type-in-Score input method.  
The lack of such a structure in Finale is what makes Type-in-Score have 
such a kludgy, bolted-on feel to it (and probably is also why it 
arrived relatively late in Finale's history).

The key is to make sure that in switching, you don't give up the 
advantages that the old system offers:  the features that derive from 
the ability to identify a collection of syllables as a group (verse), 
and the ability to identify one syllable as "following" another (ie, 
cut-and-paste access to the lyric text in its own window, ability to 
change a verse's font/size or baseline en masse, ability to shift lyric 
assignments).  But those labelings could be attached to the syllables 
under the structure, and it would be smoother than the other way 
around.

Indeed, a lot of very small changes could make Lyrics much more
usable (like allowing resizing of the click assignment dialog --
geez, how frigging hard would *that* be?),
Amen!  And the Edit Lyrics window, too.  Why on earth are these windows 
stuck in the mid-1990s, UI-wise? That's just embarrassing.

 but the basic underlying
problem of the Lyrics tool, that the visual representation of the
data and the actual underlying data do not have a clear relationship
to each other (and, secondarily, that the UIs involved require you to
understand the relationship between the displayed data and the stored
data), could, I think, only be rectified by a ground-up rewrite of
the whole thing.
mdl
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On Jun 7, 2004, at 5:24 AM, Noel Stoutenburg wrote:
 (though I consider it a design flaw that when syllable counts are 
changed in the edit lyrics box, syllables shift from the current 
system to the next one, or from the next system to the current one, 
depending upon whether the syllable count is increased or decreased;
That is the point on which you and I disagree.  I just offered an 
example in which your "design flaw" is my desired behavior.

I would like to see the guard system that protects against this in the 
shift lyrics system implemented in the edit lyrics box, but this has 
become merely and irritation for me these days).  What I object to is 
the fact that the information about how these sytems work is not 
available for the benefit of people who are today having the lyrics 
problems I had several years ago.
On that point we agree.
mdl
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On Jun 7, 2004, at 10:59 AM, David W. Fenton wrote:
Yes, it *is* a problem with Type in Score, since certain kinds of
problems that pop up in Type in Score can only be figured out by
going to Edit Lyrics. I can't remember a specific example, but with
my Requiem example, that was where I got in trouble. I was happily
using type in score, and did not realize that the default for copying
was not to create *new* lyrics, but to link to the original. Well,
the lyrics in the copied version were supposed to be different, and I
started changing them with Type in Score, and, naturally, this
screwed up the original part. And I could only work out what had gone
wrong was to go to Edit Lyrics. That's when I realized what an
incredible unmanageable mess Type in Score had allowed me to create.
Well, I'll half agree.  I concede that a problem with Type in Score is 
that there are certain things which cannot be done there, forcing the 
user to resort to Edit Lyrics -- which leads to the dangers inherent in 
combining the two.  Then again, a user can get into a heap of trouble  
by messing around with data in Edit Frames, too.  The assumption is 
that you don't mess with Edit Frames unless you know what you're doing. 
A similar assumption might be made about Edit Lyrics, except for the 
fact that there are a couple of common lyric functions that can't be 
done otherwise.

With regards to copying lyrics, I agreed long ago that the default 
should be to create new syllables in the list, rather than creating 
additional assignments to the same syllables.  This is a problem, but I 
don't see it as a problem with Type-in-Score per se.

As you know, I too prefer using Edit Lyrics, though I'll occasionally 
use Type-in-Score to fix a typo (or, more often, to temporarily reduce 
a syllable for the sake of respacing a problem measure).

mdl
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On Jun 7, 2004, at 3:14 AM, dhbailey wrote:
But if it's possible in web-sites with html programming, it can't be 
that difficult to implement.
Right, but it's not the "web-site" that does the implementing, it's the 
browser.  The browser is essentially an interpreter of HTML code.  The 
analog would be a program which is essentially an interpreter of 
MusicXML code, which is what Dolet is.  I'm suggesting that to 
implement stylesheets as described is more logically the job of an 
expanded version of Dolet than an expanded version of Finale.

But of course there are always many different ways to do a job.  If I 
implied that it can't be done in Finale, I overstated the case.  I just 
think it's less likely to happen there, so we shouldn't be so stuck on 
persuading MakeMusic when there are other avenues.

mdl
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On 7 Jun 2004 at 16:12, Mark D Lew wrote:

> On Jun 7, 2004, at 10:47 AM, David W. Fenton wrote:

> > Indeed, a lot of very small changes could make Lyrics much more
> > usable (like allowing resizing of the click assignment dialog --
> > geez, how frigging hard would *that* be?),
> 
> Amen!  And the Edit Lyrics window, too.  Why on earth are these
> windows stuck in the mid-1990s, UI-wise? That's just embarrassing.

Mid-90s? Looks more like late 80s to me!

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

___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

I wrote:
 (though I consider it a design flaw that when syllable counts are 
changed in the edit lyrics box, syllables shift from the current 
system to the next one, or from the next system to the current one, 
depending upon whether the syllable count is increased or decreased;
Oops.  I didn't write what I really meant to say.  I don't consider it a 
design flaw that syllables shift from one note to another, across system 
boundaries, but that it can happen that the syllable assigned to the 
last note of a particular staff in a score shifts to the first note of 
the beginning of whatever the next staff is in the score when the 
syllable count is changed, and that because of the guard system, shift 
lyrics cannot be used to undo this. 

ns
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-07 Thread Christopher BJ Smith

At 7:53 PM -0500 6/07/04, Noel Stoutenburg wrote:
I wrote:
 (though I consider it a design flaw that when syllable counts are 
changed in the edit lyrics box, syllables shift from the current 
system to the next one, or from the next system to the current one, 
depending upon whether the syllable count is increased or decreased;
Oops.  I didn't write what I really meant to say.  I don't consider 
it a design flaw that syllables shift from one note to another, 
across system boundaries, but that it can happen that the syllable 
assigned to the last note of a particular staff in a score shifts to 
the first note of the beginning of whatever the next staff is in the 
score when the syllable count is changed, and that because of the 
guard system, shift lyrics cannot be used to undo this.
ns

Ah ha! To guard against possibly tripping up against that particular 
"feature" is the reason why some (like me!) put lyrics for different 
staves into different verses or choruses. Soprano is verse 1, alto is 
verse 2, etc.

Copy and paste between verses works well when everyone has almost the 
same lyrics, because even if there are a couple of syllables 
difference, each staff can be freely edited without changing the 
others.

I don't remember who on this list gave me that particular advice, but 
thank you!

Christopher
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

On Jun 7, 2004, at 4:35 PM, David W. Fenton wrote:
Mid-90s? Looks more like late 80s to me!
You're probably right.  I'm habitually slow to upgrade, so I'm usually 
about five years behind.

mdl
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue

2004-06-07 Thread John Howell

At 2:07 PM -0400 6/7/04, David W. Fenton wrote:
Don't you folks always explore the menus of programs when you start
using them? With Microsoft programs on Windows, user controllable
options are stored on the Tools menu, under OPTIONS. Word also has
separate menu entries for Autocorrect. I don't if MS's Mac versions
put it under EDIT | PREFERENCES, but the point is -- you should
explore these menus and try out the settings. Read the help and check
out what the settings do.
A few minutes spent exploring can save hours of annoyance.
Of course you're absolutely right.  But my situation is this:  our 
university provides us with a new computer every 4 years.  My music 
department uses Macs exclusively.  Our computers come pre-loaded with 
the latest versions of the standard programs everyone on campus uses, 
including MS Office.  And we never get copies of the manuals. 
Therefore trying to figure out a new version of everything on the 
computers is purely a matter of trial and error, and I am NOT a good 
hacker.  If MS moves a command to a new place, it may take me 2 years 
to find it, or I may never find it at all!

For years I kept using Word 5.1a, because it's lean, it does what I 
need it to do, and it doesn't get upity and try to tell me what to 
do.  I'm sure there are some useful things in subsequent versions, 
but they aren't useful to ME and they just take up a bloated amount 
of memory.  Well, when we went to OS X I coudn't use 5.1a any more, 
so I'm stuck with what I've got, and it's been driving me nuts!

So yes, David, you're completely right, but I'm strictly a user, and 
basically a conservative person who hates having to relearn something 
new when I already have a way to do what I need to do, and that's why 
I never spend the hours it would take to "explore" new versions of 
programs.

Thanks for your thoughts.
John
--
John & Susie Howell
Virginia Tech Department of Music
Blacksburg, Virginia, U.S.A 24061-0240
Vox (540) 231-8411  Fax (540) 231-5034
(mailto:[EMAIL PROTECTED])
http://www.music.vt.edu/faculty/howell/howell.html
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Finale vs. Sibelius - Review in Macworld July 2004 Issue