I wanted to use Pitch Name Noteheads in a non standard way, for design purposes. So I created custom notehead sets, each with a copy of a factory pitch name notehead, reusing the original composite (such as comp.noteheadBlack etc…).
With this I produced (with hidden stems):
Then I selected some of them:
Then I switched to engraving mode, activated Hide Notehead on the selected ones that I then unselected:
Indeed the composites used by the Pitch Name Noteheads have an undelying glyph.EmptyBlack (whited!), because the SMUFL Note Name Noteheads arce cut-outs, and the “empty” glyph is necessary to avoid seeing the staff lines and/or leger lines through the name letters. Apparently after hiding the noteheads, the “empty” glyph remains visible, and here hides what I did not want hidden.
Is that really the expected behavior? Inasmuch as the “empty” glyph is an integrated component of the composite used for the notehead, I would have expected it to be hidden along with the Note Name Notehead glyph?
I can’t speak to how this is designed, but if you wanted to hide certain noteheads, couldn’t you just change those back to the default set first?
1 Like
Well, this is not what I am after. I am trying to build a visual simulation of the keyboard of a harpsichord, or piano, or marimba…, I would like all the notes to be already present with their names but hidden by default, and to be able easily to show some of them (it could be the notes of some chords for instance) just with the Hide notehead engraving button, without any actual changes.
Just an experiment 
Thank you for your interest.
I know you’ve started a few threads about the kind of visual things you’re trying to do with Dorico, and I admit that I don’t quite see it all myself! But looking at your images again, I do see where you’re going with this one.
If the goal is to be able to show and hide these noteheads easily, you could create two user scripts: one which changes the notehead set to default and hides the noteheads, and another which changes the notehead set to pitched and shows the noteheads. Then it’s still just one action to hide and one to show; you can invoke these user scripts either from the Script menu or from the jump bar.
1 Like
For the moment, I would like to know if I was right in my OP to expect the behavior to be different and to show a clean keyboard in the middle of the third image, without the white blobs. If I was right, then I do not see the point of writing scripts to do something which is currently achieved by one mouse click, on Hide noteheads!
And I would need more than a couple of scripts, because for the Pitch Named noteheads I can only use “singleton” sets, since there is no way dorico could select the right name, the noteheads here are not real notes on a real instrument staff (the staff is not a percussion kit, it is a normal instrument with a one line staff, and there are only 2 notes which do not matter at all, they only need to be one on the actual staff line, the second ont the first upward leger line)! As a result I need at least 12 singleton notehead sets each with one notehead, and even 36 to cover things like E#!
I know that when the script engine is brought to full fruition, the script could do the detection, but from what I read from Daniel, we are not there yet 
. And that would make for a very complex script.
If I am wrong about the question at the beginning, or even if I am right,but the fix would not be immediate, I already have plan Bs for my current endeavors, workarounds where I make a lighter use of the Pitched Named noteheads and do not need to hide them, so I am not stuck. But if I am right I could have a process flow that I would vastly prefer,
I might post some example of what I am trying to achieve (some time…)!
I would expect the same as you – “Hide Notehead” should hide the whole notehead – but it looks like that’s not how Dorico works right now.
Ah, okay, I missed that.
Well, you would only need one script to hide the existing notes, because a hide script wouldn’t care what notehead set is in use currently. But yes, in your setup I guess you would need one script for each key you wanted to unhide, since each one needs a different notehead set.
For the moment I am going to wait for an answer to the question:
- The current behavior is the right none
- The current behavior is a glitch and it will be fixed soon
- The current behavior is a glitch but it will need time
And in the mean time I will use my plan B !
Again thank for your interest and support.
P.S.: I seem to have miskatenly set this topic to resolved. Is there a way for me to undo it?
Yes – go to the post that you marked as Solution, and click Solution again to un-mark it.
The problem with hiding the composite notehead is caused by the glyph noteEmptyBlack. If you create a custom notehead consisting of just this glyph, assign the custom notehead to a note and try to hide the notehead, it will not hide. Only the development team can say whether this is the expected behavior or not.
However, there is a workaround. If you create a composite notehead consisting of the glyph timeSigMinus with its Y-Scale set to 70 and its Color set to white followed by a glyph in the range between noteAFlatBlack and noteGSharpBlack with its X-Offset set to -6.7, you can assign this notehead to a note and when you try to hide the notehead, it will hide.
I have created a project which uses this workaround:
Here is the project:
Keyboard Demo.dorico (468.2 KB)
3 Likes
!
I can’t believe it: I spent one day trying for this. I thought that I did not need to protect the whole empty note, but only the location of staff and/or leger lines., so I had to fin a kind of hyphen glyph.
I did not know about timeSigMinus, so I tried to replace it by 2 legerlines appropriately scaled and translated. Having 2 components to manage at a time was too much for me, I gave up after trying to combine offsets and attachments.
And I thought: “I am not going to beg John to do it for me!”.
I am not even sure I would have got it right if I had found timeSigMinus. 70% is reasonable, but -6.7? 13,4 is just a bit under 14.3, is that it?
Did you just computed the whole thing in a couple of hours?
It is good to have superheroes around to help.
2 Likes
Let me explain how I arrived at the Y-Scale value of 70 for the glyph timeSigMinus and the X-Offset value of -6.7 for the black note name glyph. I created a notehead consisting of noteEmptyBlack followed by timeSigMinus with its Color set to white. I adjusted the X-Offset and Y-Scale of the second glyph in order to make it as large as possible while remaining inside the first glyph. Here is the result with the Y-Scale set to 70:
To determine the widths of the glyph noteEmptyBlack and the reduced glyph timeSigMinus, I created a notehead consisting of two instances of the same glyph in different colors with the Y-Offset of the second instance set to -1. I adjusted the X-Offset of the second instance until it was aligned with the first instance. Here is the result using two instances of noteEmptyBlack with the X-Offset set to -7.15:
And here is the result using two instances of the reduced glyph timeSigMinus with the X-Offset set to -6.25:
The average of the two X-Offset values is -(7.15 + 6.25) / 2 = -6.7, so this value allows the reduced glyph timeSigMinus to be under a black note name glyph while remaining centered horizontally.
4 Likes
Masterful again.
Personally I hate the symbol editor UI, I particularly hate the attachments, and by browsing through the forum I think I am not the only one in that case.
The attachments are useful when you build something puzzle like like the monsterClef for Fred Gunn’s monsterStaff, and even the reduced notehead you helped me with before. But when you just need to use ZOrder to stack components, they are a pain in the neck. You had to fight the attachments to find what could be simple offsets if the attachments could have been disactivated, If I get it right, for all .the images here, when you added the second glyph it was stuck unnecessarily to the right of the first one, and you had to find the resetting offset by trial and error (unless there would have been some stem info would help you). Am I right?
But this a good lesson in making do with a difficult tool.
Again thanks a lot, and kudos.
