In my opinion, the word "bug" is vastly overused, and is incorrectly used for everythiing from design flaws to coding errors, and everything in between. A coding error is simple to fix: correct a couple of lines of code, and recompile. A design flaw is much more difficult; it involves reworking not only individual pieces of code, but how they all fit together. Correcting a design flaw involves many more steps, takes longer, and is vastly more difficult.

I am of the opinion that Aaron's tuplet bug is really a design flaw, and as such will require much more effort than fixing a couple of lines of code.

However comment David made,

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.

actually bears upon some of my ruminations since my last post.


The development of personal computers, or more particularly, how computer software has been implemented, have dramatically affected how I think and work. I completed high school when computers were still big and expensive, and I remember when I had a major project to complete that I learned that if I spent a significant amount of time at the beginning of a project planning and organizing my thoughts, I could save a lot of time. I remember writing longer pieces by first thinking about what I wanted to say, writing an outline, then writing the development of the outline on index cards, skipping a space between each line so that I could make corrections and revisions without the need to rewrite the whole card, using red ink for intially, blue for the first revision, and black for the second. I used index cards so that if I discovered in writing that what I had originally to be a subsidiary though turned into a major point, they could easily be rearranged. Then I sat down at the typewriter, and typing more slowly than my top typing speed in order to improve my accuracy, I typed the rough draft, double spaced, to allow for final corrections, and do preliminary layoiut work, and finally the final draft. I found a significant amout of time savings when I did this, since correcting errors, and reorganizing was time consuming work.

If I were now doing music engraving using the same principles I developed in high school for writing papers, I would plan how many measures in a system, how many systems to a page, &c., before ever striking a key in Finale, and I would go slowly, to avoid making errors.

But, I don't do music engraving according to the same principles, and for what it's worth, I don't write according to the same principles, either. "Cut and paste", and push ahead insert, and destructive backspace have eliminated much of the cost of time and effort that correcting errors used to take, so that it is not as costly to correct an error now as it once was. But there is a cost to this; my work is generally not as organized or accurate as it once was. I type faster, but make more errors, because there is little cost to correcting the errors.

Please don't misunderstand me; despite my self-confessed antediluvian tendencies, I don't necessarily want to eliminate the capabilities of "cut and past", or destructive backspace, or in Finale, the ability to move a pitch up and down the staff, or to convert a single pitch to a chord by adding a note an interval above or below. And I'm going to be happier to have the software fixed to that modifications to the tuplet do not obliterate the new feature than I will be if the software is not fixed. I just have not yet decided that a program design which encourages the user to be more organized and precise is initial entries is really flawed. Maybe we've all just become too lazy

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

Reply via email to