I've wanted to write something about the "big picture" for some time now - the discussion about enharmonic audit has finally pushed me to do so. Maybe it stirs up some discussion - but maybe, we get some answers or thoughts from the "Noteworthy product drivers".With 2.75's objects, big possibilities have arrived - as can be seen from the contributions. I have now gotten my most important wish via the "CueHeads" object, and I feel now more confident that I can create the scores I wish with acceptable effort.
However, we have now, I believe, a quite foggy vision of what Noteworthy Composer actually is or wants to be. With version 2.51, I thought I would offer my hand to create a German version - I find the product so much better and easier to use than other competing "not so high cost" score programs (Cappella is the main one used here in Germany) that this seemed a worthwhile undertaking.
However, when I saw 2.75, I dropped that idea: The reason is that NWC now suddenly looks like a "hodge-podge of features," which might be hard to explain. And with a currently non-existing German [
added later - sorry] user community (save for me and maybe a few others), explaining various tricks to a typical user might be hard. Here are some examples:
- CueHeads is great, but why can't you choose smaller heads (maybe even of the fixed 70% size) from the standard notehead menu? The "shape" noteheads are, certainly, much less useful than cue noteheads ...
- The slurs have been an ongoing topic for years - now we have even more of them in objects (which, as far as I can see, do not interact in the standard way with lyrics), but still the standard ones.
- The recent discussion about a "better enharmonic audit" also shows that there are tools around that try to improve NWC functions, but run into problems because at least some users feel unhappy about the double built-in vs. user tools world (and now, I would believe, even more so about the three-pronged built-in vs. user tools vs. objects world).
- The "extra note spacing" is still restricted to integral (and therefore too coarse) values, but there are tricks with empty-head, empty-stem grace notes that move notes a little bit.
- And there are, it seems, a host of other spacing tricks which are totally unobvious to the typical user.
- Striked-through grace notes ("Vorschläge") require a combination of built-in grace notes and a user plugin, instead of a simple checkbox on some grace note options.
Instead of considering all these features and their problems, the question behind all this is, in my opinion, more fundamental: Namely, "Where does NWC want to go?" (with regards to score printing - there is another topic which is playback, which I'll briefly touch below).
Possible answers to the "quo vadis" question are, in my opinion:
(A) NWC is now, and remains an environment for plugins where some interested people can provide many good solutions to various problems of score printing; with the assumption that users will work on their understanding of these plugins (be it user tools or objects).
- Some tools introduce new functionalty (e.g., CueHeads).
- Some replace existing NWC functions. When they are (much) better (more versatile, with better results, etc.), they should become "best practice", i.e. override built-in functions "almost always" - see the new copyright and other PageTxt objects, which can do (with quite some hassle for the setup) everything NWC can do and more. The same might be true for the various slur solutions.
(B) NWC continues to strive to be a compact (and also in the future very affordable) and efficient (from the point of the user) program. In this case, the "hodge-podge" resulting from the user tool and (NWC and user provided) objects is, in my opinion, unacceptable. E.g., looking for "slurs" in the documentation would not give average users a good solution, because better objects exist outside the core program. Looking for "cue heads" wouldn't give users a solution
at all, because the only way to get them is via the CueHead object; similarly, users would not find out how to print repeated copyright notes.
But, to give objects and - to a lesser extent? - user tools their credit (very much so!), the "community approach" to improving the functions might be part of a valuable and - to say it loud - cost-effective process which, after some users have praised a certain plug-in (user tool or object), might lead to a quick integration into the Noteworthy program, thereby using (a) the knowledge about
what is a valuable addition; and (b) the algorithmic knowledge
in the plug-in (if the author of the plug-in agrees).
(C) NWC strives to become a feature-complete program, which can do e.g. everything along the lines of Elaine Gould's "Behind Bars." For the first time, this seems to be possible - but the big question is whether NWC actually should try to accomplish this. New feature blocks that would be needed for this would probably be concepts for "multi-score printing" (printing of large works consisting of several movements or pieces or "sections"), which would probably require that almost every option could be enabled/disabled per section. I fear that such a "can-do-all vision" would lead to (a) increased pricing - which would probably kill NWC because there are other companies and programs out there occupying the "next higher price range" successfully - and (b) worse usability, because many more options would become necessary.
My heartful hope is that (B) is the way to go. This might lead to the effect that each new NWC version has "no new functionality at all", because all which is in (say) 2.85 already was provided by 2.75 plug-ins. Yet, the new 2.85 would be much better integrated and hence still worth it.
Finally, a few remarks on playback: Almost all of us NWC users need MIDI file export, i.e., "rendering the score" into a useful MIDI file. My attempts to think about how to play trills in another thread lead me to the conclusion that also there, some features are missing. For example, grace notes currently take their time off the following note (start playing on the beat), whereas in many cases (since 1820 or so), playing them as a "Vorschlag" - before the beat - would be preferable. Also here, one can ponder whether (a) the necessary features should be included in NWC; or (b) they are provided by plugins (e.g. the Trills object). In contrast to the "score features", I would opt here for "plugin-ing:" Those users who do not want plugins can do everything by meticuously writing hidden "playback staffs". Other users can use plugins that render printed score features like trills or arpeggions into acceptable or even perfect sounds.
Returning to the overall picture: With (B) above - i.e., NWC continues to try to integrate new features into the core program, even if they are provided satisfactorily or even perfectly via plugins -, I might again be tempted to create that German version (if this is technically possible at all) - i.e., continue to consider NWC as the great tool it has been for me for the last 15 years!
Regards
Harald M.
It is true there are many user tools, it can be a problem for a new user to become familiar with them: when to use and how. Also, in choral music, it is far from intuitive (much less built in) how to use four staves in the fugue and just two staves in the chorale. E.g.: two staves for the Alto part and avoiding slur, tie, note, and accidental collisions when layering. Tuples over 3 still require work arounds.
Thank you, Harald, for an extremely well-thought-through and well-written critique of the program we all love. I concur with everything you've said, and I'm also pinning my hopes on (B).
The one thing I might add is that (B) might be accomplishable through better integration of plug-ins into the program, rather than requiring them to actually be part of it. I've referred previously to Paint.net as an example of how to do it right: if you haven't checked it out, it's worth a look, especially if you work with images to any extent. When you add a plug-in to Paint.net, it simply appears in the appropriate menu, and its functions are indistinguishable from the functions of the core program: the dialogue boxes and submenus look the same and work the same, and the features interact fully with the features of the program. In NWC, what that would mean is that, for example, slurs produced by a plug-in would be controllable by everything that would control a native slur, and they would also have the same effect on the sound as a native slur. If that were the case, it wouldn't really matter to the average user whether a particular feature was a core function or a plug-in; the only thing that would count is how well it did its job.
Eric is already moving NWC that direction. Plug-ins can affect the sound (Mike's trills and tremolos are an example), and they are controlled by dialogue boxes that at least bear a resemblance to the native dialogues. (Those of us who worked with the betas can easily remember the first User Object dialogues, which were pretty geek-heavy; they've since improved dramatically.) And many of the best plug-ins are currently installed automatically along with the program, omitting the need to search out a separate download and install it in order to accomplish those functions. Perhaps what is most needed at this point is encouragement to continue along this path.
Bill
Thanks for your comments.
I obviously missed a fourth option, which seems to be the perfect one and is, if I understand it correctly, pursued by the NWC team:
(B') Integrate objects so well that they appear to be part of the program. Great!
Now, in my opinion this would mean for an object:
- It must not only "do something good", but it must do "all good" for the intended functionality: (a) Integration into NWC's "command interface" (e.g., the CueHeads must integrate themselves into the Notehead selection, where they "logically belong"); (b) Integration into NWC's "presentation interface" (e.g., the CueHeads must show small noteheads, but also integrate with distance computations for notes, rests, lyrics etc.); (c) Integration into NWC's "print interface" (i.e., take part in computations for line and page breaks); (d) Integration into NWC's "MIDI interface" (i.e., produce correct audio output; CueHeads won't do anything here, I assume, but - as Bill mentioned - slurs should).
Almost all of this, if I understand it correctly, can be done right now already (great!) - except maybe (a); but for a "seamless experience", all objects must do all this - which requires sort of an "extension point interface" with a number of required functions ... It seems to me that such a concept is, right now, somewhat at odds with objects: CueHeads uses a concept where a "segment of a staff" (starting at the object's location and ending with a corresponding object somewhere "later") behaves this way or the other (e.g. replacing invisible heads with cue heads), whereas standard noteheads have no such concept of "segment behavior". Getting both to behave alike seems to require some "even higher abstraction"...
- Documentation: Probably this could just have been mentioned as a fifth item in the list (a)...(d) above. But I think this is a crucial point: Warren wrote " it can be a problem for a new user to become familiar with [the many user tools]" (and the same is true for objects) - but I think this still sounds a little backwards: It seems to assume that it is the job of users to "become familiar", like "Didn't you know there is a thread ...?", "Didn't you keep up with the discussion about new slur objects ...?", "Didn't you ...?". But this is wrong, in my opinion: It is not a user's job to integrate knowledge over mulitple channels for typical, standard functions - this must all be in the documentation. So, a fifth and required part of writing an object is integration with the standard help file - in such a way that the tool's functionality is found at the "expected place".
- (Added later - sorry) A crucial and, in my experience, hard aspect of plug-in-based software is quality assurance: When one allows "out-sourcing" of functionality to other contributors, especially with a powerful interaction interface as outlined above, the responsibility for bug fixing - and, before that, bug detection - also becomes distributed. It seems to me that the development and release process must ensure that plug-ins behave well while the program evolves. Especially, "old plug-ins" that work fine now must still work fine in the next release. It seems to me that this requires a two-level approach: Some objects are "first class", i.e., the NWC team includes them in regression tests during development and before a new release (why not have the object's contributor take this part - probably he/she will be a beta tester anyway? because the contributor might no longer be around, for whatever reason; but her/his object might still be in full use in many many scores out there); whereas many other objects - experimental ones, abandoned ones, ... - will just "live or die."
... all this is just loud thinking to get a grip on this wonderful tool with its contributions that help me - but (with my vision of a new group of users which might not be able to take part in English discussions) also all users that "just want to use the program without being in the community".
So, thanks for the comments, and I hope I did not "require" anything, just point out one user's view of how to think about NWC.
Harald M.