Master Palette and Symbols
This Feature Request is in two parts. It was prompted by a discussion on graphic control of symbols and objects (wherein I was led to make some erroneous assumptions for reasons explained therein). As a result of more experimentation and a closer examination of how the Master Palette works, I would like to request that some thought be given to its structure and function. In my view, as presently constituted the Master Palette needlessly duplicates access to a great number of elements, and at the same time contains elements/objects of different classes which do not behave in the same manner.
In comparing the content of the Master Palette to that of the Main (F9) Palette, I have found that all of the categories except Symbols exist by default in the Advanced workspace of the Main Palette. This would be understandable if, in fact, those categories contained additional elements not contained in the same categories in the Main Palette, but for the most part they do not. There is a very small number of 'extras' within those categories in the Master, and they are such things as extreme and rarely-needed dynamic marks (pppppp, for instance), but most of the categories house the identical content already found in the Main.
That said, the obvious question is, 'Why does MuseScore need a separate Master Palette at all?' Surely all the extra coding required to produce it as a separate entity could have been avoided by simply adding the ONE unique Master category--'Symbols'--to the Advanced Workspace list for the Main Palette.
The second objection to the way the Master Palette is structured is that it contains two classes of elements which behave differently: those which act upon the score and affect playback and notation (in essence, everything except 'Symbols'), and those which are simply graphic objects that do not act on the score in any way other than visually (everything in the 'Symbols' category). This combination of different classes of elements within one database strikes me as questionable, and for the user, it is less than intuitive. I consider myself a fairly experienced user, but this dichotomy of logical organisation only became apparent to me upon close examination after my intuitive assumptions were called (thankfully) into question.
So, Part One of this feature request is to re-evaluate the necessity of maintaining the Master Palette at all, and consider re-vamping it as a sort of 'Insert Special Symbols' palette which would contain only elements not needed for most ordinary use-cases, and not available elsewhere in the program.
As an alternative, the 'Symbols' category could simply be added to the Advanced Workspace in the Main Palette, and the Master Palette could be done-away with entirely. Or, although I don't like this one much because it would bury Symbols one layer deeper, a third built-in workspace could be created--'All Elements', similar to 'All Instruments' in the Instrument list workspace--and Symbols could appear in the Main Palette list only when that workspace is selected.
Part Two of this feature request will likely make the code crew's blood run a bit colder than usual, but I think it is important.
In that modern scorewriters support such things as playback and automatic transposition (whether for clef changes, time-signature changes, or concert-pitch vs. transposing instrument notation), it strikes me as important that any symbol MuseScore offers which can be placed upon a score should be more than just an image object. It must be an active element that affects the score in the same way as all the current elements in the Main Palette already do. So when I choose the 19th-century C-clef or one of the Petrucci clefs (images currently available), dropping that clef onto my score should do more than just look good. It should cause the notation which follows it to be transposed clef-wise to match. At present, if I need to use one of those archaic clefs for a historical edition, I must place the modern equivalent on the score first, make that invisible, and then position the historical clef on top of it.
I do not know how difficult it would be to enable active behaviour for all of the symbols currently in the MuseScore repertoire, but I think the need is there to consider it. Given that MuseScore already supports active behaviour for two hundred and fourteen Bagpipe embellishments (and although I love the bagpipes and dream of playing them one day, these are not elements required by the average MuseScore user on a daily basis!) it seems logical to think about doing the same for all the rest of the relatively arcane symbols the program offers.
Comments
I think the main point of the Master Palette is so you can populate a custom palette if you wish to start from scratch, or replace something you inadvertently deleted.
There is no way we can reaosnably support complete semantics for everything in the the symbols palette. they are really treated as just that - symbols only, characters from a font that just happen to look like musical symbols. MuseScore has no real concept of what most of them mean. Only a handful *happen* to also correspond to elements that MsueScore does understand. But I don't understand the value of having MsueScore go to all the trouble of noticing which of those symbols happen to correspond to things it understands. If MsueScore understands it, then it exists somewhere else, Just add it from there, don't try adding it from the symbols palette. Sometimes you *want* to be able to add a symbol and *not* have it be interpreted normally; we wouldn't want to remove that ability. or, you might want to be able to attach it in a way that isn't normally supported (like attaching an accidental to a barline) - what should the semantic be then?
If there is some clef you need form the symbols palette that MuseScore doesn't understand, we don't need to complicate the symbols palette code to special case that - we simply need to add that clef to the regular clef palette.
In reply to I think the main point of the by Marc Sabatella
;o)
As I suspected, making all those symbols 'active' would be enough to drive all you guys round the bend for the next several years. I don't want to ask the 'possible but ridiculous' from you.
Do you think it would be possible to make a judicious selection from among the 'dumb' symbols currently offered in that palette, and add them to the 'regular' palettes so that they would behave as expected? The sorts of symbols I'm talking about are those which (should) have a major local incidence on what follows: clefs, primarily, but possibly some of the other graphics I haven't yet thought too hard about.
In reply to ;o) As I suspected, making by Recorder485
I'd say, put forth the list of things you'd like to see. I mean, we already pretty much all the clefs that appear in modern music, but if there are some specific ones older or experimental ones you see a need for, I don't think it's unreasonable to add support for them. Adding support for another clef is pretty easy. Same with another articulation or another notehead, etc.
In reply to I'd say, put forth the list by Marc Sabatella
Regarding the master palette, it has several purposes
* let users compose their own palette
* Add to the score a symbol they will never use again, they just want a ppppppp now for this piece.
* Create new key signature and new time signature
I understand your concern about Symbols vs non Symbols under the same UI. However, I also believe it's good to have everything the user can add in a custom palette (except images...) under the same dialog. I'm not a fan of having the time and key signature creation in the master palette either but again, I like the ability to have everything in this dialog... This could be resolved with menu entry for key sig and time sig, just like we have Shift+T and Shift +K shortcuts.
Regarding more "active symbols", I'm definitely in favor of adding more SMuFL clefs, noteheads, articulations and ornements (fermatas in particular) as plain MuseScore elements. It's hard to do in the 2.0.X serie without breaking anything or adding a lot of ugly compatibility code but I can imagine doing this in the next major release.
In reply to Regarding the master palette, by [DELETED] 5
I wouldn't expect this major a revision to happen in 2.0.x; I realise it will have to wait until 3.0 and that there could be some compatibility issues for scores created using earlier versions.
But please tell me what you think of this proposal:
1. The few 'extra' active elements contained in the individual palettes (the 'pppppp' and 'fffffff' sorts of things) of the Master could be added to the individual palettes in the Advanced workspace of F9.
2. Then the 'Master' could be renamed 'Special Symbols' and consist of ONLY those symbols now housed under 'Symbols', things which are not available elsewhere. That would give this 'palette' a unique utility, instead of having it overlap by 80% the material in F9.
3. Better yet, that huge, rather disorganised mass of symbols could be categorised under several headings, such as 'Percussion', 'Noteheads,' 'Pitch modifiers,' 'Stops and ranks,' 'Lute," and so forth. It would make finding and selecting a special symbol much easier for the users.
I agree with you about the custom time signatures and key signatures not belonging in the palettes of the 'Master'. They should indeed be accessible through a properties dialogue, menu, or shortcut, or possibly via a special icon in the appropriate section of the F9 palettes.
In reply to I wouldn't expect this major by Recorder485
Again, we need the master palette to be fully populated as it is for use in building custom palettes. We can't have it only be symbols; there would be no way to restore, say, the "real" fermata to a palette.
As for organizing the huge list of symbols, yes, that would be nice. But hopefully you have noticed you can search it using the box at the top of the window? It should actually be pretty easy to find all clefsl; just type "clef". But of course it isn't always easy to know what to search for.
I do agree it seems "messy" to have the custom key and time signatures in the master palette. I'd definitely be interested in hearing alternate proposals for hwo that might work.
In reply to I'd say, put forth the list by Marc Sabatella
@Marc Sabatella:
For my work, the first thing that springs to mind would be the historical clefs and time signature symbols.
In the case of the '19th century' C clef (a misnomer; it was used frequently in the 18th century), the existing clef symbol is not 'positioned' so it would be necessary to create versions on the first, second, third, and fourth line of the staff (soprano, mezzo, alto, tenor). I have not yet had occasion to use a Petrucci c-clef, but might one day need to do that, so those would be on the list as well. The '3' time signature symbol is too big; but the alternative symbol
is too small. 18th-century French music used this frequently so I would like to have a properly-sized working '3'.
Except for the percussion symbols (which, like staff text, do not need to be active unless we are worried about playback, a strictly secondary consideration), you are correct in noting that many (most) of the symbols in that special palette are exotics that would be required rarely; I wouldn't expect you to make them all 'active', but stopping with my own short list wouldn't be a good idea, either. My needs are centered around historical material from the 16th, 17th, and 18th centuries; specialists in mensural or neumatic music will have other needs, as well specialists in ethnic music and composers of 'modern' music. Is it possible (or practical) to 'activate' such things as the 'Quasi-random squiggle' symbols?
I don't know, but you would. ;o) Just throwing out some ideas, here....
In reply to @Marc Sabatella: For my work, by Recorder485
Preumably the clefs should be easy, so thanks for the list. But I don't understand what semantics you would expect for the squiggly line. Does it take the place of a note with a specific duration?
In reply to Preumably the clefs should be by Marc Sabatella
I haven't got the least personal interest in that squiggle; it's not the sort of thing Bach, Geminiani, or Barsanti used very often. ;o) I only mentioned it because MuseScore needs to meet the needs of people who work with other types of music than I do. Possibly some 21st-century Stockhausen or Cage might need to put something like that in one of his scores as a way of telling the cellist to 'let your fingers do the walking....'
Alfred Blatter (Instrumentation and Orchestration, Schirmer, 1997) shows an example of the use of the squiggle on p. 40 of the second edition, to indicate a vibrato which varies in speed and width simultaneously.
*
*
*
*
But I still can't imagine how you'd 'activate' that symbol, and even if you did manage, it would only affect playback. It has no incidence on the notation under it. I wouldn't give it a high priority....
In reply to I haven't got the least by Recorder485
Exactly. And this is true for 90% of the symbols on the palette - they don't *have* specific defined semantics that could possibly make sense to implement. Which is why I'm looking for a list of of symbols that *do* have clearly expected semantics and that there is a real world need for. Some of these - like adding clefs - should be easy. Others - like adding support for the two-measure repeat sign - have clearly defined semantics and there is a real world need for but aren't nearly so easy. Still, I'd rather hearing about symbols like that than symbols with no clearly defined semantics, or not real world need, or neither.
In reply to Exactly. And this is true by Marc Sabatella
Well, good. We're on the same page, then.
I've looked through that set of symbols a few times now, and although there are a fair number of them I have never seen before (and don't have a clue about their use), I have provisionally divided them into three classes:
1. Symbols which should have an active effect on the notation which follows, and which consequently also should affect audio playback. Clefs and time signatures are the two biggies in this class. These need to have their 'semantics' defined and implemented.
2. Symbols which do not need to affect the program's recognition/generation of the notation itself, but which could affect the audio playback. Articulation, ornaments, pitch-bends, squiggles, acoustically-defined pitch alterations, dynamics, non-standard accidentals, and other similar elements. If the soundfont can support the meaning of these symbols, their audio semantics could be defined, but as a second priority. Otherwise, the only semantics these need to have defined and implemented are for size and placement; they should 'snap-to' a default offset from the anchor note or rest selected, instead of having to be placed manually with the mouse or the inspector. And they should be sized according to the staff scaling, unless that box is unchecked on the symbol's properties dialogue.
3. Symbols which have no incidence on notation and no practical incidence on audio playback (i.e.: the indicated sounds don't exist in the soundfont), and thus can be treated as nothing more complex than pictographic staff or system text. Most of the percussion symbols (mallet types, gunshots, board-clappers, cannon shots, etc.) are in this class, as well as all the specialised marks for organ, accordion, lute, harmonium, etc. These need only a way to control their size and placement, similar to formatting staff text. (It would be really cool if they could be dropped into a staff- or system-text box and then sized point-wise by using the text editor...!)
What have I missed, so far?
In reply to Well, good. We're on the same by Recorder485
Again, clefs *already* have their semantics defined - when added from the clefs palette. When added from the symbols palette, they are supposed to just be symbols, so you have the freedom to add them without their semantics in cases where you want that. So we aren't discussing inventing semantics for elements on the symbols palette; we are discussing which elements that currently only exist on the symbols palette would be good candidates to also have on the regular palettes. Where "good candidate" means, again, there is a clear meaning everyone would agree on, and a real world need for the symbol to exist there.
So the questins again is, *which* clefs, articulations, etc have both of those properties?
One thing that might not be clear: the symbols in the symbols palette are mostly not provided by us. They are just the characters that happen to be in the Bravura font, defined as part of the SMuFL standard and provided by a third party. They add symbols all the time. We have no special knowledge of what they are or reason to beloeve that just because a symbol exists on the Bravura font hat there mist be a reason to include it on anything but the symbols palette.
In reply to Again, clefs *already* have by Marc Sabatella
I guess the short answer is, the symbols I placed in the first of the three classes defined above: Clefs and time signature symbols. There are actually relatively few of each that aren't duplicated in the regular, working palettes, but those that aren't seem to me to be important ones to add to them.
The longer answer would remove decorative-only clefs from that class. I don't think we need active semantics for an upside-down flopped F-clef, for instance (but maybe someone will tell me I'm wrong?).
I will work out a detailed list and post it to see if anyone has additions or objections.
And thanks for the clarification on where all those symbols came from; I had not bothered to think about the souce of the font itself, which I really ought to have done given my background in graphics.
In reply to I guess the short answer is, by Recorder485
Regarding the grouping of SMuFL symbols, we did it for text elements (create a text, then press F2 or the alpha button in the bottom left). You should find the same symbols than in the Z palette but to be used in text. Here the list is not searchable... but categorized.