Re: [Finale] Finale spacing issue: F2009, OS X
Well, we would have to see the whole system to know exactly, but I would say that this is as good as Finale can do with a measure of that width. If you give it a little more width, then Finale won't be forced into collisions. You can't expect the basic spacing algorithm that Finale uses to change sixteenth note spacing through the measure. Now, there are some things you mentioned that might affect it. You said this same figure (I assume with accidentals) later had no problem (I assume the same measure width) then the measure might be corrupt (yes, that happens a lot). Copy the contents to another measure somewhere else, delete the entire measure stack, insert a new measure, and copy the contents back. Maybe include a measure on either side to make sure you excised the bad stuff. If you open the Edit Frame and compare it to the other identical measure you might find something checked by accident (gamma radiation or just scrambled Finale brains.) One thing to try before this, however. I sometimes get extraneous beat markers, and if I space it using Beat Spacing (metatool 3) then Note Spacing, (metatool 4) this sometimes helps. Christopher On Sat Jan 23, at SaturdayJan 23 9:51 PM, Matthew Hindson (gmail) wrote: In the linked image: http://imgur.com/Aux4V.png you will notice the bad spacing between notes 2 and 3. Apart from manually adjusting the third or second notes using the appropriate Special Tool, the normal Music Spacing options have no effect. Has anyone else run into this? "Avoid collision of notes and accidentals" is checked in the Music Spacing options. The spacing is being applied to this particular part only, i.e. there are no other staves affecting the spacing. The other bars in the part have no problems with spacing, even the same figure in later bars have no clashes, so it's not that the spacing is generally squishy. Matthew ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Finale spacing issue: F2009, OS X
Matthew Hindson (gmail) wrote: In the linked image: http://imgur.com/Aux4V.png you will notice the bad spacing between notes 2 and 3. Apart from manually adjusting the third or second notes using the appropriate Special Tool, the normal Music Spacing options have no effect. Has anyone else run into this? "Avoid collision of notes and accidentals" is checked in the Music Spacing options. The spacing is being applied to this particular part only, i.e. there are no other staves affecting the spacing. The other bars in the part have no problems with spacing, even the same figure in later bars have no clashes, so it's not that the spacing is generally squishy. The behavior is perfectly logical for a number of different reasons. Most importantly, these kind of rhythms don't (IMO) look good with the default fibonacci spacing value of 1.62. Lower the Scaling Factor of the spacing (you can try as low as 1.40) and respace the music and the problem should go away. Best regards, Jari Williamsson ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Finale spacing issue: F2009, OS X
Happens all the time with us (FinMac 2010). We generally solve the problem either by (a) using the Special tools note mover (a royal PITA), or (b) making the measure (or _all_ measures) a little wider using the Measure Tool or Spacing Tool, or (c) changing the Note Spacing values globally It appears to be an "issue" with the spacing algorithms where there are accidentals before notes. If you want to start a petition to MM, you've got my signature! Eric Habsburger Verlag Frankfurt (Dr. Fiedler) www.habsburgerverlag.de eric.f.fied...@t-online.de e.fied...@em.uni-frankfurt.de On 24.01.2010, at 03:51, Matthew Hindson (gmail) wrote: In the linked image: http://imgur.com/Aux4V.png you will notice the bad spacing between notes 2 and 3. Apart from manually adjusting the third or second notes using the appropriate Special Tool, the normal Music Spacing options have no effect. Has anyone else run into this? "Avoid collision of notes and accidentals" is checked in the Music Spacing options. The spacing is being applied to this particular part only, i.e. there are no other staves affecting the spacing. The other bars in the part have no problems with spacing, even the same figure in later bars have no clashes, so it's not that the spacing is generally squishy. Matthew ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Finale spacing issue: F2009, OS X
Eric Fiedler wrote: (c) changing the Note Spacing values globally Why not locally? Note spacing settings are only applied when respacing is done and if you turn off AMS you'll have full control over the spacing of the document. It's easy to build a few FinaleScripts to provide spacing for the different spacing situations you'll encounter. For example, if you normally use Fibonacci spacing and would like a tighter (such as 1.4) for just a selected region, this script would respace and then go back to the Fibonacci value. --- menu item "document options" list "Music Spacing" press "spacing widths..." type "1.4" near "Scaling Factor" press "ok" press "ok" respace menu item "document options" list "Music Spacing" press "spacing widths..." type "1.62" near "Scaling Factor" press "ok" press "ok" --- Of course, "spacing styles" as Aaron Sherber suggested earlier in this forum would also be a nice feature addition. It appears to be an "issue" with the spacing algorithms where there are accidentals before notes. The issue is that there's too much spacing requirements in too little horizontal space and the error must appear somewhere. Either the spacing ratio will be wrong or there will be collisions. Although collisions would look worse in print, incorrect spacing ratio would also be an error. And the issue that Finale doesn't support optical music kerning to provide intelligent space crunching. If you want to start a petition to MM, you've got my signature! If you want something to work differently, just contact MM directly through Tech Support. Best regards, Jari Williamsson ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Finale spacing issue: F2009, OS X
> Matthew Hindson (gmail) écrit: > >Has anyone else run into this? > > > >"Avoid collision of notes and accidentals" is checked in the > Music Spacing > >options. > > > >The spacing is being applied to this particular part only, i.e. > there are > >no other staves affecting the spacing. The other bars in the > part have no > >problems with spacing, even the same figure in later bars have > no clashes, > >so it's not that the spacing is generally squishy. > > I've seen this problem several times: a bar where Finale doesn't seem to > notice the presence of an accidental. I think it's Johannes > (correct me if > I'm wrong) who pointed out a fairly easy way to correct this: use > TGTools, > and add 0 extra space to the bar in question. > > Dennis Brilliant! Any idea why this works? -Lee ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Finale spacing issue: F2009, OS X
I hear what you're saying...and sometimes a local solution is the best and only way to go in a pinch. But on the other hand, there's something about a score with a number of different spacing algorithms that doesn't look quite right to me. As I understand it, the old engravers of yesteryear used one set of spacings for a whole piece or movement, which _did_ require a lot of calculations before hammering in the first note punch, but which produced results which are easy to read and in addition exude a wonderful kind of harmonious "rightness" that has a lot to do with the overall graphical balance between black and white on the page. Or am I being too fussy here? I'd be interested in your take on the subject — or anybody's take, for that matter. Eric Habsburger Verlag Frankfurt (Dr. Fiedler) www.habsburgerverlag.de eric.f.fied...@t-online.de e.fied...@em.uni-frankfurt.de On 24.01.2010, at 14:55, Jari Williamsson wrote: Eric Fiedler wrote: (c) changing the Note Spacing values globally Why not locally? ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Finale spacing issue: F2009, OS X
On Jan 25, 2010, at 2:44 AM, Eric Fiedler wrote: I hear what you're saying...and sometimes a local solution is the best and only way to go in a pinch. But on the other hand, there's something about a score with a number of different spacing algorithms that doesn't look quite right to me. As I understand it, the old engravers of yesteryear used one set of spacings for a whole piece or movement, which _did_ require a lot of calculations before hammering in the first note punch, but which produced results which are easy to read and in addition exude a wonderful kind of harmonious "rightness" that has a lot to do with the overall graphical balance between black and white on the page. Or am I being too fussy here? I'd be interested in your take on the subject — or anybody's take, for that matter. My theory is that a consistent spacing look across the entire piece is always the goal, but a uniform set of Finale note spacing values is not the best way to achieve that goal. I guess that means I'm assuming the engraver knows better than the program what looks good, and he will use the program as a tool to achieve it. A constant note-spacing variable is extremely useful to that and will be used most of the time, but there will be times when it's better to depart from that, and I'm trusting the engraver to know when it's appropriate. If the argument against a feature is that some users will use it to produce uglier work, there are plenty more things you'd have to oppose. (For one thing, 75% of desktop publishers shouldn't be allowed to have more than eight typefaces) mdl ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Finale spacing issue: F2009, OS X
On Mon Jan 25, at MondayJan 25 1:16 PM, Mark D Lew wrote: (For one thing, 75% of desktop publishers shouldn't be allowed to have more than eight typefaces) Eight? What are the other seven? 8-) Christopher ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Finale spacing issue: F2009, OS X
On 25 Jan 2010 at 11:44, Eric Fiedler wrote: > I hear what you're saying...and sometimes a local solution is the > best and only way to go in a pinch. But on the other hand, there's > something about a score with a number of different spacing algorithms > that doesn't look quite right to me. As I understand it, the old > engravers of yesteryear used one set of spacings for a whole piece or > movement, which _did_ require a lot of calculations before hammering > in the first note punch, but which produced results which are easy to > read and in addition exude a wonderful kind of harmonious "rightness" > that has a lot to do with the overall graphical balance between black > and white on the page. Or am I being too fussy here? I'd be > interested in your take on the subject - or anybody's take, for that > matter. My guess is that however strict any house style that's implemented by human engravers might be, there's going to be a ton of minor ad hoc adjustments that are either not specifically delineated by the house style's spacing rules, or that violate them in any particular case. Computers are not smart enough to do anything but follow the rules slavishly. If you want them to break the rules, you have to define a rule! That is, the computer can never do anything other than exactly what it's told (though introducing a randomness factor, as with Human Playback, might potentially improve results for certain kinds of operations without needing to define rules that override other rules). To really implement what a human being does, you'd probably need to write a computer program that would take too long to calculate the layout. One computer approach might be to use a multi-pass approach, i.e., do a default spacing, then look at it a second time to see if there are any suspicious things that need to be fixed. I'm not sure how easy it is to examine the Finale data for that, but it might be possible to fix certain kinds of errors in a second pass (or flag them and ask the user what you want to do about them). Yet another approach could be to train the spacing mechanism to fix certain things (similar to the way you train an OCR or voice recognition program). However, there can always be unexpected results from that, so whether you wanted the spacing definition to learn something like that permanently, or learn it only for the present file would be a difficult question. Another thing to consider is having your music spacing settings to always incorporate manual changes, but that can lead to other problems (you'd have to turn it off if you wanted to re-run the spacing to get rid of mistaken manual spacing). But I think a human being will *always* do better than a computer. However, the issue is how much time it takes the human being, and if the computer can get 99.8% of it right and the human can fix the remaining .2% in a short period of time (especially when determining how to fix that .2% is not susceptible to algorithmic description, or has no solution that experienced engravers can all agree on), there's little reason to overcomplicate the computer algorithm. There are a few things that Finale always gets wrong and those are fixable in the algorithm, but the things that go wrong only in relatively exotic circumstances are probably never going to be fixed. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Finale spacing issue: F2009, OS X
On Mon Jan 25, at MondayJan 25 2:25 PM, David W. Fenton wrote: One computer approach might be to use a multi-pass approach, i.e., do a default spacing, then look at it a second time to see if there are any suspicious things that need to be fixed. I'm not sure how easy it is to examine the Finale data for that, but it might be possible to fix certain kinds of errors in a second pass (or flag them and ask the user what you want to do about them). Actually, we kind of already do that. I use the default Finale spacing that gets things apart from things that shouldn't be touching, then apply TG Tools or Patterson plugins to any area that I think needs touchup, finishing up with some manual spacing (ugh!) But are you referring to PROGRAMMING a multi-pass spacing algorithm? I know guys like Johannes and the two Dennises do this kind of thing constantly and probably have it streamlined, but I would LOVE to have some of my manual spacing tasks taken over by a plugin. Some of them are pretty simple and could easily be programmed. I wrote in about a week ago asking a very specific question about spacing of seconds (and other intervals, for that matter!) in different layers when the downstem layer is higher than the upstem layer, but got no response, so I imagine that particular problem is not automatically addressable. Christopher ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Finale spacing issue: F2009, OS X
On 25 Jan 2010 at 14:36, Christopher Smith wrote: > On Mon Jan 25, at MondayJan 25 2:25 PM, David W. Fenton wrote: > > > One computer approach might be to use a multi-pass approach, i.e., do > > a default spacing, then look at it a second time to see if there are > > any suspicious things that need to be fixed. I'm not sure how easy it > > is to examine the Finale data for that, but it might be possible to > > fix certain kinds of errors in a second pass (or flag them and ask > > the user what you want to do about them). > > Actually, we kind of already do that. I use the default Finale > spacing that gets things apart from things that shouldn't be > touching, then apply TG Tools or Patterson plugins to any area that I > think needs touchup, finishing up with some manual spacing (ugh!) But > are you referring to PROGRAMMING a multi-pass spacing algorithm? Yep. Programming-wise, sometimes it's easier to start from one state, calculate a new state, and then start over from that state with a new calculation than it is to try to get there in one pass. It also eases the resource requirements in terms of CPU and memory (though these days with quad-core CPUs and 8GBs of RAM and more, that's hardly an issue). > I know guys like Johannes and the two Dennises do this kind of thing > constantly and probably have it streamlined, but I would LOVE to have > some of my manual spacing tasks taken over by a plugin. Some of them > are pretty simple and could easily be programmed. I wrote in about a > week ago asking a very specific question about spacing of seconds > (and other intervals, for that matter!) in different layers when the > downstem layer is higher than the upstem layer, but got no response, > so I imagine that particular problem is not automatically addressable. This raises the old plugin argument, i.e., whether MM gets away with not improving Finale's internals because someone steps up and ameliorates the problems with a plugin (Patterson Beams, anyone?). Since I use a really old version of Finale (2003), I still have to deal with old spacing problems like the colliding 2nds in layers and terrible grace-not spacing. I believe both of these have been fixed in later versions (the colliding 2nds long ago, the grace notes much later, and if I recall correctly, not 100% fixed). Those kinds of things ought to be fixed in the basic spacing algorithms within Finale (and my melisma problem should be, too), not addressed with a plugin. On the other hand, there are some things that I think a plugin should do. For instance, I wish there were some way to use the beat charts that would not require moving all the handles. That is, if you could, say, widen a measure, allocate more space for the first beat (by shift-draggin the 2nd-beat handle) and then tell your plugin to space the 2nd beat on to use the available space (as opposed to the music bumping up against the bar line). Probably a bad example, but it's something I have to do regularly frequently, i.e., use beat charts to fix an internal spacing problem, but then have to respace the rest of the measure manually. Much of that is caused by the fact that I have to get a lot of music into a very small space (because of the limits of 2 pages per piece/movement for my viol consort), so one of the reasons I run into the issue is because I'm forcing the music into less space than is ideal. But nonetheless, I see that kind of thing as very much appropriate to implementation as a plugin type. General spacing defects should be fixed within Finale, though. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Finale spacing issue: F2009, OS X
Eric Fiedler wrote:
As I understand it, the old engravers of
yesteryear used one set of spacings for a whole piece or movement, which
_did_ require a lot of calculations before hammering in the first note
punch, but which produced results which are easy to read and in addition
exude a wonderful kind of harmonious "rightness" that has a lot to do
with the overall graphical balance between black and white on the page.
Or am I being too fussy here? I'd be interested in your take on the
subject — or anybody's take, for that matter.
If you look at the spacing examples at page 37 of Herbert Chlapik's "Die
Praxis des Notengraphikers" and try to achieve those examples in Finale,
you'll see that to "translate" the rules he uses for old-fashion plate
engraving/spacing, you'd need to apply many different kinds of Finale
spacing in different measures, mainly because the "spacing languages"
are different between Finale and hand engraving.
I agree with you that different spacing within a Finale document can
sometimes look odd, but it mostly appears when similar kind of measures
have been treated differently.
Apart from the basic algorithms, another big difference is that Finale
currently can not judge what true "collision" is, while an eye has no
problem judging that. An when speaking of finetuning ("Der optische
Ausgleich", page 63-64 in that same truly excellent book) Finale has no
support at all, although it's quite easy to train the eye in spotting
those instances to fix the spacing (with beat chart editing and a little
automation by TGTools).
Best regards,
Jari Williamsson
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Finale spacing issue: F2009, OS X
David W. Fenton wrote: << On the other hand, there are some things that I think a plugin should do. For instance, I wish there were some way to use the beat charts that would not require moving all the handles. ... >> The UI on beat chart editing is just awful. I don't mind moving the beat spacing around, and I accept that it's something I take upon myself as a fussy engraver -- but the crappy way that the handles are moved one at a time and you can't really see what you're doing is so unnecessary. If they would just clean up the UI for this editing task without actually changing anything internal, that would be much appreciated. My version of Finale isn't quite as ancient as David's, but I'm still many years behind. I don't suppose there's been anything for beat chart editing lately, has there? mdl ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
