noel, thanks for the reflected considerations of my proposals.
first i would again mention that - as you have understood - i am not proposing the reduction of any existing functionality, this seems to be the biggest fear in arguments against my proposals.
your comments about the numerous tools were interesting, but a group of computer software tools are not the same thing as concrete objects we use for various notational (for example) tasks: a pencil cannot magically become a red felt marker without the user removing the former from his hands and replacing it it with the latter, while the analogy of such a feat can be done automatically (contextual clicking for note-, measure- or page-assigned Texts) or with almost no effort when using a sophisticated computer software programme.
if I understand the basis for Jef's proposal correctly, it reduces to "these things act on the same things, and therefore they all be the same".
mmmm, sort of, but no i am not trying to reduce anything - functionality or usefulness - but rather make a more complete tool which can do more of what it should be able to do, and do the things it currently does far more efficiently. a simple example: with contextual Text assignment, a single click creates a note expression (metatool-assigned), one more click creates a new page-attached Text - without recourse to changing the tool and mode of application, as is currently the case.
actually i am interested in reducing something: the overlapping functionality and the redundancies in the programme. admittedly, to some users, these redundancies are insignificant or even invisible, however that in itself is not, in my view, a sufficient argument against the merging of the expression and text tools. in any case, those who see no point in merging the tools probably will also not see any changes when the two tools are merged, and since their work won't even be affected by the changes, such fears should not justify arguments against merging the tools.
to a large extent, although they may have very different functions (varying according to the era of the music being notated and, in music of the past 120 years, the individual user's or composer's or piece's stylistic particularities), all text expressions and text blocks can be considered as text-based graphic elements during the process of notation: dynamics and text blocks are floating "graphical" items placed on the score (typically) separate from (but of course having a clear relation to) the notes and staves (contrary for example to articulations) whose placement varies according to the context (immediately-adjacent text block vs. "footnotes"; piano vs. flute vs. voice dynamics).
the notation of the score is not the same thing as the composition of the work, or the interpretation and performance of the work, and in considering both dynamics and text blocks as Text items, i am referring specifically to the notation of the music.
that one cannot immediately see how the two can be efficiently merged - the second most common argument against - is something that should be addressed at the implementation level, not the conceptual level. in any case, some of the problems that might crop have already been addressed, and the solutions were relatively simple to find. we ought to concentrate on _what_ should be done, not _how_ (admitting of course, that it should not however be ignored completely at this stage).
jef
--
shirling & neueweise \................/ new music notation specialists mailto:[EMAIL PROTECTED] :.../ http://newmusicnotation.com _______________________________________________ Finale mailing list [email protected] http://lists.shsu.edu/mailman/listinfo/finale
