Re: The Orchestral Staff Attribute Bug
Reply #23 –
G'day bidderxyzzy,
I wonder if it is truly as trivial as you suggest? What impact will such a change have on the rest of the code? Just how difficult will it be to code around the dependancies? - only Eric can truly tell.
Afraid I must disagree with you here... NWC's behaviour is mostly just fine for my needs - far from "utterly unacceptable for any purpose whatever".
If it is the visual representation that is paramount then what's the problem with hidden staves that do the actual work for playback?
I concur, and thankyou.
Hmm, I've read complaints about this before, but haven't really experienced it. In fact, whenever the enharminic spelling has been a problem I simply make sure the key signature is correct and do a |Tools|Audit Enharmonic Spelling| - this usually fixes things quite well. 'Tis a good idea to Force Accidentals before and key sig change...
I have found this to be a minor irritant too.
Perhaps we need to examine in whose eyes the result is wrong... Eric has written the code. It is my understanding that the code does what he wrote it to do. To me this is an expected result - whether I like the result or not is totally irrelevant. Thus not a bug. Simply a disagreement in design preferences between people.
If he had written the program to behave as we would prefer but got this result instead then it would be a bug - and knowing Eric's responsiveness in the past, it would be quickly fixed.
While I'm almost certain I've seen it mentioned somewhere I can't remember, or don't know - amounts to the same thing - what reference(s) Eric has used in defining the design parameters. Perhaps what we are seeing actually corresponds with said reference - I can't tell you for sure 'cos I ain't seen it!
============
You seem to use SharpeEye quite a lot - PLEASE, stop using MIDI as the intermediate step and export as mxml and use mxml2nwc to import - gets rid of the enharmonic spelling and triplet problems altogether.
Try it, it works!