Re: [Finale] new and improved text tool
David W. Fenton wrote: What I *would* support is if the text expression dialog's text box at the top were instead replaced with the standard Finale text editor. Then you could put anything in the text expression that you could put into the text editor, and the user interface would be exactly the same in both places. Text expresssions would then be text blocks with additional expression-only properties added to them. This is exactly how expression works in Fin2004 and later. Best regards, Jari Williamsson ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
Kurt Gnos wrote: At 09:15 23.02.2005, you wrote: It's a nice list, but I think that getting compact and reliable PS, EPS, and PDF output would be sufficient for one year's upgrade. If this is supposed to be a tool for publishing, it has got to be able to output in the principle formats for publication. Amen! Just my point of view! I have sworn to myself if they won't do it in the next upgrade, I will swich to Sibelius... Kurt Before taking that step, if you know somebody who has Sibelius, try it out to be sure you'll like it. It would be sad to be able to get those formats of output but to be unable to produce the output you want or are hired to produce. I'm not saying you won't be able to (I don't know what sort of music you are engraving), just that you should be sure you will be able to work with Sibelius. It is as idiosyncratic in its ways of forcing you to work as Finale is. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
On the other hand I am pretty sure the feature set for 2k6 has already been decided anyway, so we are talking about 2k7, maybe 2k8, so that really shouldn't be a reason. Johannes Kurt Gnos wrote: At 09:15 23.02.2005, you wrote: It's a nice list, but I think that getting compact and reliable PS, EPS, and PDF output would be sufficient for one year's upgrade. If this is supposed to be a tool for publishing, it has got to be able to output in the principle formats for publication. Amen! Just my point of view! I have sworn to myself if they won't do it in the next upgrade, I will swich to Sibelius... Kurt ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
Dennis Bathory-Kitsz wrote: Have a look at this: http://maltedmedia.com/photos/toolbar.gif It still escapes me why this kind of thing cannot live happily in two different tools. Before the expression tool was improved I could see that there was some overlap between measure text blocks and measure text expressions, however, all these problems are now indeed covered in the expression tool in my opinion, and I see no need to merge the two tools. That is not to say that both tools could be vastly improved. Coming back to the original feature request, although you can make any feature request you like, I don't really see the benefit of making one like this, since firstly it is unlikely that MM will actually make such a major interface change and at the same time merge tools (to which a lot of people have either objected or don't really follow the need for it), and secondly I sort of feel that merging the two tools is going to make things worse. In fact, I fear that by the end we will have a merged tool with the same design problems we have already, and none of the shortcomings of the text block tool fixed. Given that choice I'd rather see major improvements to the text block tool, and a better selection dialog for expressions, then let MM invest their resources into merging the two without any benefit that I can see. I would like to see the kind of toolbar you invented for the two tools, of course, but separately. The kind of text I type into the text tool I would never want to use in the expressions tool, and vice versa. This was a little different before expressions allowed multiple fonts and multi-line items, but now that that problem is solved I simply use expressions, and only use measure attached textblocks in very specific cases, which do not overlap with the expression tool. Johannes Johannes -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
At 11:58 AM 2/24/05 +0100, Johannes Gebauer wrote: It still escapes me why this kind of thing cannot live happily in two different tools. jef suggested two. My followup suggestion was to combine at least seven tools (text, expression, articulation, chord, lyrics, clef, time signature) and let any item be assigned any feature. No matter. It was just a wish. Maybe somebody at Finale will notice. As I said to Noel, My only reason to jump in was to suggest re-thinking the *entirety* of these entries and perhaps get a unified and transparent palette out of it as a nice consequence. (I've stopped with F2K3 because later versions are victimware. If I'm eventually gonna have to buy victimware anyway, I might as well make suggestions while I shop around!) Dennis ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
David W. Fenton wrote: Of course, I also seem to remember something about pre-defined vertical positioning having been added in a recent version of Finale, so I may be late with the idea. Indeed. In fact, expression positioning goes far beyond anything articulation can offer. The two are different, and for a reason, imo. Johannes -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
shirling neueweise wrote: hi all, i am submitting a proposal to CODA, It's a nice list, but I think that getting compact and reliable PS, EPS, and PDF output would be sufficient for one year's upgrade. If this is supposed to be a tool for publishing, it has got to be able to output in the principle formats for publication. Daniel Wolf ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
The other thing is that I am not convinced that merging the text and the expression tools is such a good idea. Instead I would prefer to have some better options for placing text blocks and for handling them in part extraction. My main requests are: 1) Allow measure attached text blocks to be placed on page coordinates. This would immensely facilitate the creation of Titles and footnotes, and would prevent some of the mess that is created every time I extract parts. 2) Allow title pages without music to be carried into extracted parts. 3) Give the File Info more custom fields which can then be included in text blocks (this would make house styles much easier to set up). Johannes d. collins wrote: Daniel Wolf écrit: It's a nice list, but I think that getting compact and reliable PS, EPS, and PDF output would be sufficient for one year's upgrade. If this is supposed to be a tool for publishing, it has got to be able to output in the principle formats for publication. I can only agree. I'm not in favor of requesting any new bells and whistles as long as such important features are broken (EPS export AND import, which no one mentions). Dennis ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
Jef I too, have changes I'd like to see with the text tool, and some of them are consistent with some of what you propose, but before I comment further, perhaps you could please address the issue of what benefits you see arising from your proposal to merging what is currently the list of the text subset of the expression tool, with the list of the text tool. Personally, I just don't see enough benefit to such a merger to justify this proposed combination. Frankly, some of the issues you raise, while they make sense for one side--as an example, the capability of greater control over typographical issues makes a great deal of sense in the current text tool--seem unnecessary on the other--when the text string contains only one line, or a single character, full justification seems like a bit of overkill. Further, I'm not sure that I think it's a salutary change to force me to read through all the dynamics text expressions when I want to edit the critical footnotes, or vice versa, or in a more extreme case, in a current project, where I've created a program for an upcoming performance of the Bach St. John Passion, entirely within Finale, using Text blocks for the text, with the original German on the left, and the English translation on the right, and the chorales notated in-line, so that, should they choose, members of the audience can sing along. I currently have in my probram, 14 chorales, and 315 text blocks, without yet adding dynamics, or other text expressions to that number. Finally, the biggest shortcomings I see in the text tool do not seem to be addressed: 1) the inability to access the attributes of a text block from the text block edit dialog of that same block; 2) the inability to assign the same text block to discontinuous ranges of pages, as in 2-5, 6-9; 3) the inability to address the text attributes sequentially, by stepping through the list; and 4) the inability to access a particular range of text blocks, say, to make a change in ten blocks beginning with number 250. and one major shortcoming I see in the text expression tool, 5) the inability to group expressions into collections, so that in my expression list, I could define a group, dynamics, place all the dynamics related expressions into that, and collapse the group when I wanted to view only the tempo related text expressions. ns ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
On Feb 23, 2005, at 1:41 AM, shirling neueweise wrote: GENERAL * Text can be assigned to an individual note or measure (as with the old Expression Tool) or to a page or range of pages (as with the old Text Tool). * Once assigned, default positioning of the individual Text can be altered or overridden, by double-clicking the text's handle in the score, clicking override, and redefining the positioning (this does not affect the original). I am wondering how this would work out in a score. There is already the issue that crops up when trying to assign note-attached versus measure-attached text expressions - if you enter the wrong type you have to delete the expression and start over. On the other hand, if you are working ONLY with one type for the moment, it is fast and easy. I would hate to add mouse-clicks to the process. Is this clear enough? Did you have an idea about how the interface would work in this case? Otherwise it looks very clean and presentable (with capitals and everything! We're so proud!) Christopher ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
At 05:31 AM 2/23/05 -0600, Noel Stoutenburg wrote: you could please address the issue of what benefits you see arising from your proposal to merging what is currently the list of the text subset of the expression tool, with the list of the text tool. I think merging all the text-like types is long overdue. Characters are characters, individually or combined. Folding together the text, expression, articulation, chord, lyric, clef, and time signature tools into a multifunction toolbar with a consistent interface seems ideal to me. A single toolbar could identify the type of text in use (in a droplist, where it could be changed), the activity is performs (where, say, the title could load up Midi presets or a lyric enable a patch change), its assignment (note, measure, staff, system, page, or document), etc. Like other applications do, a droplist on a toolbar would identify the current method of assignment (say, as an expression), its active (and available) parameters, and its positioning (with, say, a relative/absolute checkbox). I would love to see, on clicking an object, to what other object it was assigned (even though I prefer rubber bands, another discussion), its playback functions, etc. -- just as I would do when clicking on a vector object in a graphics program. A drag-drop icon could allow the present selected item to be dragged and attached to whatever it was dropped on. A duplicate button similar to the present one could live right there on the toobar. Then by changing the droplist for the duplicate I could, say, change a copied chord symbol into an expression, take some of lyrics and re-assign them as a title, make 4.6/3.3 or M/IV or HX or 4/4(=12/12) or Yay! into time signatures, give a clef change a bundle of Midi parameters, and so forth. A list could be opened from the toolbar with the existing expressions to drag-drop into place, or it could pop up by clicking a spot on the score as it does now. The opening contents of longer texts would be shown, and the text full box could be opened or it could be edited in place. (Even the tuplet and measure number text could show up on this toolbar.) *Any* element could be assigned vector-type stretchiness or smartness as well -- useful in, for example, stretching a crescendo and making sure it was parenthesized on succeeding pages, squashing a lyric syllable horizontally or vertically, stretching time signatures across multiple staves, or making small adjustments in a tight-fit situation. Along with stretchiness, they could be assigned various standard extensions (dots, dashes, lines, curves, custom). So the present main dialog boxes could be reduced to this toolbar, always visible, and sub-functions (such as staff lists or time signature patterning) could be popped up as needed. In other words, the division of all these textual elements by immutable, pre-determined 'musical' function was a mistake that it's now possible to correct. Out of the box, Finale's texts, articulations, expressions, chords, lyrics, clefs, and time signatures would still be assigned in their default state, but a few clicks would make possible enormous flexibility that requires workarounds now. All these functions seem to be available in the Finale data, and would ask only for a reorganization of its use and a relatively small change to the user interface. So I think jef is very much on the right track, but I'd like to see Finale go farther in overhauling the entire text-assignment system. Dennis ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
At 01:41 AM 02/23/2005, shirling neueweise wrote:
* The height of the individual item lines in the
Text List has been increased by 25-50%
(previously, any Text above 14pt fixed and many
music symbols - usually 24pt - were only
partially visible). The user can define the size
of the lines in the Document Options [Text]:
{smaller, small, normal, big, bigger}; or as a
percentage of the default size {50%, 75%, 100%,
150%, 200%}
Better (I think): The individual text items are scaled for display in the
list so that they are reasonably legible. I don't want a big item height,
because it takes up valuable screen space. I want a height of (say) 14 pts
or so, and then I want everything scaled to 14 pts for display in this
dialog. This is how TGTools Text Expression Browser handles things. You do
lose a sense of the relative sizes of different text items, but I think the
tradeoff is worth it.
Aaron.
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
At 06:31 AM 02/23/2005, Noel Stoutenburg wrote: 5) the inability to group expressions into collections, so that in my expression list, I could define a group, dynamics, place all the dynamics related expressions into that, and collapse the group when I wanted to view only the tempo related text expressions. FWIW, you can do something like this with the TGTools Expression Browser (Win only, I think). The list there can be sorted alphabetically, rather than in Finale's default order, or it can be sorted by various font criteria and then alphabetically. So for example, all of the expressions in Maestro appear first in the list (these would be dynamics). Then a section with 12 pt. text (unis, arco, pizz, etc.). Then a section with 14 pt bold text (tempo markings, etc.) You can't collapse the sections the way you want, but it sure does make it easier to find things. Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
Dennis Bathory-Kitsz wrote: At 05:31 AM 2/23/05 -0600, Noel Stoutenburg wrote: you could please address the issue of what benefits you see arising from your proposal to merging what is currently the list of the text subset of the expression tool, with the list of the text tool. I think merging all the text-like types is long overdue. Characters are characters, individually or combined. Folding together the text, expression, articulation, chord, lyric, clef, and time signature tools into a multifunction toolbar with a consistent interface seems ideal to me. I understand you point, that the interface to these tools might well bear some modification, and perhaps unification. However, there is a difference between the interface, the dialog box(es) and the objects upon which they operate. One can certainly have different tools that operate on the same object, and different objects acted on by the same tool. But just because the objects are acted on by the same tool, even if they happened to look the same, doesn't autmatically and necessarily demand that they be part of the same list. This is what both Jef and you seem to propose, and while Ive not yet made up my mind relative to a single tool for all text items, neither you, Jef did not originally, and you do not in your supporting post, address the issue of merging the lists that Jef seems to propose. ns ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
At 04:16 PM 2/23/05 -0600, Noel Stoutenburg wrote: One can certainly have different tools that operate on the same object, and different objects acted on by the same tool. But just because the objects are acted on by the same tool, even if they happened to look the same, doesn't autmatically and necessarily demand that they be part of the same list. I don't think I'm being clear. These all all interchangeable texts, with aspects of function assigned. They are only different in Finale because the program started out making them different. They were once all engraved with the same tools, and software separated them out. Now it's time to put them back together and *increase* our flexibility instead of remain straightjacked by our tools. Dennis ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
At 04:16 PM 2/23/05 -0600, Noel Stoutenburg wrote: Jef did not originally, and you do not in your supporting post, address the issue of merging the lists that Jef seems to propose. I'm just being supplementary. But think of a Palm and how it organizes addresses by categories. It's a droplist of choices. You can choose any category you name, or all, and you see those elements. So you could have the lists sorted the old way or any way, and it would all be available. Opera's mail client does that, and I think Gmail as well. Dennis ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
Dennis Bathory-Kitsz wrote: I don't think I'm being clear. These all all interchangeable texts, with aspects of function assigned. They are only different in Finale because the program started out making them different. They were once all engraved with the same tools, and software separated them out. Now it's time to put them back together and *increase* our flexibility instead of remain straightjacked by our tools. I am not against this, but I fail to see how I would benefit? There is no reason why I would want my title text blocks appear in the expression list, it would only convolut it more. OK, I know that you have ideas on how to get more organization into these lists. I have been thinking about this several times now, and I still don't see why I would want text blocks and expressions be merged into one tool. In what way would I then get faster results? In what way does this increase our flexibility? I know we need improvements to the text tool, and probably there is still ways to improve the expressions tool. Johannes -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
On Wed, 23 Feb 2005 18:07:32 -0500, Dennis Bathory-Kitsz [EMAIL PROTECTED] wrote: At 04:16 PM 2/23/05 -0600, Noel Stoutenburg wrote: Jef did not originally, and you do not in your supporting post, address the issue of merging the lists that Jef seems to propose. I'm just being supplementary. But think of a Palm and how it organizes addresses by categories. It's a droplist of choices. You can choose any category you name, or all, and you see those elements. So you could have the lists sorted the old way or any way, and it would all be available. Opera's mail client does that, and I think Gmail as well. Even better than merely categories, Gmail has Labels. You can attach any number of labels to a particular message, rather than having to pigeonhole it into on specific category. This kind of flat hierarchy is gaining ground for Internet-based information storage; an online social bookmarking site I use, called del.icio.us ( http://del.icio.us ) does a similar thing but calls the groups tags instead. I really like that method of organization. What if an email message or bookmark fits equally under the headings notation, music, and finale? With the flat hierarchy you can separate all three of these concepts but still place single items into all three groups if it's logical to do so. -- Brad Beyenhof [EMAIL PROTECTED] my blog: http://augmentedfourth.blogspot.com FinaleIRC (come chat!): http://finaleirc.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
At 07:41 23.02.2005, you wrote: Because of overlapping functionality, the previous expression tool and text tool have been combined into one powerful text tool which offers all the previous features of both tools, albeit with some revolutionary improvements. I would NOT mingle the two tools since they have an entirely other functionality. However, I'd like some of the things you mention, but in the Text Tool where I might use them. Kurt ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
On 24 Feb 2005 at 0:10, Johannes Gebauer wrote: There is no reason why I would want my title text blocks appear in the expression list, it would only convolut it more. OK, I know that you have ideas on how to get more organization into these lists. I have been thinking about this several times now, and I still don't see why I would want text blocks and expressions be merged into one tool. In what way would I then get faster results? In what way does this increase our flexibility? I tend to agree with you. What I *would* support is if the text expression dialog's text box at the top were instead replaced with the standard Finale text editor. Then you could put anything in the text expression that you could put into the text editor, and the user interface would be exactly the same in both places. Text expresssions would then be text blocks with additional expression-only properties added to them. How they are actually store, well, I couldn't give a rat's ass! This all goes back to my subclassing argument about how I think expressions and articulations really ought to work. In the scenario I've described, text expressions would be a superclass of text blocks, inheriting all the capabilities of a standard text block (and the same way of editing and manipulating them) while adding the properties necessary for expressions. -- David W. Fentonhttp://www.bway.net/~dfenton David Fenton Associateshttp://www.bway.net/~dfassoc ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
On 23 Feb 2005 at 15:30, Brad Beyenhof wrote: On Wed, 23 Feb 2005 18:07:32 -0500, Dennis Bathory-Kitsz [EMAIL PROTECTED] wrote: At 04:16 PM 2/23/05 -0600, Noel Stoutenburg wrote: Jef did not originally, and you do not in your supporting post, address the issue of merging the lists that Jef seems to propose. I'm just being supplementary. But think of a Palm and how it organizes addresses by categories. It's a droplist of choices. You can choose any category you name, or all, and you see those elements. So you could have the lists sorted the old way or any way, and it would all be available. Opera's mail client does that, and I think Gmail as well. Even better than merely categories, Gmail has Labels. You can attach any number of labels to a particular message, rather than having to pigeonhole it into on specific category. There's nothing about categories that requires there be only one per object. Microsoft's Outlook uses categories, and you can assign as many as you like to any kind of object you like. And then you can adjust your view of the objects to be sorted by categories or any other way you like. This kind of flat hierarchy is gaining ground for Internet-based information storage; an online social bookmarking site I use, called del.icio.us ( http://del.icio.us ) does a similar thing but calls the groups tags instead. This is highly problematic, in my opinion, for two reasons: 1. it's *too* simply (non-hierarchical where the natural organization actually is hierarchical. 2. there is no authority anywhere to enforce consistency in use of the tags. I really like that method of organization. What if an email message or bookmark fits equally under the headings notation, music, and finale? With the flat hierarchy you can separate all three of these concepts but still place single items into all three groups if it's logical to do so. This is what I wrote about the current Internet darling, tags, in another forum: I am amused by this whole discussion of tagging on websites, because it seems to me that my 15 years of experience in designing database applications and looking at other people's implementations of categorization systems has taught me that this kind of thing is *not* simple. There are several problems: 1. proper categorization is not flat -- it is hierarchical. With a flat tagging system, you need to double up the categories. If your item is about Museums--Musical Instruments you need to have a tag for Museums, a tag for Museums--Musical Instruments and a tag for Musical Instruments. In a hierarchically organized categorization system, that isn't required -- you need only the one tag, Museums-- Musical Instruments (which is a combination of category and subcategory). As Joe Celko has showed us in many SQL articles, it's easy enough to create n-level hierarchical trees and retrieve data from them without needing to have a complex data storage structure. This allows both the construction of the full complex tree, as well as easy searching of all levels of the tree. 2. for categorization to truly work, there needs to be some enforcement of rules for the encoding of the categories. Otherwise, you need to build a lot of smarts into your search engine. For example, if you want to search for Music a simple dumb search will not return items tagged only with Symphony unless the person doing the tagging has insured that the item is also tagged with Music (it's super-category). Now, a smart search engine could use a heirarchical category list as a lookup to find related subjects, but the result will only be as good as the quality of that lookup list. A perfect example of a failed lookup list is TiVo's recommendations. The that works is that the TiVo looks at the categories of the programs you've chosen to record (and have given thumbs up to, i.e., told the TiVo that it's a program that you really like), and then finds other programs in the same categories and suggests them to you. When I first got the TiVo, the whole reason I bought it was so as to not miss Babylon 5. Well, TiVo said Aha! B5 is science fiction, so I'll suggest more SciFi! That's certainly quite correct, but the SciFi category also included things like Third Rock from the Sun (which I despise) and Tales from the Crypt (which doesn't interest me at all). In the former case, Third Rock, the problem is that the category is not fine enough. In the latter, it's that non-SciFi has been mis-categorized (in my opinion, and from my point of view). There's also the relatively trivial issue of spelling and formatting and synonyms. Google is good at this (I'll ignore for the course of the discussion below that Google is a full-text search, not a category search, only because it's a familiar tool I can use to illustrate the problems), but it only works well when you mis-type a word in your search string, relative to the body of web pages out there.
Re: [Finale] new and improved text tool
At 12:10 AM 2/24/05 +0100, Johannes Gebauer wrote: I am not against this, but I fail to see how I would benefit? There is no reason why I would want my title text blocks appear in the expression list, it would only convolut it more. OK, I know that you have ideas on how to get more organization into these lists. I have been thinking about this several times now, and I still don't see why I would want text blocks and expressions be merged into one tool. In what way would I then get faster results? In what way does this increase our flexibility? Have a look at this: http://maltedmedia.com/photos/toolbar.gif I just put this image together -- think of it as a docked toolbar (I use PC, so imagine whatever Mac has, or other color schemes, etc.) Please don't consider it any sort of optimal interface. It's just a visual idea of how to have the info in front of your eyes. Wouldn't you like to have the parameters of whatever kind of text you're using displayed for you, duplicatable, quickly adjustable (stretchable, size adjustable), etc.? Think of all the kinds of textual items being dropped into any category, or all shown? I drool for something like this. :) Dennis ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
Responding my to my comment, in part: One can certainly have different tools that operate on the same object, and different objects acted on by the same tool. But just because the objects are acted on by the same tool, even if they happened to look the same, doesn't autmatically and necessarily demand that they be part of the same list. Dennis Bathory-Kitsz wrote: I don't think I'm being clear. These all all interchangeable texts, with aspects of function assigned. They are only different in Finale because the program started out making them different. They were once all engraved with the same tools, and software separated them out. I don't think they are interchangeable texts at all, because they have different funnctions in the music. For one thing, text expressions have a specific impact upon way the music itself is to be realized, for example, how loud, or how fast. or by whom. A running header, or a dedication in a text block have nothing to do with the way the music sounds, and I would submit that the line, Dedicated to my colleague, Dennis is _not_ at all interchangeable with Allegro ma non troppo. despite the fact that they are composed of different subsets of the same set of symbols. This is not, I submit, a case where previously interchangeable texts were separated by the software, any more than a the title page of the score of Stravinsky's The Firebird is interchangeable with a shopping list. I agree that the editing of these can use common dialog boxes, just as if one can find it, one can use Stravinsky's pencil to write a shopping list. That does not make the various types of text item interchangeable, or even functionally equivalent. ns ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] new and improved text tool
At 11:54 PM 2/23/05 -0600, Noel Stoutenburg wrote:
I don't think they are interchangeable texts at all, because they have
different funnctions in the music. For one thing, text expressions have
a specific impact upon way the music itself is to be realized, for
example, how loud, or how fast. or by whom. A running header, or a
dedication in a text block have nothing to do with the way the music
sounds, and I would submit that the line,
Dedicated to my colleague, Dennis
is _not_ at all interchangeable with
Allegro ma non troppo.
despite the fact that they are composed of different subsets of the same
set of symbols.
This is not, I submit, a case where previously interchangeable texts
were separated by the software, any more than a the title page of the
score of Stravinsky's The Firebird is interchangeable with a shopping
list.
How does one cook serve a firebird? Yum...
I guess I'm getting at the fact that the software authors had to make
decisions on how to move from pencil paper to keyboard and screen. No
such decisions were needed with that pencil, nor with engraving tools. The
musical meaning is embedded 'behind' the symbol, not as part of it -- not
until it becomes contextual. Allegro ma non troppo has no use without its
context, and so why not let us set the context? The default context would
be the typical use, so in effect, nothing would seem to change.
The hierarchical way in which the software is set up (texts, lyrics,
musical symbols, expressions, articulations, other texts...) just gets
messy, as we experience every day. There are all sorts of lists and
arrangements of items that attempt to address musical functions. So we
start dividing what is attached to notes or measures or staves or systems
or pages or documents, with no intuitive way of understanding how to change
those actions. We just talked about how to move page-attached texts
elsehwhere. The struggle with the time signature swamp is always with us.
Trying to use articulations from other font sets, or combined
articulations, is a huge pain. Multi-line expressions are a problem to
create (unless that's been changed past 2K3). There's no easy way to make
any given object a stretchiness or smartness. Duplicating an articulation
as an expression or text item is impossible, so it has to be created again.
The possibility of floating anything anywhere (so often needed) is always a
problem ('oh, we've got to make that a real rest'). All that icky ossia
business.
We could follow the logic either way -- that we further subdivide how these
symbols work. A tempo indication is very different from a psychological
expression or a section marking ... but they're all expressions attached to
measures. At some point a decision is made to group one batch of things,
but not others. And, it seems to me, there's no longer a really good reason
for that kind of grouping if a simple way of entry and presentation is
offered ... one that is always visible, and is faster and clearer than the
mess of context menus, dialog boxes, and lists of expressions and
articulations and lyrics and texts that we have now.
To me, it makes more sense to render almost character-based as text, and
then assign its musical parameters as needed -- rather than having the
parameters inherent in the programmer's idea of how a group of characters
are supposed to work.
I think jef has made a well-wrought case. My only reason to jump in was to
suggest re-thinking the *entirety* of these entries and perhaps get a
unified and transparent palette out of it as a nice consequence.
Dennis
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale
[Finale] new and improved text tool
hi all,
i am submitting a proposal to CODA, and invite
your additions: please feel free to let me know
if there are things i have missed which you feel
need updating, improvement, implementation, or if
you feel certain points i have made need to be
altered, clarified, or otherwise edited.
disclaimer: i am not interested in starting an
endless slew of commentary concerning my view
vs. your view and who should decide what is
right. while i will certainly not claim to
have some sort of uniquely enlightened and
perfect vision of the situation, the list is
compiled according to what i believe to be
necessary, what i feel the priorities are (some
proposals are in fact elaborations of others'
ideas already voiced on this list). wherever it
might seem to be possible (it usually is), i have
proposed user-definable variations so that the
(new) Text Tool might suit all users' needs.
1) if you wish to simply voice your support of
the proposals, please contact me privately (tell
me your full name, what you do - composer,
educator, publisher - , and your web address) and
i will be happy to include your name on the list
of undersigners when i send the message to CODA.
2) if you disagree with the nature of the
proposed changes, please bring up the issue on
this list, your comments will certainly be taken
into consideration as i edit the message before
sending it to coda.
3) if you disagree completely with me, and wish
to tell me nothing more than you've got it all
wrong, i instead invite you to compile a list of
your own concerns and submit it to coda, thus
sparing us both of a needless waste of time and
energy.
n'hésitez pas de commenter en francais.
ihr könnte gern auf deutsch kommentieren.
jef
** as this message is already quite long, please
quote only those points you are directly
responding to and remove all other non-relevant
bits of text from the reply.**
--
Dear CODA/MakeMusic,
Finale is close to being able to provide a
professional level of typographical control for
publishing. The overhaul of the Expression Tool
in F2004 was by no means unimportant, however
there are several issues which I believe would
render those improvements more complete.
Implementation of the following issues will, in
my view, turn current discussions of
greatly-needed and welcome additions and
improvements into discussions of revolutionary
improvements regarding the Text Tool.
The following is what i would love to read in the What's new in Finale 200?.
jef chippewa
PS before submitting this list to you, the ideas
were hashed out on the Finale List
finale@shsu.edu, managed by Mr Henry Howey.
--
THE NEW TEXT TOOL
Because of overlapping functionality, the
previous expression tool and text tool have been
combined into one powerful text tool which offers
all the previous features of both tools, albeit
with some revolutionary improvements.
The term Text is used to indicate an
individually-defined item in the Text List,
whether it contains an individual character (such
as dynamics), a word or string of words, or one
or more paragraphs.
GENERAL
* Text can be assigned to an individual note or
measure (as with the old Expression Tool) or to a
page or range of pages (as with the old Text
Tool).
* Once assigned, default positioning of the
individual Text can be altered or overridden, by
double-clicking the text's handle in the score,
clicking override, and redefining the
positioning (this does not affect the original).
VIEWING
* In order to assist the user in improving use
available monitor space, and to increase
efficiency in searching and maintaining the Text
List, the dialogue box for the Text Tool now has
a larger default size, in addition to being
resizable, both vertically and horizontally. The
size and position of the Text Window is saved in
the Finale preferences.
* The user can define the number of expressions
visible in the Text List dialogue box (definable
in the document options [text]: view n lines /
view full vertical screen / other?).
* The height of the individual item lines in the
Text List has been increased by 25-50%
(previously, any Text above 14pt fixed and many
music symbols - usually 24pt - were only
partially visible). The user can define the size
of the lines in the Document Options [Text]:
{smaller, small, normal, big, bigger}; or as a
percentage of the default size {50%, 75%, 100%,
150%, 200%}
* Clicking on a Text in the list displays it in a
vertically-scrollable box to the right of the
settings instead of opening a separate dialogue
box (i.e. it now functions similar to the
Document Options list).
* In the Text Designer (previously Text
Expression Designer), the Text and Playback
definitions both appear when clicking on the
Text Definition tab, and the Note Positioning
and the Measure Positioning definitions both
appear when clicking on the Positioning tab.
* Font settings for the individual Texts are no
longer a
