[Finale] Dynamic Parts in Finale

[Darcy James Argue]

On 06 Jul 2005, at 1:43 AM, Tyler Turner wrote:


At this point, I think it would
be good to make suggestions to MakeMusic for which
parts of that feature you actually need most. What
would be the minimum implementation for the feature
that would give you most of the usefulness? Sibelius'
method is pretty flashy, complete with instantaneous
update. If something like that isn't necessary, it
would be good to mention that. I'm pretty sure that
MakeMusic will at least be looking at this feature
again now that Sibelius has included it. They have a
lot of other stuff on their plate though, so the less
work they'd have to spend on it, the better chance
they'd be able to do it.


Okay, that's a good idea.  Let's see if we can flesh something out 
on-list before submitting.


First off, though, I think the goal should be to *surpass* Sibelius in 
this area.  I would hate to see Finale add half-assed Dynamic Parts 
(and Video Sync) options that were only pale imitations of Sibelius 
features.  I think the way to go is the way Finale went with Human 
Playback (which had a rocky start but which I now find indispensable) 
-- Finale should try to out-do Sibelius's implementation, at least 
eventually.


But first, the bare-bones version:

• First, Special Part Extraction would need to be revamped to be able 
to save independent an layout for each staff.  That's the obvious 
starting point.  For now, let's call this new version of Special Part 
Extraction "Dynamic Parts" (same as the Sibelius version of the 
feature).


• We need to be able to apply all of the current part extraction 
options to the Dynamic Parts.  There should be a menu item, called 
something like "Extract Dynamic Parts," that is identical to the 
current "Extract Parts" dialog and enables all of the functionality of 
regular part extraction.


[Actually, to be honest, it would be nice if the Extract Parts dialog 
were smart enough to recognize multi-staff parts -- like harp and piano 
-- automatically.]


• After Extracting Dynamic Parts, there should be a new addition to the 
View menu -- in addition to Scroll View and Page View (and, in Fin2k6, 
Studio View) there should be a "Parts View" menu, opening to a submenu 
of all dynamically extracted parts.  There should be keyboard shortcuts 
to advance or retreat through dynamically extracted parts, and keyboard 
shortcuts to switch between Score View  (i.e., Scroll/Page/Studio) and 
Parts View.  (IMO, only Page View is necessary for Parts view -- same 
as the way Special Part Extraction already works. We don't need to be 
able to see dynamically extracted parts in Scroll View.)


• Finale should ask what the default Page Setup for extracted parts 
should be -- it's a good assumption that it will *not* be the same as 
the score.  However, this should not affect the Page Setup for the 
score, and you should still be able to set the Page Setup for each 
dynamically extracted part independently, if you wish.


• Obviously, each dynamically extracted part should have independent 
note spacing and layout.


• The split-screen feature in Sibelius is desirable but not absolutely 
necessary.  The important thing is, after doing a dynamic part 
extraction, note changes in Dynamic Parts should affect the score, and 
vice versa.


 • After doing a dynamic extraction, changes in expression 
*positioning* in the part should not affect the score, and vice versa.  
However, adding a new expression in the part *should* affect the score, 
and vice versa.  Same with articulations, smart shapes, etc -- changes 
in *positioning* should not cross the part-score barrier.  But 
*deleting* these elements, or *creating new ones*, should affect both 
score and parts.


[Maybe we could also exploit the difference between note-attached and 
measure attached expressions?  Like, all note-attached expressions show 
in Parts + Score, but Measure-Attached expressions can be set to show 
up in either Score view or Parts view?  This should be easy, since it's 
almost identical to the way Measure-Attached expressions already work.]


• If this feature is to work, Finale will have to (finally) fix chord 
symbols in "Open Key/Atonal" scores (to use Sibelius's terminology).  
Chord symbols should *always* transpose when attached to transposing 
staves, even in pieces with no key signature.


• Note spelling will be tricky, especially if your score is set to 
display in concert pitch.  I guess the bare-bones approach would be to 
leave note spelling linked, always -- so if you have a concert A# in a 
Bb clarinet part in your score, you will have a B# in your part; and if 
you flip it to a C nat. in your part, it will become a Bb in your 
(concert) score.  I don't know how Sibelius handles this issue, but 
that would be the simplest solution and also -- in most cases -- the 
most desirable solution.


• For cue notes to work properly using Dynamic Parts, it would be 
*very* useful -- probably obligatory, in fact -- to add a new layer 
option

Re: [Finale] Dynamic Parts in Finale

[Darcy James Argue]

One more thing occurs to me -- what about multi-part staves?

As far as I can tell, Sib 4.0 has no good way of handling these via 
Dynamic Parts -- if your score has Clarinets 1 & 2 on the same staff, 
you can't use Dynamic Parts to extract them to separate staves.


This would be an area where Finale could potentially surpass Sibelius 
-- especially if they were willing to work closely with Tobias to 
directly implement his "Smart Explosion of Mutli-Staff parts" into 
Finale's version of Dynamic Parts.


- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY

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

Re: [Finale] Dynamic Parts in Finale

[Darcy James Argue]

Another thing,

The video in on dynamic parts Sibelius is actually quite misleading.  
You see the narrator click on a part name, and instantly, a 
split-screen appears.  That's not what actually happens when you use 
the program.  In fact, it's not a split screen at all, it's two 
separate windows (which you can see if you look closely at the video -- 
those are two Windows XP windows, not a single window with a 
split-screen view).


When you select a Dynamic Part in Sibelius, it spawns a completely new 
window.  My preference would be for Finale to *not* do that.  I like 
the concept of parts as a separate View in *the same window* -- hence 
my idea of Parts View and Score View.


When you use Special Parts Extraction, when you switch from scroll view 
(score) to page view (part), it doesn't spawn a new document window.  
When Finale implements Dynamic parts, I would like it to follow that 
model instead of the Sibelius model.


- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY

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

Re: [Finale] Dynamic Parts in Finale

[Eric Dannewitz]

On Wed, 6 Jul 2005, Darcy James Argue wrote:

> Okay, that's a good idea.  Let's see if we can flesh something out
> on-list before submitting.
>
***CLIPPED*

Wow, totally AGREE on all this!!
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Dynamic Parts in Finale

[Darcy James Argue]

To clarify:

Using the "switch between full score and part" button in Sibelius works 
exactly way I would like my proposed "Parts View" and "Score View" to 
work in Finale.


On the other hand, directly selecting a part from the dropdown menu in 
Sibelius (when "Full Score" is showing) spawns a new window.  That's 
bad UI -- I don't want Finale to emulate that.


- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY


On 06 Jul 2005, at 3:24 AM, Darcy James Argue wrote:


Another thing,

The video in on dynamic parts Sibelius is actually quite misleading.  
You see the narrator click on a part name, and instantly, a 
split-screen appears.  That's not what actually happens when you use 
the program.  In fact, it's not a split screen at all, it's two 
separate windows (which you can see if you look closely at the video 
-- those are two Windows XP windows, not a single window with a 
split-screen view).


When you select a Dynamic Part in Sibelius, it spawns a completely new 
window.  My preference would be for Finale to *not* do that.  I like 
the concept of parts as a separate View in *the same window* -- hence 
my idea of Parts View and Score View.


When you use Special Parts Extraction, when you switch from scroll 
view (score) to page view (part), it doesn't spawn a new document 
window.  When Finale implements Dynamic parts, I would like it to 
follow that model instead of the Sibelius model.


- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY

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



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

Re: [Finale] Dynamic Parts in Finale

[Darcy James Argue]

Another thing,

(Sorry, I'm on a roll here.)

Weirdly, the sample file in Sibelius that highlights the Dynamic Parts 
feature (an alto sax concerto by Richard Payne) also highlights a 
potential snag in the feature in the very first measure.


Flutes 1 & 2 have an 8va marking (to avoid collision with the piccolo 
staff above).


I personally would *not* want the 8va marking in the parts -- it only 
goes up to G6 (four ledger lines above the staff), so I'd want to write 
that at pitch.  But there's no way to change the Dynamic Part without 
also changing the score, or breaking the live link between the two.


I think all of this just goes to show that Dynamic Parts is a 
complicated issue.  Sibelius has made an excellent start, but there's 
definitely room for Finale to surpass them, if they are willing to make 
Dynamic Parts as much of a priority as Human Playback has been.


I think after Fin2k6 is released, it's time to start flooding Coda with 
feature requests for Dynamic Parts.


- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY

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

Re: [Finale] Dynamic Parts in Finale

[dhbailey]

Darcy James Argue wrote:

[snip of great description of linked score/parts]

Looking over this list, I guess what it comes down to is that almost 
every aspect of Sibelius's implementation of this feature is either 
absolutely necessary or (like "copy layout") extraordinarily desirable. 
 The only thing aspect that's a bit of a frill is the split-screen 
Part-Score view.  That's a bit of a frill, and I could live without it. 
Everything else is integral to the usefulness of the feature.




And I fail to see how this linked score/parts would not benefit 
practically every Finale user.


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

Re: [Finale] Dynamic Parts in Finale

[Chuck Israels]

I am in total agreement with Darcy's suggestions and my experience  
with MM is that they will listen, if enough of us communicate.


I am forwarding this to one of the folks there who consistently  
responds to my communiques.


Chuck


On Jul 5, 2005, at 11:58 PM, Darcy James Argue wrote:


On 06 Jul 2005, at 1:43 AM, Tyler Turner wrote:



At this point, I think it would
be good to make suggestions to MakeMusic for which
parts of that feature you actually need most. What
would be the minimum implementation for the feature
that would give you most of the usefulness? Sibelius'
method is pretty flashy, complete with instantaneous
update. If something like that isn't necessary, it
would be good to mention that. I'm pretty sure that
MakeMusic will at least be looking at this feature
again now that Sibelius has included it. They have a
lot of other stuff on their plate though, so the less
work they'd have to spend on it, the better chance
they'd be able to do it.



Okay, that's a good idea.  Let's see if we can flesh something out  
on-list before submitting.


First off, though, I think the goal should be to *surpass* Sibelius  
in this area.  I would hate to see Finale add half-assed Dynamic  
Parts (and Video Sync) options that were only pale imitations of  
Sibelius features.  I think the way to go is the way Finale went  
with Human Playback (which had a rocky start but which I now find  
indispensable) -- Finale should try to out-do Sibelius's  
implementation, at least eventually.


But first, the bare-bones version:

• First, Special Part Extraction would need to be revamped to be  
able to save independent an layout for each staff.  That's the  
obvious starting point.  For now, let's call this new version of  
Special Part Extraction "Dynamic Parts" (same as the Sibelius  
version of the feature).


• We need to be able to apply all of the current part extraction  
options to the Dynamic Parts.  There should be a menu item, called  
something like "Extract Dynamic Parts," that is identical to the  
current "Extract Parts" dialog and enables all of the functionality  
of regular part extraction.


[Actually, to be honest, it would be nice if the Extract Parts  
dialog were smart enough to recognize multi-staff parts -- like  
harp and piano -- automatically.]


• After Extracting Dynamic Parts, there should be a new addition to  
the View menu -- in addition to Scroll View and Page View (and, in  
Fin2k6, Studio View) there should be a "Parts View" menu, opening  
to a submenu of all dynamically extracted parts.  There should be  
keyboard shortcuts to advance or retreat through dynamically  
extracted parts, and keyboard shortcuts to switch between Score  
View  (i.e., Scroll/Page/Studio) and Parts View.  (IMO, only Page  
View is necessary for Parts view -- same as the way Special Part  
Extraction already works. We don't need to be able to see  
dynamically extracted parts in Scroll View.)


• Finale should ask what the default Page Setup for extracted parts  
should be -- it's a good assumption that it will *not* be the same  
as the score.  However, this should not affect the Page Setup for  
the score, and you should still be able to set the Page Setup for  
each dynamically extracted part independently, if you wish.


• Obviously, each dynamically extracted part should have  
independent note spacing and layout.


• The split-screen feature in Sibelius is desirable but not  
absolutely necessary.  The important thing is, after doing a  
dynamic part extraction, note changes in Dynamic Parts should  
affect the score, and vice versa.


 • After doing a dynamic extraction, changes in expression  
*positioning* in the part should not affect the score, and vice  
versa.  However, adding a new expression in the part *should*  
affect the score, and vice versa.  Same with articulations, smart  
shapes, etc -- changes in *positioning* should not cross the part- 
score barrier.  But *deleting* these elements, or *creating new  
ones*, should affect both score and parts.


[Maybe we could also exploit the difference between note-attached  
and measure attached expressions?  Like, all note-attached  
expressions show in Parts + Score, but Measure-Attached expressions  
can be set to show up in either Score view or Parts view?  This  
should be easy, since it's almost identical to the way Measure- 
Attached expressions already work.]


• If this feature is to work, Finale will have to (finally) fix  
chord symbols in "Open Key/Atonal" scores (to use Sibelius's  
terminology).  Chord symbols should *always* transpose when  
attached to transposing staves, even in pieces with no key signature.


• Note spelling will be tricky, especially if your score is set to  
display in concert pitch.  I guess the bare-bones approach would be  
to leave note spelling linked, always -- so if you have a concert  
A# in a Bb clarinet part in your score, you will have a B# in your  
part; and if you flip it to a C nat. in

Re: [Finale] Dynamic Parts in Finale

[David W. Fenton]

On 6 Jul 2005 at 2:58, Darcy James Argue wrote:

>   The only thing aspect that's a bit of a frill is the split-screen
> Part-Score view.  That's a bit of a frill, and I could live without
> it.

Outside of the demo showing how changes to notes in either view show 
up in the other window, and how the coloring of expressions with 
spacing adjustments differs, I'm not sure I can see a justification 
for it.

Well, maybe if you wanted to copy something from one part to another? 
But that's really more about displaying two different parts side-by-
side, not part and score. But, it seems to me that implementing 
display of multiple parts theoretically is no different from 
implementing display of a part and the base score.

Does anyone know if Sibelius can display two dynamic parts 
simultaneously? If not, it would be a pretty serious ommission.

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

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

Re: [Finale] Dynamic Parts in Finale

[Eric Dussault]

It would probably benefit most people, but as of now I don't see how  
it could handle large scores with divisi on one staff (or alternating  
with one or several parts in the score depending on the situation)  
for winds and brass instruments.
I normally duplicale my score to make the changes necessary before  
extracting parts (exploding multi-notes staves into their respective  
own staves.

What is the solution for this, Darcy?
this is a pretty normal example I think.

 Darcy, could you post the complete proposal that has been made to  
MakeMusic?


Éric Dussault

Le 05-07-06 à 06:46, dhbailey a écrit :

And I fail to see how this linked score/parts would not benefit  
practically every Finale user.



Éric Dussault



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

Re: [Finale] Dynamic Parts in Finale

[David W. Fenton]

On 6 Jul 2005 at 3:28, Darcy James Argue wrote:

> Using the "switch between full score and part" button in Sibelius
> works exactly way I would like my proposed "Parts View" and "Score
> View" to work in Finale.
> 
> On the other hand, directly selecting a part from the dropdown menu in
> Sibelius (when "Full Score" is showing) spawns a new window.  That's
> bad UI -- I don't want Finale to emulate that.

How in the world would you want it implemented?

There is no real alternative that doesn't put heavy restrictions on 
your ability to view multiple parts simultaneously.

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

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

Re: [Finale] Dynamic Parts in Finale

[David W. Fenton]

On 6 Jul 2005 at 3:24, Darcy James Argue wrote:

> Another thing,
> 
> The video in on dynamic parts Sibelius is actually quite misleading. 
> You see the narrator click on a part name, and instantly, a
> split-screen appears.  That's not what actually happens when you use
> the program.  In fact, it's not a split screen at all, it's two
> separate windows (which you can see if you look closely at the video
> -- those are two Windows XP windows, not a single window with a
> split-screen view).
> 
> When you select a Dynamic Part in Sibelius, it spawns a completely new
> window. . .

But not an *independent* one -- it's a child window of the parent 
Finale window. This seems to me exactly the correct way to do it.

> . . . My preference would be for Finale to *not* do that.  I like
> the concept of parts as a separate View in *the same window* -- hence
> my idea of Parts View and Score View.

How would you want it implemented, as two panes of a single window? 
If you do that, you end up with the ability to have only two panes, 
meaning you could not compare multiple parts simultaneously.

> When you use Special Parts Extraction, when you switch from scroll
> view (score) to page view (part), it doesn't spawn a new document
> window.  When Finale implements Dynamic parts, I would like it to
> follow that model instead of the Sibelius model.

Well, I think it should work the same way as "New Window" within a 
document works -- it opens a new document window showing the same 
document, and you can adjust that window's view accordingly. 

It seems to me that "score view" and "violin part view" are 
equivalent -- just views of the same underlying data. And there 
should be no special privileging of score view over any part views.

The simplest way to implement it, seems to me, with the most 
flexibility, is to start from Finale's current implementation of New 
Document Window, where you can switch between scroll and page view in 
any of those windows independently. If you then add the part views as 
options in each of those document windows, you've got maximum 
flexibility.

I can't see how your suggestion would do anything but prevent the 
implementation of viewing more than one part at a time.

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

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

Re: [Finale] Dynamic Parts in Finale

[Dennis Bathory-Kitsz]

At 12:04 PM 7/6/05 -0400, Eric Dussault wrote:
>It would probably benefit most people, but as of now I don't see how  
>it could handle large scores with divisi on one staff (or alternating  
>with one or several parts in the score depending on the situation)  
>for winds and brass instruments.

This would really ask for a (welcome) re-thinking of how Finale handles
information -- part-based rather than measure/staff based.

This has been discussed before, but it basically means tagging what
constitutes a part. A part is a player or a voice, and no matter where the
part goes, the tag follows it. Extraction then pulls the parts out by their
tags, and not by what staff they might be on at the moment, or if they're
tacit for a movement, or if they're running a2 for a while, or if they're
up/down stems, or homophonic, or contrapuntal.

Dennis


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

Re: [Finale] Dynamic Parts in Finale

[Andrew Stiller]

On Jul 6, 2005, at 2:58 AM, Darcy James Argue wrote:


.  Let's see if we can flesh something out on-list before submitting.

• First, Special Part Extraction would need to be revamped to be able 
to save independent an layout for each staff


Of all the long list of proposed features that follows, I'm not at all 
sure I feel a need for *any* of them.  Darcy is asking  for a profusion 
of new dialog boxes and windows, whereas I would have thought it  
obvious that any dynamic parts linking  should be transparent: I change 
the score, the change is automatically (after signing off on an alert 
box) conveyed  to the parts. Period.


And as I wrote in a separate  post, even that  would be much  less 
useful to me  than the reverse: change a part and have  it 
automatically (after an alert box) affect the score.


Andrew Stiller
Kallisti Music Press
http://home.netcom.com/~kallisti/


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

Re: [Finale] Dynamic Parts in Finale

[Eric Dannewitz]

Yeah. I agree. Thinking about it, if I do changes, it is AFTER parts are 
extracted, after they have been "proof played". That is when someone 
goes "You know, this would be better. Or that looks funny".


If Finale does part linking/dynamic parts, or whatever you want to call 
it, it needs to be TWO way. If you make a change in the part, or in the 
score, they BOTH get updated.


Andrew Stiller wrote:

Of all the long list of proposed features that follows, I'm not at all 
sure I feel a need for *any* of them.  Darcy is asking  for a 
profusion of new dialog boxes and windows, whereas I would have 
thought it  obvious that any dynamic parts linking  should be 
transparent: I change the score, the change is automatically (after 
signing off on an alert box) conveyed  to the parts. Period.


And as I wrote in a separate  post, even that  would be much  less 
useful to me  than the reverse: change a part and have  it 
automatically (after an alert box) affect the score.




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

Re: [Finale] Dynamic Parts in Finale

[David W. Fenton]

On 6 Jul 2005 at 12:19, Andrew Stiller wrote:

> On Jul 6, 2005, at 2:58 AM, Darcy James Argue wrote:
> 
> > .  Let's see if we can flesh something out on-list before
> > submitting.
> >
> > • First, Special Part Extraction would need to be revamped to be
> > able to save independent an layout for each staff
> 
> Of all the long list of proposed features that follows, I'm not at all
> sure I feel a need for *any* of them.  Darcy is asking  for a
> profusion of new dialog boxes and windows, whereas I would have
> thought it  obvious that any dynamic parts linking  should be
> transparent: I change the score, the change is automatically (after
> signing off on an alert box) conveyed  to the parts. Period.
> 
> And as I wrote in a separate  post, even that  would be much  less
> useful to me  than the reverse: change a part and have  it
> automatically (after an alert box) affect the score.

I don't see why you'd want an alert box. The only reason I can see it 
is in order to break the habits of thought that independent file part 
extraction has built up in experienced Finale users, where they can 
do anything to the part and know that the score remains unchanged.

It seems to me self-evident that linked parts are the way Finale 
should have been designed from the beginning. The spawing of 
individual independent files, while perhaps dictated by the realities 
of computer processing power at the time Finale was designed, make no 
sense at all when Finale is viewed as a database program. The data 
file is a database, and there are various report views for showing 
that data and subsets of that data. That is a perfectly natural way 
to think of the program and the presentation of its data.

Then the only question is whether or not the different views are 
completely independent of each other in terms of the "view" 
characteristics (i.e., layout) or if subviews (individual parts) 
inherit characteristics from the global view (score).

I can't see any reason except the inertia of experience to not see 
linked parts as a huge advantage, especially for composers who are in 
Dennis's situation (i.e., making revisions to the piece based on 
feedback from a reading with actual musicians).

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


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

Re: [Finale] Dynamic Parts in Finale

[Aaron Sherber]

At 12:19 PM 07/06/2005, Andrew Stiller wrote:
>Of all the long list of proposed features that follows, I'm not at all
>sure I feel a need for *any* of them.  Darcy is asking  for a profusion
>of new dialog boxes and windows, whereas I would have thought it
>obvious that any dynamic parts linking  should be transparent: I change
>the score, the change is automatically (after signing off on an alert
>box) conveyed  to the parts. Period.

Well, yes, I think that's implicit in Darcy's suggestion. The rest of 
it has to do with what happens *after* that, allowing you to have a 
different format for parts than for score (or different formats for 
different parts -- I use different settings for piano parts than for 
other instruments, e.g.) or to change spacing in the part without 
having it affect the score.


>And as I wrote in a separate  post, even that  would be much  less
>useful to me  than the reverse: change a part and have  it
>automatically (after an alert box) affect the score.

I think that's also implicit in Darcy's post, and it's also how 
Sibelius does things. You also have the option of changing certain 
things (note spacing, expression positioning, etc.) in the parts and 
having them *not* affect the score.


Aaron.

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

Re: [Finale] Dynamic Parts in Finale

[David W. Fenton]

On 6 Jul 2005 at 9:30, Eric Dannewitz wrote:

> If Finale does part linking/dynamic parts, or whatever you want to
> call it, it needs to be TWO way. If you make a change in the part, or
> in the score, they BOTH get updated.

Given that the pre-Sibelius 4 discussions of linked parts here in 
this forum revolved around the idea of implementing them by extending 
Special Part Extraction, where does the idea that it *wouldn't* be 
two-way by default come from?

The whole principle behind the discussion was that parts would be a 
limited view of the same data as the full score. That idea has 
inherent within it two-way editing. Of course, "two-way" editing is 
an incorrect concept, as it reflects the idea that the two views are 
somehow based on independent data, when, in fact, the whole point is 
that you're editing exactly the same data.

I'm confused by the need to mention this, as it was inherent in the 
original discussion here on the list, as is also explicitly described 
in the Sibelius demo.

It's also been repeatedly mentioned in our discussion of Sibelius's 
implementation.

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

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

Re: [Finale] Dynamic Parts in Finale

[Eric Dannewitz]

David W. Fenton wrote:


On 6 Jul 2005 at 9:30, Eric Dannewitz wrote:
 

Given that the pre-Sibelius 4 discussions of linked parts here in 
this forum revolved around the idea of implementing them by extending 
Special Part Extraction, where does the idea that it *wouldn't* be 
two-way by default come from?
 

Because the name, SPECIAL PART EXTRACTION means, to me, it's going to be 
UNLINKED from the score. Hence the name, extraction.


So, if Finale did something like Sibelius's Dynamic Parts, it should be 
something called LINKED parts. Or maybe we need to refer to it as 
something else then.



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

Re: [Finale] Dynamic Parts in Finale

[Darcy James Argue]

On 06 Jul 2005, at 12:19 PM, Andrew Stiller wrote:



On Jul 6, 2005, at 2:58 AM, Darcy James Argue wrote:


.  Let's see if we can flesh something out on-list before submitting.

• First, Special Part Extraction would need to be revamped to be able 
to save independent an layout for each staff


Of all the long list of proposed features that follows, I'm not at all 
sure I feel a need for *any* of them.  Darcy is asking  for a 
profusion of new dialog boxes and windows, whereas I would have 
thought it  obvious that any dynamic parts linking  should be 
transparent: I change the score, the change is automatically (after 
signing off on an alert box) conveyed  to the parts. Period.


And as I wrote in a separate  post, even that  would be much  less 
useful to me  than the reverse: change a part and have  it 
automatically (after an alert box) affect the score.


I thought everyone understood that this was implicit in the idea of 
Dynamic Parts.


The proposed features that follow are, to me, essential if the feature 
is to be actually useful.  If you can't specify a separate page format 
for the parts, or you can't specify a different font size and 
positioning for text blocks in the parts than in the score, or you 
can't include cue notes in the parts but not the score, or you can't 
change the positioning of dynamics in the parts but not the score, then 
Dynamic Parts becomes much less useful.


- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY




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

Re: [Finale] Dynamic Parts in Finale

[Eric Dannewitz]

Yeah, the demo that Sibelius has, it looks like you can change notes, 
dynamics and page layouts. But what about all the other stuff? Text 
blocks? Different fonts? Slurs? articulations? Can you move these around?



Darcy James Argue wrote:

The proposed features that follow are, to me, essential if the feature 
is to be actually useful.  If you can't specify a separate page format 
for the parts, or you can't specify a different font size and 
positioning for text blocks in the parts than in the score, or you 
can't include cue notes in the parts but not the score, or you can't 
change the positioning of dynamics in the parts but not the score, 
then Dynamic Parts becomes much less useful.


- Darcy




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

Re: [Finale] Dynamic Parts in Finale

[Aaron Sherber]

At 01:28 PM 07/06/2005, Eric Dannewitz wrote:
>Because the name, SPECIAL PART EXTRACTION means, to me, it's going to be
>UNLINKED from the score. Hence the name, extraction.

Erm, in current Speical Part Extraction in Finale, nothing is 
unlinked. Any changes you make in Special Part Extraction are 
reflected in the score.


I agree that Special Part Extraction may not be the best name for 
this, since nothing is physically extracted, but it's been called 
that in Finale forever, and we were discussing the idea of dynamic 
parts based on this model.


Aaron.

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

Re: [Finale] Dynamic Parts in Finale

[Darcy James Argue]

On 06 Jul 2005, at 12:10 PM, David W. Fenton wrote:


On 6 Jul 2005 at 3:24, Darcy James Argue wrote:



When you select a Dynamic Part in Sibelius, it spawns a completely new
window. . .


But not an *independent* one -- it's a child window of the parent
Finale window. This seems to me exactly the correct way to do it.


Well, I don't know how XP works so I can't comment on that end of it.  
But on the Mac, there is no such thing as a "child" window.



. . . My preference would be for Finale to *not* do that.  I like
the concept of parts as a separate View in *the same window* -- hence
my idea of Parts View and Score View.


How would you want it implemented, as two panes of a single window?


No -- no split screen.  It would be just another view inside the main 
window, like Page View and Scroll View.



If you do that, you end up with the ability to have only two panes,
meaning you could not compare multiple parts simultaneously.


Hmm.  Well, you could open multiple copies of the same document -- but 
I don't think that's a very good solution, either.


The problem is that -- on Mac at least -- it's very bad UI to have 
changes in one open document automatically affect another document.  
With Dynamic Parts, we are talking about a *single* document that 
contains both the score and the parts.  Parts view is just a different 
way of viewing the underlying data.  But as soon as we start spawning 
separate windows, that looks -- to Mac users -- like separate, 
independent documents, and that's not what we want for Dynamic Parts.


It's hard for me to say if this is a problem, because I never compare 
two (or more) parts on-screen simultaneously.  If I want to compare 
parts, I print them out.  But if on-screen comparison of multiple parts 
is important to people, I guess there needs to be some way of doing 
that -- I would just prefer to do that *without* spawning a bunch of 
new windows.  But that's a tough nut to crack.



Well, I think it should work the same way as "New Window" within a
document works -- it opens a new document window showing the same
document, and you can adjust that window's view accordingly.


There is no "New Window" menu item on the Mac.


The simplest way to implement it, seems to me, with the most
flexibility, is to start from Finale's current implementation of New
Document Window, where you can switch between scroll and page view in
any of those windows independently. If you then add the part views as
options in each of those document windows, you've got maximum
flexibility.

I can't see how your suggestion would do anything but prevent the
implementation of viewing more than one part at a time.


I have no problem with the UI you suggested for Windows, if that's what 
Windows users are used to.  But the approach you suggest is completely 
nonstandard on the Mac.


In Sibelius -- at least on Mac -- you can't compare two parts 
side-by-side.  You can only have the score window plus one dynamic part 
open at any one time.


There is also a warning in Sibelius: "Closing the full score will also 
close the parts.  Do you want to do this?"


- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY

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

Re: [Finale] Dynamic Parts in Finale

[Lon Price]

On Jul 6, 2005, at 10:02 AM, David W. Fenton wrote:It seems to me self-evident that linked parts are the way Finale  should have been designed from the beginning. The spawing of  individual independent files, while perhaps dictated by the realities  of computer processing power at the time Finale was designed, make no  sense at all when Finale is viewed as a database program. The data  file is a database, and there are various report views for showing  that data and subsets of that data. That is a perfectly natural way  to think of the program and the presentation of its data. You know, MOTU's Composer's Mosaic was designed this way, and was the reason I went with it instead of Finale in 1990.  Mosaic gave the user the ability to create as many "views" of his/her music as wanted--either scroll views or page views--and all were contained within a single file.  One could open any or all views, and then toggle between them.  You could put together a scroll view of just the woodwinds, for example.  You could have a concert score and a transposed score in the same file, and of course all of the parts, either transposed or concert.  Where MOTU dropped the ball was the fact that any change made anywhere affected everywhere else.  Tweaking the score to make it look right screwed up the parts, and vice versa.  We users had to end up creating two files--one for parts and the other for the score.  Besides that, the program was really buggy and needed a lot of work.  Unfortunately (for us Mosaic users), MOTU introduced Digital Performer at about the same time, and eventually virtually all of their R&D went into that program, and, even though we users tried to get them not to, MOTU abandoned Mosaic altogether (although they still sell it).  My report on Mosaic is still on my website:     in case anyone is interested in reading it.Lon  Lon Price, Los Angeles <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>   ___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Dynamic Parts in Finale

[Darcy James Argue]

On 06 Jul 2005, at 2:10 PM, Eric Dannewitz wrote:

Yeah, the demo that Sibelius has, it looks like you can change notes, 
dynamics and page layouts. But what about all the other stuff? Text 
blocks? Different fonts? Slurs? articulations? Can you move these 
around?


RE: Text blocks, it seems to depend what they are attached to.  I could 
move the title of the Sax Concerto in the parts, and it stayed put in 
the score.  But moving the composer's name affected both parts and 
score.


[BTW, everyone knows that the Sib 4.0 demo is AVAILABLE NOW, right?  
You guys can all go try this for yourselves.]


- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY

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

Re: [Finale] Dynamic Parts in Finale

[Eric Dannewitz]

Oh, you know, I think I have EXTRACT Parts and Special Part Extraction 
grouped together. They are different.


Aaron Sherber wrote:

Erm, in current Speical Part Extraction in Finale, nothing is 
unlinked. Any changes you make in Special Part Extraction are 
reflected in the score.


I agree that Special Part Extraction may not be the best name for 
this, since nothing is physically extracted, but it's been called that 
in Finale forever, and we were discussing the idea of dynamic parts 
based on this model.




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

Re: [Finale] Dynamic Parts in Finale

[William Roberts]

Eric wrote:

> Yeah, the demo that Sibelius has, it looks like you can change 
> notes, dynamics and page layouts. But what about all the other 
> stuff? Text blocks? Different fonts? Slurs? articulations? Can you 
> move these around?

I got tired of reading all this stuff here today and not being able to join in, 
so I downloaded the demo to try it out.  I opened up one of the examples they 
supply with the demo, and was quickly able to work out how this all works.  
After an hour's playing, here's what I know.

It looks like, if you drag something in the score, it moves in the parts, but 
if you move it in the parts, it won't move in the score.  So, say you have an 
expression marking by a horn note that collides with a low note in a concert 
score, when you look at the transposed part, you can drag that note up to be 
nearer the note (which is now a 5th higher) and it won't move in the score, 
plus it goes a different color to show you what's happened.

Slurs and ties appear to be independent, too, e.g. you can drag a slur or flip 
the curve of a tie in the part and it won't affect the score, which is great 
for those transposed parts.  Articulations (things like staccatos and marcatos) 
look like they have to be the same side of the note in the part as they are in 
the score, and it's the same with things like respelling the note: when I tried 
to respell a note in the part, it changed in the score, too.

Text was a bit funky, but I worked it out.  Looks like every kind of text can 
have a different size in the score in the parts, so you can have a bigger title 
in the score relative to the size of the staff than you would in the parts.  
Looks like you can also have a different default position of each kind of text 
in the score and parts if you want, so if you want expressions above the staff 
in the score but below in the part, you can do that (not sure why you'd want 
to, but you can!).

I have to say that it looks really, really easy.  The demo's crippled, as you 
might expect, but I tried clicking Print All Parts in the File menu, and it 
just spooled out the first page of each part, without me having to do anything. 
 It's easy to switch between the part and the score (just choose it from the 
menu, or hit a key), and it's fast on my computer, too!

I don't know how you guys feel about this, but my gut is that MakeMusic! will 
have to add this feature now, just to stay competitive with Sibelius.  It must 
be galling for them to have Sibelius announce a new version about a week after 
they do, and for people on this listserve to spend more time talking about the 
new Sibelius than Finale 2k6!

Best,
-WR

-- 
___
NEW! Lycos Dating Search. The only place to search multiple dating sites at 
once.
http://datingsearch.lycos.com


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

Re: [Finale] Dynamic Parts in Finale

[Darcy James Argue]

On 06 Jul 2005, at 3:11 PM, William Roberts wrote:

It looks like, if you drag something in the score, it moves in the 
parts, but if you move it in the parts, it won't move in the score.  
So, say you have an expression marking by a horn note that collides 
with a low note in a concert score, when you look at the transposed 
part, you can drag that note up to be nearer the note (which is now a 
5th higher) and it won't move in the score, plus it goes a different 
color to show you what's happened.


That's true but there's more.  Once you drag something -- let's say, a 
dynamic, or an 8va marking -- in the part, it unlinks the positioning 
of that element.  So if you go back and move it again in the score, it 
won't affect the part.  You can also re-link elements after unlinking 
them.


And -- exactly as I suggested in my outline of how Finale ought to do 
this -- unlinking only affects positioning.  If you delete an unlinked 
dynamic from the part, it disappears from the score, too.  It's also 
possible to create score-only or parts-only expressions, etc.


Sibelius really put a lot of thought into this feature.  Almost 
everything works just like you'd expect.


I don't know how you guys feel about this, but my gut is that 
MakeMusic! will have to add this feature now, just to stay competitive 
with Sibelius.


I sure hope so.  The only upside is, as Robert pointed out, it may be 
cheaper and easier for them to implement this now that Sibelius has 
shown how it ought to be done.


- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY


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

Re: [Finale] Dynamic Parts in Finale

[William Roberts]

Darcy wrote:

> In Sibelius -- at least on Mac -- you can't compare two parts 
> side-by-side.  You can only have the score window plus one dynamic 
> part open at any one time.

That's not true.  You can resize the document windows and position them next to 
each other.  I also went digging in the Prefs dialog and found an option in 
there to open each new part in a new window, so you can actually have as many 
parts open as you like simultaneously.  And Sibelius does seem to have a New 
Window item in the Window menu, which does what you'd expect it to (and I 
notice that Word X 2004 has it too, for example).

The more I play with this, the more I like it!

Best,
-Will

-- 
___
NEW! Lycos Dating Search. The only place to search multiple dating sites at 
once.
http://datingsearch.lycos.com


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

Re: [Finale] Dynamic Parts in Finale

[David W. Fenton]

On 6 Jul 2005 at 10:28, Eric Dannewitz wrote:

> David W. Fenton wrote:
> 
> >On 6 Jul 2005 at 9:30, Eric Dannewitz wrote:
> >
> >Given that the pre-Sibelius 4 discussions of linked parts here in
> >this forum revolved around the idea of implementing them by extending
> > Special Part Extraction, where does the idea that it *wouldn't* be
> >two-way by default come from?
> >
> Because the name, SPECIAL PART EXTRACTION means, to me, it's going to
> be UNLINKED from the score. Hence the name, extraction.

Except that SPECIAL PART EXTRACTION as it exists today is *not* 
unlinked from the score -- it *is* the score, just a different view 
of it.

The flaw in it is that layout changes also change the score, and 
that's why most people create a new file to do their special part 
extraction in.

> So, if Finale did something like Sibelius's Dynamic Parts, it should
> be something called LINKED parts. Or maybe we need to refer to it as
> something else then.

To me "linked" means between files, and that raises a whole host of 
difficult issues if you're trying to maintain links between separate 
objects in the file system that could be renamed or moved via means 
outside Finale.

That's why I said earlier on that "linked parts" was a term I don't 
like, as it implies certain things.

I see no easy way to implement dynamic parts with part files separate 
from the score.

I think it's fairly easy to see, given the already pre-existing 
special parts extraction view, how it could be done in the score file 
-- it would "simply" be a matter of changing special parts extraction 
so that layout changes done in that mode are stored separately from 
the layout for the score *not* viewed in that mode, and with the 
layout changes stored for each individual part.

One advantage would be that if it were implemented this way, you 
could still use groups and the like to define parts that have more 
than one staff in them. However, it wouldn't be possible without some 
kind of huge workaround (seems to me) to implement exploding layers 
into separate parts, unless you could have part definitions be layer-
specific.

Of course, we're all speculating about things that don't exist. I'm 
doing so based on my understanding of the relationship between 
databases and views of data from a database, as well as a rudimentary 
understanding of object orientation in computer programming.

And so far as I can see, no one is suggesting that a dynamic parts 
function should remove existing functionality from Finale. If you had 
a part that needed to be extracted in a way that the new dynamic 
parts didn't really support, then you could still do a traditional 
extraction to a separate file. You'd lose the link back to the score, 
but losing it for the 2/4/6 parts that require exploding to different 
staves would still mean you'd have the linkage for all the other 
parts -- that is, it would vastly reduce the amount of work to 
maintain all the *other* parts.

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

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

Re: [Finale] Dynamic Parts in Finale

[David W. Fenton]

On 6 Jul 2005 at 14:30, Darcy James Argue wrote:

> On 06 Jul 2005, at 12:10 PM, David W. Fenton wrote:
> 
> > On 6 Jul 2005 at 3:24, Darcy James Argue wrote:
> 
> >> When you select a Dynamic Part in Sibelius, it spawns a completely
> >> new window. . .
> >
> > But not an *independent* one -- it's a child window of the parent
> > Finale window. This seems to me exactly the correct way to do it.
> 
> Well, I don't know how XP works so I can't comment on that end of it. 
> But on the Mac, there is no such thing as a "child" window.

Sure there is. Any document window spawned by Finale is a child of 
the parent Finale window. The way that is represented onscreen and 
the available behaviors for that window are completely different 
between Windows and OS X/Mac OS, but the windows are still child 
windows of Finale (i.e., spawned by Finale and owned by Finale for 
the purpose of displaying Finale data).

> >> . . . My preference would be for Finale to *not* do that.  I like
> >> the concept of parts as a separate View in *the same window* --
> >> hence my idea of Parts View and Score View.
> >
> > How would you want it implemented, as two panes of a single window?
> 
> No -- no split screen.  It would be just another view inside the main
> window, like Page View and Scroll View.

But you can't view Page View and Scroll View simultaneously in the 
same file unless you open a new document window.

> > If you do that, you end up with the ability to have only two panes,
> > meaning you could not compare multiple parts simultaneously.
> 
> Hmm.  Well, you could open multiple copies of the same document -- but
> I don't think that's a very good solution, either.

Opening multiple document windows solves the problem, though. And 
that's what I'm reading you as having said you don't like.

> The problem is that -- on Mac at least -- it's very bad UI to have
> changes in one open document automatically affect another document. 

How are multiple windows on a single document implemented on the Mac? 
Whatever method is used for that would make perfect sense for part 
view.

> With Dynamic Parts, we are talking about a *single* document that
> contains both the score and the parts.  Parts view is just a different
> way of viewing the underlying data.  But as soon as we start spawning
> separate windows, that looks -- to Mac users -- like separate,
> independent documents, and that's not what we want for Dynamic Parts.

Well, perhaps I'm wrong to assume that FinMac has the ability to open 
multiple windows on the same Finale file?

> It's hard for me to say if this is a problem, because I never compare
> two (or more) parts on-screen simultaneously.  If I want to compare
> parts, I print them out.  But if on-screen comparison of multiple
> parts is important to people, I guess there needs to be some way of
> doing that -- I would just prefer to do that *without* spawning a
> bunch of new windows.  But that's a tough nut to crack.

I do it for copying system layouts (i.e., choosing system breaks). 
Sibelius's capability for copying layouts from one part to another 
would obviate that, but I can definitely see wanting to view a couple 
of parts at a time for other reasons, as well, such as editing the 
parts from a printed set of parts that have been marked up during a 
rehearsal/performance.

> > Well, I think it should work the same way as "New Window" within a
> > document works -- it opens a new document window showing the same
> > document, and you can adjust that window's view accordingly.
> 
> There is no "New Window" menu item on the Mac.

You can't view two parts of a Finale document simultaneously?

*BOGGLE*

Tons of my editing work requires this! It's how I do my musicological 
editing, where I make editorial suggestions to make, say, an 
exposition and a recap have similar dynamics/articulations/bowings.

> > The simplest way to implement it, seems to me, with the most
> > flexibility, is to start from Finale's current implementation of New
> > Document Window, where you can switch between scroll and page view
> > in any of those windows independently. If you then add the part
> > views as options in each of those document windows, you've got
> > maximum flexibility.
> >
> > I can't see how your suggestion would do anything but prevent the
> > implementation of viewing more than one part at a time.
> 
> I have no problem with the UI you suggested for Windows, if that's
> what Windows users are used to.  But the approach you suggest is
> completely nonstandard on the Mac.
> 
> In Sibelius -- at least on Mac -- you can't compare two parts 
> side-by-side.  You can only have the score window plus one dynamic
> part open at any one time.

That would seem to me to be a very severe limitation.

> There is also a warning in Sibelius: "Closing the full score will also
> close the parts.  Do you want to do this?"

That means they aren't really independent windows, and if the same 
warning applies in the Windows version, 

Re: [Finale] Dynamic Parts in Finale

[Darcy James Argue]

On 06 Jul 2005, at 7:16 PM, David W. Fenton wrote:


On 6 Jul 2005 at 14:30, Darcy James Argue wrote:



Well, I don't know how XP works so I can't comment on that end of it.
But on the Mac, there is no such thing as a "child" window.


Sure there is. Any document window spawned by Finale is a child of
the parent Finale window.


That's not how it works on Mac.  There *is* no "parent" Finale window, 
so there's no "spawning".  When no Finale documents are open, there is 
no Finale window either -- the application is still running, and you 
can switch to Finale, but there's no window.  When multiple Finale 
documents are open, they are all part of the same hierarchy.  There is 
no way that one parts window can "belong" to a score window.


This lack of window hierarchy concerns me -- for instance, if you had 
two different scores open simultaneously, it might be difficult to tell 
which part window belonged to which score.  Especially if you had, for 
example, two different revisions of the same score open at the same 
time.



Opening multiple document windows solves the problem, though. And
that's what I'm reading you as having said you don't like.


On reflection, I'm fine with doing it either way (as Sieblius does) -- 
so long as there is a way to switch between parts *without* spawning a 
bunch of new windows.  For my own work, I would find that UI much more 
clear than having to deal with a mess of windows.



How are multiple windows on a single document implemented on the Mac?


You open a second copy of the document via the "Open" menu, and the 
Finder labels the windows "Brilliant Concerto.mus:1" ; "Brilliant 
Concerto.mus:2"; etc.



Whatever method is used for that would make perfect sense for part
view.


As long as you can do it both ways, I'm happy.


There is no "New Window" menu item on the Mac.


You can't view two parts of a Finale document simultaneously?

*BOGGLE*


No, you can, you just open a second copy of the same document.  That's 
something that always makes me uncomfortable, though -- I try to avoid 
that if possible.  (I have enough trouble with the File Overwrite bug 
as it is!)



Tons of my editing work requires this! It's how I do my musicological
editing, where I make editorial suggestions to make, say, an
exposition and a recap have similar dynamics/articulations/bowings.


Whenever I have to do anything like this, I use a printout, marked up 
as necessary.  I hate proofing and editing on-screen.



In Sibelius -- at least on Mac -- you can't compare two parts
side-by-side.  You can only have the score window plus one dynamic
part open at any one time.


That would seem to me to be a very severe limitation.


I was wrong -- there's a "open parts in new windows" option in the 
preferences.


David, since you have a lot to say about this feature, I highly 
recommend you download the Sibelius 4 demo and try it for yourself -- 
see how it's implemented, see what you like and don't like.  That would 
help us make better suggestions about how Finale could implement the 
feature.


- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY

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

Re: [Finale] Dynamic Parts in Finale

[David W. Fenton]

On 6 Jul 2005 at 19:38, Darcy James Argue wrote:

> On 06 Jul 2005, at 7:16 PM, David W. Fenton wrote:
> 
> > On 6 Jul 2005 at 14:30, Darcy James Argue wrote:
> 
> >> Well, I don't know how XP works so I can't comment on that end of
> >> it. But on the Mac, there is no such thing as a "child" window.
> >
> > Sure there is. Any document window spawned by Finale is a child of
> > the parent Finale window.
> 
> That's not how it works on Mac.  There *is* no "parent" Finale window,
> so there's no "spawning".. . .

You may not have a box drawn around a rectangle onscreen, but there 
is unquestionably a window onscreen that represents the parent Finale 
process. Document windows are children of that process.

The difference between Windows and Mac is in how this lineage is 
displayed. On Windows, child windows exist only inside the parent 
window. On the Mac, since the parent window does not actual have a 
restricted border, the windows appear independent, and can be moved 
anywhere onscreen.

But they are *still* child windows of Finale.

> . . .  When no Finale documents are open, there is
> no Finale window either -- the application is still running, and you
> can switch to Finale, but there's no window. . . .

Isn't the Finale menu bar visible? That's a window, just not a 
bordered window containing the child windows.

> . . . When multiple Finale
> documents are open, they are all part of the same hierarchy.  There is
> no way that one parts window can "belong" to a score window.

There is no visual representation of that relationship, but it is 
still present. 

What happens if you have 3 document windows open in Finale and you 
exit Finale? Don't the child windows close?

> This lack of window hierarchy concerns me -- for instance, if you had
> two different scores open simultaneously, it might be difficult to
> tell which part window belonged to which score.  Especially if you
> had, for example, two different revisions of the same score open at
> the same time.

I'm stunned that FinMac lacks the ability to compare two different 
parts of the same file in separate document windows. I've often 
thought that some day I might switch to Mac, but that shows I 
couldn't possibly do so!

> > Opening multiple document windows solves the problem, though. And
> > that's what I'm reading you as having said you don't like.
> 
> On reflection, I'm fine with doing it either way (as Sieblius does) --
> so long as there is a way to switch between parts *without* spawning a
> bunch of new windows.  For my own work, I would find that UI much more
> clear than having to deal with a mess of windows.

Well, I did *not* say that all the parts should automatically open 
their own document windows! I'm not even sure the default parts view 
should display the score at all, to be honest. What utility is there 
in that, except to demo the linkage between score and parts?

Once you see the list of available part views it should work just 
like a web browser -- you have a choice of opening the other part 
view in the same document window you're currently using, or to launch 
it in a new window.

> > How are multiple windows on a single document implemented on the
> > Mac?
> 
> You open a second copy of the document via the "Open" menu, and the
> Finder labels the windows "Brilliant Concerto.mus:1" ; "Brilliant
> Concerto.mus:2"; etc.

Ah. Well, then you *do* have multiple document windows. It's surely 
not a second copy of the document that is open, since that would 
cause contention for the file on disk. If you edit in window 1 and 
then go to window 2 and save, aren't the changes in window 1 saved? 
If so, then you've already got multiple windows viewing a single 
document.

> > Whatever method is used for that would make perfect sense for part
> > view.
> 
> As long as you can do it both ways, I'm happy.

Well, I don't know why you assumed that I was proposing opening *all* 
the parts simultaneously any time you switched to part view!

> >> There is no "New Window" menu item on the Mac.
> >
> > You can't view two parts of a Finale document simultaneously?
> >
> > *BOGGLE*
> 
> No, you can, you just open a second copy of the same document.  That's
> something that always makes me uncomfortable, though -- I try to avoid
> that if possible.  (I have enough trouble with the File Overwrite bug
> as it is!)

Sounds like it's implemented with a result just like that in Windows, 
except the Windows UI makes it less dangrous feeling -- you launch a 
new window from the WINDOW menu by choosing NEW WINDOW. The title bar 
is exactly the same as for your separate document windows.

I doubt you have any reason to feel nervous about it. If you really 
were opening the document a second time, one of them would surely 
have to be read-only, and my bet is that this is not the case.

> > Tons of my editing work requires this! It's how I do my
> > musicological editing, where I make editorial suggestions to make,
> > say, an exposition and a recap 

Re: [Finale] Dynamic Parts in Finale

[Mark D Lew]

On Jul 6, 2005, at 3:46 AM, dhbailey wrote:

And I fail to see how this linked score/parts would not benefit 
practically every Finale user.


Well, it wouldn't benefit me, since I almost never extract parts.  My 
work is about 99% piano-vocal or choral, so there's never any parts to 
extract.


Don't get me wrong.  I'm not opposed to the feature.  Obviously it's 
important to a lot of users.  I'm just contesting your implication that 
it's good for everyone.


mdl

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

Re: [Finale] Dynamic Parts in Finale

[David W. Fenton]

On 6 Jul 2005 at 18:12, Mark D Lew wrote:

> On Jul 6, 2005, at 3:46 AM, dhbailey wrote:
> 
> > And I fail to see how this linked score/parts would not benefit
> > practically every Finale user.
> 
> Well, it wouldn't benefit me, since I almost never extract parts.  My
> work is about 99% piano-vocal or choral, so there's never any parts to
> extract.
> 
> Don't get me wrong.  I'm not opposed to the feature.  Obviously it's
> important to a lot of users.  I'm just contesting your implication
> that it's good for everyone.

Exactly how does "benefit practically every Finale user" equate to 
"good for everyone"?

Fact is, it doesn't. You can only disagree with my statement if you 
insist on reading it to say something that I didn't say.

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

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

Re: [Finale] Dynamic Parts in Finale

[Michael Cook]

On 6 Jul 2005, at 20:30, Darcy James Argue wrote:


There is no "New Window" menu item on the Mac.


Where are you looking? This menu item has been in every version of 
Finale I've had, from 3.0 to 2005b. It's in the "Window" menu.


Michael Cook

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

Re: [Finale] Dynamic Parts in Finale

[Darcy James Argue]

On 07 Jul 2005, at 3:21 AM, Michael Cook wrote:


On 6 Jul 2005, at 20:30, Darcy James Argue wrote:


There is no "New Window" menu item on the Mac.


Where are you looking? This menu item has been in every version of 
Finale I've had, from 3.0 to 2005b. It's in the "Window" menu.


I stand corrected!

I had been looking in the File menu, but of course, the Window menu is 
a more logical place for it.


I've been using Finale since v3.0 as well, and for some inexplicable 
reason I never noticed that menu item.


- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY


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

Re: [Finale] Dynamic Parts in Finale

[dhbailey]

Mark D Lew wrote:


On Jul 6, 2005, at 3:46 AM, dhbailey wrote:

And I fail to see how this linked score/parts would not benefit 
practically every Finale user.



Well, it wouldn't benefit me, since I almost never extract parts.  My 
work is about 99% piano-vocal or choral, so there's never any parts to 
extract.


Don't get me wrong.  I'm not opposed to the feature.  Obviously it's 
important to a lot of users.  I'm just contesting your implication that 
it's good for everyone.




I do admit that I hadn't considered that piano music and piano/vocal 
music wouldn't benefit from linked parts.


I should change my remark from "practically every" to "a large number."  :-)

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

Re: [Finale] Dynamic Parts in Finale

[Johannes Gebauer]

I haven't followed the whole discussion yet, but I do hope that if/when 
Finale reinvents dynamic score and parts linking they also come up with 
a new intelligent way of handling cue notes.


Here is what I think would be the least:
1) Mark target part.
2) Command Cue Notes
3) Mark source part

The rest should be automatic, and the Cue notes should update when the 
source is altered. Plus I want fully automatic rest handling, clef 
handling (including clef after the key sig at beginning of the system), 
and no fiddling with any of this. And if I want the cue notes removed 
this should be really easy at the click of a menu. And Cue notes should 
not be in a layer, or rather there needs to be a new, cue note layer.


Don't tell me there is a plugin for that, just another of those ideas 
that never worked properly. I can't tell you how much time I have wasted 
with cue notes in the last few months.


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

Re: [Finale] Dynamic Parts in Finale

[Robert Patterson]

If a plugin has trouble doing cue notes, why would it be any easier in the 
native program? If you care how the cue notes look, no automation MM is likely 
to come up with is like to be good enough. If you don't care, then TGTools is 
sufficient, although there are a few tweaks that would be helpful. (So help me, 
I do care, so TGTools provides only a starting point for me.)

When I said I thought dynamic parts would be possible within an annual cycle, 
what I meant was:

* Separate Page and System records per part
* Separate note spacing per part
* Separate "Special Part Extraction" bits to limit which expressions appear 
where.
* A UI to allow separate Page Views for each part
* (Marginally Possible) a way to hide a particular layer in a particular page 
view (for, e.g., cue notes)

Off the table, I suspect, would be separate font settings for titles. Also, if 
like me you combine parts in a score and split them out in parts, you could not 
use dynamic parts. (I seriously doubt that Sibelius's new feature provides this 
capability either.)

Of all those bullet points, the one would give me the most heartburn is 
separate note spacing. It is essential, but I suspect it tears at the heart of 
Finale and would be extremely risky and painful to implement. The entire 
picture gives me heartburn as a plugin developer, too.

Perhaps this is a case of "be careful what you ask for". The more I think about 
it, the less useful I personally would find it. Automatic vertical spacing 
seems much more attractive to me.




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

Re: [Finale] Dynamic Parts in Finale

[Johannes Gebauer]

Robert,

I don't think you quite understood what I am after. I find the basic 
concept of how cue notes are included in the first place very short 
sighted. Simply adding them to a free layer is always going to cause all 
sorts of problems. What I want is a separate cue notes layer.


The reason I am asking for this now is the cue notes-dynamic score and 
parts link. Cue notes will have to be dealt with when creating dynamic 
score and parts. Ideally I'd like to see a completely new concept for 
them, which would make cue notes much easier in the first place. And the 
new concept would make much more sense when score and part linking is 
there, too. The specifics of the design are debatable.


I know this is whishful thinking, but since we are debating 
improvements, this is one which would save _me_ lots of hours.


The smart cue notes plugin doesn't cut it for me, it causes more trouble 
than it is worth in my experience.


All that said, I actually believe that you are right, and that score and 
part linking will not be all that easy to include in Finale.


However, I wonder whether a new concept of part updating will be 
possible nonetheless. Even using plugins.


Johannes

Robert Patterson schrieb:

If a plugin has trouble doing cue notes, why would it be any easier
in the native program? If you care how the cue notes look, no
automation MM is likely to come up with is like to be good enough. If
you don't care, then TGTools is sufficient, although there are a few
tweaks that would be helpful. (So help me, I do care, so TGTools
provides only a starting point for me.)

When I said I thought dynamic parts would be possible within an
annual cycle, what I meant was:

* Separate Page and System records per part * Separate note spacing
per part * Separate "Special Part Extraction" bits to limit which
expressions appear where. * A UI to allow separate Page Views for
each part * (Marginally Possible) a way to hide a particular layer in
a particular page view (for, e.g., cue notes)

Off the table, I suspect, would be separate font settings for titles.
Also, if like me you combine parts in a score and split them out in
parts, you could not use dynamic parts. (I seriously doubt that
Sibelius's new feature provides this capability either.)

Of all those bullet points, the one would give me the most heartburn
is separate note spacing. It is essential, but I suspect it tears at
the heart of Finale and would be extremely risky and painful to
implement. The entire picture gives me heartburn as a plugin
developer, too.

Perhaps this is a case of "be careful what you ask for". The more I
think about it, the less useful I personally would find it. Automatic
vertical spacing seems much more attractive to me.




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




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

Re: [Finale] Dynamic Parts in Finale

[Robert Patterson]

I do see what you are after (a cue note layer). I just don't see enough added 
benefit to enough users that it will happen. That said, from what I've seen 
starting in Fin04, MM has laid the groundwork for more than 4 layers. Whether 
they ever implement them remains to be seen.

Obviously, you care how cues look, too. I find myself doing alot of copying and 
pasting of cues, so an entire orch. will get a Flute 1 cue even if that may not 
always be the best one.




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

Re: [Finale] Dynamic Parts in Finale

[Andrew Stiller]

On Jul 6, 2005, at 1:02 PM, David W. Fenton wrote:


It seems to me self-evident that linked parts are the way Finale
should have been designed from the beginning. ...The data
file is a database, and there are various report views for showing
that data and subsets of that data
Then the only question is whether or not the different views are
completely independent of each other in terms of the "view"
characteristics (i.e., layout) or if subviews (individual parts)
inherit characteristics from the global view (score).



I agree--with  this caveat: The Page Setup parameters must be 
independently configurable/savable for the score and for each 
individual part. Anything less is a deal-breaker as far as I'm 
concerned. As of now, I know of no program that allows more than one 
Page Setup configuration (at a time) per file, and I have therefore 
assumed that this restriction is unavoidable. Correct me if I'm wrong.


And while we're at it, would it be asking too much to figure out some 
way to transfer page setup data between platforms?  I realize the 
operation is done completely differently in Mac vs. Windows, but 
information is information  isn't it?--and should, therefore, somehow 
be retrievable and transferrable.


Andrew Stiller
Kallisti Music Press
http://home.netcom.com/~kallisti/

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

Re: [Finale] Dynamic Parts in Finale

[David W. Fenton]

On 7 Jul 2005 at 17:57, Johannes Gebauer wrote:

> I don't think you quite understood what I am after. I find the basic
> concept of how cue notes are included in the first place very short
> sighted. Simply adding them to a free layer is always going to cause
> all sorts of problems. What I want is a separate cue notes layer.

I've always felt that the key to a sensible implementation of cue 
notes was in the MIRROR feature.

But nobody uses that because it's all bollixed up and doesn't really 
work.

If they fixed that, it would give you a lot of what you desire with 
linked cue notes. If they then added conditional display to mirrors, 
or the ability to apply a staff style that displayed mirrors in part 
view but not in score view, then you'd have what you want.

But I wouldn't hold my breath.

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

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

Re: [Finale] Dynamic Parts in Finale

[Johannes Gebauer]

David W. Fenton schrieb:


I've always felt that the key to a sensible implementation of cue 
notes was in the MIRROR feature.


But nobody uses that because it's all bollixed up and doesn't really 
work.


If they fixed that, it would give you a lot of what you desire with 
linked cue notes. If they then added conditional display to mirrors, 
or the ability to apply a staff style that displayed mirrors in part 
view but not in score view, then you'd have what you want.


But I wouldn't hold my breath.



I do actually use the mirror feature. It works, but parts of the 
interface is pretty dreadful. The only other complaint I have is that 
Finale pops up a warning about mirrors not being converted properly when 
extracting parts _after_ it has done all the extracting. a) I can't 
understand why it doesn't pop up the warning _before_ it goes about 
extracting all the parts, and b) I don't understand why they never fixed 
this shortcoming in the first place.


I agree that the mirror tool would be a very good way to implement cue 
notes, if it was improved slightly.


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

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

Re: [Finale] Dynamic Parts in Finale

[David W. Fenton]

On 7 Jul 2005 at 16:24, Andrew Stiller wrote:

> On Jul 6, 2005, at 1:02 PM, David W. Fenton wrote:
> 
> > It seems to me self-evident that linked parts are the way Finale
> > should have been designed from the beginning. ...The data file is a
> > database, and there are various report views for showing that data
> > and subsets of that data Then the only question is whether or
> > not the different views are completely independent of each other in
> > terms of the "view" characteristics (i.e., layout) or if subviews
> > (individual parts) inherit characteristics from the global view
> > (score).
> 
> I agree--with  this caveat: The Page Setup parameters must be 
> independently configurable/savable for the score and for each 
> individual part. Anything less is a deal-breaker as far as I'm 
> concerned. As of now, I know of no program that allows more than one
> Page Setup configuration (at a time) per file, and I have therefore
> assumed that this restriction is unavoidable. Correct me if I'm wrong.

The way I've always described dynamic parts has been exactly that way 
-- that there is independent information stored for each view. If the 
positioning of a "p" in the flute part can be independent from the 
score, that means that there is a special data structure dedicated to 
the flute part for store layout/positioning data specific to that 
particular part.

Including page/system layout definitions in that is a no-brainer.

Now, I'd also say there should be a layer intermediate between the 
score and parts, a "default part layout" definition, so that when you 
create a part view, it inherits those part layout parameters (much 
like Finale's current independent page layouts settings for extracted 
parts). Then, when you edit a particular part (perhaps optimizing and 
dragging a few systems, or changing the margins of a few system to 
fit more/fewer systems on a page), those changes would be stored for 
the part.

> And while we're at it, would it be asking too much to figure out some
> way to transfer page setup data between platforms?  I realize the
> operation is done completely differently in Mac vs. Windows, but
> information is information  isn't it?--and should, therefore, somehow
> be retrievable and transferrable.

I'm not sure why there's a problem today. If you create a file with 
page layout definitions in it, you can save a library, or send the 
file to someone and they can save the library for page layout and 
import it into their document. Or use Robert's Settings Scrapbook to 
copy the settings.

I'm not sure what you're asking for here that can't be done in a 
manner that's already pretty consistent with the way these things 
work in Finale.

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

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

Re: [Finale] Dynamic Parts in Finale

[Johannes Gebauer]

David W. Fenton schrieb:

And while we're at it, would it be asking too much to figure out some
way to transfer page setup data between platforms?  I realize the
operation is done completely differently in Mac vs. Windows, but
information is information  isn't it?--and should, therefore, somehow
be retrievable and transferrable.



I'm not sure why there's a problem today. If you create a file with 
page layout definitions in it, you can save a library, or send the 
file to someone and they can save the library for page layout and 
import it into their document. Or use Robert's Settings Scrapbook to 
copy the settings.


I'm not sure what you're asking for here that can't be done in a 
manner that's already pretty consistent with the way these things 
work in Finale.




You are talking about Page layout, while Andrew was refering to Page 
Setup. Two different things in Finale.


The problem Andrew describes has nothing to do with libraries, and it is 
even a problem going from OS 9 to OS X. To my knowledge there is no easy 
work around.


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

Re: [Finale] Dynamic Parts in Finale

[Matthew Hindson Fastmail Account]

Johannes Gebauer wrote:

The smart cue notes plugin doesn't cut it for me, it causes more trouble 
than it is worth in my experience.


Johannes, I'm interested in the problems you've had with this - are you 
using the one in the TGTools set?  Because I find this to be an absolute 
time-saver in so many respects.  There are some things I wish it would 
do better (such as automatically move the whole-bar rests out of the way 
of the music), but other than that, I've had almost no problems with it.


Matthew


--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.10/43 - Release Date: 6/07/2005

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

Re: [Finale] Dynamic Parts in Finale

[David W. Fenton]

On 8 Jul 2005 at 1:09, Johannes Gebauer wrote:

> David W. Fenton schrieb:
> >>And while we're at it, would it be asking too much to figure out
> >>some way to transfer page setup data between platforms?  I realize
> >>the operation is done completely differently in Mac vs. Windows, but
> >>information is information  isn't it?--and should, therefore,
> >>somehow be retrievable and transferrable.
> > 
> > I'm not sure why there's a problem today. If you create a file with
> > page layout definitions in it, you can save a library, or send the
> > file to someone and they can save the library for page layout and
> > import it into their document. Or use Robert's Settings Scrapbook to
> > copy the settings.
> > 
> > I'm not sure what you're asking for here that can't be done in a
> > manner that's already pretty consistent with the way these things
> > work in Finale.
> 
> You are talking about Page layout, while Andrew was refering to Page
> Setup. Two different things in Finale.

Do you mean printer-based page setup? Finale on Windows has never 
been very smart about page setup, unlike every other Windows program, 
that is smart enough to store information about page setup in the 
document file.

> The problem Andrew describes has nothing to do with libraries, and it
> is even a problem going from OS 9 to OS X. To my knowledge there is no
> easy work around.

Please enlighten me as to what Andrew is talking about.

Whatever it is, if there's a data structure in Finale that already 
stores the information, there is no reason to assume that this data 
structure will not be duplicated in part views, in order that parts 
can have independent settings.

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

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

Re: [Finale] Dynamic Parts in Finale

[Johannes Gebauer]

I am talking about the smart cue notes plugin that is part of Finale 
(not TGTools, though I think Tobias programmed the plugin, too).


Johannes

Matthew Hindson Fastmail Account schrieb:

Johannes Gebauer wrote:

The smart cue notes plugin doesn't cut it for me, it causes more 
trouble than it is worth in my experience.



Johannes, I'm interested in the problems you've had with this - are you 
using the one in the TGTools set?  Because I find this to be an absolute 
time-saver in so many respects.  There are some things I wish it would 
do better (such as automatically move the whole-bar rests out of the way 
of the music), but other than that, I've had almost no problems with it.


Matthew




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

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

Re: [Finale] Dynamic Parts in Finale

[Andrew Stiller]

On Jul 7, 2005, at 7:47 PM, David W. Fenton wrote:


The problem Andrew describes has nothing to do with libraries, and it
is even a problem going from OS 9 to OS X. To my knowledge there is no
easy work around.


Please enlighten me as to what Andrew is talking about.

Whatever it is, if there's a data structure in Finale that already
stores the information, there is no reason to assume that this data
structure will not be duplicated in part views, in order that parts
can have independent settings.



On the Mac, in any printable application, there is a File menu item 
called Page Setup, wh.  calls up a dialog in wh. printer settings are 
stored. If, for example, you want to print a part on folded 11X17 
sheets, the Finale layout would prescribe ordinary letter-size paper, 
but the Page Setup should prescribe 11X17. Obviously, one would often 
want to do just this for parts, but not for the score they came from.


My concern is that I have never heard of any Mac application in which 
two different Page Setup configurations could be applied simultaneously 
to the same file, and I therefore wonder whether it might prove 
impossible to do such a thing in the Mac environment.


Andrew Stiller
Kallisti Music Press
http://home.netcom.com/~kallisti/

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

Re: [Finale] Dynamic Parts in Finale

[Darcy James Argue]

On 08 Jul 2005, at 12:25 PM, Andrew Stiller wrote:

My concern is that I have never heard of any Mac application in which 
two different Page Setup configurations could be applied 
simultaneously to the same file,


Yes you have -- Sibelius 4.0.

and I therefore wonder whether it might prove impossible to do such a 
thing in the Mac environment.


Clearly not.

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY

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

Re: [Finale] Dynamic Parts in Finale

[dhbailey]

Andrew Stiller wrote:


On Jul 6, 2005, at 1:02 PM, David W. Fenton wrote:


It seems to me self-evident that linked parts are the way Finale
should have been designed from the beginning. ...The data
file is a database, and there are various report views for showing
that data and subsets of that data
Then the only question is whether or not the different views are
completely independent of each other in terms of the "view"
characteristics (i.e., layout) or if subviews (individual parts)
inherit characteristics from the global view (score).



I agree--with  this caveat: The Page Setup parameters must be 
independently configurable/savable for the score and for each individual 
part. Anything less is a deal-breaker as far as I'm concerned. As of 
now, I know of no program that allows more than one Page Setup 
configuration (at a time) per file, and I have therefore assumed that 
this restriction is unavoidable. Correct me if I'm wrong.




Andrew, I posed your question on the Sibelius list, concerning 
independent page setup parameters for each part, and here is the answer 
from the resident Sibelius employee, confirming that you can indeed have 
independent page setups for each part:


The first bit is my question -- the part beginning with "yes indeed" is 
his response:


[quote]
> Someone on the Finale list asked if we can use different page setup
> definitions for one or more parts, separate from the page setup
> definitions (I think he was asking basically about changing paper size
> for the parts, differently from the score, and possibly even asking if
> each part could have its own page definition, so, for whatever reason,
> someone might print a violin part on 8.5x11 (sorry, I'm American and I
> can never keep those A sizes straight) in portrait mode but print
> percussion parts on 8.5x14 (legal) in landscape mode.
>
> Is this possible?

Yes, indeed.  The Multiple Part Appearance dialog allows you to change
the page and staff size for one or more parts; if you want finer
control, you can go to the Layout > Document Setup dialog when viewing a
dynamic part and change things like margins etc. there (which can then
be propagated to other parts via house styles).  Each part can naturally
have a completely different page size if necessary.

Furthermore, on Mac, where it is necessary for each part to have its own
printer-specific Page Setup data, you can click the 'Page Setup' button
in the Multiple Part Appearance dialog and set the printer-specific
properties for one or more parts, and of course this can also be set
individually for each part via the File > Page Setup dialog if you wish.
  (Nothing of this sort is required on Windows, where you set the paper
size to be used for the print job via the Properties button in the File
> Print dialog, or Sibelius simply uses the Windows default paper size).
[endquote]

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

Re: [Finale] Dynamic Parts in Finale

[David W. Fenton]

On 8 Jul 2005 at 12:25, Andrew Stiller wrote:

> On Jul 7, 2005, at 7:47 PM, David W. Fenton wrote:
> 
> >> The problem Andrew describes has nothing to do with libraries, and
> >> it is even a problem going from OS 9 to OS X. To my knowledge there
> >> is no easy work around.
> >
> > Please enlighten me as to what Andrew is talking about.
> >
> > Whatever it is, if there's a data structure in Finale that already
> > stores the information, there is no reason to assume that this data
> > structure will not be duplicated in part views, in order that parts
> > can have independent settings.
> 
> On the Mac, in any printable application, there is a File menu item
> called Page Setup, wh.  calls up a dialog in wh. printer settings are
> stored. If, for example, you want to print a part on folded 11X17
> sheets, the Finale layout would prescribe ordinary letter-size paper,
> but the Page Setup should prescribe 11X17. Obviously, one would often
> want to do just this for parts, but not for the score they came from.
> 
> My concern is that I have never heard of any Mac application in which
> two different Page Setup configurations could be applied
> simultaneously to the same file, and I therefore wonder whether it
> might prove impossible to do such a thing in the Mac environment.

Since it's data that's stored in the document, all the programmers 
have to do is create a data structure in the document that stores the 
different settings.

There is no need to assume that this would be ignored in a dynamic 
parts implementation.

Can anyone say what the situation is with Sibelius 4? Surely they 
already implement independent page setup for parts and scores, all in 
one file? The question is, is it for all parts or can independent 
page setups be saved for each individual part (as you rightly 
require)? 

If you can have separate settings for score and parts as a whole in a 
single file (as I assume Sibelius already does), there is no 
technical reason to prevent allowing for storing independent page 
setups for each part.

Now, technical capabilities aside, it's something that the 
programmers need to have hammered home that they need to implement, 
so in sending in a feature request for dynamic parts to MakeMusic, 
you need to stress that this is needed, just in case they don't think 
it through sufficiently.

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

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

[Finale] Dynamic Parts in Finale - multi-file solution?

[Darcy James Argue]

Robert Patterson and Johannes Gebauer have raised some excellent points 
about the feasibility of a single-file solution for Dynamic Parts in 
Finale.  There is also the issue of a possible additional performance 
hit if Finale were to implement "live updating" as Sibelius does.


What about a multi-file solution with manual updates -- after 
extracting parts, an option to "update parts based on score" or "update 
score based on parts"?  Would that be a more feasible solution?  Is 
there any way such a solution could duplicate all of the functionality 
of Sibelius's Dynamic Parts -- just without the auto-updating?  Would 
this be the poor man's version, or could it actually be a *better* 
solution than SIb's single-file solution, if it was properly 
implemented?


Your thoughts?

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY

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

Re: [Finale] Dynamic Parts in Finale - multi-file solution?

[David W. Fenton]

On 7 Jul 2005 at 17:50, Darcy James Argue wrote:

> Robert Patterson and Johannes Gebauer have raised some excellent
> points about the feasibility of a single-file solution for Dynamic
> Parts in Finale.  There is also the issue of a possible additional
> performance hit if Finale were to implement "live updating" as
> Sibelius does.
> 
> What about a multi-file solution with manual updates -- after 
> extracting parts, an option to "update parts based on score" or
> "update score based on parts"?  Would that be a more feasible
> solution? . . .

No, it wouldn't.

It would vastly increase the complexity of implementing dynamic 
parts, because it would require duplicating all the data in other 
files, and then creating mechanisms that harmonize changes to the 
data in the different files. 

As a database programmer who creates replicated applications for my 
clients, I can tell you that this is not a simple thing.

What happens when changes in two different parts cause a collision 
when pushed up to the score? This can't happen with a single-file 
part view approach, since the changes occur sequentially, and are 
passed up to the score view as they are made. With separate files, 
you either have to queue them with a time stamp (a transaction-based 
approach) or figure out some way to harmonize potential conflicts.

I spend all my time working with these issues in databases and I can 
tell you: it's much easier to have all the changes taking place in a 
single database than it is to try to synchronized changes in multiple 
related databases.

> . . . Is there any way such a solution could duplicate all of the
> functionality of Sibelius's Dynamic Parts -- just without the
> auto-updating?  Would this be the poor man's version, or could it
> actually be a *better* solution than SIb's single-file solution, if it
> was properly implemented?

It could duplicate it, but:

1. it would be vastly more complex to implement, AND

2. it would be much more prone to breaking, both internally 
(improperly resolved conflicting edits) and externally (intervention 
via the file system, or any other method outside Finale).

Coordinating multiple independent files is just a terrible idea 
compared to the single-file with views alternative.

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

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

Re: [Finale] Dynamic Parts in Finale - multi-file solution?

[Darcy James Argue]

On 07 Jul 2005, at 7:18 PM, David W. Fenton wrote:


No, it wouldn't.


Yes, I knew you'd object. I'm actually pretty sympathetic to your view, 
but I also have good reason to believe a multi-file equivalent to 
Dynamic Parts (perhaps implemented by plug-ins -- e.g., "Update score 
based on this part" and "Update parts based on this score") is vastly 
more likely to be implemented than a single-file solution, at least in 
the short term.


So, for the moment, can we put aside the issue of technical hurdles?  
It's the "harmonizing potential conflicts" aspect that I'm more 
interested in.


Let's put it another way -- let's say you *had* to come up with a 
multi-file, manually synchronized plugin equivalent to Sibelius's 
Dynamic Parts.  What would that look like?  How would you want it to 
resolve discrepancies between score and parts?


- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY



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

Re: [Finale] Dynamic Parts in Finale - multi-file solution?

[David W. Fenton]

On 8 Jul 2005 at 3:42, Darcy James Argue wrote:

> On 07 Jul 2005, at 7:18 PM, David W. Fenton wrote:
> 
> > No, it wouldn't.
> 
> Yes, I knew you'd object. I'm actually pretty sympathetic to your
> view, but I also have good reason to believe a multi-file equivalent
> to Dynamic Parts (perhaps implemented by plug-ins -- e.g., "Update
> score based on this part" and "Update parts based on this score") is
> vastly more likely to be implemented than a single-file solution, at
> least in the short term.

I think you're dreaming. The complexities of synchronizing files are 
an order of magnitude greater than those of relating data structures 
within a single file.

Now, if they separated the data structure from the layout files, then 
it could work. That is, every Finale file would have two files, one 
the database, and one the file you worked with to edit and format the 
data (this is the way it's done in properly-designed Access database 
applications -- your data tables are in one file, while the forms and 
reports, etc., that you use to interact with your data are in another 
file, linked to the data file). Then, to create a part, you'd simply 
create a new layout file, linked to the same data store.

Now, another way of implementing that might be to have the data stay 
in the score file, and then have the parts be separate files that 
have no actual frame data in them, and, instead, link back to the 
data in the score file. This would be not much more complicated than 
implementing it all within one file, and if you like the idea of 
having separate files (I *don't* like this idea), then that would be 
an easy way to implement it that wouldn't be very different from 
implementing it the way I've suggested.

> So, for the moment, can we put aside the issue of technical hurdles? 
> It's the "harmonizing potential conflicts" aspect that I'm more
> interested in.
> 
> Let's put it another way -- let's say you *had* to come up with a
> multi-file, manually synchronized plugin equivalent to Sibelius's
> Dynamic Parts.  What would that look like?  How would you want it to
> resolve discrepancies between score and parts?

[what follows was written *before* I wrote most of what is above, so 
it pre-dates my idea of having a Score file with data in it and part 
files with no data, just layout information]

I would want to avoid the problem. Seriously.

In a multi-user database, if two people edit the same record, you 
have some choices for what to do:

1. lock the record as soon as user1 edits it so user2 can't start an 
edit. Problem: inconvenient to user2, especially if user1 starts and 
edit and goes to lunch.

2. don't lock but keep track of who is editing. If user1 starts an 
edit, allow user2 to start an edit of the same record. If either of 
the users save the record, you have to inform the other user when 
*they* save the record that somebody else has edited the record and 
then you give them a choice of what to do:

  1. overwrite the other user's changes with mine

  2. drop my changes and use the other user's changes

  3. show me the differences so I can resolve them somehow

Now, all of this is a huge user interface challenge. First off, a 
dialog that gives you these 3 choices is very hard to understand -- 
most users won't know what the hell it means. You could skip it all 
and just do #3, but designing a user interface for that is very 
difficult, too.

Of course, what you're suggesting is not multi-user editing, but it 
kind of comes down to the same thing. This is the scenario that is 
basically the same:

1. you have a SCORE.

2. you have PART1 and PART2.

3. you edit PART1.

4. you edit PART2.

5. you tell Finale to update the score with the changes you made to 
PART1.

6. you tell Finale to update the score with the changes you made to 
PART2.

Now, what if you made mutually contradictory changes in PART1 and 
PART2 (and let's leave aside changes that shouldn't cascade back to 
the score)? Perhaps there aren't any linked changes that would 
overlap, but my bet is that there would be.

Take, for instance, inserting a measure into a part. Say you insert 
it at measure 20. And you do it in both the parts. Finale has to be 
smart enough to know that you've done the same thing twice, not made 
two independent insertions. Now, from a common-sense perspective, 
that sounds simple, but from a computer point of view, it's rather 
complicated. If you think of it as FRAMES, and each FRAME is assigned 
a unique ID, somehow Finale has to translate from the FrameIDs of the 
part (which, since it's a separate, newly created file, independent 
of the score, will be different from the score) to the FrameIDs of 
the score. I don't know how this would be managed. A lookup table? 
Or, creating the parts using the same FrameIDs as the score? Again, I 
don't know, since there are drawbacks to both (the second is actually 
an attractive alternative, since then you'd have an exact match back 
to the original data; bu