Using special characters for a line's begin/end text
Anyone have a nice methodology for doing so?
Problems I've come across:
There's no access to special characters while typing into line Begin/End text like when doing so with staff-text as far as I am aware. The Master palette doesn't work while inputting line begin/end text. And if I make a staff-text, select a special character such as a right-arrow and then try to copy and paste it, the result becomes something else besides what I copied (like a box with ? or something like an oriental character)
Because of these problems, I end up copying from a document editor the symbol I want and paste into the line begin/end text and it usually works. Hoping maybe there's a better way...
Comments
In version 2 you could put the name of a symbol in brackets and it would be included, in version 3 this is only for special items like pedal symbols among others.
In version 2 you could put the name of a symbol in brackets and it would be included, in version 3 this is only for special items like pedal symbols among others.
In reply to In version 2 you could put… by mike320
The syntax you want is
where any of the standard SMuFL symbols can be used. I don't think there is is a way to access non-SMuFL symbols (eg, Unicode symbols). Was there really a way in MuseScore 2?
In reply to The syntax you want is <sym… by Marc Sabatella
I copied and pasted what you just posted into the begin text of a line and got a left arrow in version 2. Apparently I've been trying the wrong symbols in the past when I tried to do this in version 3. Copying exactly what you posted does work in version 3.
The hover text is not the same as what you typed. Is there a good source for SMuFL names?
In reply to I copied and pasted what you… by mike320
Where are you seeing "hover text" - and do you mean a tooltip? I don't see any for the text of a line. I see it for instrument names but that has special handling I think.
Best place I know to get SMuFL names is from the SMuFL spec itself - https://w3c.github.io/smufl/gitbook/. See the "Glyph tables" section, for example.
In reply to Where are you seeing "hover… by Marc Sabatella
The tooltip in the master palette when you hover over the arrow you used as an example.
MuseScore definitely uses a subset. I think there are almost as many categories in the standard as there are glyphs in MuseScore.
In reply to The tooltip in the master… by mike320
The tooltip text there is the human readable (verbose) form,
In reply to Where are you seeing "hover… by Marc Sabatella
Hrm, maybe in the Master Palette the SMuFL names should also be shown tastefully to aid in doing this sort of thing? Thanks for the syntax pointer.
In reply to Hrm, maybe in the Master… by worldwideweary
It should be built into MuseScore somehow. This is the type of thing I would never worry about discoverability for. I tried right clicking a glyph and chose properties in hopes the SMuFL name was there - no dice.
In reply to It should be built into… by mike320
I notice that a function Sym::id2name(SymId id) exists which returns a char* to the SMuFL name (the exact names used). That's to say, it shouldn't be difficult to grab the symID from hovering over the master palette items, and then in the right-click menu include a function option like "Copy SMuFL name-tag to clipboard" and have that actually add along with the SMuFL name to the clipboard. I think that would make sense, but not sure how others would think about it.
In reply to I notice that a function Sym… by worldwideweary
I like right click but it seems someone who makes decisions wants to forget the right mouse button exists.
In reply to I like right click but it… by mike320
I'm not sure where you got that idea, as far as I know everyone involved in design and development does like using the context menus and putting things in there where appropriate. But there definitely are valid reasons to say this should not be the only way to do something. We fail that test a few places - some things like the piano roll editor and image capture require use of the right click menu, and that's a big part of why many people never figure them out. But where it can make some functionality that is also provided elsewhere easier to access and doesn't make the context menu too crowded to be useful, I can't recall anyone ever objecting.
In reply to I'm not sure where you got… by Marc Sabatella
There seems to be a systematic attempt to remove everything possible from the right click menu. I don't want the right click menu to be the only way to do anything but I would rather use the right click menu than be forced to go to the inspector for every little thing I need to do. My mouse is already over the note, now I have to move it all the way across the screen and select the palette to do anything. I keep the palettes, inspector and selection filter tabbed at all times as do many other people.
In reply to There seems to be a… by mike320
Well, if you mean that we want as much as possible to be doable via the always-available Inspector rather than require the extra work and disruption of having to discover and bring up a special purpose modal dialog, interact with it, guess at the result, then close it to see how your guess works, that’s true. The idea is to make things easier to find, easier to access, and easier to work with. I’m not understanding the sense in which this is anything but an objectively good thing?
Anyhow, if that’s all you meant - moving property settings from hard to find and awkward modal dialogs and into the Inspector, that much is true. And it’s not just certain people favoring this, it’s pretty universal. I thought you were referring to commands being taken and moved to a place that was harder rather than easier to access. And that’s why I was confused - I’m not aware of any such cases.