Some thoughts about an editor for scales and temperaments
Background
As progress is being made (primarily thanks to sraduvictor) in applying a scale or temperament to a score with actual playback (see a discussion
in the issue tracker and actual code being worked on
in github), the need arises for an editor which allows the user to define his own and/or modify existing ones.
Having already implemented such a thing (once upon a time in the plug-in for MuseScore 1.x and more recently for an Android app, which will be published shortly), I believe it useful to share my thoughts about which features such an editor should have and how it should look to be useful.
Note: TPC, Tonal Pitch Class: the position of a given pitch within the sequence or (pseudo-)'circle' of the fifths; this defines how the pitch has to be interpreted (the name derives from internal choices made a long time ago in the MuseScore code, but is now openly used in the community; the concept it refers to is a general concept behind the whole of Western music and not only). Currently MuseScore supports a range of 35 TPC's from Fbb to B## (with a very low probability this will change in any coming future).
Layouts:
The editor shall have at least two alternative layouts, presenting the same data in different perspectives:
- A linear list in TPC order (the 'non-circle' of the fifths)
- A matrix by accidental and base note
The user shall be free to select either layout for editing whatever scale/temperament he is interested in (for instance via a pair of radio buttons) and to change from one to another at any moment during editing.
The 'non-circle' of the fifths
This is usually the most useful layout/presentation for working on temperaments. If a default layout has to be chosen, my suggestion is that it should be this one.
It shall not show data about the notes themselves but about the fifths between them, displaying -- in principle -- all the 34 fifths between the 35 TPC's currently supported by MuseScore.
The most obvious arrangement is a vertical sequence of edit boxes. To be decided if it shall go 'up' (lowest TPC at the bottom) or 'down (lowest TPC at the top).
Data shall be shown in at least 3 different ways:
- absolute cent values: the interval of each fifth in cent;
- delta cent from the equal temperament (12EDO) fifth which, by definition, is 700 cent;
- the interval as a frequency ratio
Again, the user shall be free to switch to any representation at any moment. For editing, the editor would interpret any entered datum according to the currently displayed representation.
It would be nice to compute and show the resulting major thirds and/or the resulting 'beatments' (English?) (for a reference octave), but this is probably overkill and would heavily clutter the display; perhaps, in a second step, these could be added as separate, purely informative displays.
The note matrix
This layout is in several cases more useful for scales and for some temperament. It shall arrange the 7 base notes (C D E F G A B) along one axis and the 5 accidentals (bb, b, natural, #, ##) along the other, for 35 cells corresponding to the 35 TPC's currently supported by MuseScore. Deciding about a 5x7 or a 7x5 arrangement is mostly a matter of convenience, according the overall layout of the window, of the hosting programme, etc.: neither arrangement seems to me clearly preferable to the other.
Data shall be shown in at least 3 different ways:
- actual within-the-octave position of the note in cent (0 - 1199);
- delta cent from the corresponding note in the 12EDO, which is defined by the TPC of the note;
- the interval as a frequency ratio (0.0 - 1.999...)
with two different references:
- using C as reference
- using A as reference
This is because, in theoretical works, scales and temperament are often defined relatively to C (and the user shall be able to verify/enter the data in this way), but are then often physically implemented within instruments relatively to A (as A should always be 'in tune'. Ultimately the playback should always use A-relative tuning to match any external musical context) and the user shall be able to read/enter data in this way too.
Here too, the user shall be free to switch to any representation/reference at any moment. For editing, the editor would interpret any entered datum according to the currently displayed representation/reference.
Amount of data
All the above assumes that up to 35 notes are defined and displayed, but this is often unnecessary (and could even be confusing). In most cases, scales and temperaments define far less than 35 notes per octave (if needed at all, the undefined notes are usually in practice duplicated from their enharmonic equivalents).
Each scale / temperament shall report to the editor the TPC range for which it has unique data and the editor shall hide all the other slots, visualizing only the unique data and un-cluttering the display as much as possible.
If possible, the editor should allow to increase / reduce the TPC range of a scale / temperament, but I would rate this more a "nice to have" thing than a requirement.
__________
Note: the above assumes that any scale and temperament being edited can be represented as a contiguous (no holes) sequence of TPC of at least 12 steps.
This is not universal, of course; however, scales which are really impossible to map to a set of TPC are a rather specialized domain, which would be nice to support in MuseScore, in principle and if possible but, I believe, not at the expenses of almost anything else in the programme.
Scales which can be mapped to TPC sequences, but either non-contiguous (with 'holes' in the sequence) or with less than 12 notes per octave would create many problems in many other aspects of the programme (should it be possible to enter a note which does not exist in the currently selected scale? how to play it back? and so on) to be worth the effort.
Thanking for reading and hoping this can be on any use,
M.
Comments
I have one question. For the 'non-circle' of the fifths, should the representation be only one vertical line with all the notes?
Looking at the scales plugin from 1.3 I see it is not easy to discern what scale was applied to the current score. Should I have the Select Temperament show the current temperament that is being applied? And have importing a scala file automatically apply the scale to the score? Or should I have another box showing the current Temperament?
Would it be ok if I have only two options for showing the pitches : by absolute interval and by deltas. And for the absolute values support both cents and ratios, while for deltas I support only cents?
For the 'non-circle' of the fifths should the order be the one I'm posting at the end?
In case this order does not apply anymore (eg. Fbb becomes higher than E), should I invalidate this button so you can only edit the note matrix?
Bs - 0
C - 0
Dbb - 0
Bss - 100
Cs - 100
Db - 100
Css - 200
D - 200
Ebb - 200
Ds - 300
Eb - 300
Fbb - 300
Dss - 400
E - 400
Fb - 400
Es - 500
F - 500
Gbb - 500
Ess - 600
Fs - 600
Gb - 600
Fss - 700
G - 700
Abb - 700
Gs - 800
Ab - 800
Gss - 900
A - 900
Bbb - 900
As - 1000
Bb - 1000
Ass - 1100
Another idea would be to start with C at 0 and end with C at 1200
C - 0
Dbb - 0
Bss - 100
Cs - 100
Db - 100
Css - 200
D - 200
Ebb - 200
Ds - 300
Eb - 300
Fbb - 300
Dss - 400
E - 400
Fb - 400
Es - 500
F - 500
Gbb - 500
Ess - 600
Fs - 600
Gb - 600
Fss - 700
G - 700
Abb - 700
Gs - 800
Ab - 800
Gss - 900
A - 900
Bbb - 900
As - 1000
Bb - 1000
Ass - 1100
Bs - 1200
C - 1200
For the edit dialog I see I also need to store the A note tuning. Should I have it separately?, or stop doing the readjustment o the notes to have A tuning be 0?
Instead of reinventing the wheel, why not use the Scala project's format?
http://www.huygens-fokker.org/scala/
It would save a lot of work, and the chances are that the early music temperaments you want to use have already been defined.
All that needs to be done then is pass the tuning onto FluidSynth by means of a MIDI Tuning Standard Universal System Exclusive Message.
Given that a wide range of synths already support the scala format (see the list on the Scala Home Page), MuseScore would then be ensuring compatibility with a wide range of hardware and software synths.
In reply to Instead of reinventing the by ChurchOrganist
Michael, please see this discussion on the issue tracker about why this is likely not to be a good idea.
In reply to Instead of reinventing the by ChurchOrganist
The Scala format appears to be a list of relative pitches, but it doesn't specify Tonal Pitch Class. However, the format does allow comments, and the spec also says:
"Pitch values, each on a separate line, either as a ratio or as a value in cents...Anything after a valid pitch value should be ignored." Perhaps you could simply extend the format by writing the TPC after the pitch? Any other information needed could be stored in comments and you'd still be left with a valid Scala file.
In reply to Instead of reinventing the by ChurchOrganist
1) This thread is about a (yet to be implemented) editor for scales and temperaments; it seems to me that discussing an interchange format for import/export has no relationship with the look of an editor which operates completely within MuseScore. It also seems to me that this relates only remotely (if at all) with the format MuseScore would use to store those data internally.
2) This discussion is already going on in the link quoted above (in fact, some consensus has already been reached). As more convenient for the clarity of the topic being discussed and to ease the understanding of the content, I would suggest to post there any further discussion or start a new thread.
Thanks!
In reply to Instead of reinventing the by ChurchOrganist
I intended my suggestion to be a way for users to share presets for the Editor, not for internal storage, so I think it is relevant here. Sorry I didn't make that clear earlier.
Your editor idea is great, but I can only really see it being used by experts. The average user would find it much easier to import a file and have the work done for them. The editor could have a dropdown list of preset temperaments and the option to save or load a new preset from a file similar to the one I described. The new temperament would remain in the dropdown menu for use in future scores.
In reply to I intended my suggestion to by shoogle
As I said in the comment below : "sooner or later a scale manager would be needed..."; please one step at a time or we risk to never arrive at any conclusion.
Even for the scale manager, though, I do not believe it would be useful to use as storage format a textual format which only contains half of the data.
In reply to I intended my suggestion to by shoogle
As I said above, you would add the missing information in such a way that the file remains a valid Scala file (but possibly change the extension to avoid confusion). The advantage (and indeed the purpose) of the Scala format being text-based is that it is human-readable and can be shared on message forums, etc.
We agree that a scale manage is needed "at some point", but I think it would actually be more useful to most users than the editor. By using a human-readable format you could even have only the scale manager and not an editor, which is what I think @ChurchOrganist was suggesting. You would rely on users writing the import files themselves, or you could even create a web-based editor that would use the same layout you described and use it to produce an import file that they would download and open with the scale manager.
I can see that you have gone to great trouble to suggest a logical, informative way to structure the editor, but the fact remains that it would only be usable by people with expert-level knowledge in three fields:
It is simply not possible, in my opinion, to make the editor usable by a person lacking that background knowledge. But someone with that knowledge would be more than capable of writing a simple Scala-like text file (or even just adding TCP information to an existing file). I think the point that @ChurchOrganist was making is that resources are limited, so why create extra work for yourself.
In reply to As I said above, you would by shoogle
Sorry to insist, but I completely fail to understand why we keep discussing interchange import/export file format when the topic is an internal MuseScore tool.
If you (or anybody else) is not interested in the editor and do not plan to use, you are totally free to ignore it. For me (and possibly not for me alone), having the possibility to apply a scale or a temperament to a score without being able to edit it would be of too limited usefulness.
In reply to As I said above, you would by shoogle
Of course you could edit it if you edited the text file...
I have the necessary background knowledge to use the editor, but I know that most people don't have that knowledge, and those that do would manage just fine with text files. I am a developer too, and I'm simply saying, as one developer to another, that there's an opportunity for you to save yourself some work here. If you still want an editor you are, of course, more than welcome to create one.
In reply to Of course you could edit it by shoogle
The editor I am working on at the moment can use scala files. In fact this is how I am testing it. Internally MuseScore will store the data in different formats, but one of these formats will be compatible with scala format (absolute cents).
The only difference between these will be that scala needs to have pitches in increasing order, while Musescore expects certain notes at each index no matter if they increase or decrease in pitch. The other difference is that we automatically assume A to be tuned to the standard pitch so we shift everything for this to work. I could change the logic to stop doing this and show the tuning from the scala file. If a user wants to have true A pitch he can just change it back to 0.
If you have any other concerns or ideas, please leave a comment!
@sraduvictor:
Order of the fifths: the 'non-circle' of the fifths should be in the order of the fifths, which is the same as the order of the TPC's (in fact, TPC's come from the order of the fifths), from Fbb to B##. As said above, I assume that not always all 35 values would be displayed, but only those for which the specific scale / temperament has unique values (the curent code stores these boundaries in
minTpcandmaxTpc); but still, what is shown shall in that order.'non-circle' layout: I imagine a linear vertical sequence (from Fbb to B##) to be the most convenient. Another usual representation is with an actual circle, but this might take too much screen real estate and be non-trivial to design properly, once the circle ends up having three full turns. So, a linear arrangement is likely to be better.
As edit boxes are usually wider than tall, a horizontal arrangement is likely to be too wide. With an average of 12-15 values represented, a vertical arrangement should fit in a reasonably high dialogue box (more complex scales with more notes may need scrolling, but sooner or later this would happen anyway).
It would be nice if the layout show two columns, one with the note names and one with the fifth width values, but shifted:
Fbb [val] Cbb [val] Gbb ...but I am not sure this can be designed tightly enough. Suggestions are welcome, though.
Values: I would suggest to start with what seems more useful: user feedback will provide additional perspective. Just FYI: delta cents are useful for getting a quick idea of the scale/temperament; ratios to make calculations and get relations with reference intervals (it might not be obvious to anybody that an E tuned at -22 delta cent is in pure major third with a C tuned at 0 delta cent; a ratio of 1.25 is more explicit).
C vs. A tuning: hmmm, I do not see a real need to store anything separately; in the data the editor will retrieve from the scale manager, tunings for C and for A are given (in the 15th and 18th TPC slots respectively); to show C-based values, values are displayed with the C tuning subtracted, to show A-based values, values are displayed with the A tuning subtracted.
Scale manager: sooner or later a scale manager would be needed, importing, (exporting?), listing scales / temperaments and applying a selected one to the current score. But one step at a time...
In reply to @sraduvictor: Order of the by Miwarre
Should i also show the difference between Bbb and Fb. I guess i didn't do this because i'm not familiar with this concept.
Should i stop tuning A to true value when we import a scala file? You can always adjust A tuning to get there without changing original values. Or zhould A tuning change original values to show the adjusted pitch?
I'm a bit lost - so is it possible to try out the different musical temperaments used before Bach came up with equal temperament? How about the scale used in carnatic music, see page 19 of the attached?