[Finale] Bug in independent time sig staff style
Hi all, I'm wondering if there's a good workaround for this bug, in Fin11 and probably earlier versions: Start with a new default document. Add a second staff. Define a new staff style, copyable, and check 'Independent Time Signature'. Apply this staff style to the second staff, and then change that staff's time sig to 5/4. Now enter 5 quarter notes in the first measure of the second staff, and then use your favorite method to copy that first measure and paste into the second. Instead of putting five quarters into the second measure, Finale puts in four quarter notes, then inserts a *new bar* and puts the last quarter note in that new bar. This doesn't happen if the second staff is set to Independent Time Sig in staff attributes, without using a staff style. But I'm doing a piece in which occasionally one group of instruments has an independent time sig, and occasionally another group does. It would be a pain if I had to set all instruments to independent time sig and then always change the time sig for each staff. Any creative ideas? Thanks, Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Bug? Slurs VS. Slash-notation in Finale 2010
I tested this in FinMac2010, and the slurs stay unless they venture into the slash notation area, then they get hidden. All slurs that stay entirely out of the slash area show normally. This does not appear to be a bug, as I am having trouble figuring out a situation in which I would want slurs over slash notation. Is this something that changed in 2010? I notice the dialogue box is a bit different now, and Smart Shapes are greyed out as items to choose to appear or not. Though if I did, I would probably enter a quarter note B on the beat where I want slash notation, change the note head to the slash figure, hide the stem, and the slur would proceed normally. Once I did it once, I could copy it to other parts of other measures to avoid the whole rigmarole again. Christopher On Aug 23, 2009, at 7:23 PM, Karl-Johan Ankarblom wrote: Hi! Can anyone confirm this behaviour: (Fin 2010.r4 on Windows XP Pro) I'm working on a chart where alot of measures have some parts as slash notation (applied as Staff Style), and parts of the measure as Standard Notation (no/cleared Staff Style). After applying the slurs I want on the Standard Notation part of the measure, the slurs DISAPPEAR (as soon as the graphics are updated) !! If I delete the Staff Style with Slash Notation in the other parts of the measure, the slurs re-appear. But as long as the measure has parts that is Slash Notation and parts there are not, the slurs don't get shown. Bug? (and a very irritating one if so...) Thank you in advance! Greetings, Kalle Karl-Johan Ankarblom Bredkilsbacken 4 SE-171 53 SOLNA Tel: +46 (0)70 794 08 74 ___ 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
[Finale] Bug? Slurs VS. Slash-notation in Finale 2010
Hi! Can anyone confirm this behaviour: (Fin 2010.r4 on Windows XP Pro) I'm working on a chart where alot of measures have some parts as slash notation (applied as Staff Style), and parts of the measure as Standard Notation (no/cleared Staff Style). After applying the slurs I want on the Standard Notation part of the measure, the slurs DISAPPEAR (as soon as the graphics are updated) !! If I delete the Staff Style with Slash Notation in the other parts of the measure, the slurs re-appear. But as long as the measure has parts that is Slash Notation and parts there are not, the slurs don't get shown. Bug? (and a very irritating one if so...) Thank you in advance! Greetings, Kalle Karl-Johan Ankarblom Bredkilsbacken 4 SE-171 53 SOLNA Tel: +46 (0)70 794 08 74 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
On 17.02.2009 David W. Fenton wrote: Certainly I could auto-update layout and avoid this problem, but I'm *never* going to do that. Do recent versions of Finale manage not to screw up existing layouts? Perhaps it has something to do with the fact that I tend to work back and forth between 75% and 100% view and perhaps printing from one or the other magnifications causes the problem? The solution is auto-update layout. Why would you never do that? I think there might be a slight misunderstanding of what updating the layout actually does. It does not manipulate any data (unless such options are active) in the actual file. All it does is it resets the rendering on-screen. No magic. Leaving auto-update off is asking for trouble in my view (quite the opposite disabling other auto-options, like music spacing, multi-measure-rests and the like which include huge risks that some desired manipulations are lost through an auto-update). Johannes ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
On 17.02.2009 David W. Fenton wrote: The reason why this bothers me is because it means data is constantly being discarded and recreated. This means that there will be a certain level of fragmentation in the file's internal structures (whether in RAM only, in temp files only, or in the actual file image saved on the hard drive, I don't know). This kind of fragmentation is the kind of thing that can lead to file corruption, so I want to avoid as much of that as possible. Well, I am not an expert on Finale's data structures, but I am pretty sure updating the layout actually changes nothing in the file itself. All it does is cause a re-calc of how this data is parsed. I don't believe there are any reports of any problems with automatic layout updates causing any corruption at all, if anything it tidies up the mess. Go switch it on. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
On 17.02.2009 David W. Fenton wrote: There is simply no excuse for repeating a system from one page to another. That's a bug. I shouldn't have to update page layout (manually or automatically) just to be sure I don't encounter that bug. The bug is that auto-layout-update can be disabled in the first place. The only reason this option is still there is that this preserves the was Finale worked pre-auto-layout-update. The reason Finale worked like that was underpowered processing which couldn't cope with the processing power needed to update the layout after every edit. Again, unless you are working on a vastly underpowered machine, switch the thing on and forget about it. The other bug is that it actually disables itself from time to time, at least here on my computer. No idea what causes that. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
On 17 Feb 2009 at 0:47, Darcy James Argue wrote: On 17 Feb 2009, at 12:24 AM, David W. Fenton wrote: there was no reason that page layout needed to be updated. Yes there is, as I said. You modified note values. That always requires the layout to be updated. That's just how Finale works. No, there was absolutelyl positively no reason to update the layout as I didn't respace the music (and don't have automatic music spacing turned on). It was perfect as is, and none of my edits were to data that would have altered the page layout (and couldn't have done so, anyway, since systems were locked, with hard system breaks and hard page breaks). So in other words, turning on Automatic Update Layout with the normal settings (preserve system locks) would not have done anything except prevent this bug from biting you. I've explained in another post why I don't like the way automatic update layout works -- I fear it risks file corruption. On 17 Feb 2009 at 0:07, Darcy James Argue wrote: That is a classic instance of a situation that requires you to update layout. Why? So that you avoid precisely this situation. This is a stupid bug. Agreed. But it is a known, longstanding bug that can be avoided 100% of the time by leaving Automatic Update Layout on. And there is no disadvantage to doing so. From my point of view, there *is* a possible disadvantage with a very bad downside. And I've been using Finale since 1991 and never had this happen before. There is no excuse for printing phantom systems on phantom pages. Agreed. But this is also pretty much guaranteed to happen if you have Automatic Update Layout off and neglect to *always* manually update layout before printing. IMO, Finale just flat-out does not work properly without Automatic Update Layout turned on. (The alternative is to always manually update the layout prior to printing, which amounts to the same thing.) When I've changed the music spacing, I *always* manually update layout. When I've made no such changes, there's absolutely no reason Finale should need the layout updated before printing. None. Seriously. Just turn it on. Nope -- not gonna do it. -- 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] Another question about a possibly-fixed Finale bug
On 17 Feb 2009 at 0:50, Darcy James Argue wrote: On 17 Feb 2009, at 12:24 AM, David W. Fenton wrote: Again, this is why I feel that the layout should always update automatically. And I respectfully disagree. I don't want things jumping around onscreen while I'm working. Respectfully, David, I don't think you fully understand how the feature works. It does not result in anything jumping around onscreen. It only results in things displaying and printing correctly, instead of incorrectly. You snipped the context. I did not claim that automatic layout updating caused that problem, but automatic music spacing *does* cause the problem. And it's only if I had automatic music spacing turned on that the music spacing could have changed without me respacing the music. And that's the only thing that would have possibly required an update layout. -- 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] Another question about a possibly-fixed Finale bug
On 17 Feb 2009 at 10:03, Johannes Gebauer wrote: On 17.02.2009 David W. Fenton wrote: Certainly I could auto-update layout and avoid this problem, but I'm *never* going to do that. Do recent versions of Finale manage not to screw up existing layouts? Perhaps it has something to do with the fact that I tend to work back and forth between 75% and 100% view and perhaps printing from one or the other magnifications causes the problem? The solution is auto-update layout. Why would you never do that? I think there might be a slight misunderstanding of what updating the layout actually does. It does not manipulate any data (unless such options are active) in the actual file. Page layout is not stored in the Finale file? You realize how ridiculous that is? Or is the claim that it's not stored in the Enigma database, but somewhere outside it? That would ameliorate my fragmentation concerns, certainly, if I knew that to be true. All it does is it resets the rendering on-screen. And the printing -- don't forget the printing. No magic. Leaving auto-update off is asking for trouble in my view (quite the opposite disabling other auto-options, like music spacing, multi-measure-rests and the like which include huge risks that some desired manipulations are lost through an auto-update). I explained why I don't like the idea of automatic music updating, because of potential churn in the data file, and the possibility of file corruption. Many people have strange file corruptions with later versions of Finale that are inexplicable. Maybe having automatic layout updating on is one of the sources of that. -- 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] Another question about a possibly-fixed Finale bug
On 17 Feb 2009 at 10:06, Johannes Gebauer wrote: On 17.02.2009 David W. Fenton wrote: There is simply no excuse for repeating a system from one page to another. That's a bug. I shouldn't have to update page layout (manually or automatically) just to be sure I don't encounter that bug. The bug is that auto-layout-update can be disabled in the first place. Well, I would definitely say it's a design flaw that Finale can't manage this more reliably. The only reason this option is still there is that this preserves the was Finale worked pre-auto-layout-update. The reason Finale worked like that was underpowered processing which couldn't cope with the processing power needed to update the layout after every edit. As I've suggested in regard to the resulting churn in the data structures, there is at least one other plausible reason to have it off. Again, unless you are working on a vastly underpowered machine, switch the thing on and forget about it. I'm not, and I'm also not going to turn it on. -- 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] Another question about a possibly-fixed Finale bug
On 17 Feb 2009 at 10:09, Johannes Gebauer wrote: On 17.02.2009 David W. Fenton wrote: The reason why this bothers me is because it means data is constantly being discarded and recreated. This means that there will be a certain level of fragmentation in the file's internal structures (whether in RAM only, in temp files only, or in the actual file image saved on the hard drive, I don't know). This kind of fragmentation is the kind of thing that can lead to file corruption, so I want to avoid as much of that as possible. Well, I am not an expert on Finale's data structures, but I am pretty sure updating the layout actually changes nothing in the file itself. You can't seriously believe that, can you? Before my update layout, pages displayed the problem. After I updated, the problem went away. I saved the file, of course, and when I open it now, it doesn't display incorrectly. This indicates to me that data was written to the file. All it does is cause a re-calc of how this data is parsed. I don't believe there are any reports of any problems with automatic layout updates causing any corruption at all, if anything it tidies up the mess. How would you know if automatic layout update were the cause of file corruption? Go switch it on. Not gonna do it. -- 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] Another question about a possibly-fixed Finale bug
Darcy James Argue wrote: I will repeat, for not the first time, that I do not understand the rationale for anyone leaving Automatically Update Layout off. Here is mine: Finale has a bug in how it relates to plugins and you can avoid that bug by turning off AUL. Specifically, any plugin that needs to determine page layout info, such as which system and/or page a measure may be on, does not work reliably if AUL is on. That includes, specifically, my Beam Over Barlines plugin and others. I also leave it off because it caused a significant performance hit the last time I experimented with it. With a large orch. score of several dozen pages it was a noticable lag. This was admittedly a previous computer and I'd be surprised if that was still much of an issue, but I've become so used to working without AUL that I never have a problem with it. Learn to hit the keyboard shortcut for UL often. David's concern that excessive updating could cause fragmentation is probably not warranted. This is based on a plugin-writer's level of knowledge about Finale internals, rather than a Finale developer's. But without boring the list with a a lot of technical specifics, that is my impression. -- Robert Patterson http://RobertGPatterson.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
David W. Fenton wrote: On 17 Feb 2009 at 10:09, Johannes Gebauer wrote: On 17.02.2009 David W. Fenton wrote: The reason why this bothers me is because it means data is constantly being discarded and recreated. This means that there will be a certain level of fragmentation in the file's internal structures (whether in RAM only, in temp files only, or in the actual file image saved on the hard drive, I don't know). This kind of fragmentation is the kind of thing that can lead to file corruption, so I want to avoid as much of that as possible. Well, I am not an expert on Finale's data structures, but I am pretty sure updating the layout actually changes nothing in the file itself. You can't seriously believe that, can you? Before my update layout, pages displayed the problem. After I updated, the problem went away. I saved the file, of course, and when I open it now, it doesn't display incorrectly. This indicates to me that data was written to the file. Actually, I believe that Finale gets it's print data from the graphics card -- at least it did when I first started using it because I had a problem with printing and contacted tech support and they told me that and gave me a workaround until I updated the drivers for my graphics card. So if the printing does indeed get its data from the on-screen realization, then saving the file and re-opening it, even without updating the layout might have solved the problem. I'm not convinced that update layout does anything other than force the graphics card to redraw from the file, instead of keeping possibly erroneous data in the memory chips of the graphics card, which would cause the layout problems. -- David H. Bailey dhbai...@davidbaileymusicstudio.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
On 17.02.2009 David W. Fenton wrote: Well, I am not an expert on Finale's data structures, but I am pretty sure updating the layout actually changes nothing in the file itself. You can't seriously believe that, can you? Before my update layout, pages displayed the problem. After I updated, the problem went away. I saved the file, of course, and when I open it now, it doesn't display incorrectly. This indicates to me that data was written to the file. the emphasis being on display incorrectly. That doesn't mean anything is incorrect in the data file. The data file doesn't change. If you end up in a situation where the layout has not been updated, and updating it would change anything, the very same change would appear if you closed and reopened the file. I tested that a long time ago (before there was an automatic update). Updating the layout sets things straight. It is similar to a screen redraw, which also doesn't change the file. Johannes ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
On 17.02.2009 David W. Fenton wrote: I think there might be a slight misunderstanding of what updating the layout actually does. It does not manipulate any data (unless such options are active) in the actual file. Page layout is not stored in the Finale file? You realize how ridiculous that is? The page layout as such is not stored in the file. All that is stored is things like system size, locked systems, new page or system settings for certain measures and the like. Finale does not save information like measure 36 is the top left measure of page 2. It just ends up there through a lot of other parameters. Ridiculous it may be (I actually have no opinion on that), but that's how Finale works. And it is the same way that Word works with words, which is the reason why Word files may look differently when opened on another machine with different printer settings. That is ridiculous. In Finale this is prevented as it uses it's internal page measurements. Johannes ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
On 17.02.2009 David W. Fenton wrote: You snipped the context. I did not claim that automatic layout updating caused that problem, but automatic music spacing *does* cause the problem. And it's only if I had automatic music spacing turned on that the music spacing could have changed without me respacing the music. And that's the only thing that would have possibly required an update layout. Now I am confused, are you saying you were talking about automatic music spacing all along? That's a completely different horse, I would not switch that on if someone payed me to do it. Johannes ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
On 17.02.2009 dc wrote: I'm afraid David is right on this count. I just modified the music spacing, saved and closed the file without updating the layout. When I reopen it, the layout is still the same and needs to be updated. Well, that's actually not what David just discribed, he said it doesn't display incorrectly, but he saved after the update. Anyway, this is news to me. I was sure that saving and reopening would actually do the same as updating the layout, but perhaps that is no longer true (I am pretty sure it was true a long time ago). Johannes ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
On 17 Feb 2009, at 8:59 AM, Robert Patterson wrote: Darcy James Argue wrote: I will repeat, for not the first time, that I do not understand the rationale for anyone leaving Automatically Update Layout off. Here is mine: Finale has a bug in how it relates to plugins and you can avoid that bug by turning off AUL. Specifically, any plugin that needs to determine page layout info, such as which system and/or page a measure may be on, does not work reliably if AUL is on. That includes, specifically, my Beam Over Barlines plugin and others. Okay, that's a good reason. I haven't encountered that problem with any of your plugins, but I don't use Beam Over Barlines. David's reasons, on the other hand, make no sense at all to me. He keeps mentioning issues related to Automatic Music Spacing, which of course has nothing to do with Automatic Update Layout, and his concerns about fragmentation and churn seem unwarranted. MM should fix the plugin issue and then remove the option to toggle Automatic Update Layout -- in effect making it always on. Cheers, - Darcy - djar...@earthlink.net Brooklyn, NY ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
[Finale] Re: Another question about a possibly-fixed Finale bug
A couple things from this Automatic Update Layout discussion: 1) Plug-ins can turn the various automatic layout settings on and off. If you see automatic layout being switched out from under you, see if you can relate this to running a specific plug-in. If so, please report the problem to MakeMusic and/or the plug-in developer. 2) Robert, I had a question regarding your point about plug-ins that needs to determine page layout info not working reliably if AUL is on. Can't your plug-in just do an update layout call first in order to set the page and system information that you need? This is related to Johannes's point that Finale does not completely store page and system layout in the file, but computes them dynamically from information in the file. Many other types of Finale formatting work this way, such as stem direction. Other notation programs work in a similar way in terms of computing formatting information dynamically. This is one reason why our MusicXML translation programs for Finale and Sibelius need to run as plug-ins rather than standalone programs. Best regards, Michael Good Recordare LLC www.recordare.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Another question about a possibly-fixed Finale bug
The short answer is no. As I recall, the specific problem occurs for Beam Over Barline when the beam crosses a page boundary. Finale does an internal AUL in mid-stream at one point when I force a recalculation of measure (or bar) metrics, and at that point I can no longer see the relevant system info during the lifetime of that plugin run-event. (There is no way for the plugin to function without forcibly recalculating metrics.) This is regardless of whether I update layout first. On Tue, Feb 17, 2009 at 1:07 PM, Michael Good goodli...@recordare.comwrote: Can't your plug-in just do an update layout call first in order to set the page and system information that you need? ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
On 17-Feb-09, at 17-Feb-09 1:26 PM, Darcy James Argue wrote: On 17 Feb 2009, at 8:59 AM, Robert Patterson wrote: Darcy James Argue wrote: I will repeat, for not the first time, that I do not understand the rationale for anyone leaving Automatically Update Layout off. Here is mine: Finale has a bug in how it relates to plugins and you can avoid that bug by turning off AUL. Specifically, any plugin that needs to determine page layout info, such as which system and/or page a measure may be on, does not work reliably if AUL is on. That includes, specifically, my Beam Over Barlines plugin and others. Okay, that's a good reason. I haven't encountered that problem with any of your plugins, but I don't use Beam Over Barlines. David's reasons, on the other hand, make no sense at all to me. He keeps mentioning issues related to Automatic Music Spacing, which of course has nothing to do with Automatic Update Layout, and his concerns about fragmentation and churn seem unwarranted. MM should fix the plugin issue and then remove the option to toggle Automatic Update Layout -- in effect making it always on. In older versions of Finale I would sometimes make tacet sheets with the titles all there but with all the staves deleted and replaced with the word TACET in large size Arial Black. Updating the layout on these files would cause the titles to disappear, leaving me with a blank page. Since command-U is practically a nervous tic with me, this caused me problems at times... 8-) I have also noticed in 2008 and 2009 that updating of layout does NOT occur automatically in some situations where it should, like after respacing one measure in a system. Maybe this is because it got turned off, as Darcy mentioned in a previous post, and I never thought to check, assuming it WAS on. I will be vigilant in the future for this. Christopher ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
On 17 Feb 2009 at 14:52, dc wrote: I don't have the automatic update layout out on, but I update it manually as needed without even thinking. It's a habit I've had for so many years that I never even thought of changing this setting. I'm pretty automatic with it, too, especially during the process of doing page layout. But I only do that after the notes are all entered and spaced appropriately. I didn't respace the music after changing the note values, because it didn't need to be respaced (it was generous enough that the alterations wouldn't have altered the widths of any of the measures). Since I don't have automatic music spacing turned on, and I didn't respace the music, I simply don't understand why the layout would have gotten fracked up just from me changing a few dotted whole notes to whole note + half rest, or a few half notes to half rests. In *all* cases was such that the exact same rhythm was found vertically in the same measure stack, so redoing the music spacing would not have changed the width of any of the measures in any case. -- 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] Another question about a possibly-fixed Finale bug
On 17 Feb 2009 at 7:59, Robert Patterson wrote: David's concern that excessive updating could cause fragmentation is probably not warranted. This is based on a plugin-writer's level of knowledge about Finale internals, rather than a Finale developer's. But without boring the list with a a lot of technical specifics, that is my impression. AUL doesn't offer me anything I have ever needed, either, as my workflow is such that I do page layout at the end of the entry process. If I had changed the music in such a way as to alter the width of any measures, I would have respaced the music and manually updated the layout. But given that I did no edits that changed the widths of any measures, it never occurred to me to check the page layout before printing to PDF. Lesson learned on *that* score (no pun intended)! -- 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] Another question about a possibly-fixed Finale bug
On 17 Feb 2009 at 9:49, dhbailey wrote: David W. Fenton wrote: On 17 Feb 2009 at 10:09, Johannes Gebauer wrote: On 17.02.2009 David W. Fenton wrote: The reason why this bothers me is because it means data is constantly being discarded and recreated. This means that there will be a certain level of fragmentation in the file's internal structures (whether in RAM only, in temp files only, or in the actual file image saved on the hard drive, I don't know). This kind of fragmentation is the kind of thing that can lead to file corruption, so I want to avoid as much of that as possible. Well, I am not an expert on Finale's data structures, but I am pretty sure updating the layout actually changes nothing in the file itself. You can't seriously believe that, can you? Before my update layout, pages displayed the problem. After I updated, the problem went away. I saved the file, of course, and when I open it now, it doesn't display incorrectly. This indicates to me that data was written to the file. Actually, I believe that Finale gets it's print data from the graphics card *All* WYSIWYG applications use the rasterizer of your printer driver for the screen calculations, and it has always been that way. I don't see what this has to do with anything, though. The problem was not a screen display issue -- it was a case of completely ignoring a set page layout that had already been stored in the data file (and retrieved and reprinted more than once, BTW). -- at least it did when I first started using it because I had a problem with printing and contacted tech support and they told me that and gave me a workaround until I updated the drivers for my graphics card. Yes, bugs in video drivers can cause problems with printing. So if the printing does indeed get its data from the on-screen realization, then saving the file and re-opening it, even without updating the layout might have solved the problem. But what would have caused the layout to get out of whack in the first place? I have not changed printer or video drivers between the last time I printed the file, and the editing session where I changed a few notes. I'm not convinced that update layout does anything other than force the graphics card to redraw from the file, instead of keeping possibly erroneous data in the memory chips of the graphics card, which would cause the layout problems. Really? Manually updating data changes measure widths, e.g., spacing measures that are not filling up a whole system (or are scrunched up on one side) to evenly fill the whole system, and recalculating automatic system breaks based on measure widths that have changed since the last layout update. Yes, of course, for display purposes, there's going to have to be interaction with the printer driver, but these are not display issues -- these are issues of where the bar lines fall horizontally in a system, and where the systems break. That's data that *must* be stored in the data file, seems to me, as I can't conceive of how it could be recalculated correctly upon re- opening the file if it has not been stored already. -- 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] Another question about a possibly-fixed Finale bug
On 17 Feb 2009 at 16:15, Johannes Gebauer wrote: On 17.02.2009 David W. Fenton wrote: Well, I am not an expert on Finale's data structures, but I am pretty sure updating the layout actually changes nothing in the file itself. You can't seriously believe that, can you? Before my update layout, pages displayed the problem. After I updated, the problem went away. I saved the file, of course, and when I open it now, it doesn't display incorrectly. This indicates to me that data was written to the file. the emphasis being on display incorrectly. Well, they *printed* incorrectly, not just displayed incorrectly. That doesn't mean anything is incorrect in the data file. The data file doesn't change. If you end up in a situation where the layout has not been updated, and updating it would change anything, the very same change would appear if you closed and reopened the file. Sorry, but I'm really not following you here. If the onscreen layout is screwed up, I expect it to print that way. If I close the file without updating the layout, I expect to see the same screwed-up layout. If I update layout so that it's correct and then save the file, I expect the layout to still be correct when I open it again. That proves that the updated layout data has been stored in the file. If it had not been stored, then the file would return to the screwed- up state the next time it was opened. Yes? No? Maybe? I tested that a long time ago (before there was an automatic update). Updating the layout sets things straight. It is similar to a screen redraw, which also doesn't change the file. The data *must* be written to the file at some point, otherwise, how could the file then be correct the next time you open it? This still doesn't explain why changing a few notes without updating the music spacing should invalidate an existing locked page layout. -- 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] Another question about a possibly-fixed Finale bug
On 17 Feb 2009 at 16:19, Johannes Gebauer wrote: On 17.02.2009 David W. Fenton wrote: I think there might be a slight misunderstanding of what updating the layout actually does. It does not manipulate any data (unless such options are active) in the actual file. Page layout is not stored in the Finale file? You realize how ridiculous that is? The page layout as such is not stored in the file. All that is stored is things like system size, locked systems, new page or system settings for certain measures and the like. Um, aren't those the only thing that page layout could possible mean? And when you respace music so that measure widths change, when you do an update layout, the displayed (and printed) measure widths change (and are retained when you save and re-open the file). If this information is not saved anywhere, but calculated on the fly, how in the world can Finale reconstruct the layout that was correct if the data that describes the difference between the pre-update page layout and the post-update page layout? Something is being stored. I do now understand your point that not all details of page layout are stored (since anything that can be derived from the stored data can be calculated at page display time), but the parameters that describe the difference between displayed/printed measure widths and system breaks and page breaks before and after a page layout update have to be saved to the file, or otherwise, you'd have to do the layout update every time you opened the file. Finale does not save information like measure 36 is the top left measure of page 2. It just ends up there through a lot of other parameters. Of course. I never imagined that it did, nor intended to suggest that. But it certainly stores sufficient information to recreate the page layout onscreen when the file was last saved when the filed is next opened. Ridiculous it may be (I actually have no opinion on that), but that's how Finale works. I don't believe there's anything ridiculous about it. I'm trying to figure out why my file needed a page layout update when there had been no alterations to the widths of any of the measures, nor to any the system or page breaks (the system layout was locked). None of the systems were actually reflowed, in fact, but Finale somehow decided that I wanted two systems repeated on two phantom pages. Sure, it's a bug, but I can't see why the edits that I made should have caused that bug. Nor do I believe I should have needed to do a layout update to retain the existing layout. -- 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] Another question about a possibly-fixed Finale bug
On 17 Feb 2009 at 16:27, Johannes Gebauer wrote: On 17.02.2009 dc wrote: I'm afraid David is right on this count. I just modified the music spacing, saved and closed the file without updating the layout. When I reopen it, the layout is still the same and needs to be updated. Well, that's actually not what David just discribed, he said it doesn't display incorrectly, but he saved after the update. Hold on -- this doesn't exactly correctly restate what I said. Here's what happened: 1. I created the file with the correct notes and all, spaced the music, worked out the system and page layouts, locked everything in place (manual page layout updates along the way), saved the file and printed to PDF. All was right with the world. 2. I made some small edits to the last two pages of the piece, changing some half notes to half rests and some dotted whole notes to whole notes + half rest. 3. I did not respace the music, as the vertical measure stacks in all cases had the same rhythms in them already (so no measure widths would have changed). 4. I printed a PDF (which is my default printer driver, BTW, because I have no printer attached -- this did not change at any point during the editing process). I didn't notice that it had two extra pages, the first being p. 3, which repeated the last system of p. 2, and p. 6, which repeated the last system of p. 5. It's interesting that the first extra system was music that was *before* the edits that I made in step 2 (which entirely involved the original pp. 3-4). 5. Having been informed of the screwed-up layout, I opened the file in page view, noted the phantom systems/pages, and navigated to p. 1 and updated the layout manually. All was fixed. If you want to compare the source file and the final file, they are here: http://dfenton.com/Teares/Scores/HasslerIntrada.pdf http://dfenton.com/Teares/Scores/HasslerIntradaSimplified.pdf The first two pages are identical, but also note that while the music is different on the last two pages (we have a novice tenor 2 player, so all of his moving parts were transferred to one or the other of the other two tenor players, and his part was simplified to make it very easy to play at the rather fast tempo we've chosen), the measure widths are uniformly identical. And if you look at the music vertically, this is to be expected. Indeed, some of the simplifications removed some quarter notes, which could have made the measures narrower had I respaced the music. So, given this history, and this specific layout, why exactly should I have needed to update the layout? I didn't change video drivers. I didn't change computers. I didn't change the printer driver or any settings in the printer driver. Anyway, this is news to me. I was sure that saving and reopening would actually do the same as updating the layout, but perhaps that is no longer true (I am pretty sure it was true a long time ago). I really don't know what you mean. My point is that if I update layout and save the file, the file will reflect the changes that occurred when I did the manual update. That means that the data that changed has been recorded in the file. -- 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] Another question about a possibly-fixed Finale bug
On 17.02.2009 David W. Fenton wrote: Sorry, but I'm really not following you here. If the onscreen layout is screwed up, I expect it to print that way. If I close the file without updating the layout, I expect to see the same screwed-up layout. If I update layout so that it's correct and then save the file, I expect the layout to still be correct when I open it again. That proves that the updated layout data has been stored in the file. If it had not been stored, then the file would return to the screwed- up state the next time it was opened. Yes? No? Maybe? No, because as far as I can see any time you open the file it gets updated anyway. It is the screwed up state that is not saved, not the correct one. Dennis noticed it otherwise though, so I am no longer sure. Whatever the case, I still cannot understand your reasoning for not having the auto-update feature on. File corruption? Well, if anything updating the layout seems to clear up corruption. Johannes ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
On 17 Feb 2009 at 16:29, Johannes Gebauer wrote: On 17.02.2009 David W. Fenton wrote: You snipped the context. I did not claim that automatic layout updating caused that problem, but automatic music spacing *does* cause the problem. And it's only if I had automatic music spacing turned on that the music spacing could have changed without me respacing the music. And that's the only thing that would have possibly required an update layout. Now I am confused, are you saying you were talking about automatic music spacing all along? That's a completely different horse, I would not switch that on if someone payed me to do it. No. I brought up automatic music spacing because someone admonished me that by changing any notes that the existing layout was somehow invalidated and needed to be updated just because I changed the content of some of the measures. The only way I can think that this would be so would be if I had been working with automatic music spacing turned on (which I don't), so I can't see any reason why just changing some of the notes would invalidate the page layout and necessitate a recalc. If the changes I'd made had changed the widths of the measures, I certainly would have respaced the music manually and then updated the layout manually. But as anyone can clearly see from comparing the two PDFs, nothing I did changed any of the measure widths, so there was really no reason at all to need to update the page layout. But I only brought up automatic music spacing because that's the only conceivable reason I can think of why page layout could change just from editing a few notes that don't change any measure widths. -- 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] Another question about a possibly-fixed Finale bug
On 17.02.2009 David W. Fenton wrote: Ridiculous it may be (I actually have no opinion on that), but that's how Finale works. I don't believe there's anything ridiculous about it. But those were your words ...;-) Johannes ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
On 17.02.2009 David W. Fenton wrote: AUL doesn't offer me anything I have ever needed, either, as my workflow is such that I do page layout at the end of the entry process. If I had changed the music in such a way as to alter the width of any measures, I would have respaced the music and manually updated the layout. But given that I did no edits that changed the widths of any measures, it never occurred to me to check the page layout before printing to PDF. It still strikes me as odd that this problem never happened to you before as it was one of my very first printing disasters with Finale, long before AUL was introduced. I took AUL as a godsend when it came, to prevent these printing problems. I had them numerous times... Johannes ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Another question about a possibly-fixed Finale bug
On 17.02.2009 Michael Good wrote: 1) Plug-ins can turn the various automatic layout settings on and off. If you see automatic layout being switched out from under you, see if you can relate this to running a specific plug-in. If so, please report the problem to MakeMusic and/or the plug-in developer. If this is true, Robert could just determine the state of the setting and switch it off before running, then on again, no? In which case I can't understand what that problem is about in the first place other than needing a few extra lines of code in the PIs. Johannes ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
On 17 Feb 2009 at 13:26, Darcy James Argue wrote: David's reasons, on the other hand, make no sense at all to me. He keeps mentioning issues related to Automatic Music Spacing, which of course has nothing to do with Automatic Update Layout I only brought up automatic music spacing because someone asserted that *of course* I needed to update the layout after changing some of the notes. And the only plausible reason I could come up with for that assertion would be if automatic music spacing were turned on. As you can see from a comparison of the PDFs (URLs listed in another post), there was not a single measure whose width changed in the edited version of the file. -- 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] Another question about a possibly-fixed Finale bug
On 17 Feb 2009 at 22:14, Johannes Gebauer wrote: Whatever the case, I still cannot understand your reasoning for not having the auto-update feature on. Because I do my page layout updates manually, at the time in my workflow when I'm laying out the pages. If I then edit in such a way as to change any measure widths, I'll respace the music and update the layout. In this case, I didn't change any measure widths, hence, no need to update layout. So far as I can see, the only reason I should turn on automatic layout updates is to avoid this one bug. Having been bitten by it, now I'll always look at the pages before printing them, and then proof the results. I normally would do that, but this time the changes were trivial and didn't change the layout (and it certainly didn't change any of my measure widths or system breaks, BTW). I also don't have automatic Windows updates turned on, because I have made a lot of money from restoring PCs that were screwed up by automatic updates. I don't believe in doing automatically what can be done on demand in a structured workflow. I want to control when things happen, and I don't see any reason to change that. Indeed, I have been working this way for as long as I've been using Finale (i.e., since 1991), and until now have never had a problem. I wouldn't have had the problem had I properly proofed, but I didn't know Finale was so undependable. Lesson learned, obviously. -- 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] Another question about a possibly-fixed Finale bug
On 17 Feb 2009, at 4:23 PM, David W. Fenton wrote: On 17 Feb 2009 at 13:26, Darcy James Argue wrote: David's reasons, on the other hand, make no sense at all to me. He keeps mentioning issues related to Automatic Music Spacing, which of course has nothing to do with Automatic Update Layout I only brought up automatic music spacing because someone asserted that *of course* I needed to update the layout after changing some of the notes. Well, you do! And the only plausible reason I could come up with for that assertion would be if automatic music spacing were turned on. No, the plausible reason is that if you don't update the layout, you get problems like the one you just described. The rest of us have been running into those problems all the time, for years. Which is why we either turn Automatic Update Layout on, or reflexively update the layout before printing. Every time. Even if we made no changes at all. You keep complaining that there is no reason why you SHOULD have had to update the layout in your situation. Well, sure, we all agree with that. But you go to war with the notation software you have, not the notation software you wish you had. The way Finale actually works is that whenever you make ANY change to the note or rest durations in ANY measure, if you don't update the layout you are risking exactly the kind of problem you had yesterday. Cheers, - Darcy - djar...@earthlink.net Brooklyn, NY ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
On 17 Feb 2009 at 22:22, Johannes Gebauer wrote: On 17.02.2009 David W. Fenton wrote: AUL doesn't offer me anything I have ever needed, either, as my workflow is such that I do page layout at the end of the entry process. If I had changed the music in such a way as to alter the width of any measures, I would have respaced the music and manually updated the layout. But given that I did no edits that changed the widths of any measures, it never occurred to me to check the page layout before printing to PDF. It still strikes me as odd that this problem never happened to you before as it was one of my very first printing disasters with Finale, long before AUL was introduced. I took AUL as a godsend when it came, to prevent these printing problems. I had them numerous times... Sure, it's happened before, but only in cases where I messed up the workflow. In this case, there was no edit to the file that justified an update layout, and that situation is one I've never encountered (i.e., page layout messes up after edits that don't change the page layout). -- 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] Another question about a possibly-fixed Finale bug
On 17 Feb 2009 at 16:34, Darcy James Argue wrote: On 17 Feb 2009, at 4:23 PM, David W. Fenton wrote: On 17 Feb 2009 at 13:26, Darcy James Argue wrote: David's reasons, on the other hand, make no sense at all to me. He keeps mentioning issues related to Automatic Music Spacing, which of course has nothing to do with Automatic Update Layout I only brought up automatic music spacing because someone asserted that *of course* I needed to update the layout after changing some of the notes. Well, you do! No, I really don't. The measure widths haven't changed, so even if I've replaced a whole note with sixteen 32nd notes, there is no reason I need to update the page layout. No, it won't look good, but it shouldn't require a page layout update. And the only plausible reason I could come up with for that assertion would be if automatic music spacing were turned on. No, the plausible reason is that if you don't update the layout, you get problems like the one you just described. A bug. A really stupid bug. One that does not occur because of any actual data in your file. The rest of us have been running into those problems all the time, for years. Which is why we either turn Automatic Update Layout on, or reflexively update the layout before printing. Every time. Even if we made no changes at all. I have never before encountered a situation in which the page layout needed updating when measure widths had not changed. You keep complaining that there is no reason why you SHOULD have had to update the layout in your situation. Well, sure, we all agree with that. But you go to war with the notation software you have, not the notation software you wish you had. The way Finale actually works is that whenever you make ANY change to the note or rest durations in ANY measure, if you don't update the layout you are risking exactly the kind of problem you had yesterday. I'll update the layout when the layout is wrong. In this case, my mistake was in not looking at the onscreen display of the page layout. But I'm not going to update the page layout when I can see onscreen that it's correct, even though you claim I should have to do so if I've changed any notes. This is bloody ridiculous. I've been using Finale for 18 years. I've *never* encountered this situation before (i.e., page layout goes haywire after edits that don't alter any of the measure widths or system/page breaks). I now know not to print without previewing. This is not the same thing at all as saying that I need to turn on automatic layout update. -- 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] Another question about a possibly-fixed Finale bug
On 17 Feb 2009, at 5:03 PM, David W. Fenton wrote: On 17 Feb 2009 at 16:34, Darcy James Argue wrote: On 17 Feb 2009, at 4:23 PM, David W. Fenton wrote: On 17 Feb 2009 at 13:26, Darcy James Argue wrote: I only brought up automatic music spacing because someone asserted that *of course* I needed to update the layout after changing some of the notes. Well, you do! No, I really don't. Fine, suit yourself. But if you don't update the layout in these circumstances, then you are leaving yourself vulnerable to the very problem you originally wrote to complain about. You came to the list and complained you'd been bitten by a nasty bug. You have been told by several people how to avoid that bug in future. But you seem to feel that on principle, you shouldn't have to take those steps. You insist on doing things in the exact same way that led you to be bitten by the bug in the first place. Okay then. Good luck with that. Cheers, - Darcy - djar...@earthlink.net Brooklyn, NY ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
[Finale] Re: Another question about a possibly-fixed Finale bug
Hi Robert, Thanks for the explanation about the Beam Over Barlines plug-in. But in that case, as Johannes asked, why not just turn Automatic Update Layout off from within the plug-in? You can then do a manual update layout, do the plug-in changes, run further manual update layouts if needed, then restore the original AUL settings when done. If this won't work I'd like to know what I'm missing, since it will probably come in handy some time in the future! Best regards, Michael Good Recordare LLC www.recordare.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Another question about a possibly-fixed Finale bug
On 17.02.2009 Michael Good wrote: Thanks for the explanation about the Beam Over Barlines plug-in. But in that case, as Johannes asked, why not just turn Automatic Update Layout off from within the plug-in? You can then do a manual update layout, do the plug-in changes, run further manual update layouts if needed, then restore the original AUL settings when done. If this is indeed possible I would welcome an update to your other plugins, too. The one which gives me grief with this bug most often ist the Tie-Mover plugin, but I have seen it in Patterson Beams as well. Johannes ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
On 17.02.2009 David W. Fenton wrote: Well, you do! No, I really don't. The measure widths haven't changed, so even if I've replaced a whole note with sixteen 32nd notes, there is no reason I need to update the page layout. No, it won't look good, but it shouldn't require a page layout update. You see, David, you are simply wrong, and your desaster is proof. Whatever you have done has caused your layout to be un-updated. This is not really a bug as Finale doesn't claim that it doesn't have this problem, that's why it provides the layout update function in the first place. It happened after you did something which you think shouldn't cause it to happen, but that doesn't mean that it doesn't happen. It is normal with Finale. Naturally we wouldn't mind if it didn't happen, but nowhere does it say that it doesn't, nor that you can then print without updating the layout and not get the problems you describe. So I cannot follow you that this is a bug. It is normal behaviour, even if you haven't seen it. Ok, I have understood that you don't want AUL turned on, fair enough if this makes you feel better. There may be reasons not to turn it on. It still doesn't make this a bug. Before printing you will have to update the layout. Perhaps somewhere in the internals of Makemusic someone has a list of things which will cause the layout to go un-updated, but even that will probably not make you happier, unless you update the layout every single time you want to print something. Johannes ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
On 17.02.2009 David W. Fenton wrote: I'll update the layout when the layout is wrong. In this case, my mistake was in not looking at the onscreen display of the page layout. But I'm not going to update the page layout when I can see onscreen that it's correct, even though you claim I should have to do so if I've changed any notes. This is bloody ridiculous. I've been using Finale for 18 years. I've *never* encountered this situation before (i.e., page layout goes haywire after edits that don't alter any of the measure widths or system/page breaks). I now know not to print without previewing. This is not the same thing at all as saying that I need to turn on automatic layout update. I can't help but thinking you sound like a little child saying I won't sleep tonight. Anyway, I have seen this bug too many times... Johannes ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
[Finale] Another question about a possibly-fixed Finale bug
I use WinFin2003, and just had a disaster with uploading a PDF produced after some minor edits on a file. I did nothing but alter some of the note values in some measures (altering quite a few dotted whole notes to be whole notes plus half rest). I didn't think about it, and just reprinted the PDF. The original layout was 4 pages, 1 piece on pp. 1-2, the other on pp. 3-4. The PDF I just printed came out with the piece on pp. 1-2, the last system of p. 2 repeated on p. 3, the 2nd piece on pp. 4-5 and the last system of p. 5 repeated on p. 6. I immediately recognized the problem when informed about it and opened the file, went to page layout view, hit Ctrl-U and reprinted, and it came out fine. Certainly I could auto-update layout and avoid this problem, but I'm *never* going to do that. Do recent versions of Finale manage not to screw up existing layouts? Perhaps it has something to do with the fact that I tend to work back and forth between 75% and 100% view and perhaps printing from one or the other magnifications causes the problem? Does this still happen? I certainly haven't encountered it when I hadn't even changed anything but the internal content of measures (i.e., changes that don't have any effect whatsoever on the width of measures). This really screwed up a project that needed to be finished by tomorrow night, and now won't be (because I'm totally booked all day tomorrow). And it makes me look really stupid, given that I was bitching about the form in which the editing was conveyed to me. I'm definitely in a really bad mood right now. -- 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] Another question about a possibly-fixed Finale bug
On 16 Feb 2009, at 11:56 PM, David W. Fenton wrote: Certainly I could auto-update layout and avoid this problem, but I'm *never* going to do that. I will repeat, for not the first time, that I do not understand the rationale for anyone leaving Automatically Update Layout off. In fact, I don't even understand why Finale allows turning it off as an option. It should be always on. There is, as far as I can tell, no advantage at all to turning it off. And it is infuriating that recent versions of Finale tend to forget this setting and require you to turn it on manually every time you launch the app. I did nothing but alter some of the note values in some measures (altering quite a few dotted whole notes to be whole notes plus half rest). David, no disrespect, but OF COURSE you need to do an update layout after altering note values! That is a classic instance of a situation that requires you to update layout. Again, this is why I feel that the layout should always update automatically. Cheers, - Darcy - djar...@earthlink.net Brooklyn, NY ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
On 17 Feb 2009 at 0:07, Darcy James Argue wrote: On 16 Feb 2009, at 11:56 PM, David W. Fenton wrote: Certainly I could auto-update layout and avoid this problem, but I'm *never* going to do that. I will repeat, for not the first time, that I do not understand the rationale for anyone leaving Automatically Update Layout off. In fact, I don't even understand why Finale allows turning it off as an option. It should be always on. There is, as far as I can tell, no advantage at all to turning it off. And it is infuriating that recent versions of Finale tend to forget this setting and require you to turn it on manually every time you launch the app. Uh, I've had it OFF as long as the feature has existed, but this is the first time it's ever done this -- there was no reason that page layout needed to be updated. It was perfect as is, and none of my edits were to data that would have altered the page layout (and couldn't have done so, anyway, since systems were locked, with hard system breaks and hard page breaks). There is simply no excuse for repeating a system from one page to another. That's a bug. I shouldn't have to update page layout (manually or automatically) just to be sure I don't encounter that bug. I did nothing but alter some of the note values in some measures (altering quite a few dotted whole notes to be whole notes plus half rest). David, no disrespect, but OF COURSE you need to do an update layout after altering note values! That is a classic instance of a situation that requires you to update layout. Why? I didn't respace, and certainly don't have automatic music spacing turned on (why would I do that? that's 1000 times worse that automatic page layout updating). Indeed, the system layout remained identical. The only difference was that Finale created two phantom systems that were nothing more than repeats of the last system of the previous pages. Again, this is why I feel that the layout should always update automatically. And I respectfully disagree. I don't want things jumping around onscreen while I'm working. And the way automatic page layout works means that there's far more page layout recalculating done than is necessary (because the automatic page layout recalc on the current page discards the layout for all subsequent pages, which means they have to be recalced, as opposed to a manual recalc which will update the layout from the present page to the end of the document). This is a stupid bug. There is no excuse for printing phantom systems on phantom pages. My question remains: is the bug fixed? Or is everybody using automatic layout updates so they wouldn't encounter it even if the bug still existed? -- 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] Another question about a possibly-fixed Finale bug
On 17 Feb 2009 at 0:24, David W. Fenton wrote: And the way automatic page layout works means that there's far more page layout recalculating done than is necessary (because the automatic page layout recalc on the current page discards the layout for all subsequent pages, which means they have to be recalced, as opposed to a manual recalc which will update the layout from the present page to the end of the document). The reason why this bothers me is because it means data is constantly being discarded and recreated. This means that there will be a certain level of fragmentation in the file's internal structures (whether in RAM only, in temp files only, or in the actual file image saved on the hard drive, I don't know). This kind of fragmentation is the kind of thing that can lead to file corruption, so I want to avoid as much of that as possible. Maybe I'm paranoid. But as someone who works with file-based databases, I know what kinds of problems come from this kind of data churn. It's never good in the long run. -- 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] Another question about a possibly-fixed Finale bug
Hi David, On 17 Feb 2009, at 12:24 AM, David W. Fenton wrote: there was no reason that page layout needed to be updated. Yes there is, as I said. You modified note values. That always requires the layout to be updated. That's just how Finale works. It was perfect as is, and none of my edits were to data that would have altered the page layout (and couldn't have done so, anyway, since systems were locked, with hard system breaks and hard page breaks). So in other words, turning on Automatic Update Layout with the normal settings (preserve system locks) would not have done anything except prevent this bug from biting you. On 17 Feb 2009 at 0:07, Darcy James Argue wrote: That is a classic instance of a situation that requires you to update layout. Why? So that you avoid precisely this situation. This is a stupid bug. Agreed. But it is a known, longstanding bug that can be avoided 100% of the time by leaving Automatic Update Layout on. And there is no disadvantage to doing so. There is no excuse for printing phantom systems on phantom pages. Agreed. But this is also pretty much guaranteed to happen if you have Automatic Update Layout off and neglect to *always* manually update layout before printing. IMO, Finale just flat-out does not work properly without Automatic Update Layout turned on. (The alternative is to always manually update the layout prior to printing, which amounts to the same thing.) Seriously. Just turn it on. You will save yourself countless headaches. The fact that you have not previously encountered situations like the one you describe only means that you have been very lucky. Cheers, - Darcy - djar...@earthlink.net Brooklyn, NY On 17 Feb 2009 at 0:07, Darcy James Argue wrote: On 16 Feb 2009, at 11:56 PM, David W. Fenton wrote: Certainly I could auto-update layout and avoid this problem, but I'm *never* going to do that. I will repeat, for not the first time, that I do not understand the rationale for anyone leaving Automatically Update Layout off. In fact, I don't even understand why Finale allows turning it off as an option. It should be always on. There is, as far as I can tell, no advantage at all to turning it off. And it is infuriating that recent versions of Finale tend to forget this setting and require you to turn it on manually every time you launch the app. Uh, I've had it OFF as long as the feature has existed, but this is the first time it's ever done this -- there was no reason that page layout needed to be updated. It was perfect as is, and none of my edits were to data that would have altered the page layout (and couldn't have done so, anyway, since systems were locked, with hard system breaks and hard page breaks). There is simply no excuse for repeating a system from one page to another. That's a bug. I shouldn't have to update page layout (manually or automatically) just to be sure I don't encounter that bug. I did nothing but alter some of the note values in some measures (altering quite a few dotted whole notes to be whole notes plus half rest). David, no disrespect, but OF COURSE you need to do an update layout after altering note values! That is a classic instance of a situation that requires you to update layout. Why? I didn't respace, and certainly don't have automatic music spacing turned on (why would I do that? that's 1000 times worse that automatic page layout updating). Indeed, the system layout remained identical. The only difference was that Finale created two phantom systems that were nothing more than repeats of the last system of the previous pages. Again, this is why I feel that the layout should always update automatically. And I respectfully disagree. I don't want things jumping around onscreen while I'm working. And the way automatic page layout works means that there's far more page layout recalculating done than is necessary (because the automatic page layout recalc on the current page discards the layout for all subsequent pages, which means they have to be recalced, as opposed to a manual recalc which will update the layout from the present page to the end of the document). This is a stupid bug. There is no excuse for printing phantom systems on phantom pages. My question remains: is the bug fixed? Or is everybody using automatic layout updates so they wouldn't encounter it even if the bug still existed? -- 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 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another question about a possibly-fixed Finale bug
On 17 Feb 2009, at 12:24 AM, David W. Fenton wrote: Again, this is why I feel that the layout should always update automatically. And I respectfully disagree. I don't want things jumping around onscreen while I'm working. Respectfully, David, I don't think you fully understand how the feature works. It does not result in anything jumping around onscreen. It only results in things displaying and printing correctly, instead of incorrectly. Just try it. Cheers, - Darcy - djar...@earthlink.net Brooklyn, NY ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
[Fwd: Re: [Finale] bug?]
Found it! greetings Raimund Lintzen Original-Nachricht Betreff: Re: [Finale] bug? Datum: Tue, 27 Feb 2007 11:11:09 EST Von: [EMAIL PROTECTED] Antwort an: finale@shsu.edu An: finale@shsu.edu In a message dated 2/27/07 8:30:39 AM, [EMAIL PROTECTED] writes: Oliver Pospiech wrote: Please, who can help me? Does anybody know this behaviour of finale (2006c WinXP): blocked::http://www.oliver-pospiech.de/ blocked::http://www.oliver-pospiech.de/bug.jpg www.oliver-pospiech.de/bug.jpg - thick, blue signs crossed over the screen! What can I do against it? Believe it or not, the Blue Triangle appears because you have Internet Explorer 7 installed on your computer. To get rid of the triangle, click on the Document Menu -- Document Options -- Lines and Curves. In the upper right hand corner is a Resolution field. Change the number in the field until the triangle disappears (try 10). ** AOL now offers free email to everyone. Find out more about what's free from AOL at http://www.aol.com. ___ 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] Another Perspective on MM and Finale Bug Fixes
Yep http://www.finalemusic.com/finale/system-requirements.aspx Martin Banner wrote: I currently do all my work on Finale 2003a on my Mac Powerbook G4 (3 1/2 years old) with OS 10.3.9. Would I need to go to a more recent Mac OS in order to use Fin2008 (or even Fin2009)? Martin ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Another Perspective on MM and Finale Bug Fixes
I currently do all my work on Finale 2003a on my Mac Powerbook G4 (3 1/2 years old) with OS 10.3.9. Would I need to go to a more recent Mac OS in order to use Fin2008 (or even Fin2009)? Martin On Oct 18, 2007, at 3:20 PM, Leigh Daniels wrote: I wonder if the lack of bug fixes in the initial release of Fin2008 and the lack of a Fin2008 update are due to the immanent release of Leopard. I believe that there are major changes, including kernel changes, coming with the new OS. If this is true and if I were MM, I would be putting all my resources into a Finale release that would be based on the new OS and would fix the major bugs we've been talking about recently, thus killing two birds with one stone. I'm hopeful this is the case, but I am not expecting it to be so. **Leigh ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale Martin Banner [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
[Finale] Another Perspective on MM and Finale Bug Fixes
I wonder if the lack of bug fixes in the initial release of Fin2008 and the lack of a Fin2008 update are due to the immanent release of Leopard. I believe that there are major changes, including kernel changes, coming with the new OS. If this is true and if I were MM, I would be putting all my resources into a Finale release that would be based on the new OS and would fix the major bugs we've been talking about recently, thus killing two birds with one stone. I'm hopeful this is the case, but I am not expecting it to be so. **Leigh ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Finale Bug Fix Wish List
I have been a finale (FinWin) user since 3.7, and right now, although I find the Sibelius discussion tempting, I do not plan on switching. I have upgraded to 2008, and while I am not a heavy user (maybe an hour a day), nor am I a professional engraver/musician/composer, I do occasional work gratis for others which means I do have to put my very best foot forward in the finished product. I have learned much from the professionals on this list, but don't think my work is up to their fine standards or exacting detail. As such, I have run into few of the bugs they have, but I have run into some, such as the hyphenation bug. Nevertheless, whenever one of them has a beef with MM, I pay attention, because as a computer professional, I try to keep attuned to user complaints, even if they are not for my products. Also, I know that this issue affects what users really want - productivity. And, therefore, I know that I know that these bugs, even though I may not have run into them myself, will eventually affect me sooner or later. I have been reasonably productive with 2k8. But, again, I'm not a professional. There are things that I think need fixing (e.g., Unicode). There are improvements that took getting used to, but I like better once I got accustomed to using it (e.g., the new selection/mover tool). There are some things that just confuse me (some keystrokes have been re-assigned). But, when it comes to computers, I adapt quickly, and most of this has not bothered me. My 2c. Daniel Wolf wrote: Thanks to all for the overwhelming response to my question about users skipping the current upgrade or switching products. Most surprising was the fact that no one on the list has stepped up and indicated that he or she has either upgraded and been satisfied with the upgrade or has the intention to upgrade. Personally, I'm an experienced user who has invested a lot of time and money in Finale, since 3.7. I have upgraded regularly, missing only 2004; I have purchased TG Tools as well. I like Finale's flexibility in entry methods (I'm a command line fan), as well as its capacity for finding a number of solutions to notational problems, especially for new music. With my own templates and working routine, I would really prefer not to switch from using Finale as my primary notation program, but the current state of the program raises some real concerns about its future. I have been writing an item about the current state of Finale for my blog, Renewable Music ( http://renewablemusic.blogspot.com/ ). I have written to MakeMusic outlining my concerns but have yet to receive any response. In the article, I would like to document the persistent bugs concretely. Specifically, which long-standing bugs in the program are deal breakers, keeping current users from either upgrading or driving a user to switch products? Daniel Wolf Frankfurt ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
[Finale] Re: Finale Bug Fix Wish List
Thanks to all for the overwhelming response to my question about users skipping the current upgrade or switching products. Most surprising was the fact that no one on the list has stepped up and indicated that he or she has either upgraded and been satisfied with the upgrade or has the intention to upgrade. Personally, I'm an experienced user who has invested a lot of time and money in Finale, since 3.7. I have upgraded regularly, missing only 2004; I have purchased TG Tools as well. I like Finale's flexibility in entry methods (I'm a command line fan), as well as its capacity for finding a number of solutions to notational problems, especially for new music. With my own templates and working routine, I would really prefer not to switch from using Finale as my primary notation program, but the current state of the program raises some real concerns about its future. I have been writing an item about the current state of Finale for my blog, Renewable Music ( http://renewablemusic.blogspot.com/ ). I have written to MakeMusic outlining my concerns but have yet to receive any response. In the article, I would like to document the persistent bugs concretely. Specifically, which long-standing bugs in the program are deal breakers, keeping current users from either upgrading or driving a user to switch products? Daniel Wolf Frankfurt ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Finale Bug Fix Wish List
I recall at least one person who said that he had upgraded to Fin2008 and was very happy with it. (Or did he say 'content' with it?) At least there was one (and possibly another) over the past 3 weeks or so that have said they're using it quite well. David H. Bailey Daniel Wolf wrote: Thanks to all for the overwhelming response to my question about users skipping the current upgrade or switching products. Most surprising was the fact that no one on the list has stepped up and indicated that he or she has either upgraded and been satisfied with the upgrade or has the intention to upgrade. Personally, I'm an experienced user who has invested a lot of time and money in Finale, since 3.7. I have upgraded regularly, missing only 2004; I have purchased TG Tools as well. I like Finale's flexibility in entry methods (I'm a command line fan), as well as its capacity for finding a number of solutions to notational problems, especially for new music. With my own templates and working routine, I would really prefer not to switch from using Finale as my primary notation program, but the current state of the program raises some real concerns about its future. I have been writing an item about the current state of Finale for my blog, Renewable Music ( http://renewablemusic.blogspot.com/ ). I have written to MakeMusic outlining my concerns but have yet to receive any response. In the article, I would like to document the persistent bugs concretely. Specifically, which long-standing bugs in the program are deal breakers, keeping current users from either upgrading or driving a user to switch products? Daniel Wolf Frankfurt ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Finale Bug Fix Wish List
I am having _very cautious_ success with 08, because a couple of -very serious- bugs I (and almost no one else, bugs which were serious enough to keep me from using 07 at all) had with 07 , have been fixed in 08. I am just starting into some serious 08 use, and there are so many GUI changes that I sometimes feel as if I am starting over. I use 06 also, when I can, but for various reasons I work in 08 at times. I also would like such a list. What are the worst of the 08 bugs? Raymond Horton Daniel Wolf wrote: Thanks to all for the overwhelming response to my question about users skipping the current upgrade or switching products. Most surprising was the fact that no one on the list has stepped up and indicated that he or she has either upgraded and been satisfied with the upgrade or has the intention to upgrade. Personally, I'm an experienced user who has invested a lot of time and money in Finale, since 3.7. I have upgraded regularly, missing only 2004; I have purchased TG Tools as well. I like Finale's flexibility in entry methods (I'm a command line fan), as well as its capacity for finding a number of solutions to notational problems, especially for new music. With my own templates and working routine, I would really prefer not to switch from using Finale as my primary notation program, but the current state of the program raises some real concerns about its future. I have been writing an item about the current state of Finale for my blog, Renewable Music ( http://renewablemusic.blogspot.com/ ). I have written to MakeMusic outlining my concerns but have yet to receive any response. In the article, I would like to document the persistent bugs concretely. Specifically, which long-standing bugs in the program are deal breakers, keeping current users from either upgrading or driving a user to switch products? Daniel Wolf Frankfurt ___ 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] Re: Finale Bug Fix Wish List
David Bailey said: I recall at least one person who said that he had upgraded to Fin2008 and was very happy with it. (Or did he say 'content' with it?) At least there was one (and possibly another) over the past 3 weeks or so that have said they're using it quite well. And so Les responds: Okay, I'll bite -- I upgraded to '08 (Win) as soon as it was announced.My primary hope was that some of the relatively (IMHO) minor bugs which had plagued '07 would be repaired.My use is probably a little more casual than most on the list - arrangements, original work for my orchestra. Occasionally other outside projectsso my use therefore, may be as concentrated/intensely as many 10 - 12 hours a day for days/weeks on end - and then a week or two with no use whatsoever.Most of my scores are full-orchestral, 22 - 28 staves are the norm. Works (on occasion) as long as an hour or so; usually anything of that size is created as multiple-movement/section files which are later merged. And so, after the initial surprise of the new selection tool - and re-programming my comfort/familiarity to its functionality, I found '08 on the whole to be a positive upgrade.I have now come to really appreciate the selection tool behavior. But: Playback?Nearly never utilize it. But that's where I had a bit of a prob with '08. A friend asked for specific musical cue advice throughout a VERY imminent production of The Taming of the Shrew he was directing and I realized it would probably take me less time to write him an incidental score than it would to pull cues.And he was VERY pleased with the idea of using GPO playback with an original Marsden score :)So far so good.I wrote the score in three days, but then found playback in '08 to be VERY problematic. (Incidentally: WinXP, 2G RAM, Athlon XP 1900+) Really bad dropouts; tempo fluctuations caused by minor score complexities...the GPO playback was unusable to me. I experimented with CPU overload settings, took an axe to polyphony far beyond what I artistically found acceptable - and was eventually able, through much coaxing and compromise - to achieve something acceptable though by now means desireable.Then - just for 'fun', I transcribed one of the brief movements as originally written to 2007 - and bingo!Perfect playback.. Really didn't want to convert the whole score back to '07, and fortunately my friend has the musical discretion of a dead, deaf ox and was thrilled.But I was not.And I didn't pursue the issue of GPO playback because it's only a very occasional need, but still.would be nice to know what the hell's going on THERE Any ideas, anyone? Best - and eager to try the Sibelius crossgrade as soon as time allows a bit of experimentation Les Les Marsden Founding Music Director and Conductor, The Mariposa Symphony Orchestra Music and Mariposa? Ah, Paradise!!! http://arts-mariposa.org/symphony.html http://www.geocities.com/~jbenz/lesbio.html - Original Message - From: dhbailey To: finale@shsu.edu Sent: Monday, October 15, 2007 4:57 PM Subject: Re: [Finale] Re: Finale Bug Fix Wish List I recall at least one person who said that he had upgraded to Fin2008 and was very happy with it. (Or did he say 'content' with it?) At least there was one (and possibly another) over the past 3 weeks or so that have said they're using it quite well. David H. Bailey ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] bug: elements 'grayed out' in PDF
On Jul 8, 2007, at 9:51 PM, Rich Caldwell wrote: On Jul 8, 2007, at 9:04 PM, Christopher Smith wrote: I have never seen a PDF created on my Mac that didn't print correctly (except when printing from Windows 98), but I would suspect a font issue. For a while I had a font that displayed correctly but printed different characters!? Changing it to an OpenType font corrected all problems. Character mayhem just started happening, and with any Finale file. However, it's happening with all fonts and is inconsistent. It seems to be occurring only after opening that one file, but then it happens with any file I try to print. Quitting and restarting Finale fixes it. I've now realized that the character mayhem is entirely a Preview problem, not Finale, as the PDFs view fine in Acrobat and show up differently each time I open them in Preview. However, the bizarre grayed-out symbols seem to be a separate issue... Rich ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
[Finale] bug: elements 'grayed out' in PDF
Has anyone noticed this bug before and know of a fix? FinMac2k7c, a score originally created in 2k7a(?) probably, using linked parts: At the beginning of two (and sometimes three) of the movements, the clefs and time signatures are grayed out on the PDF print-out of the full score (using OSX's save-as-PDF). On the page before one of these movement changes, default whole rests are also grayed out. These elements show properly on screen. The parts print correctly. The common feature of the beginnings of these movements is the notation of the time signature. I've quit Finale, rebooted my computer, checked the file integrity, but the behavior remains the same. The workaround I've found was to print in sections, with those troublesome movements being the 1st page of a PDF. It didn't fix, however, the grayed out whole rests on that one page, which was corrected by manually entering whole rests. Does this bizarre behavior sound familiar to anyone? Thanks, Rich ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] bug: elements 'grayed out' in PDF
On Jul 8, 2007, at 7:22 PM, Rich Caldwell wrote: Has anyone noticed this bug before and know of a fix? FinMac2k7c, a score originally created in 2k7a(?) probably, using linked parts: At the beginning of two (and sometimes three) of the movements, the clefs and time signatures are grayed out on the PDF print-out of the full score (using OSX's save-as-PDF). On the page before one of these movement changes, default whole rests are also grayed out. These elements show properly on screen. The parts print correctly. The common feature of the beginnings of these movements is the notation of the time signature. I've quit Finale, rebooted my computer, checked the file integrity, but the behavior remains the same. The workaround I've found was to print in sections, with those troublesome movements being the 1st page of a PDF. It didn't fix, however, the grayed out whole rests on that one page, which was corrected by manually entering whole rests. Does this bizarre behavior sound familiar to anyone? I've seen grey lines and other items at times in some PDFs, particularly some created on Windows. The issue is purely a display one, however, as everything prints properly. It also seems to matter what you view it with. I have seen it particularly in Preview, while Adobe Reader 7 seems to display fine. I have never seen a PDF created on my Mac that didn't print correctly (except when printing from Windows 98), but I would suspect a font issue. For a while I had a font that displayed correctly but printed different characters!? Changing it to an OpenType font corrected all problems. Christopher ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] bug: elements 'grayed out' in PDF
On Jul 8, 2007, at 9:04 PM, Christopher Smith wrote: I have never seen a PDF created on my Mac that didn't print correctly (except when printing from Windows 98), but I would suspect a font issue. For a while I had a font that displayed correctly but printed different characters!? Changing it to an OpenType font corrected all problems. Character mayhem just started happening, and with any Finale file. However, it's happening with all fonts and is inconsistent. It seems to be occurring only after opening that one file, but then it happens with any file I try to print. Quitting and restarting Finale fixes it. Rich ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Bug in Include In Measure Numbering (was Key signature question)
Christopher Smith wrote: On May 24, 2007, at 6:52 PM, dhbailey wrote: In Fin2007, you can set the measure attribute for the second measure so that it isn't calculated in the measure numbers. In earlier versions you have to monkey around with defining additional regions to handle the measure number hassles that result from such division of current measures. Yes, the above is true, but I came up with a bug that can occur if you use that. I set a pickup measure NOT to be counted in measure numbering, then (because I forgot) I went into the Measure Numbers dialogue box and set the current region to start at measure 2. I didn't notice the resulting wrong bar numbers (no big deal in any case, and easily corrected) but what I DID notice is every time I double clicked a measure with the Measure Tool to set a double bar, it set TWO double bars; the one I clicked and the one afterwards! I was navigating the score by clicking in the Measure Number box and typing in a new number, which might have had something to do with it. Finale might have had its furry little brain addled by the number I was typing in; was it a REAL number or a DEFINED number? Hey change them both! I've noticed a bug with this include in measure numbering aspect -- even if you have display defined measure number selected when you enter a number in the box to move to that measure, it will NOT move to the correct measure number. If you have any measures set to not be included in measure numbering, those are calculated anyway. so if you have, for example, 5 different measures set to not be included in measure numbering, and you have the program set to display defined measure number and you enter 2:25, it will actually show you 2:20. In a multi-movement piece with lots of pickups in the fashion of classical minuets, this can be quite aggravating, since you can never get to exactly the measure you want. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
[Finale] Bug in Include In Measure Numbering (was Key signature question)
On May 24, 2007, at 6:52 PM, dhbailey wrote: In Fin2007, you can set the measure attribute for the second measure so that it isn't calculated in the measure numbers. In earlier versions you have to monkey around with defining additional regions to handle the measure number hassles that result from such division of current measures. Yes, the above is true, but I came up with a bug that can occur if you use that. I set a pickup measure NOT to be counted in measure numbering, then (because I forgot) I went into the Measure Numbers dialogue box and set the current region to start at measure 2. I didn't notice the resulting wrong bar numbers (no big deal in any case, and easily corrected) but what I DID notice is every time I double clicked a measure with the Measure Tool to set a double bar, it set TWO double bars; the one I clicked and the one afterwards! I was navigating the score by clicking in the Measure Number box and typing in a new number, which might have had something to do with it. Finale might have had its furry little brain addled by the number I was typing in; was it a REAL number or a DEFINED number? Hey change them both! Weird. Christopher ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Bug in Include In Measure Numbering (was Key signature question)
Although Finale 2006 added the Include in Measure Numbering bit, I would under no circumstances employ it. It seems to have been hastily added and incompletely implemented. It is a big solution to a small problem. Wisdom suggests avoiding the potential headaches. -- Robert Patterson http://RobertGPatterson.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] bug?
On Feb 27, 2007, at 9:59 PM, Raymond Horton wrote: My solution to both that problem and the idiotic postage stamp- sized printing bug that I have had with new files in 2007 (that no one else seems to have) is to stop using the accursed 2007 and go back to 2006. It works. A local fellow here has had the same problem with postage-stamp sized print. I didn't know what to tell him, though I knew the situation had arisen before. Christopher ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
[Finale] bug?
Please, who can help me? Does anybody know this behaviour of finale (2006c WinXP): blocked::http://www.oliver-pospiech.de/ blocked::http://www.oliver-pospiech.de/bug.jpg www.oliver-pospiech.de/bug.jpg - thick, blue signs crossed over the screen! What can I do against it? Thanks, Oliver ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
[Finale] bug?
Please, who can help me? Does anybody know this behaviour of finale (2006c WinXP): www.oliver-pospiech.de/bug.jpg - thick, blue signs crossed over the screen! What can I do against it? Thanks, Oliver ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] bug?
Oliver Pospiech wrote: Please, who can help me? Does anybody know this behaviour of finale (2006c WinXP): blocked::http://www.oliver-pospiech.de/ blocked::http://www.oliver-pospiech.de/bug.jpg www.oliver-pospiech.de/bug.jpg - thick, blue signs crossed over the screen! What can I do against it? I seem to recall somebody else having that problem, but I don't recall now what the solution was. Does it print this way? I've never run into it myself, using Fin2006c on WinXP. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] bug?
I think this has something to do with staff styles, but I can't remember the solution, sorry. Oliver Pospiech wrote: Please, who can help me? Does anybody know this behaviour of finale (2006c WinXP): www.oliver-pospiech.de/bug.jpg - thick, blue signs crossed over the screen! What can I do against it? Thanks, Oliver ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] bug?
In a message dated 2/27/07 8:30:39 AM, [EMAIL PROTECTED] writes: Oliver Pospiech wrote: Please, who can help me? Does anybody know this behaviour of finale (2006c WinXP): blocked::http://www.oliver-pospiech.de/ blocked::http://www.oliver-pospiech.de/bug.jpg www.oliver-pospiech.de/bug.jpg - thick, blue signs crossed over the screen! What can I do against it? Believe it or not, the Blue Triangle appears because you have Internet Explorer 7 installed on your computer. To get rid of the triangle, click on the Document Menu -- Document Options -- Lines and Curves. In the upper right hand corner is a Resolution field. Change the number in the field until the triangle disappears (try 10). ** AOL now offers free email to everyone. Find out more about what's free from AOL at http://www.aol.com. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
AW: [Finale] bug?
Believe it or not, the Blue Triangle appears because you have Internet Explorer 7 installed on your computer. To get rid of the triangle, click on the Document Menu -- Document Options -- Lines and Curves. In the upper right hand corner is a Resolution field. Change the number in the field until the triangle disappears (try 10). Great! Thank you! Oliver ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] bug?
That was I. I have a similar problem in FinWin 2007b - occasional large blue triangles (which do not affect printing, but more later). I didn't get any real suggestions offered - some people here seemed so aghast that could I briefly misidentify my version of Windows as ME instead of XP (I don't run my life around that stuff like I suppose I should) that I ran off with my tail between my legs and did not press the issue. My solution to both that problem and the idiotic postage stamp-sized printing bug that I have had with new files in 2007 (that no one else seems to have) is to stop using the accursed 2007 and go back to 2006. It works. Raymond Horton Bass Trombonist, arranger, composer Louisville Orchestra dhbailey wrote: Oliver Pospiech wrote: Please, who can help me? Does anybody know this behaviour of finale (2006c WinXP): blocked::http://www.oliver-pospiech.de/ blocked::http://www.oliver-pospiech.de/bug.jpg www.oliver-pospiech.de/bug.jpg - thick, blue signs crossed over the screen! What can I do against it? I seem to recall somebody else having that problem, but I don't recall now what the solution was. Does it print this way? I've never run into it myself, using Fin2006c on WinXP. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
[Finale] Bug?
Yesterday I installed the Finale 2k7b update, and I think I found as bug. Not a big one, but very annoying to my ways of working. Here is what I observed: Yesterday I had a lengthy session in Finale. Last night I closed and quit Finale, and I know for absolute certain that I did not save preferences. This morning I opened Finale, and it did not revert to my normal prefs, instead it kept the prefs from when I quit Finale last night. This included the current tool, the MIDI input device (my normal input device is none to avoid the error message at start up when it is missing). I checked, and the option to save prefs at exit is off. Has anyone else noticed this? If so I am going to inform MakeMusic. 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] Bug?
I found the same thing when i installed FIn2K7a, and mentioned it to tech support at MM to no avail. Also, I have enabled the software to make a copy when I do a save and directed it to a folder outside of the Finale folder) on a seperate drive on my Mac) and it repeatedly saved backup files in the Finale directory not to where I directed it to make the saves. I have had other issues (with part extraction and playback), so I have reverted back to 2K6 and am awaiting news from Native Instruments regarding their Konktakt 2 player update an am waiting to see what issues have been corrected in Fin2K7b before I install that. I can see from the user groups and this list that several people have had installation issues with the supposed fix (Fin2Kb). nevertheless, I have told Make Music that as far as I am concerned this release of Finale (2007 et al) has been a downgrade, not an upgrade. Unfortunately, it appears that I wil have to go through the aggravation of installed the new revisions as the occur until they get it right, but I can justify the time expenditure now while I can still keep working in 2K6 with no problems. The other thing I have done (maybe will complicate my life further, who knows) is requested that I be put on the list of Beta-testers for Make Music (Finale) so I can see what's coming next year and get a chance to give some feedback before they decide to ship an unfinished product again. I'm curious to hear if you are having any other issues with Fin2K7 and would like to hear from anyone else regarding the 2K7 downgrade. (Not to slam Make Music, but I think they have a great product and have been using it since the days of the Eskimo icons; I just find the practice of software companies to release upgrades that have not been bug-proofed is unconscienable, and they should wait until it's bug-free when they add new features to what's shipping. And they really need to avoid what appears to be a neck and neck race to the finish with Sibelius. I used Sibelius (2) at the request of a client a couple of years ago, and was greatly relieved to get it off my computer when the project was over (after 18 months of screaming at the brothers Finn.) Finale is the leader, Sibelius has struggled to catch up, and we will have to live with each other from this point on, but Finale should stay focused internally on their own product and build and re-design it according to a standard set higher than Sibelius' or for that matter, see their own internal bar higher and become the industry leader, hands down. (sort of like Apple has done) But Finale cannot accomplish that when they aggravate the shit out of their loyal users by shipping buggy stuff, and when time and time again I read comments from users who have given up on Make Music Tech support because they can't answer anything but very basic questions. This is where Finale will lose the notation wars, one skirmish at a time. I am forwarding a copy of this to Make Music for their review and comment, as I do not like running my mouth about anything without giving everyone equal time. Hope we all can find a solution amicably and expediently. Yesterday I installed the Finale 2k7b update, and I think I found as bug. Not a big one, but very annoying to my ways of working. Here is what I observed: Yesterday I had a lengthy session in Finale. Last night I closed and quit Finale, and I know for absolute certain that I did not save preferences. This morning I opened Finale, and it did not revert to my normal prefs, instead it kept the prefs from when I quit Finale last night. This included the current tool, the MIDI input device (my normal input device is none to avoid the error message at start up when it is missing). I checked, and the option to save prefs at exit is off. Has anyone else noticed this? If so I am going to inform MakeMusic. Johannes -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Bug?
Yesterday I installed the Finale 2k7b update, and I think I found as bug. Not a big one, but very annoying to my ways of working. Here is what I observed: Yesterday I had a lengthy session in Finale. Last night I closed and quit Finale, and I know for absolute certain that I did not save preferences. This morning I opened Finale, and it did not revert to my normal prefs, instead it kept the prefs from when I quit Finale last night. This included the current tool, the MIDI input device (my normal input device is none to avoid the error message at start up when it is missing). I checked, and the option to save prefs at exit is off. Has anyone else noticed this? If so I am going to inform MakeMusic. Johannes I can confirm that Finale 2007 (original flavour, a, and b) changes your settings preferences no matter if you have that option selected or not. I suppose you could lock your preferences file in the Finder. I get the feeling that this was supposed to be a feature enhancement and that MM didn't want all the settings to change. I don't mind opening a file with the same staff set that I left it in, but I agree, intentional changes in Finale behaviour should be documented and tested to make sure they darn well work. -Randolph Peters ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Bug?
On 08.02.2007 Randolph Peters wrote: I get the feeling that this was supposed to be a feature enhancement and that MM didn't want all the settings to change. I don't mind opening a file with the same staff set that I left it in, but I agree, intentional changes in Finale behaviour should be documented and tested to make sure they darn well work. I am not sure why this would be a feature enhancement. Randolph, I just realized that you are sending both a list message, and a personal message as your reply. There is no reason why I or anyone else would want two copies of the same message. This is the reason why Mark was confused about the reply to header recently. I certainly would prefer it if you switched this option off in your mail client. Thanks, 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] Bug?
In response to Johannes and Vern: I also experience this behavior in 2K7, though I find it only mildly annoying. There are other problems, and the communication with the support staff has deteriorated markedly since MM has gone to the web based system. It is not only mechanically more difficult to communicate, but the quality of the responses are sometimes dismally off the subject, requiring a request that they go back an reread the submission, so that they understand the question. This has happened too often to be an accident, and I can only conclude that the quality of the support staff has fallen. I have a problem loading a Document Options library (on a Mac). When I load a correctly (I believe) saved library, most of the font selections are lost - wrong fonts are substituted, requiring me to correct them and practically destroying the advantage of being able to load a Document Options Library. Has anyone else experienced this? Could it be some kind of corruption on my system? I thought that MM had acknowledged this (on the Mac side), but they now claim that they were referring to something else, and the communication with them has become so obtuse that I no longer know what's going on. Attempts to communicate with MM have become more frustrating than they are worth. Chuck Chuck Israels 230 North Garden Terrace Bellingham, WA 98225-5836 phone (360) 671-3402 fax (360) 676-6055 www.chuckisraels.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Bug?
On 08.02.2007 Chuck Israels wrote: I have a problem loading a Document Options library (on a Mac). When I load a correctly (I believe) saved library, most of the font selections are lost - wrong fonts are substituted, requiring me to correct them and practically destroying the advantage of being able to load a Document Options Library. Has anyone else experienced this? Could it be some kind of corruption on my system? I thought that MM had acknowledged this (on the Mac side), but they now claim that they were referring to something else, and the communication with them has become so obtuse that I no longer know what's going on. I had a similar problem recently with Robert's Settings Scrapbook. After copying the font settings from one Doc to another I suddently had random symbols onscreen (also after reloading the doc). I gave up and did the changes manually. Perhaps there is something wrong in the font handling in Finale? 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] Bug?
I also asked MM why any of the libraries I used/created in Fin2K6 would not load (Chord Symbols, Shape Expressions, Shapes, Articulations) in Fin2K7 but got no response to that question. Very frustrating, because I decided to use a new template (from 2K7) to work on a new piece (rather than what I have done in the past, which is: open an older template that I had customized). SO, I opened up a new 2K7 template, modified and tried to load my customized libraries, and none of them loaded. It just blinked at me when I said Open Library and I'd go to check to see if the corresponding items were now updated, and see no changes. The reason I was using Fin2K7 template was I had major problems with the playback features (using Garritan) when I opened a Finale doc that had been created in an earlier version that 2K7. (dynamics would not affect some staves, including hairpins, score and note expressions would have no impact on the dynamic levels on various staves, even when I deleted the existing symbols and replaced them, even when I reset the Velocity of the entire staff using the midi tool; etc.; I even tried re-entering some of the music to see if that helped. MM did not address these issues in my tech request and I gave up asking, and I gave up using 2K7.) NOTE: I am using a Mac G5 Dual Core 2.0 Ghz with 5.5 GB of ram, and this is the same machine I have been using Fin2K5 and 2K6 on with no issues. In response to Johannes and Vern: I also experience this behavior in 2K7, though I find it only mildly annoying. There are other problems, and the communication with the support staff has deteriorated markedly since MM has gone to the web based system. It is not only mechanically more difficult to communicate, but the quality of the responses are sometimes dismally off the subject, requiring a request that they go back an reread the submission, so that they understand the question. This has happened too often to be an accident, and I can only conclude that the quality of the support staff has fallen. I have a problem loading a Document Options library (on a Mac). When I load a correctly (I believe) saved library, most of the font selections are lost - wrong fonts are substituted, requiring me to correct them and practically destroying the advantage of being able to load a Document Options Library. Has anyone else experienced this? Could it be some kind of corruption on my system? I thought that MM had acknowledged this (on the Mac side), but they now claim that they were referring to something else, and the communication with them has become so obtuse that I no longer know what's going on. Attempts to communicate with MM have become more frustrating than they are worth. Chuck Chuck Israels 230 North Garden Terrace Bellingham, WA 98225-5836 phone (360) 671-3402 fax (360) 676-6055 www.chuckisraels.com ___ 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] Bug?
Hi Johannes, Did you report this to MM? I am going to try once again to contact Jim Bruce and see if I can get some satisfaction - at least the acknowledgment of the existence of the problem. I keep telling them about this, and they are passing it off as an anomaly of my system. Other people reporting this difficulty will at least support my communications. Thanks, Chuck On Feb 8, 2007, at 8:41 AM, Johannes Gebauer wrote: On 08.02.2007 Chuck Israels wrote: I have a problem loading a Document Options library (on a Mac). When I load a correctly (I believe) saved library, most of the font selections are lost - wrong fonts are substituted, requiring me to correct them and practically destroying the advantage of being able to load a Document Options Library. Has anyone else experienced this? Could it be some kind of corruption on my system? I thought that MM had acknowledged this (on the Mac side), but they now claim that they were referring to something else, and the communication with them has become so obtuse that I no longer know what's going on. I had a similar problem recently with Robert's Settings Scrapbook. After copying the font settings from one Doc to another I suddently had random symbols onscreen (also after reloading the doc). I gave up and did the changes manually. Perhaps there is something wrong in the font handling in Finale? Johannes -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale Chuck Israels 230 North Garden Terrace Bellingham, WA 98225-5836 phone (360) 671-3402 fax (360) 676-6055 www.chuckisraels.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Bug?
On 08.02.2007 Chuck Israels wrote: Did you report this to MM? Well, no, because it actually happened when using Settings Scrapbook. 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] Bug?
On 08.02.2007 [EMAIL PROTECTED] wrote: I also asked MM why any of the libraries I used/created in Fin2K6 would not load (Chord Symbols, Shape Expressions, Shapes, Articulations) in Fin2K7 but got no response to that question. Well, this is old news. To get your libraries updated, load them in into a document without libraries in 2k6, save a .mus file. Load that into 2k7b and save the libraries. This has been the same since Finale existed. Libraries were never compatible with newer versions, or were they? 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] Bug?
I also had problems loading my spacing libraries into 2K7 - nothing would load - MM couldn't explain it either, but they said they would look at it. The work-around for me was to use 2K6, load the library items into a blank file. Open that file with 2K7, then make a library - in my case a music spacing library - and that library file now is readable by any 2K7 file hope this helps, Thomas Schaller On Feb 8, 2007, at 10:44 AM, [EMAIL PROTECTED] wrote: I also asked MM why any of the libraries I used/created in Fin2K6 would not load (Chord Symbols, Shape Expressions, Shapes, Articulations) in Fin2K7 but got no response to that question. Very frustrating, because I decided to use a new template (from 2K7) to work on a new piece (rather than what I have done in the past, which is: open an older template that I had customized). SO, I opened up a new 2K7 template, modified and tried to load my customized libraries, and none of them loaded. It just blinked at me when I said Open Library and I'd go to check to see if the corresponding items were now updated, and see no changes. The reason I was using Fin2K7 template was I had major problems with the playback features (using Garritan) when I opened a Finale doc that had been created in an earlier version that 2K7. (dynamics would not affect some staves, including hairpins, score and note expressions would have no impact on the dynamic levels on various staves, even when I deleted the existing symbols and replaced them, even when I reset the Velocity of the entire staff using the midi tool; etc.; I even tried re-entering some of the music to see if that helped. MM did not address these issues in my tech request and I gave up asking, and I gave up using 2K7.) NOTE: I am using a Mac G5 Dual Core 2.0 Ghz with 5.5 GB of ram, and this is the same machine I have been using Fin2K5 and 2K6 on with no issues. In response to Johannes and Vern: I also experience this behavior in 2K7, though I find it only mildly annoying. There are other problems, and the communication with the support staff has deteriorated markedly since MM has gone to the web based system. It is not only mechanically more difficult to communicate, but the quality of the responses are sometimes dismally off the subject, requiring a request that they go back an reread the submission, so that they understand the question. This has happened too often to be an accident, and I can only conclude that the quality of the support staff has fallen. I have a problem loading a Document Options library (on a Mac). When I load a correctly (I believe) saved library, most of the font selections are lost - wrong fonts are substituted, requiring me to correct them and practically destroying the advantage of being able to load a Document Options Library. Has anyone else experienced this? Could it be some kind of corruption on my system? I thought that MM had acknowledged this (on the Mac side), but they now claim that they were referring to something else, and the communication with them has become so obtuse that I no longer know what's going on. Attempts to communicate with MM have become more frustrating than they are worth. Chuck Chuck Israels 230 North Garden Terrace Bellingham, WA 98225-5836 phone (360) 671-3402 fax (360) 676-6055 www.chuckisraels.com ___ 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 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Bug?
At 07:58 -0800 2/8/07, Chuck Israels wrote: the communication with the support staff has deteriorated markedly since MM has gone to the web based system. It is not only mechanically more difficult to communicate, but the quality of the responses are sometimes dismally off the subject... have you considered submitting a complaint through MM support? (snark snark) seriously though i did look once, and i don't recall seeing anywhere for customer feedback or something. -- shirling neueweise ... new music publishers mailto:[EMAIL PROTECTED] :.../ http://newmusicnotation.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Bug?
Hi Jef, There is a place for feedback, but I am now in phone communication with the head of customer support at MM (Jim Bruce), a non-technical guy who is attempting to get the tech people (specifically the Mac guys) to respond to this library issue and the mishandling of fonts. I hope I will get their attention. I am trying to communicate in a courteous and friendly way in order to help us help MM help us (ABA - hn). Jim says they are working on a much improved web based system of communication to be implemented later this year. I'm glad to hear it, because this one is clumsy, to say the least. Jim says they get 4,000 web requests and 15,000 phone calls a month! Maybe fixing bugs would reduce some of that load. Chuck On Feb 8, 2007, at 9:24 AM, shirling neueweise wrote: At 07:58 -0800 2/8/07, Chuck Israels wrote: the communication with the support staff has deteriorated markedly since MM has gone to the web based system. It is not only mechanically more difficult to communicate, but the quality of the responses are sometimes dismally off the subject... have you considered submitting a complaint through MM support? (snark snark) seriously though i did look once, and i don't recall seeing anywhere for customer feedback or something. -- shirling neueweise ... new music publishers mailto:[EMAIL PROTECTED] :.../ http://newmusicnotation.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale Chuck Israels 230 North Garden Terrace Bellingham, WA 98225-5836 phone (360) 671-3402 fax (360) 676-6055 www.chuckisraels.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Bug?
Johannes Gebauer / 2007/02/08 / 12:21 PM wrote: This has been the same since Finale existed. Libraries were never compatible with newer versions, or were they? Well, my chord lib is fairly complicated, which I just load it up when I get new Finale versions. I delete the entire chord lib on the new Maestro Default file first, tho. I am grateful now I can select multiple chord objects to delete them all at once. This wasn't possible before. When did I first create this chord lib? Fin97? Fin3.2? Or was it Fin2.6? Anyway, the only problem I have had doing this is that assigned MIDI pattern gets screwed so I have to re-teach it. -- - Hiro Hiroaki Honshuku, A-NO-NE Music, Boston, MA http://a-no-ne.com http://anonemusic.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Bug?
On Feb 8, 2007, at 11:21 AM, Johannes Gebauer wrote: On 08.02.2007 [EMAIL PROTECTED] wrote: I also asked MM why any of the libraries I used/created in Fin2K6 would not load (Chord Symbols, Shape Expressions, Shapes, Articulations) in Fin2K7 but got no response to that question. Well, this is old news. To get your libraries updated, load them in into a document without libraries in 2k6, save a .mus file. Load that into 2k7b and save the libraries. This has been the same since Finale existed. Libraries were never compatible with newer versions, or were they? they always were compatible. Until 2K7 I was using my 2004 libraries. Thomas Schaller ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Bug?
I only recall one earlier version (long ago) where Finale libraries wouldn't translate, and the documentation was very clear on this point: I think it was around the time that MacIntosh moved from Sys software 6.x to 7.0. But, I have been nigrating libraries since Finale 2002 with no issues. On 08.02.2007 [EMAIL PROTECTED] wrote: I also asked MM why any of the libraries I used/created in Fin2K6 would not load (Chord Symbols, Shape Expressions, Shapes, Articulations) in Fin2K7 but got no response to that question. Well, this is old news. To get your libraries updated, load them in into a document without libraries in 2k6, save a .mus file. Load that into 2k7b and save the libraries. This has been the same since Finale existed. Libraries were never compatible with newer versions, or were they? Johannes -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Bug?
On 08.02.2007 Thomas Schaller wrote: they always were compatible. Until 2K7 I was using my 2004 libraries. Sorry, my bad, you are correct. 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] Bug?
Chuck Israels / 2007/02/08 / 01:24 PM wrote: Jim says they are working on a much improved web based system of communication to be implemented later this year. I'm glad to hear it, because this one is clumsy, to say the least. Jim says they get 4,000 web requests and 15,000 phone calls a month! Maybe fixing bugs would reduce some of that load. Will you recommend this support system to them? http://www.rightnow.com/ I know this company since early days which was started by a few genius kids in Colorado. Now a lot of companies, big and small, use this system. Their customer list even doesn't show small companies like Kensington and Steinberg (Pinnacle). They charge less for small business. I help administrate one of them, and it is probably the best supporting system exists for quite sometime. -- - Hiro Hiroaki Honshuku, A-NO-NE Music, Boston, MA http://a-no-ne.com http://anonemusic.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Bug?
Hi Hiro, That is exactly the system Jim said they would be implementing. MM doing something right, at least the second time around! Thanks - and warm regards, Chuck On Feb 8, 2007, at 11:05 AM, A-NO-NE Music wrote: Chuck Israels / 2007/02/08 / 01:24 PM wrote: Jim says they are working on a much improved web based system of communication to be implemented later this year. I'm glad to hear it, because this one is clumsy, to say the least. Jim says they get 4,000 web requests and 15,000 phone calls a month! Maybe fixing bugs would reduce some of that load. Will you recommend this support system to them? http://www.rightnow.com/ I know this company since early days which was started by a few genius kids in Colorado. Now a lot of companies, big and small, use this system. Their customer list even doesn't show small companies like Kensington and Steinberg (Pinnacle). They charge less for small business. I help administrate one of them, and it is probably the best supporting system exists for quite sometime. -- - Hiro Hiroaki Honshuku, A-NO-NE Music, Boston, MA http://a-no-ne.com http://anonemusic.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale Chuck Israels 230 North Garden Terrace Bellingham, WA 98225-5836 phone (360) 671-3402 fax (360) 676-6055 www.chuckisraels.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Bug?
On 8-Feb-07, at 11:44 AM, [EMAIL PROTECTED] wrote: I also asked MM why any of the libraries I used/created in Fin2K6 would not load (Chord Symbols, Shape Expressions, Shapes, Articulations) in Fin2K7 but got no response to that question. A little-known and often-overlooked feature that the support staff seem to be unaware of: libraries can stop working from version to version, and furthermore they are NOT cross-platform (PC to Mac). The best thing to do is to load them into an empty 2006 document, save, then open the document in 2007 and save the libraries from there. Christopher ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Bug?
Chuck Israels wrote: Attempts to communicate with MM have become more frustrating than they are worth. I know! I report serious bugs to try and make the program better, but I get the feeling that MM doesn't even read my messages. My last report has been going back and forth for 3 weeks and the responses are getting stranger and stranger. -Randolph Peters ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
[Finale] bug with split-measure and mid-measure repeats plug-ins
I ran accidentally into this bug today. I needed to use the split measure plug-in in a part to split an unmeasured bar that was too long. Later I noticed that the last measure of the part was gone! Here are the steps (100% reproducible for me):A few bars before the last one, select one measure and apply the split measure plug-in (plug-ins --measure--split-measure). Contemplate the last measure as it vanishes. Same result with the Mid-measure repeat plug-in.I suspect that it has something to do with the sometimes unpredictable behavior of the include in measure numbering feature that was added in 2006. I thought it had been worked out in 2007 but I am not sure anymore.Anyone else has experimented that?Éric Dussault___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Bug Report: Blank Notation Tuplet Bug
Hi Darcy, I have had similar strangeness in 2006 with applying blank notation to beamed tuplets. In my template, beams and tuplet numbers disappear resulting in single notes and stems throughout the measure (no tuplet numbers visible anymore). Is this the same thing you are describing? Hmm... -K On Jan 8, 2006, at 9:11 PM, Darcy James Argue wrote: Applying blank notation to a group of beamed (unbracketed) tuplets causes tuplet brackets to appear. FinMac2006c. - Darcy - [EMAIL PROTECTED] http://homepage.mac.com/djargon 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
[Finale] Bug Report: Blank Notation Tuplet Bug
Applying blank notation to a group of beamed (unbracketed) tuplets causes tuplet brackets to appear. FinMac2006c. - Darcy - [EMAIL PROTECTED] http://homepage.mac.com/djargon Brooklyn, NY ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Bug report - Slurs between layers between systems -2006PC (REPOST)
Customer support also has the wonderful task of processing orders and taking questions on the new product. There's always a bit of a deluge whenever we release a product that's a popular seller. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of dhbailey Sent: Friday, October 28, 2005 3:42 PM To: finale@shsu.edu Subject: Re: [Finale] Bug report - Slurs between layers between systems -2006PC (REPOST) Shouldn't that be the shipping department, though? Thanks for keeping us posted -- I was genuinely wondering what was up. David H. Bailey Fisher, Allen wrote: Last I checked, power's on. (Unless I'm just such a bright-shining beacon light in the evil world of software development :-) ) They're just really busy because we just started shipping PrintMusic. On 10/28/05 12:50 PM, dhbailey [EMAIL PROTECTED] said this: Matthew Van Brink wrote: Hi, Finale People! Just sent this bug report to winsupport -- I *assume* it's a bug ... but please let me know if I've missed something obvious in the program options, etc. *** Good morning! Just discovered this disturbing bug, easily replicated: * Finale2006 PC * for two subsequent systems * create a slur between a note in layer1 in the first system to a note in layer2 in the second system * the slur does not appear on the first system, only on the bottom system. I guess I have to go back to using Finale2005 so that I'm not wasting my time making imperfect scores in Finale2006 :( Okay, thanks for taking care of this promptly. ~matt van brink [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Do let us know when you get a response from the dear folks at winsupport -- I sent a message (actually 2, since I forgot to attach a file to the first message) at around 8am, Eastern Daylight Time, Wednesday the 26th and haven't even gotten a we're too busy to contact you personally yet so this is generated by a robot so you don't think we're ignoring you -- please stand by and we'll get to you eventually reply yet. Maybe Minnesota was hit by the hurricanes and power's out there, too? ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale -- David H. Bailey [EMAIL PROTECTED] ___ 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] Bug report - Slurs between layers between systems -2006PC (REPOST)
At 10/31/2005 11:38 AM, Fisher, Allen wrote: Customer support also has the wonderful task of processing orders and taking questions on the new product. There's always a bit of a deluge whenever we release a product that's a popular seller. Wow! I never heard of customer support also doing anything with new orders. I thought they were supporting current customers? Seems arcane, to me. Phil Daley AutoDesk http://www.conknet.com/~p_daley ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Bug report - Slurs between layers between systems -2006PC (REPOST)
At 10/31/2005 01:07 PM, Fisher, Allen wrote: They do that as well, but current customers include not only current users with technical questions, but dealers, folks upgrading and wanting to know what's new, taking orders, etc. Taking orders? I just went down and talked to my customer support person. I said, What if a customer called and was complaining about a bug in Version X and you told him it was fixed in Version Y? And then the customer says, OK, I'd like to buy Version Y. The answer is, call your local dealer, or order it on the e-store. Customer support NEVER takes orders for product. Customer support is not the sales organization. Phil Daley AutoDesk http://www.conknet.com/~p_daley ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Bug report - Slurs between layers between systems - 2006PC
On Oct 28, 2005, at 3:08 PM, Lon Price wrote: How about in a piano part, where in one measure a note needs to be in layer 2, but there's no need to do layers in the next measure--all notes are layer 1. This happens to me all the time when writing piano music, and so far this bug hasn't bitten me, but I'll on the lookout for it in the future. In that case I expect I'd want all the notes in the second measure to be in layer 2. For me, no need to do layers does not automatically translate into layer 1. I'm curious about how others do this. Do you always use layer 1 if there's no second layer? For example, suppose you've got a piano piece with a bass part that has a persistent bass note keeping the beat throughout the piece, and in addition to that there are occasional melody fragments above that but still in the bass clef. Would you use layer 1 for measures which have only the low notes? That seems weird to me. If something is obviously a single music line or motif, I want to keep it in the same layer, not bounce it around based on whether there are notes above it or below it. I like making my layers match the internal logic of the music. Even if the printed page looks exactly the same whether a note is in layer 1 or layer 2, I'll always put them all in the right layer just because it pleases my sense of correctness. Perhaps this is correlated to, um, other respects in which David F and I have a similar attitude. I don't know if it has ever made a difference on layers specifically, but I can think of several examples -- in Finale and elsewhere -- where the general philosophy of setting things up properly the first time even if it makes no difference in the result for the immediate output, has saved me headaches down the road when something needs to be changed. Anyway, I think we all agree that Finale *should* be able to draw the slur properly, but as bugs go this is a pretty easy one to get around, isn't it? How hard is it to swap the notes into the right layers to make it draw right? Even if you're haphazard about your layers in normal practice, it's a simple matter to fix it when you get a buggy slur. If it's an simple fix, fine, but if addressing this bug eats up time resources for MakeMusic, I can think of plenty of other bugs that are much harder to kludge around. mdl ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
