I note that Scaler sometimes styles keys in non-standard ways, e.g. Fb minor (i.e., E minor), or G# major (i.e., Ab major). These do not align with normal conventions and it would be useful if Scaler set the nomenclature to the correct enharmonic name. It doesn’t have any practical implication in terms if music output but since Scaler is acting as a theory tutor to some degree, this should be corrected.
As a relative newbie to music making who just recently went through learning a lot of music theory, I asked the same question previously. And the answer I found was that it had to do with the scale the note/key was part of. That the overall aspiration is to only use a note name once per scale, that is to never have A and Ab, or D and D# in the same scale, rather G# + A, and D + Eb. To name it so that the letters are as unique as can be and only show up once in a scale, and that sometimes leads to adjacent white keys that don’t really have an equivalent of sharp or flat on a black key in between them (such as E and F, or B and C) to be expressed as Cb or B#, or E# or Fb respectively. And this seems to be a general music theory convention, not just Scaler specific. I hope I understood this correctly?
One certainly does find examples of unusual enharmonic nomenclature in western classical music, but it is relatively rare. The reason for maintaining a strict nomenclature has to do with the circle of fifths - the version of which is found in Scaler also needs correcting - and the number of flats/sharps in the key. Let’s look at the standard crossover point between F# and Gb, both have six respectively, and that clutters up the stave. If we go clockwise around the circle in major from here we’d end up with C# major and seven sharps; it makes more sense to consider it enharmonically as Db, which has five flats. This way, the maximum number of flats/sharps is six. If ever you need to transfer music to stave for an orchestra, they would scratch their heads if they saw seven or eight sharps on the page. It’s simply unnecessary and would make their job that much more difficult. Music convention in this respect makes sense and I think that Scaler should follow it.
Thanks for feedback @redheavy As you can appreciate there is a whole world of live ecosystems and algorithms in the backend and we can’t force a flat or sharp in every application. There are technical reasons why they display the way they do, that being said and agreeing with your points you can change what is displayed across various screens, like in the scale list (click on the # or b), circle of fifths or on the scale title in section B.
We do overall need the improvement but also remember that possibly the majority of our users use scaler as a tool to help with harmony without having a great deal of theory behind them so the CO5th for example is intended to quickly choose chords rather than see the make up of each scale specifically (as per your intention of transcribing for Orchestra ) hope that all resonates with you.
Hi, no worries at all. I think Scaler is an outstanding piece of work and I am enjoying getting to work with it for my own composition sketches; it’s very helpful. As a coder myself I appreciate that there’s a lot going on under the hood, and I agree that the majority of users won’t be transferring their work to score. It’s a niggle, nothing more. Keep up the good work!