Re: Reality check (Was Re: [Finale] Re: Tuplet bug in Fin2005 demo)
William Roberts wrote: I pay money for my Finale upgrades because they contain features that I want, and that will save me time. I don't expect my software to be bug-free -- I'm far too realistic for that. But provided it's quicker for me to use Finale than it is to use a pencil and paper, and provided I'm not constantly fighting against bugs in the software, then hey, I'm happy. But perhaps I'm just not as passionate/crazy as you, David! Best, -WR Moi? Passionate? Crazy? Could be. Could be just that sometimes things rub me the wrong way and I get all bent out of shape unnecessarily. Ultimately, the company doesn't care as long as we give them the money, which I do with each upgrade because I, too, find it better and easier to get results with the software than without it. I also know that there isn't any alternative, and the software industry knows that as well. There's no way I can produce engraved output without my computer, and there's no way Sibelius or any other software product I am aware of can give me the quality of output that Finale gives me, nor the control over that printed output that Finale gives me. Doesn't mean I won't get upset when they say "We know it's a bug and we're not going to fix it." But they know I don't have a choice either. Maybe that's what galls me the most. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: Reality check (Was Re: [Finale] Re: Tuplet bug in Fin2005 demo)
David Bailey wrote: > So because nobody does it, we shouldn't expect it? That's not what I'm saying. What I'm saying is that MakeMusic and Sibelius could both be worse. They could simply not acknowledge complaints made by their customers, just as huge corporations like Microsoft and Adobe do. You'd blast them for that, too. And isn't it better that MakeMusic acknowledge the problems their users are having than it would be if they ignored them? It seems to me that you're far too hung up on the particular phraseology of a response from a tech support person, probably dashed off in a real hurry when he or she has another hundred or more emails to deal with. I'm not misguided enough to suppose that I know everything that goes on inside a commercial organisation. I don't know why a particular bug might get fixed or might not get fixed, or what all the factors might be in the decision. But I do feel a lot better knowing that the bug is known about, and that the company acknowledge its existence. After all, the first step to a bug being fixed is a bug being found! > Just because the software industry sucks in its response to consumer > problems and complaints and refuses to acknowledge that it markets > flawed producst, we shouldn't bother to complain? That's not what I'm saying, and you know it. What I mean is that we, as customers, should pick our battles. And ultimately the only way we can truly register our displeasure is to vote with our dollars: if we complain but still buy the product anyway, the company won't see it as a contribution to a "please don't go out of business" fund (after all, is this a business or a charity we're talking about here?). They'll see it as somebody liking the upgrade enough to put the money down for it. We're definitely sending mixed messages as consumers if we say, "We don't like the way you do business, but we're going to pay you anyway!" I pay money for my Finale upgrades because they contain features that I want, and that will save me time. I don't expect my software to be bug-free -- I'm far too realistic for that. But provided it's quicker for me to use Finale than it is to use a pencil and paper, and provided I'm not constantly fighting against bugs in the software, then hey, I'm happy. But perhaps I'm just not as passionate/crazy as you, David! Best, -WR -- ___ Find what you are looking for with the Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10 ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
At 07:58 AM 08/23/2004, Jari Williamsson wrote: >The bug has nothing to do with rests specifically - it has to do with >the angle of the calculated bracket slope, and to the bracket/number >compensation for steep angles. >Entering the last tuplet on the topmost example on MM's web page >triggers the same bug as you're experiencing. Okay, fair enough -- although I've already uninstalled the demo, so I'll take your word for it. This actually makes the bug more troublesome than I originally thought, since it affects more tuplets. Thanks, Aaron. ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
Aaron Sherber writes: > Those examples show only one tuplet which begins with a rest, and that > tuplet has the interval of only a second. In the examples I posted, the > vertical discrepancy varied according to the interval of the remaining > notes, and tuplets that start with a rest and then have a second or a third > look fine as well. The bug has nothing to do with rests specifically - it has to do with the angle of the calculated bracket slope, and to the bracket/number compensation for steep angles. Entering the last tuplet on the topmost example on MM's web page triggers the same bug as you're experiencing. Best regards, Jari Williamsson ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
At 06:41 AM 08/23/2004, Jari Williamsson wrote: >Compare the examples on that page with what you get in the same >situations in the release version and you'll see that the bug appeared >AFTER the build the marketing people were using. Those examples show only one tuplet which begins with a rest, and that tuplet has the interval of only a second. In the examples I posted, the vertical discrepancy varied according to the interval of the remaining notes, and tuplets that start with a rest and then have a second or a third look fine as well. >"Since the tuplet >enhancements are my single reason for upgrading, will you still give >me the early-bird discount when I have been confirmed that the >maintenance release works as expected?" Ahh ... that's the part of the question I didn't ask -- but I'll do so now! Thanks, Aaron. ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: Reality check (Was Re: [Finale] Re: Tuplet bug in Fin2005 demo)
William Roberts wrote: David Bailey wrote: But they're just as bad at not fixing long-standing bugs that some users have been complaining about for a long time as well as introducing new bugs and saying "we'll try to fix it in a future upgrade." So that rather than the two companies really goading each other into offering superior products to each other, instead they seem to be matching each other in corporate attitude. Quick reality check, before all this bitching and moaning makes us lose our perspective altogether: how many software companies have you dealt with who will actually directly acknowledge a bug to you, and tell you that they'll try to fix it in a future upgrade? And how many commercial software companies have you dealt with who will ship a patched version just to fix a single problem? Have you ever got an acknowledgement from a human being at Microsoft about a bug in Word, say? Or from a human being at Adobe about a bug in Acrobat Reader? Or from a human being at Macromedia about a bug in Shockwave? So because nobody does it, we shouldn't expect it? Do you agree with your children when they say "Everybody's doing it, so I should be able to, also!" when the behavior is something you find to be either bad or improper? Don't you ever tell them that you expect BETTER from them? Just because the software industry sucks in its response to consumer problems and complaints and refuses to acknowledge that it markets flawed producst, we shouldn't bother to complain? Wow, I never would have thought about it that way. Interesting point of view. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
Aaron Sherber writes: > I have a hard time believing that this is a bug that > came up late in the beta cycle. If I had to guess, I'd say it come up > fairly early, but they realized they couldn't fix it and still ship on > time. OK, I'll going to give you that hard time... Look at: http://www.finalemusic.com/finale/features/new/engraver.asp Compare the examples on that page with what you get in the same situations in the release version and you'll see that the bug appeared AFTER the build the marketing people were using. I personally find all the speculating in this and a couple of other threads a bit useless, since it doesn't raise the interesting questions. Here's a question that I haven't seen mentioned/answered: What was the answer from customer support when you told them "I tested the Fin2005 demo, and the Enhanced Tuplet feature does not work as advertised (for example compared to your web page), which has also been confirmed by tech support. I assume that you fix this soon in a maintenance release. Since the tuplet enhancements are my single reason for upgrading, will you still give me the early-bird discount when I have been confirmed that the maintenance release works as expected?" What was their answer? Best regards, Jari Williamsson ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: Reality check (Was Re: [Finale] Re: Tuplet bug in Fin2005 demo)
At 01:16 PM 8/22/04 -0500, William Roberts wrote: >Quick reality check >how many software companies have you dealt with >who will actually directly acknowledge a bug to you, >and tell you that they'll try to fix it in a future upgrade? Top of my head... Cakewalk (when they hosted a news server; they may still, but I don't use their web forum) Systran (issued a patch immediately after I found a bug last week in their new version 5) Qbik (issued a patch 48 hours after I found two bugs last week in their new version 6) Opera (they maintain a public bug list and post patches regularly) I would have said Syntrillium, but I never found a bug in Cool Edit Pro. Adobe's got it now, so who knows. >Have you ever got an acknowledgement from a human >being at Microsoft about a bug in Word, say? Or from a >human being at Adobe about a bug in Acrobat Reader? >Or from a human being at Macromedia about a bug in >Shockwave? Umm... Finale is still at the 'personal' level. If they can't acknowledge an issue, who will? Oh, right. The companies I mentioned above. :) Dennis ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Reality check (Was Re: [Finale] Re: Tuplet bug in Fin2005 demo)
David Bailey wrote: > But they're just as bad at not fixing long-standing bugs > that some users have been complaining about for a long time as well as > introducing new bugs and saying "we'll try to fix it in a future upgrade." > > So that rather than the two companies really goading each other into > offering superior products to each other, instead they seem to be > matching each other in corporate attitude. Quick reality check, before all this bitching and moaning makes us lose our perspective altogether: how many software companies have you dealt with who will actually directly acknowledge a bug to you, and tell you that they'll try to fix it in a future upgrade? And how many commercial software companies have you dealt with who will ship a patched version just to fix a single problem? Have you ever got an acknowledgement from a human being at Microsoft about a bug in Word, say? Or from a human being at Adobe about a bug in Acrobat Reader? Or from a human being at Macromedia about a bug in Shockwave? If so, I want email addresses and/or phone numbers! Now I'm not saying that we should all fall on our knees and worship either Coda or Sibelius for acknowledging that there are problems with their programs -- but in the land of software companies, it seems we could be a lot worse off. A while back I read a fascinating article about the kinds of things that go on in software companies when dealing with bugs. I looked it up for you and recommend http://headblender.com/joe/blog/archives/microsoft/001280.html Best, -WR -- ___ Find what you are looking for with the Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10 ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
Hi Aaron, Yes, I see what you mean: the larger the intervals get, the more the number seems to pull away from the bracket; a black eye for Enhanced Tuplets. However, if you are doing a piece with mostly linear tuplet passages, I think things will look fairly reasonable, with less fussing than before 5K. Since this is one of only 3 features that I will find useful this time around, it would be nice if it worked perfectly! Dan Carno At 06:58 PM 8/21/2004, you wrote: At 03:00 PM 08/21/2004, Dan Carno wrote: >We may be talking about different things here, but when I enter an eighth >note tuplet, with the first note a rest, and do not edit it, I have a >reasonable centered number (vertically & horizontally) relative to the >bracket. But look at http://files.aaron.sherber.com/tuplet.gif The problem is more apparent when you have several of these tuplets with different intervals -- the number is positioned vertically different from the bracket. Or enter just one tuplet, with the two notes an octave apart, and you'll see that the number is not in the correct vertical position. Aaron. ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale Daniel Carno Music Engraving Services Quality work in Sibelius, Finale, and Score 4514 Makyes Road Syracuse, New York 13215 (315) 492-2987 [EMAIL PROTECTED] ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
At 03:00 PM 08/21/2004, Dan Carno wrote: >We may be talking about different things here, but when I enter an eighth >note tuplet, with the first note a rest, and do not edit it, I have a >reasonable centered number (vertically & horizontally) relative to the >bracket. But look at http://files.aaron.sherber.com/tuplet.gif The problem is more apparent when you have several of these tuplets with different intervals -- the number is positioned vertically different from the bracket. Or enter just one tuplet, with the two notes an octave apart, and you'll see that the number is not in the correct vertical position. Aaron. ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
Dan Carno wrote, in part: Enhanced tuplets work OK, unless you edit one by dragging one of the notes (or changing one into a chord), in which case you will have to edit the number position. I would rather do this until a fix comes along than deal with the mess that pre-Fin 2005 tuplets present. to which I responded: As soon as FIN 2k5 is installe, I mean to explore what happens, if after making the corrections, one selects the tuplet tool, deletes the tuplet, and then recreates the same tuplet. I have now done this, and I find that when one deletes the tuplet after changes have been made, and recreates it using the tuplet dialog box, the appearance between the two is the same. ns ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
David, most of the time I would be in agreement with the position you define when you wrote: As for your comments on the tech-personnel's position in the heirarchy at MakeMusic, as the ONLY interface for the end user after we give our credit card number to consummate the sale, it is terrible organization if the tech support personnel don't have inside knowledge to all that is going on in the development chain. To have one's interface with one's customers not be able to give knowledgeable answers should be unthinkable. What kind of support can they really give, other than rote recitation of what's printed in their notebooks? That's probably why most of us ask questions here before contacting tech support! I'm willing to cut MakeMusic! extra slack this week because I assume that shipping the new product for both FIN and MAC has displaced normal routine for people in Tech support, and the members of the design team, and in two weeks or a month, I will also look for a more thorough answer, though my different view of what exactly the problem is still allows the remote possibility of the answer "that's becasue of vendor supplied code over which we have no direct control" at that time. As far as Tech support being able to give knowledgeable answers, well, in order to give it, they first have to have it to give, and I'm not sure the answer to this issue has been worked out yet, beyond, "it's a known issue, we're working on it, and if possible we'll get it fixed as soon as possible". Again, not necessarily the answer I want, and not the answer I'm going to accept long term, but for me, I'm willing to buy it as the answer in the short term. And for what it's worth, Tech support is not the only interface for the end user personnel. As a public company, the names of the corporate officers are matters of public record, and a bit of research on the website can get a name from which one can extract an email address, and interface with them, if need be. I haven't the need at this point. ns ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
Hi Aaron, We may be talking about different things here, but when I enter an eighth note tuplet, with the first note a rest, and do not edit it, I have a reasonable centered number (vertically & horizontally) relative to the bracket. Now I have to admit, under magnification, the center "tine" of the 3 does seem a hair under the horizontal bracket lines, and there doesn't seem to be a setting to adjust this, but I don't consider this much of a liability considering the positive things in the Enhanced tuplet feature. Like Sam Johnson's flying Dog, I can't complain much that it didn't stay up all that long. Dan Carno At 10:25 AM 8/21/2004, you wrote: At 10:05 AM 08/21/2004, Dan Carno wrote: >Am I missing something here? Enhanced tuplets work OK, unless you edit one >by dragging one of the notes (or changing one into a chord), in which case >you will have to edit the number position. It's not just a matter of dragging or changing. If you create a tuplet where the first note is a rest, the vertical position of the number seems to be determined independently of the position of the bracket. My original post involved dragging because that's an easy way to watch the number move apart from the bracket, but the spacing problem is there even if you just create the tuplet directly. Aaron. ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale Daniel Carno Music Engraving Services Quality work in Sibelius, Finale, and Score 4514 Makyes Road Syracuse, New York 13215 (315) 492-2987 [EMAIL PROTECTED] ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
On 21 Aug 2004, at 12:24 PM, Robert Patterson wrote: A more important concern I would have is that if you take all the trouble to manually edit your numeral positions, what happens if they *do* fix the bug in the maintenance release? I'm guessing you'll have to then go and remove all you painstaking manual edits. But that's easy -- in Fin 2005, there is an option to reset all tuplets (or all tuplets in selected measures). If necessary, you can also do it on a case-by-case basis by right-clicking the tuplet handle and choosing "Reset" from the contextual menu. - Darcy - [EMAIL PROTECTED] Brooklyn, NY ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
Noel Stoutenburg wrote: [snip] Further, thinking back on my own experiences, there have meen more times than I want to admit to when some problem occurred, and looking back, I cannot come up with a single good reason for not seeing the problem developing. I'm in no position to do anything but accept that there might be such issues for other people, and this might be one of those.. Fair enough -- I hadn't thought of that possibility, and it may have accrued through fixing other problems at the last minute, totally unrelated. I can accept that. As for your comments on the tech-personnel's position in the heirarchy at MakeMusic, as the ONLY interface for the end user after we give our credit card number to consummate the sale, it is terrible organization if the tech support personnel don't have inside knowledge to all that is going on in the development chain. To have one's interface with one's customers not be able to give knowledgeable answers should be unthinkable. What kind of support can they really give, other than rote recitation of what's printed in their notebooks? That's probably why most of us ask questions here before contacting tech support! -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
I snipped and rearranged from what David wrote to first answer:\ The tech-support reply that Aaron received, however, indicates that they knew about the bug. The reply didn't contain any "Oh my goodness, we've never seen that before -- we'll start working on it right now to fix it in the patch." Instead it was more along the lines of we'll try to fix it by the time the patch will be released. Why not hold up the patch until the damn bug is fixed? Well, since we do not know where on the organizational chart the tech support rep is sitting, we don't really know how to evaluate how much he knows. Since I don't know that he's high enough up the organizational chart to sit on the design committee, I'm going to assume 1) that the author of the email that Aaron received is not high enough on the organizational chart to make any promises about what priorities are assigned to what issues, and would be overstepping the limits of his duties to make any promises about whether or a particular bug can be fixed, or when it will be; 2) that fixing the issue is more complex than it seems to the end user, because it involves redesign at a fairly low level in the software, and at the moment, in the press of getting the software product shipped, that the design committee is on temporary hiatus, but will take this issue up at their next meeting; 3) that there is some chance that some of the software involved in the this issue is product purchased from an outside vendor, and that if this purchased product is any part of the problem, that MakeMusic has no direct control over when the problem might be resolved; 4) a request for further information on this issue in a week or two will result in more detailed information. As to David's comment, I find it hard to believe that NOBODY in the entire process, from developpers to alpha-testers to beta-testers never ever tried to move a note using enhanced tuplets or to begin a tuplet with a rest. Neither scenario, they knew about the enhanced tuplet bug and shipped anyway or none of their testing actually edited the enhanced tuplets, is a pleasant one. I don't find it hard to believe that nobody discovered this problem, for a variety of reasons. I can think of any number of reasons why the bug might not have been discovered, one of which is that this is an issue which arose as an unintended collateral consequence of resolving a problem in a related subsystem, during one of the last builds before deciding to release the product to the market. There may have been no way given available resources to resolve this issue and solve the earlier (and more serious) issue . Or the problem may be in code Finale has licensed, but which they have no direct control over to allow the bug to be fixed. Further, thinking back on my own experiences, there have meen more times than I want to admit to when some problem occurred, and looking back, I cannot come up with a single good reason for not seeing the problem developing. I'm in no position to do anything but accept that there might be such issues for other people, and this might be one of those.. NS ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
Noel Stoutenburg wrote: As soon as FIN 2k5 is installe, I mean to explore what happens, if after making the corrections, one selects the tuplet tool, deletes the tuplet, and then recreates the same tuplet. I can assure you that any changes you have made will be lost in this case. It is no different in current versions. "Enhanced" just means that those tuplets have a default behavior that is different (and much more complex) than the current default behavior. Any manual edits are stored with the tuplet as offsets from the default. I know this for a fact. (This is Tuplet Mover's nightmare world.) A more important concern I would have is that if you take all the trouble to manually edit your numeral positions, what happens if they *do* fix the bug in the maintenance release? I'm guessing you'll have to then go and remove all you painstaking manual edits. This is one reason why I, as I've already said, never use a first release for real work. -- Robert Patterson http://RobertGPatterson.com ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
Dan Carno wrote, in part: Enhanced tuplets work OK, unless you edit one by dragging one of the notes (or changing one into a chord), in which case you will have to edit the number position. I would rather do this until a fix comes along than deal with the mess that pre-Fin 2005 tuplets present. As soon as FIN 2k5 is installe, I mean to explore what happens, if after making the corrections, one selects the tuplet tool, deletes the tuplet, and then recreates the same tuplet. ns ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
Aaron Sherber wrote: At 10:05 AM 08/21/2004, Dan Carno wrote: >Am I missing something here? Enhanced tuplets work OK, unless you edit one >by dragging one of the notes (or changing one into a chord), in which case >you will have to edit the number position. It's not just a matter of dragging or changing. If you create a tuplet where the first note is a rest, the vertical position of the number seems to be determined independently of the position of the bracket. My original post involved dragging because that's an easy way to watch the number move apart from the bracket, but the spacing problem is there even if you just create the tuplet directly. That's always been a problem with tuplets in Finale -- one would think that "enhanced" would also include "improved" rather than just "different." -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
Well, auto bracket is indeed the setting that makes this work. I never work with MakeMusic Templates so mine wasn't set up to take advantage of this. Éric Le 21 août 2004, à 10:17, dhbailey a écrit : I have no clue where it is set, because it isn't there in the tuplet options, all I know is that when I enter triplet 8ths, beamed together (they come out that way in speedy entry) all I get is a number, but if I have mixed note values there is a bracket.___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
Dan Carno wrote: At 09:01 AM 8/21/2004, Owain Sutton wrote: I'm one lost sale of 2005 because of this problem. Much of the music I deal with is 'tuplet-heavy'...the new tuplet function was the sole feature that would make the upgrade worth the money. Now it appears it wouldn't be. Am I missing something here? Enhanced tuplets work OK, unless you edit one by dragging one of the notes (or changing one into a chord), in which case you will have to edit the number position. I would rather do this until a fix comes along than deal with the mess that pre-Fin 2005 tuplets present. I'm often dragging notes (where various bars or parts have matching rhythms but different pitches). The bug will make enhanced tuplets virtually unusable to me. ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
At 10:05 AM 08/21/2004, Dan Carno wrote: >Am I missing something here? Enhanced tuplets work OK, unless you edit one >by dragging one of the notes (or changing one into a chord), in which case >you will have to edit the number position. It's not just a matter of dragging or changing. If you create a tuplet where the first note is a rest, the vertical position of the number seems to be determined independently of the position of the bracket. My original post involved dragging because that's an easy way to watch the number move apart from the bracket, but the spacing problem is there even if you just create the tuplet directly. Aaron. ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
At 10:17 AM 8/21/04 -0400, dhbailey wrote: >Éric Dussault wrote: > >> sorry but I don't see this option in 2004. Could you develop ? >> >> Éric >> >> Le 21 août 2004, à 09:59, dhbailey a écrit : >> >> But that's already in place at least for triplets -- in Fin2004 (and >> as far back as I can recall, although I don't think as far back as >> Fin3.5 when I started with Finale) when I enter triplet 8th notes >> they aren't bracketed while mixed triplets are bracketed. > >I have no clue where it is set, because it isn't there in the tuplet >options, all I know is that when I enter triplet 8ths, beamed together >(they come out that way in speedy entry) all I get is a number, but if I >have mixed note values there is a bracket. I have the bracket/number combo in 2K3. I think I had to turn off that cryptic option "auto bracket" to get it to work. Dennis ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
Éric Dussault wrote: sorry but I don't see this option in 2004. Could you develop ? Éric Le 21 août 2004, à 09:59, dhbailey a écrit : But that's already in place at least for triplets -- in Fin2004 (and as far back as I can recall, although I don't think as far back as Fin3.5 when I started with Finale) when I enter triplet 8th notes they aren't bracketed while mixed triplets are bracketed. I have no clue where it is set, because it isn't there in the tuplet options, all I know is that when I enter triplet 8ths, beamed together (they come out that way in speedy entry) all I get is a number, but if I have mixed note values there is a bracket. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
OK. You probably meant the Auto bracket feature with brackets on. So I just learned something that I wasn't using. A great time saver that I was missing from previous versions. Thanks David, Éric Le 21 août 2004, à 10:06, Éric Dussault a écrit : sorry but I don't see this option in 2004. Could you develop ?___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
sorry but I don't see this option in 2004. Could you develop ? Éric Le 21 août 2004, à 09:59, dhbailey a écrit : But that's already in place at least for triplets -- in Fin2004 (and as far back as I can recall, although I don't think as far back as Fin3.5 when I started with Finale) when I enter triplet 8th notes they aren't bracketed while mixed triplets are bracketed.___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
Éric Dussault wrote: The new tuplets are way better even without Enhanced Tuplets. The feature shape--> bracket - with the option --> never bracket beamed notes - is a great time saver. But that's already in place at least for triplets -- in Fin2004 (and as far back as I can recall, although I don't think as far back as Fin3.5 when I started with Finale) when I enter triplet 8th notes they aren't bracketed while mixed triplets are bracketed. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
At 09:01 AM 8/21/2004, Owain Sutton wrote: I'm one lost sale of 2005 because of this problem. Much of the music I deal with is 'tuplet-heavy'...the new tuplet function was the sole feature that would make the upgrade worth the money. Now it appears it wouldn't be. Am I missing something here? Enhanced tuplets work OK, unless you edit one by dragging one of the notes (or changing one into a chord), in which case you will have to edit the number position. I would rather do this until a fix comes along than deal with the mess that pre-Fin 2005 tuplets present. Dan Carno Daniel Carno Music Engraving Services Quality work in Sibelius, Finale, and Score 4514 Makyes Road Syracuse, New York 13215 (315) 492-2987 [EMAIL PROTECTED] ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
The new tuplets are way better even without Enhanced Tuplets. The feature shape--> bracket - with the option --> never bracket beamed notes - is a great time saver. Éric Le 21 août 2004, à 09:01, Owain Sutton a écrit : dhbailey wrote: Noel Stoutenburg wrote: [snip]> I have experienced something that bears on this matter, namely that MakeMusic! was wrong again this year on their intended shipping date. You may remember how last year, the product was announced at the end of July, anticipating shipping the middle of August, and only the Windows version shipped at the end of August. This year, the public product announcement was on August 16, with shipping anticipated on the 20th or so. This did not happen. My copy shipped on August 18, EARLIER than I was told the estimated ship date would be. Thus, when Aaron sent in his report about the bug to support, my copy of the software was already in transit. If Aaron discovered it on his first attempt to use the enhanced tuplets, in the demo that they are using to lure new customers, on a feature that is one of the major new enhancements they are touting, then either they knew about it well before letting the product go "gold" or they have a lousy beta-testing program that doesn't require beta-testers to actually try out new features. I find it hard to believe that NOBODY in the entire process, from developpers to alpha-testers to beta-testers never ever tried to move a note using enhanced tuplets or to begin a tuplet with a rest. Neither scenario, they knew about the enhanced tuplet bug and shipped anyway or none of their testing actually edited the enhanced tuplets, is a pleasant one. The tech-support reply that Aaron received, however, indicates that they knew about the bug. The reply didn't contain any "Oh my goodness, we've never seen that before -- we'll start working on it right now to fix it in the patch." Instead it was more along the lines of we'll try to fix it by the time the patch will be released. Why not hold up the patch until the damn bug is fixed? If Sibelius were any better in any of these regards (fixing bugs quickly with interim patches, not containing annoying gotchas where the tech support says "yeah, we know about those, they're on the long list of things to try to fix in a future upgrade") Finale would definitely get left behind. But they're just as bad at not fixing long-standing bugs that some users have been complaining about for a long time as well as introducing new bugs and saying "we'll try to fix it in a future upgrade." So that rather than the two companies really goading each other into offering superior products to each other, instead they seem to be matching each other in corporate attitude. I'm one lost sale of 2005 because of this problem. Much of the music I deal with is 'tuplet-heavy'...the new tuplet function was the sole feature that would make the upgrade worth the money. Now it appears it wouldn't be. ___ Finale mailing list [EMAIL PROTECTED].edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
dhbailey wrote: Noel Stoutenburg wrote: [snip]> I have experienced something that bears on this matter, namely that MakeMusic! was wrong again this year on their intended shipping date. You may remember how last year, the product was announced at the end of July, anticipating shipping the middle of August, and only the Windows version shipped at the end of August. This year, the public product announcement was on August 16, with shipping anticipated on the 20th or so. This did not happen. My copy shipped on August 18, EARLIER than I was told the estimated ship date would be. Thus, when Aaron sent in his report about the bug to support, my copy of the software was already in transit. If Aaron discovered it on his first attempt to use the enhanced tuplets, in the demo that they are using to lure new customers, on a feature that is one of the major new enhancements they are touting, then either they knew about it well before letting the product go "gold" or they have a lousy beta-testing program that doesn't require beta-testers to actually try out new features. I find it hard to believe that NOBODY in the entire process, from developpers to alpha-testers to beta-testers never ever tried to move a note using enhanced tuplets or to begin a tuplet with a rest. Neither scenario, they knew about the enhanced tuplet bug and shipped anyway or none of their testing actually edited the enhanced tuplets, is a pleasant one. The tech-support reply that Aaron received, however, indicates that they knew about the bug. The reply didn't contain any "Oh my goodness, we've never seen that before -- we'll start working on it right now to fix it in the patch." Instead it was more along the lines of we'll try to fix it by the time the patch will be released. Why not hold up the patch until the damn bug is fixed? If Sibelius were any better in any of these regards (fixing bugs quickly with interim patches, not containing annoying gotchas where the tech support says "yeah, we know about those, they're on the long list of things to try to fix in a future upgrade") Finale would definitely get left behind. But they're just as bad at not fixing long-standing bugs that some users have been complaining about for a long time as well as introducing new bugs and saying "we'll try to fix it in a future upgrade." So that rather than the two companies really goading each other into offering superior products to each other, instead they seem to be matching each other in corporate attitude. I'm one lost sale of 2005 because of this problem. Much of the music I deal with is 'tuplet-heavy'...the new tuplet function was the sole feature that would make the upgrade worth the money. Now it appears it wouldn't be. ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
Noel Stoutenburg wrote: [snip]> I have experienced something that bears on this matter, namely that MakeMusic! was wrong again this year on their intended shipping date. You may remember how last year, the product was announced at the end of July, anticipating shipping the middle of August, and only the Windows version shipped at the end of August. This year, the public product announcement was on August 16, with shipping anticipated on the 20th or so. This did not happen. My copy shipped on August 18, EARLIER than I was told the estimated ship date would be. Thus, when Aaron sent in his report about the bug to support, my copy of the software was already in transit. If Aaron discovered it on his first attempt to use the enhanced tuplets, in the demo that they are using to lure new customers, on a feature that is one of the major new enhancements they are touting, then either they knew about it well before letting the product go "gold" or they have a lousy beta-testing program that doesn't require beta-testers to actually try out new features. I find it hard to believe that NOBODY in the entire process, from developpers to alpha-testers to beta-testers never ever tried to move a note using enhanced tuplets or to begin a tuplet with a rest. Neither scenario, they knew about the enhanced tuplet bug and shipped anyway or none of their testing actually edited the enhanced tuplets, is a pleasant one. The tech-support reply that Aaron received, however, indicates that they knew about the bug. The reply didn't contain any "Oh my goodness, we've never seen that before -- we'll start working on it right now to fix it in the patch." Instead it was more along the lines of we'll try to fix it by the time the patch will be released. Why not hold up the patch until the damn bug is fixed? If Sibelius were any better in any of these regards (fixing bugs quickly with interim patches, not containing annoying gotchas where the tech support says "yeah, we know about those, they're on the long list of things to try to fix in a future upgrade") Finale would definitely get left behind. But they're just as bad at not fixing long-standing bugs that some users have been complaining about for a long time as well as introducing new bugs and saying "we'll try to fix it in a future upgrade." So that rather than the two companies really goading each other into offering superior products to each other, instead they seem to be matching each other in corporate attitude. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
In the past couple of hours, since I wrote: WRT the latter point, the fundamental issue related to this is one that Dr. Patterson and I both alluded to: lead time. We don't know when the bug was discovered. While the response of MakeMusic! suggests that they knew about it before Aaron's post, we don't know for how long they had known about the bug. I submit that there is little enought value to MakeMusic! to intentionally ship a substandard product, that at the time this bug was discovered, it was too late to hold back the shipment without a substantial cost in time or goodwill. I have experienced something that bears on this matter, namely that MakeMusic! was wrong again this year on their intended shipping date. You may remember how last year, the product was announced at the end of July, anticipating shipping the middle of August, and only the Windows version shipped at the end of August. This year, the public product announcement was on August 16, with shipping anticipated on the 20th or so. This did not happen. My copy shipped on August 18, EARLIER than I was told the estimated ship date would be. Thus, when Aaron sent in his report about the bug to support, my copy of the software was already in transit. ns ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
At 10:48 PM 08/20/2004, Noel Stoutenburg wrote: >WRT the latter point, the fundamental issue related to this is one that >Dr. Patterson and I both alluded to: lead time. We don't know when the >bug was discovered. Yes, this is very true. My assumption is that since I found the bug so quickly, at least one of the beta testers probably did as well. But I have no proof of that. >With respect to the former, IMO,. if the bug only occurs when the tuplet >begins with a rest, then it fails to rise to my own definition of >"serious" or "basic". To me, a serious bug is one which causes the >computer to hang up, and lose all data, or fail to start at all. Well, I certainly agree that that kind of bug is more serious, but... > A bug >which affects only the instance when the tuplet begins with an eighth >rest merely rises to the level of "irritating", or "annoying", and >should not inhibit the shipment process. ...I think I was using the words more relatively. The idea of enhanced tuplets is to make it unnecessary (or at least far less necessary) to manually edit tuplets. IMO, one of the worst current tuplet issues occurs when the tuplet begins with a rest: the bracket is flat and in the staff, often colliding with notes. Enhanced tuplets solves this positioning problem but makes it necessary to manually edit the tuplet anyway, to get the number positioning correct. So to me this bug is "basic" relative to its feature, since it renders that feature significantly less useful. Similarly, the other bug discussed recently about Speedy in Page View is basic because it renders *that* feature useless. >BTW, what happens if, instead of an eighth note rest, one creates the >tuplet with two sixteenth note rests at the beginning, and goes back and >deletes one of the sixteenth notes, and changes the remaining one to an >eighth? This is a highly impractical sequence in Speedy Entry (i.e., not at all speedy) -- and it gives the same result. I don't want to beat this issue to death, if I haven't already. I agree that this is no worse than many other Finale bugs, but I find the particular combination of factors associated with it quite galling. Your mileage may vary. Aaron. ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
Hi Noel, The bug does not occur only when a tuplet begins with a rest, although the effect is more extreme when it does. In a quarter note triplet (no rests), for example, if you drag one of the quarters up or down far enough, the number and the bracket separate; the farther you drag, the greater the separation. The bug also rears its little ugly head if you make one of the notes a chord by double-clicking. And, the bug is not fooled at all by changing the duration of the rest. I have found no way around this, other than to avoid having to edit in the first place. Since using a QWERTY keyboard for entry demands "editing" in order to create chords, if you don't use a midi keyboard for entry, you must turn "Enhanced tuplets" off, and face dragging numbers vertically to make them look right. Dan Carno At 10:48 PM 8/20/2004, you wrote: With respect to the former, IMO,. if the bug only occurs when the tuplet begins with a rest, then it fails to rise to my own definition of "serious" or "basic". To me, a serious bug is one which causes the computer to hang up, and lose all data, or fail to start at all. A bug which affects only the instance when the tuplet begins with an eighth rest merely rises to the level of "irritating", or "annoying", and should not inhibit the shipment process. BTW, what happens if, instead of an eighth note rest, one creates the tuplet with two sixteenth note rests at the beginning, and goes back and deletes one of the sixteenth notes, and changes the remaining one to an eighth? Daniel Carno Music Engraving Services Quality work in Sibelius, Finale, and Score 4514 Makyes Road Syracuse, New York 13215 (315) 492-2987 [EMAIL PROTECTED] ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
Darcy James Argue wrote, in part: >What Robert said. Seriously. Aaron, they told you they know about the >bug, they are actively trying to fix it, and if possible, it will be >dealt with in the first maintenance release. What more do you want? to which Aaron responded It's bad faith to ship a product with a serious known bug in an advertised new feature. For me, that's what it comes down to. The good faith options would have been delaying release until it was fixed, leaving out that option until it worked correctly, or mentioning in a footnote that the feature was incomplete. and in response to a post I mand, Aaron wrote (in part): In my personal opinion, if they determined that they could not fix a basic bug in a newly advertised feature and still ship on time, they should have left the feature out. Since they had not yet advertised the feature, no one would have missed it. To me, agreement with Aaron hinges on two things. First, what is "serious" or "basic", and second, whether the bug was in fact known about in time to remove the affected part of the software before the release. WRT the latter point, the fundamental issue related to this is one that Dr. Patterson and I both alluded to: lead time. We don't know when the bug was discovered. While the response of MakeMusic! suggests that they knew about it before Aaron's post, we don't know for how long they had known about the bug. I submit that there is little enought value to MakeMusic! to intentionally ship a substandard product, that at the time this bug was discovered, it was too late to hold back the shipment without a substantial cost in time or goodwill. With respect to the former, IMO,. if the bug only occurs when the tuplet begins with a rest, then it fails to rise to my own definition of "serious" or "basic". To me, a serious bug is one which causes the computer to hang up, and lose all data, or fail to start at all. A bug which affects only the instance when the tuplet begins with an eighth rest merely rises to the level of "irritating", or "annoying", and should not inhibit the shipment process. BTW, what happens if, instead of an eighth note rest, one creates the tuplet with two sixteenth note rests at the beginning, and goes back and deletes one of the sixteenth notes, and changes the remaining one to an eighth? ns ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
At 07:11 PM 08/20/2004, Robert Patterson wrote:
>On the contrary, my contacts there
>are always most cordial and helpful to the extent it is possible.
Personally, I would say that's true roughly half the time, but then your
mileage may vary.
>I am also unhappy with some of the bugs in enhanced tuplets, but I
>hardly see the bugs as cause to pillory the product or the company.
Again, speaking personally, I have grown increasingly exasperated at Coda's
failure to address longstanding bugs which render useless features which
they advertise. Automatically positioning tuplets are a big timesaver
(especially for tuplets that start with a rest), but not if you have to
tweak them in other ways. And yes, I know that there are ways to address
tuplet issues with your plugin, but that's not my point here.
>To get the CDs printed and in our greedy paws requires lead time. They
>have to decide go/no-go long before the ship date. Any bugs that surface
>after the go decision have to wait for maintenance.
This is a bug I noticed within one minute (literally) of opening the demo
and starting to play with the tuplets. ("They adjust when you move notes?
Gee, let me try...") I have a hard time believing that this is a bug that
came up late in the beta cycle. If I had to guess, I'd say it come up
fairly early, but they realized they couldn't fix it and still ship on
time. That they decided to stick to the ship date and still advertise
enhanced tuplets as a new feature strikes me as particularly dishonest.
>is planned for a fix, but they can't guarantee it. We do not know what
>is involved. If the fix requires them to spend 8 weeks entirely
>rewriting and retesting enhanced tuplets, then the fix probably won't
>make it in.
In that case -- again, assuming they've known about this for a while -- it
would have been more honest to just leave out enhanced tuplets, or at least
the auto-positioning aspect.
Aaron.
___
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
At 07:25 PM 08/20/2004, Darcy James Argue wrote: >What Robert said. Seriously. Aaron, they told you they know about the >bug, they are actively trying to fix it, and if possible, it will be >dealt with in the first maintenance release. What more do you want? It's bad faith to ship a product with a serious known bug in an advertised new feature. For me, that's what it comes down to. The good faith options would have been delaying release until it was fixed, leaving out that option until it worked correctly, or mentioning in a footnote that the feature was incomplete. (A few years ago, I was running Finale under NT4 and had several issues. Upon contacting winsupport, I was told that those features were not fully supported under NT4, despite the fact that the product was advertised as working under that OS. And yes, this was at a time when NT4 was a current OS.) Aaron. ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
What Robert said. Seriously. Aaron, they told you they know about the bug, they are actively trying to fix it, and if possible, it will be dealt with in the first maintenance release. What more do you want? - Darcy - [EMAIL PROTECTED] Brooklyn, NY ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
dhbailey wrote: > It certainly seems like Finale's a sinking ship, what's more one with a totally unwarranted arrogance. Makemusic's quarterly reports are available for anyone to see at their website. Finale 2004 seems to have provided a much-needed cash infusion, to the tune of a 74% increase for the most recent quarter. Their cash-flow situation is apparently positive, even if they are booking a loss for the quarter of $0.5 million. These are hardly the numbers of a sinking ship. I've worked a good bit with Makemusic employees (entirely by email). No one has ever seemed arrogant to me. On the contrary, my contacts there are always most cordial and helpful to the extent it is possible. I am also unhappy with some of the bugs in enhanced tuplets, but I hardly see the bugs as cause to pillory the product or the company. Finale has introduced annoying bugs with nearly every new feature they've ever added, yet here we are still using it. To get the CDs printed and in our greedy paws requires lead time. They have to decide go/no-go long before the ship date. Any bugs that surface after the go decision have to wait for maintenance. This has been a fact of Finale life for at least a decade. For this reason, I *never* start using a new version until after the maintenance release is available. If the Makemusic reps said they would try to fix this tuplet bug in the maintenance release, then I would take that at face value. They will be juggling many defects with limited resources to fix them. If the rep said "maybe", it just means they don't want to be held accountable if it doesn't make it. What they are probably really saying is that this bug is planned for a fix, but they can't guarantee it. We do not know what is involved. If the fix requires them to spend 8 weeks entirely rewriting and retesting enhanced tuplets, then the fix probably won't make it in. The thing is, you can always turn the enhanced feature off, in which case you are no worse off than you are now. Even with the enhanced positioning turned off, there is still much to rejoice at in the new tuplets. The new features I like are the metric numerical centering and the new number formats. -- Robert Patterson http://RobertGPatterson.com ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Re: Tuplet bug in Fin2005 demo
Aaron Sherber wrote: Hi all, FWIW, I received the following from WinSupport about the tuplet bug I reported: >For your concern about that tuplet bug, it is something we know about, and >it is being looked at for being fixed in an upcoming maintenance release if >possible. I could go on for several paragraphs about what it says that they are releasing a product with a known and obvious bug in one of their new and highly touted features, and that it will be fixed "if possible" -- but I think I'll just leave it at that. It certainly seems like Finale's a sinking ship, what's more one with a totally unwarranted arrogance. Combine this "we'll fix it if possible, maybe in a maintenance update" along with the implied "if it's not possible, or if we don't feel like it, we won't fix it, or maybe we'll fix in an update we'll try to make you pay for" with the totally uncalled for "yes it's a bug and no, we don't intend ever to fix it" attitude expressed about the recognizable and easily reproducible 2-page-in-speedy-entry-disappearing-from-view bug, and it seems like MakeMusic is in need of a corporate attitude adjustment. Either that or they're actively TRYING to kill Finale and drive everybody over to Sibelius. Just be forewarned, those who are thinking of jumping to Sibelius, that they have a list which, according to the company representative who is a member of the Sibelius yahoogroup, is "long and growing" of things which "may be considered for a future version" and "may be fixed in a future version." Seems like the notation market is so small that good attitudes aren't considered a positive business asset. Too bad -- let's hope they get a corporate manager who really cares about the customers. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
