Template talk:Music

Template:Accidental & Template:User Instruments List

Per the discussion on Wikipedia:Manual of style (music), I've put what was at Accidental here; moved the user box to Template:User Instruments List (discuss at Template talk:User Instruments List) and moved the newly created "Music portal" navigation box to Template:Music portal. -- Myke Cuthbert (talk) 15:49, 10 July 2007 (UTC)

alternate notation for sharps and flats

What do you think about supporting {{music|#}} and {{music|b}} (using the number sign "#" and letter "b") as alternatives to {{music|sharp}} and {{music|flat}}?--Dbolton 21:56, 10 July 2007 (UTC)

I think it's a great idea. The only thing we have to be concerned about is whether we might want to reserve "b" for the note--I know I've had that issue with building little music grammars before. But I think that it's fine to give it up, since if we are going to do notes, we'll probably do "note|b" or something like that. Myke

I decided to hold back on the {{music|#}} and {{music|b}}, but added support for Unicode flats and sharps, i.e. {{music|♯}} and {{music|♭}}. This should make it more convenient if you are converting a page of Unicode sharps and flats.--Dbolton 17:02, 16 July 2007 (UTC)

Actually, I'd say let's go with # and b for now, so I can convert some pages which use that notation also. I doubt the double-flat, double-sharp notation will ever be used, but bb and ## perhaps? Reminds me to start getting the ^1 to ^8 working as well as some Roman numerals. -- Myke Cuthbert (talk) 17:47, 16 July 2007 (UTC)

Protection?

Perhaps page protection would be appropriate for this page if most important changes have been made now? I'm sure it will have very extensive usage at some point in the near future. ck lostsword•T•C 14:33, 20 July 2007 (UTC)

I would agree with semi-protection, but at present full protection would probably be counter productive. The template isn't yet used in that many places and hasn't had any vandalism (knock on wood). Most importantly, it's not close to finished and the major contributors to the template aren't administrators, so it would prevent further contributions. -- Myke Cuthbert (talk) 22:08, 20 July 2007 (UTC)

No problem for now - just an option for in the future :). ck lostsword•T•C 22:24, 20 July 2007 (UTC)

Example

This is a very cool template and I applaud your efforts. My only problem is in the "sample text" under the heading "Notes and rests". That looks like a clear place where prose should be used, not characters. It's bad style to write in that way, even if one can. Can someone please think of a better example of their use? I'll ponder it as well, but nothing is immediately coming to mind. Mak (talk) 16:04, 20 July 2007 (UTC)

I'm happy to find a piece of text that would be a better demonstration that we can agree on--I just put something quickly that came to mind. If I were actually writing, I would spell out "whole note." However, there is a movement to use symbols more often within text--Edward Tufte devotes a chapter to it in both his first (?) and fourth books on design. I don't think that there's any better way to convey the syncopated rhythm in the second half of the sentence. Saying "eighth rest, half note, quarter note, eighth note" is far too bulky and would slow down a musically literate reader, while the figure is too small to justify using an external figure. The Bach font encourages such uses [1]. Looking at the book next to me, Allen Atlas's Renaissance Music, I see these uses on pp. 50 & 51. Christopher Hasty also embeds metrical examples in text in his Meter as Rhythm (Oxford; first usage, coincidentally, also on pp. 50&51). And the first theory book I looked at (Clendinning and Marvin) does also. I'm more finding these examples to satisfy my curiosity than to refute you--I've embedded rhythms within text in just about every article I've published, and wanted to make sure that I wasn't alone. In double-spaced contexts I've also embedded whole staves of music within text, but it just doesn't look right in single-spaced writing. Best, -- Myke Cuthbert (talk) 22:08, 20 July 2007 (UTC)

Yes, when I looked at it again I realised that the latter rhythm would be awkward as prose, but the use of the whole note symbol definitely threw me off, and feels like bad style. Perhaps just change the whole note to text? I'm glad to know of other inline uses of rhythmic notation, though. Mak (talk) 22:42, 20 July 2007 (UTC)

I modified the sample sentence per Mak's suggestion.--Dbolton 02:51, 21 July 2007 (UTC)

Firefox change?

Has anyone else noticed a change in behavior on Firefox? Now all the music symbols that don't use this template are displaying as "?" on my system instead of the proper flats and sharps. Is it just my system? I certainly didn't uninstall any fonts. -- Myke Cuthbert (talk) 04:02, 28 December 2007 (UTC)

Odd. I haven't noticed this myself. Does the behavior continue after a system restart?--Dbolton (talk) 05:34, 28 December 2007 (UTC)

It seems to come and go; a restart seems to help -- and actually, if I leave the page open for a few minutes, after awhile the flats appear. Maybe it's a memory leak in determining which glyphs are present and which are missing in the font. I notice that some of the ja:xxxxx links appear as ja:??????? at first and then resolve themselves into the proper characters. So it's probably not a pan-firefox problem. Phew! I did change a few articles to use the template anyhow, so that's probably a good thing.  :) -- Myke Cuthbert (talk) 05:51, 28 December 2007 (UTC)

Flats and Sharps

Are rendering squares in Internet Explorer 6.0. OK in Mozilla 3.0 Fefogomez (talk) 13:52, 9 July 2008 (UTC)

Flats and sharps appear as empty squares in Internet Explorer 6 and 7. Flats and sharps appear in Firefox 2.0 but are sub-standard. Firefox 3.0 has a lot of font rendering and graphics improvements so flats and sharps appear fine without the template. --Dbolton (talk) 21:02, 9 July 2008 (UTC)

Are you sure? It works perfectly in my Internet Explorer 7 so long as this template is used. (Actually my system renders it fine either way, but I know I have the Vista fonts installed on XP so it's an odd system). But the main point of the template at first was to get proper IE rendering of flats and sharps. If it doesn't work, we should change the output of the template to produce an image for flat, sharp, and natural, as it does for double-sharp and double-flat. -- Myke Cuthbert (talk) 19:28, 10 July 2008 (UTC)

Sorry for being unclear. My comment above referred to the status of sharps and flats without the use of the template. I am not aware of any display issues when the template is used.--Dbolton (talk) 06:01, 11 July 2008 (UTC)

Thanks! That makes things clearer. I was worried for a minute. -- Myke Cuthbert (talk) 17:55, 12 July 2008 (UTC)

Diminished symbol

I suggest we add support for the diminished symbols (°) and (^ø).

I believe this would require adding the following lines to the code, but I am afraid of breaking it.

 | dim = °
 | dimslash = <sup>&#248;</sup>

Jake the Editor Man _(talk) 17:14, 25 September 2008 (UTC)

I'm reluctant to add this unless there is a significant viewing problem that prevents the use of ° and <sup>ø</sup>. Plain Unicode text is clearer for editors to read and understand. --Dbolton (talk) 16:58, 26 September 2008 (UTC)

Oops, I missed that there were any objections and went ahead and added it -- it can be removed if it's a problem. I wouldn't have added dim alone, but since ø needs a <sup> tag to make it display properly, it seemed worth it. But I can be persuaded to remove them.

I also noticed that someone has created svg symbols for whole, half, and 16th rests; symbols which were missing before. So I went ahead and added them. -- Myke Cuthbert (talk) 15:14, 27 September 2008 (UTC)

Text size as EM

The SVG images don't scale with different font sizes. I suggest that EM be used instead of PX as the unit of measurement. SharkD (talk) 19:12, 2 January 2009 (UTC)

I just tested the em measurement to see if it would work but the syntax is ignored. It is not possible to use em measurements on a image (see WP:Extended image syntax#Size). --dbolton (talk) 22:33, 2 January 2009 (UTC)

We'll just have to wait until inline SVG images are supported by Wikipedia/browsers. SharkD (talk) 06:04, 4 January 2009 (UTC)

Symbols for cut time and common time

Perhaps a more realistic request: can we get symbols for common time and cut time? Something along the lines of {{Music|Cut}}? I was looking at Marty's book on Mozart's tempo indications and he uses those symbols within the text a lot. James470 (talk) 04:49, 26 August 2009 (UTC)

Symbols for half-flat and -sharp

Can someone add the Arabic half-flat and -sharp symbols ( and )? The addition would be

| halfb
| halfflat = [[File:Arabic music notation half flat.svg|9px]]
| half#
| halfsharp = [[File:Arabic music notation half sharp.svg]]

151.203.246.40 (talk) 19:56, 30 October 2009 (UTC)

Are you sure those are standard beyond the Middle East? I think Bartok and Penderecki used slightly different symbols. James470 (talk) 00:11, 31 October 2009 (UTC)

Actually, I have no idea. I just saw them mentioned in MoS:MUSIC and thought that, if they deserved mention there, they should have a place here. 151.203.246.40 (talk) 23:15, 31 October 2009 (UTC)

Before there are any edit wars over this (and there have been for much less), we need to be certain that: a) these are the symbols most often used for the purpose, and b) there is a real need to use these symbols within the text, as opposed to within music notation excerpts. James470 (talk) 02:19, 1 November 2009 (UTC)

The half sharp (sometimes confusingly also called quarter-sharp because it's a quarter-tone accidental) is becoming pretty standard; I could support going with this file; but the half flat is more commonly a reversed-♭ in contemporary classical and music theory texts. I don't know the Arabic music world well enough to know if the half-flat is totally standardized there. Other symbols exist and are commonly used for both sharp and flat. -- Myke Cuthbert (talk) 19:24, 1 November 2009 (UTC)

In Wikipedia:Manual of Style (music) both symbols are mentioned. At least the following articles refer to them: Quarter tone, Flat (music), Sharp (music), Accidental (music), Enharmonic genus, Microtonal music, 31 equal temperament, Arabic maqam, Arabic music, Arab tone system, Arab culture, Rast (maqam). So I think there is a reason to add the symbols to the template. The half sharp seems to be rather uniform, the half flat appears in two forms as a backward or a slashed flat. So we might want to include both (named bstroke and bbackward?). −Woodstone (talk) 22:29, 1 November 2009 (UTC)

For what it's worth, note that File:QuartertoneMaqams.png actually uses the reversed flat sign instead of the flat sign with stroke. James470 (talk) 23:57, 1 November 2009 (UTC)

I have seen more of the "d" (reversed flat) in western music that uses quartertones than I have any other symbol. On a side note, Unicode uses flags to show half-flats (U+1D132, U+1D133), LilyPond uses the reversed flat (and even has a "there is no standard for quartertones" disclaimer!), and the Melakartas that I have seen uses the slash. Not sure what laTEX uses though.

As for standardization at Wikipedia, I would recommend going with the western style reversed flat as "default" ({{music|halfflat}} = ), but allowing someone the option to choose the other symbols depending on the context ({{music|halfflat-arabic}} = , or something like that) and ({{music|halfflat-flag}}). Can't say I know what the 'perfect' nomenclature should be for this kind of use, but at least it leaves the option available for all the different styles until the music world standardizes on some symbol. - NDCompuGeek (talk) 14:30, 10 November 2009 (UTC)

I have put them in as proposed (named halfsharp, halfflat and flatstroke). They look rather larger than the other signs. I tried to adjust, but no effect. How do they look to you? −Woodstone (talk) 15:46, 10 November 2009 (UTC)

Um, yeah, wow. They do seem a bit big as compared to the other signs.... maybe use the "x12px" height syntax instead of the "12px" width syntax? I'm not real good with image syntax, so YMMV and take with a HUGE grain of salt and other miscellaneous disclaimers....

Also, what about having the options for "demisharp" and "demiflat" included? - NDCompuGeek (talk) 20:46, 15 November 2009 (UTC)

Additional quarter-tone accidentals

If we include the demiflat and demisharp symbols, shouldn't the sesquiflat (, [[Image:Llpd+1½.svg|x16px]]) and sesquisharp (, [[Image:Llpd-1½.svg|x16px]]) symbols be represented also? As with the demiflat, there is an alternative version of the flat sign with slashes (, [[Image:Llpd-1½_var.svg|x16px]]). - NDCompuGeek (talk) 20:46, 15 November 2009 (UTC)

Russian names?

User ESSch added the Russion names of the symbols in the table. Since this is a template in the English WP, this serves no purpose and should be removed. −Woodstone (talk) 01:56, 13 January 2010 (UTC)

And since this is the American Wikipedia, I would also like the British names removed as well. Have we anyone to argue for the removal of the American names as well? Good day, kind sir. ;-) James470 (talk) 06:58, 14 January 2010 (UTC)

I understand the concept of what ESSch wanted, since the template is mirrored in other language WPs, and would make updating easier there, but it is true that having Russian names alone in the template does not make sense. -- Michael Scott Cuthbert (talk) 00:42, 21 January 2010 (UTC)

Sure, whatever. James470 (talk) 05:46, 21 January 2010 (UTC)

Thanks!

To John Cardinal for making the documentation easier to read and more beautiful. And to Ford Prefect 42 for the addition of time signatures. -- Michael Scott Cuthbert (talk) 16:26, 6 March 2010 (UTC)

Superseded

If one goes to the image description page for File:Figure_rythmique_noire_hampe_haut.svg one finds that it has been marked as superseded by File:Quarter note with upwards stem.svg due to the fact that the sides are cut off. However, since all the notehead images used here have their sides cut off File:Quarter note with upwards stem.svg doesn't fit in and unless there are similar replacements for all it should not be used in this context. Hyacinth (talk) 08:37, 3 April 2010 (UTC)

Dotted half

Would it be terribly difficult to make ., such as for use in Symphony for Classical Orchestra? Or should I just kludge it with . ? James470 (talk) 02:55, 1 August 2010 (UTC)

I'd do it with the "kludge" method, because we don't have a full musical vocabulary, and . looks close enough. Otherwise we'd need double-dotted half, triple-dotted sixteenth, etc. eventually. -- Michael Scott Cuthbert (talk) 06:05, 6 August 2010 (UTC)

You're absolutely, totally right. I sometimes forget how Wikipedia likes to take some things to the logical extreme (and even illogical extreme) even after being confronted with reminders of this. I only foresee needing the dotted half for tempo indications, and I've never seen a composer indicate anything like M.M. ... = 100; but who knows, someone would come along and contrive a situation just for the sake of requiring such an otherwise unnecessary extension. James470 (talk) 00:44, 7 August 2010 (UTC)

Font choices

Edokter (talk | contribs) has been making changes to this template that I feel merit discussion here. See the page history. Lanthanum-138 (talk) 12:29, 29 March 2011 (UTC)

I assume you are referring to http://en.wikipedia.org/w/index.php?title=Template%3AMusic&action=historysubmit&diff=421159118&oldid=421132374 The choice of fonts is intentional, and researched extensively so you were correct to revert the change and bring the discussion to the talk page. (The Unicode template is designed for a more general purpose and does not meet our needs). Without the specified font choices the accidentals do not appear on Internet Explorer (which is the original purpose for creating this template). If there are problems with the current choice of fonts, please be specific: what operating system, what version, what browser, what browser version, which of these fonts do you have (or not have) on your system, etc.--dbolton (talk) 02:56, 6 April 2011 (UTC)

Scale degrees

Why are the scale degrees above where text lies and at a smaller font, especially when this makes it difficult to use them with any other variants of the music template such as accidentals, and while the math symbols with carets are below text lies? For example:

Music template: "The submediant in minor, or ♭, is..."

Math markup: "The subdominant, or ♭${\hat {6}}$, is..."

Side by side: vs. ${\hat {6}}$ vs. 6.

Hyacinth (talk) 15:21, 3 July 2011 (UTC)

I'm not clear. Are you saying that you prefer the Math markup or the Music template? Here's what it looks like to me: http://i54.tinypic.com/rt4a4g.png (Windows 7, Firefox 5) --dbolton (talk) 19:39, 3 July 2011 (UTC)

Dbolton's version is exactly what I see too (same OS), and I much prefer the music markup. -- Michael Scott Cuthbert (talk) 22:54, 8 July 2011 (UTC)

I understand it like this: regular text is positioned on an invisible baseline: _abcdef_. Letters like p and q stick below that line. Hyacinth asks why the musical 6 is sinking below that line, instead of on that line (as the regular 6 is).

My note on this: can be done, but the image would become smaller. In regular font size (browser not zoomed in), the image may become illegible. But we could give it a try. Math markup is even more irregular: it breaks up the line relularity (it pushes outward the text lines). For regular reading, that is undesired (ugly), but math needs it. -DePiep (talk) 15:15, 27 September 2012 (UTC)

No, I was asking why the musical six was above the invisible line.

The real reason is that File:Scale deg 6.svg has a bunch of white space at the bottom, as may be seen in the thumbnail to the right. Hyacinth (talk) 22:40, 27 September 2012 (UTC)

Who wants ♭ lining? -DePiep (talk) 22:19, 30 September 2012 (UTC)

I have adjusted the 9 image (as earlier images: at 200px height, it has 6px margin). Is this OK (before/after):

Music template: "Example texts: ♭  , is..."

Better compare: old 6:  new 9:  -DePiep (talk) 21:46, 8 October 2012 (UTC) (oops, I signed late)

Δ vs Δ

Resolved

Doesn't that defeat the purpose of the template? If one is just going to use Δ one could simply use it without the template. Hyacinth (talk) 22:15, 14 May 2012 (UTC)

It renders slightly differently: Δ (without {{Music}}) vs Δ (with {{Music}}). Double sharp (talk) 12:30, 15 May 2012 (UTC)

Those look identical. Perhaps its a difference in our operating systems or software? Anyways, good to know. Hyacinth (talk) 22:08, 15 May 2012 (UTC)

On my setup (Win7/FF) the former is an isosceles triangle and the latter is an equilateral. But I don't have an opinion pro or con for keeping it. -- Michael Scott Cuthbert (talk) 18:24, 19 May 2012 (UTC)

Resolved. This happened: internally in the template, all input is changed into lowercase before checking in the list. That way all input Sharp, SHARP, sharP, sharp is catched nicely. Now Δ is the Greek capital letter delta. It was in the list, but was not catched because the correct input "Δ" was turned into its lowercase "δ" -- no match. I have added the lowercase, it returns the delta as expected. Extra note: using the template for such trivial action (input = output) still is usefull, because this way the same font will be used as with other musical symbols. -DePiep (talk) 15:07, 27 September 2012 (UTC)

Oops again. I misread this early old post. It's not about the error (template did not catch input capital "Δ"). It was about the representation (so the error was temporal). Now that I see the essense, I can say: when in music, use this template. It will show the musical symbols well, even on other browsers (we cannot see oourselves). -DePiep (talk) 21:52, 8 October 2012 (UTC)

Beatles RfC

You are invited to participate in an RfC at Wikipedia talk:Requests for mediation/The Beatles on the issue of capitalising the definite article when mentioning that band's name in running prose. This long-standing dispute is the subject of an open mediation case and we are requesting your help with determining the current community consensus. Thank you for your time. For the mediators. ~ GabeMc ^{(talk|contribs)} 22:59, 22 September 2012 (UTC)

Time Signatures

I updated the Time Signatures to be serif and bold to better match real time signatures. I have a "pull request" on the underlying Lua code to make the numbers touch each other; when that request is completed, the template should automatically update to be even more accurate. -- Michael Scott Cuthbert (talk) 19:38, 27 January 2015 (UTC)

Mscuthbert, a question about the proper way to identify a time signature in prose (text of an article) came up during a recent GA review. An editor felt that a bold time signature in continuous prose, such as "many pieces in ³
₄ time were performed ...", looked awkward. This is more obvious when several are listed (see Time signature). A brief review of music reference books showed that time signatures were usually rendered without bold ( and often in the form of a fraction, i.e., "3/4"). Is there a way to defeat the bolding for use in text? —Ojorojo (talk) 15:11, 12 July 2016 (UTC)

Chiming in: serif & bold may be closer to engraved music, but it looks out of place in running text. The only way I know to avoid that is to use ordinary letters ("3/4") or the template:su directly (which is used after a detour via {{Time signature}} with bolded arguments by {{Music}}): {{su|a=c|p=3|b=4|lh=0.85em}} which gives: ³
₄. I would prefer something like {{Music|time_plain|3|4}} would do that. -- Michael Bednarek (talk) 04:20, 13 July 2016 (UTC)

I think this looks better. Editors should have the option to use a "time plain" template. —Ojorojo (talk) 13:47, 13 July 2016 (UTC)

Errors after December 9 edits

Hyacinth, your recent edits to this template have created {{error}} transclusions in three articles:

• Just intonation
• Ben Johnston (composer)
• Septimal quarter tone

Can you fix these? Thanks, Wbm1058 (talk) 16:31, 9 December 2015 (UTC)

Incorrect spacing

I noticed that the # and b signs produced by this template have considerable white space around them, making combinations like F# and Bb look like F # and B b (here not using the template to show different behaviours stably). So I modified the template with some negative margin. Other editors notified me that this does not work out correctly in all cases. Anyone suggestions how to solve this issue? −Woodstone (talk) 18:45, 2 May 2012 (UTC)

The old display may well be a bit excessive in its spacing, but the current version is worse (see above); please revert urgently. -- Michael Bednarek (talk) 02:46, 3 May 2012 (UTC)

I would like to revive this issue. The spacing of this template, at least in case of # and b, is incorrect and produces ugly excessive white space before and after the accidental.

• with current template: A♯ or A♭ or A♯m, good symbols bad spacing
• in plain text: A# or Ab or A#m, bad symbols, good spacing

I have tried to solve this issue a long time ago, but met resistance. Who can help to find a good solution? Woodstone (talk) 14:25, 9 January 2017 (UTC)

Here, using Firefox, Chrome, IE under Win-7 on a desktop PC, I see no excessive space surrounding the accidentals. Which browsers/operating systems/devices do you use? Could you show a screenshot? -- Michael Bednarek (talk) 00:57, 10 January 2017 (UTC)

I am seeing the screenshot of the lines above on Chrome on an Android tablet.Woodstone (talk) 13:15, 10 January 2017 (UTC)

Screenshot to show excessive spacing

Thank you for providing the screenshot and the description of your environment. I, too, see the extra spacing on a Kindle Fire and on an Android phone. It's now very late here and I can't pursue this any further at the moment, but I think it might have something to do with improper kerning data for the Unicode entities &#x266d; (flat) and &#x266f; (sharp), and possible as well for &#x266e; (natural). Testing this theory: how are these three unicode flats spaced for you: "♭♭♭" ? They should be similar to "bbb", and they are on my desktop. I'll look at them tomorrow on my phone. -- Michael Bednarek (talk) 14:03, 10 January 2017 (UTC)

These three flats are all similarly spaced as my screen shot above. Meanwhile I tried the default Samsung 'Internet' app. Results are the same as Chrome. Woodstone (talk) 15:22, 10 January 2017 (UTC)

They also appear spaced on my phone; each seems to be surrounded by some extra white space. This is probably caused by some misinformation in the phone's font data about the width of these Unicode characters. I'm pretty sure there's nothing the server (Wikipedia) can do about that. Reverting to ASCII characters would defeat the purpose of the template. Using images, like it does for double flat () would add considerable cost to the template and would need extensive consultation and eventual consensus; btw, that would look like this: "", and 3 in a row: "". As you can see, these images also appear too low compared to the line's baseline. -- Michael Bednarek (talk) 11:45, 11 January 2017 (UTC)

I think I've found a way to give those who have these problems (as I do, in fact) the means of overcoming them by using style sheets to correct the spacing. If the flat, natural, and sharp symbols in the template were to be enclosed in <span id="music-flat"> … </span>, <span id="music-natural"> … </span>, and <span id="music-sharp"> … </span> pairs, respectively, then anyone whose browsers put extra spaces around these characters could remove them by putting lines of the form

#music-flat { margin-left: -3px; margin-right: -3px}

#music-natural { margin-left: -3px; margin-right: -3px}

#music-natural { margin-left: -3px; margin-right: -3px} (These no longer work. See below for correction)

in a css style sheet, as I have done in my common.css.
I have modified the music template sandbox to incorporate these suggestions and test them. As far as I can tell, they work as expected, and will cause no problems for anyone without the adjustment instructions in any of their style sheets. Here are some expressions displayed using both the current music template and the music sandbox template, as modified:

A♭-major, A♭-major;

A♮-major, A♮-major;

A♯-major, A♯-major.

Without the adjustment instructions in a style sheet, the first and second expressions in each of these pairs should render identically. With the above instructions included in a style sheet, however, the flat, natural and sharp symbols in the second expression of each of these pairs should be shifted 3 pixels to the left, and the text following those symbols 6 pixels to the left. That's certainly how it works for me, at least.

Before implementing these suggestions in the template proper, I thought it best to run them past the denizens of this talk page in case there's something I might be missing.
David Wilson (talk · cont) 18:19, 27 November 2017 (UTC)

Because your changes, unsurprisingly, made no difference to the template's output here on my desktop. I have no objection to your proposal. -- Michael Bednarek (talk) 04:41, 28 November 2017 (UTC)

Using the current template with Chrome on my PC displays the symbols without extra spacing, but on my Android phone all tested browsers do display the extra space. So the problem partly still exists. I do not see a way to add additional CSS on a phone, so it would have to be done in a WP user CSS. Because of the differences in display, this CSS would have to inquire about the environment (PC or Phone). That may be possible but is beyond my (and most reader's) knowledge. If it appears to work well it might be better to implement it in the standard WP CSS. −Woodstone (talk) 07:22, 28 November 2017 (UTC)

If the problem doesn't occur on any PCs, then my proposed solution will be of limited use, because, as you say, there doesn't appear to be any way to supply browsers on mobile devices with a user style sheet, so the proposed solution is only going to be effective when you're actually logged in to your Wikipedia account. If the problem does occur with any PC browsers, then I presume it could be resolved with user style sheets—although I can't do the tests necessary to confirm this because I don't currently own one that's working.

On a more positive note, it's not difficult to tailor the css code so that it won't be activated by your PC, even when you're logged on to Wikipedia. You need to add some javascript code to your common.js file, and then prepend the css selectors given above for your common.css file with code like html[data-useragent*='unique-string'], where "unique-string" is a substring of your browser's user-agent string. See my my common.css file for the code that works for me on my IPad Pro. For your Android phone the string "Android" is probably good enough to work, but if you can find out the version number that follows "Android", it would be good to add that as well (on second thought, adding the version number is probably not such a good idea, because it will require the common.css to be amended every time you update the operating system).

David Wilson (talk · cont) 13:39, 28 November 2017 (UTC)

I have now made the proposed changes to the template proper.
David Wilson (talk · cont) 13:50, 28 November 2017 (UTC)

Argh, and the clarinet page went boom. :-( --SarekOfVulcan (talk) 15:44, 28 November 2017 (UTC)

fixed. Checking for other likely errors... --SarekOfVulcan (talk) 15:46, 28 November 2017 (UTC)

Did an AWB run, cleaned up a bunch of "music|♯" uses. --SarekOfVulcan (talk) 16:04, 28 November 2017 (UTC)

Wouldn't it be simpler and safer to revert the recent changes? -- Michael Bednarek (talk) 16:07, 28 November 2017 (UTC)

Simpler, yes. Safer, who knows? But really, there's no good reason I can see to pass a symbol to the music template - either use the symbol, or pass the text. I found a 5-year-old case of doing it for rendering purposes - I don't want to assume that's still a problem today. --SarekOfVulcan (talk) 16:20, 28 November 2017 (UTC)

Since the breaking change has been fixed, I'll stop the AWB run. Someone might want to consider either finishing it, or actually removing the template where it's not needed.--SarekOfVulcan (talk) 16:34, 28 November 2017 (UTC)

Apologies for the stuff-up. I thought I'd tested all the cases on the test cases page, but I obviously couldn't have done it properly.

David Wilson (talk · cont) 16:49, 28 November 2017 (UTC)

Seeing the actual change made, I now realise it's not technically correct. The attribute "id" is supposed to have a unique value within the whole page. So if the are more occurrences of one of the symbols, this is violated. You should have used a "class" instead. Sorry for not noticing it earlier. −Woodstone (talk) 06:36, 29 November 2017 (UTC)

The change of the attribute from "id" to "class" means that the css selectors I gave above no longer work. Selectors which will work with the "class"attribute are the following:

span.music-flat { margin-left: -3px; margin-right: -3px}

span.music-natural { margin-left: -3px; margin-right: -3px}

span.music-natural { margin-left: -3px; margin-right: -3px}

David Wilson (talk · cont) 05:26, 30 November 2017 (UTC)

Moving this section to the bottom, since most of the discussion happened after the above sections were posted. --SarekOfVulcan (talk) 16:38, 30 November 2017 (UTC)

Just for comparison, here's the straight text use of the flat symbol, compared with the template (no CSS), and I just copied the results of the template and pasted it back into the wikitext, to make sure it was an accurate comparison. I'll include a screenshot of how it renders in Chrome on Windows 10 as well.

A♭, A♭

Screenshot:

--SarekOfVulcan (talk) 16:38, 30 November 2017 (UTC)

• Reviving this discussion, I have noticed on my iPhone (iOS 13.3, Safari) that there is always a space before the flat but not the sharp. For example (taken from the "music" documentation):

"The C♯ crops up very early in Beethoven's Symphony No. 3 in E♭."

Do others see this difference? See also the recent discussion below on this page, which I just noticed. Jmar67 (talk) 13:29, 15 April 2020 (UTC)

Helmholtz-Ellis notation

Can we include the Helmholtz-Ellis notation as well? For example: --kupirijo (talk) 10:41, 26 September 2019 (UTC)

Template-protected edit request on 14 January 2020

Would it be possible to add the following accidentals to the template: https://www.smufl.org/version/latest/range/arelEzgiUzdilekAeuAccidentals/ . This is to be able to improve the wikipedia article Turkish makam. Thank you. --kupirijo (talk) 08:40, 14 January 2020 (UTC) kupirijo (talk) 08:40, 14 January 2020 (UTC)

 Not done @Kupirijo: please make your edits in the sandbox and test your changes. When ready, reactivate the edit request. — xaosflux ^Talk 19:17, 14 January 2020 (UTC)

@Xaosflux: I have made the edit in the sandbox. How is this incorporated into the original template? --kupirijo (talk) 20:51, 6 February 2020 (UTC)

I have copied the kucuksharp section to the main template. If you want the other notation as well, please add it to the sandbox and then re-activate this edit request. I have just synced the sandbox with the live template to ensure that any new modifications don't wipe out changes in the live template. – Jonesey95 (talk) 22:54, 6 February 2020 (UTC)

Reviving Extra Space Problem / HTML 4.0 vs 5.0 Browsers

As noted in a previous thread, there is a problem with the flat character, no matter which method you use to make it {{music|flat}} or {{music|b}} or {{flat}} or just entering the unicode symbol: it adds extra space before and after the flat sign. Sharp doesn't have this problem. Example: G♭ minor, G♯ minor. Makes displays look really crappy. I'm surprised nobody's corrected this in all these years. What's up?

Another oddity I've noticed: I tried just typing the actual unicode symbols in an article, which works, but the symbols' font is too large and creates extra space between lines. Obviously the wiki code for these templates reduces the font size. I'm using Safari on an iPad, BTW. Using the entity method &#x266d; or &#x266f; (or their equivalent decimal numbers), produces the same problem (at least on iPad Safari).

What worries me, though, about the use of all these templates or even entering the unicode symbol, is that both these characters, flat and sharp, no matter what method you use to produce them, are HTML 5.0. If you have an older 4.0 compliant browser, as many readers do, the symbol will display as a question mark or a square or blob or somesuch thing. I would therefore suggest refrain from using ANY of these flat or sharp templates at all and just type the WORD: G-flat minor. The convention is to put a dash between the letter key and the word "flat" or "sharp", with no spaces (per MOS). I see people do mass changes on pages that have the word spelled out, changed to the symbol template (everybody using {{music|sharp}}, not {{sharp}}). Doing such mass changes and using these templates is a bad idea IMO, for compatibility. Plain English text avoids all these problems. LisztianEndeavors (talk) 23:19, 28 January 2020 (UTC)

I commented on this in the other thread before seeing this one. Jmar67 (talk) 13:39, 15 April 2020 (UTC)

I came here to comment on the same thing, having noticed the issue at piano. Looking at the code, I see nothing to my less-trained eyes that would indicate the reason that the flat symbol has the space but the sharp symbol does not. Anybody with insight as to why that is? oknazevad (talk) 15:41, 28 August 2020 (UTC)

Template-protected edit request on 19 November 2020

"h-minor" is wrong. "b-minor" is right. MFSHK (talk) 08:10, 19 November 2020 (UTC)

That fixed itself thanks to the redirect at Commons for C:File:D-major h-minor.svg to C:File:D-major b-minor.svg. It just needed a purge here. -- Michael Bednarek (talk) 09:49, 19 November 2020 (UTC)

TBH, although I think I added them way back in 2011, the main use I can think of for the key-signatures is to refer to the Hugh Macdonald article with the title ⁹
₈... Double sharp (talk) 19:59, 22 November 2021 (UTC)

Double-sharp and double-flats

Could the double-sharp and double-flat symbols be replaced by the actual Unicode characters 𝄪 and 𝄫 rather than images? Using images makes it difficult to link and copy-paste, and the actual Unicode characters have been in Unicode since way back in 2001 (Unicode 3.1). Double sharp (talk) 15:15, 29 November 2021 (UTC)

Example: G-sharp major, where "F" needs to be linked, as it's the leading note. With the image this doesn't work, but as "F𝄪" it would. Double sharp (talk) 15:27, 29 November 2021 (UTC)

To editor Double sharp:  Not done for now: looks like a consensus needs to be established for this alteration. There are a lot of images used for symbols in this template, plus it should probably be in sync with Template:Music at Commons. Please garner the needed consensus before using the {{edit template-protected}} template again. P.I. Ellsworth - ed. ^put'r there 19:44, 29 November 2021 (UTC)

I can't see any reason not to use 𝄪 (double sharp 𝄪) and 𝄫 (double flat 𝄫) instead of the images and , but my exposure to browsers and operating systems is limited. BTW, the article G-sharp major shows that linking under the current scheme can be done. -- Michael Bednarek (talk) 01:41, 30 November 2021 (UTC)

I'll put a comparison below, and obviously this will look different on different systems, but for my system 𝄪 is disproportionately small (almost illegible), and 𝄫 renders poorly but at least is the same size as ♭. I think there is less inconsistency among the more common ♭ ♮ ♯ glyphs. There is also the question of triple-flat, which can't be accomodated and would become an outlier. Personally I think the current setup is preferable, albeit with the change I proposed below to make triple-sharp all SVG. - Rainwarrior (talk) 05:26, 17 July 2024 (UTC)

I've added a screenshot illustration showing what Michael Bednarek's recent changes to the sandbox (unicode double flat/sharp) look like rendered on my PC. See #triplesharp... below for the image and explanation. - Rainwarrior (talk) 18:33, 17 July 2024 (UTC)

Comparison:

• Double sharp: 𝄪 𝄪 vs {{music|doublesharp}}
• Double flat: 𝄫 𝄫 vs {{music|doubleflat}}
• Accidentals: ♭𝄫(?) 𝄫 ♭ ♮ ♯ 𝄪 ♯𝄪 vs ♭ ♮ ♯

If you place the Unicode character as the alt, readers will be able to can copy and paste. You can also supply a link in the img. — kwami (talk) 07:48, 27 August 2024 (UTC)

Use of the half-diminished Unicode codepoint

Would it be possible to adopt the double-flat/double-sharp convention regarding {{music|halfdim}}? There's a Unicode codepoint U+01D1A9 for it now, which renders as 𝆩. It's certainly not well supported presently, which is why I'm curious if it could be rendered as SVG in lieu of its actual codepoint. Remsense (talk) 04:13, 17 May 2023 (UTC)

Dynamics

I'm surprised that dynamics such as fff are not included here. Is there a reason? Tayste (edits) 22:16, 20 June 2023 (UTC)

Template-protected edit request on 9 July 2023

Please delete line 80 - '17 upside down' is duplicated

also line 180 - 'dot' is duplicated

also '+' is duplicated at lines 118 and 270 - please remove the duplicate at line 270 Desb42 (talk) 10:48, 9 July 2023 (UTC)

 Done – Jonesey95 (talk) 14:52, 9 July 2023 (UTC)

Double whole note

We already have an image for the "Double whole note". Why not just use that as the template result? Enx8 (talk) 18:26, 8 March 2024 (UTC)

@Paine Ellsworth: We need to use c:File:Double whole note.svg instead off c:File:Music-doublewholenote.svg; the image you added includes bar lines. intforce (talk) 19:35, 8 March 2024 (UTC)

 Completed – {{music|doublewholenote}} = . P.I. Ellsworth , ed. ^{put'er there} 19:54, 8 March 2024 (UTC)

Also added to the music template on Commons. P.I. Ellsworth , ed. ^{put'er there} 20:40, 8 March 2024 (UTC)

128th note and rest

Decided to make another topic because I wanted this to stand out from the double whole note ("breve")

I found two images of the 128th note and rest.

File:Quintuple-croche tête en bas.svg Not sure why the note image is so small, hopefully you can work with it

File:128th rest.svg same with this one.

Will subscribe to keep updated. Enx8 (talk) 13:44, 11 March 2024 (UTC)

 Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. — Martin (MSGJ · talk) 12:23, 12 March 2024 (UTC)

Using feet for organ stops, air columns, etc.

Following the discussion and recent amendment to MOS:FOOT to allow for specific use in music, and another discussion about pitch on MOS:MUSIC, I propose a possible "foot" shortcut that displays the correct prime character for use with (e.g.) organ stops, wind instrument air columns, etc. Something like adding the following:

| ft
| '
| feet
| foot =<span class="music-foot">&prime;</span>

so that "this organ has a 16′ pedal stop" can be notated using 16{{music|foot}}. It's only a convenience shortcut, because using 16{{prime}} ought to have the same result (16′). — Jon (talk) 21:00, 20 March 2024 (UTC)

Actually I've overlooked the usage of the {{prime}} template, as pointed out in the MOS:FOOT discussion above, which is that 16′ should be notated using {{prime|16}} which fixes typographic spacing details, and not 16{{prime}}. Not sure how this music template can handle a second parameter like this, e.g. {{music|foot|16}}? Perhaps this is all too hard...! — Jon (talk) 21:06, 20 March 2024 (UTC) ...aha, | foot ={{{2}}}<span class="music-foot">&prime;</span>

triplesharp should be all SVG not a mixture of unicode and svg

{{music|triplesharp}} = This currently looks very poorly, with half of it using unicode ♯ and half of it using SVG. Ideally we should create a new single SVG containing the whole combined symbol, though a lower effort version might do this:

[[File:Sharp.svg|{{{size|x16px}}}|sharp]][[File:DoubleSharp.svg|{{{size|x8px}}}|double sharp]] = 

- Rainwarrior (talk) 18:28, 14 June 2024 (UTC)

I've created the proposed SVG:

[[File:TripleSharp.svg|{{{size|x16px}}}|triple sharp]] = 

Example:

F F♯ F F B B B♭ B

- Rainwarrior (talk) 19:23, 14 June 2024 (UTC)

Could we not just use the Uncode glyphs everywhere instead? That way we can rely on font kerning (e.g. ♯𝄪) since it's now 2024 and we have SMuFL and better browsers. — Jon (talk) 05:49, 19 June 2024 (UTC)

I can't find any triple accidentals in Musical Symbols (Unicode block). -- Michael Bednarek (talk) 06:12, 19 June 2024 (UTC)

Yeah looks like we'd need a SMuFL-compliant font: Standard Accidentals 12-EDO Jon (talk) 21:36, 19 June 2024 (UTC)

We cannot expect Wikipedia readers to install a SMuFL-compliant font (especially not Bravura with its convoluted intsallation procedure). -- Michael Bednarek (talk) 02:03, 20 June 2024 (UTC)

Agreed. That said, I don't see why we can't use the Unicode characters for 𝄪 and 𝄫 which have been in circulation since 3.1 (c. 2001). — Jon (talk) 04:26, 20 June 2024 (UTC)

Agreed. A {{edit template-protected}} needs to be launched. This has been requested before (#Double-sharp and double-flats), and there is now demonstrable consensus in its favour. -- Michael Bednarek (talk) 05:43, 20 June 2024 (UTC)

Adding {{edit template-protected}} as mentioned. - Rainwarrior (talk) 15:40, 16 July 2024 (UTC)

It is unclear (to me, a template editor willing to implement this request) what the actual request is. Can someone please modify the /sandbox page with the consensus proposed new code? Thanks. – Jonesey95 (talk) 17:45, 16 July 2024 (UTC)

This is the change I was proposing: Template:Music/sandbox diff. The goal is simply to replace a use of mixed unicode + SVG for "triple sharp" with a single unified SVG. I believe consensus is demonstrated that a unified presentation is desired, but I may have misinterpreted Michael Bednarek.

There is a tangent here, hinting at an alternative way to unify its presentation, by going all-unicode, but that would require a larger change replacing of all four of "double flat", "triple flat", "double sharp", "triple sharp", and the lack of a viable unicode triple flat seems to stand in the way of this possibility. - Rainwarrior (talk) 05:11, 17 July 2024 (UTC)

While we're here discussing it though, your example shows up the inconsistencies between the Unicode characters and the SVGs. Are we using Lilypond for the SVGs?

— Jon (talk) 21:55, 19 June 2024 (UTC)

The triple-sharp SVG I created is a combination of the two existing sharp and double-sharp SVGs by Papy77, which I don't think were created with Lilypond. They are simply described as "own work" on their commons pages. - Rainwarrior (talk) 05:30, 17 July 2024 (UTC)

I added the use of Unicode double flats and double sharps to the sandbox. If unwanted, revert. -- Michael Bednarek (talk) 07:56, 17 July 2024 (UTC)

While in theory I would prefer the semantic advantage of unicode double sharps, in practice they look extremely poor on my system. They may look very well on other systems, but I feel it's important to consider many common setups. In the image below, you can see that the double-flat has an odd shape, and the double sharp especially is objectionably small and poorly placed. This illustration shows the current sandbox test on my Windows 10, Chrome setup:

Left column is existing template: unicode flat, svg double-flat, svg double-sharp, unicode+svg triple sharp. Second column is sandbox right now: unicode flat, unicode double-flat (your change), unicode double-sharp (your change), svg triple sharp (my change). - Rainwarrior (talk) 18:30, 17 July 2024 (UTC)

Here's my screenshot from Template:Music/testcases:

The Unicode double flat is slightly larger than the SVG, similar to your dispaly, and the double sharp slight smaller, and sits a pixel or two lower, but not as badly formed as yours. As I wrote, if undesirable, revert my edit. Either way, I support the edit request. -- Michael Bednarek (talk) 02:35, 18 July 2024 (UTC)

Okay, I have reverted that change in the interest of keeping this edit request more simple, and only about the triple-sharp change I proposed. I do think the double-flat/double-sharp unicode change is worth debating, but maybe as a separate issue. FWIW the offending font on Windows 10 is "Segoe UI Symbol" which is a common fallback point for unicode symbols on Windows 10, and no other default-installed fonts have those glyphs. - Rainwarrior (talk) 22:30, 19 July 2024 (UTC)

Consensus is unclear to me. When you're (plural) ready for someone to make the edit, please feel free to mark the edit request as unanswered. Izno (talk) 02:16, 26 July 2024 (UTC)

(What a brouhaha about a few pixels.) For the record, and as I wrote above, I support the implementation of triple sharps as proposed in the sandbox. -- Michael Bednarek (talk) 03:41, 26 July 2024 (UTC)

FWIW me too, I concede/concur and support as proposed — Jon (talk) 03:55, 26 July 2024 (UTC)

This seems to be 3 for and 0 against, so I'll set it back to unanswered. For convenience here again is the proposed change: sandbox diff - Rainwarrior (talk) 06:30, 29 July 2024 (UTC)

 Done I think that I have implemented the requested change. For future reference, it is always a good idea to copy the live template to the sandbox before making a change. This makes the difference between the live template and the sandbox easy for an unfamiliar template editor to understand. – Jonesey95 (talk) 17:52, 30 July 2024 (UTC)

Nice SVG score output

If you want nice SVG output, which actually works really nicely (I have it working on my test instances of MediaWiki) then please make some noise on this bug. It's ridiculous that it is now eleven years old and I don't think anyone involved has any appreciation of how much of a difference it would make. — Jon (talk) 00:42, 21 June 2024 (UTC)