{"action":"created","issue":{"url":"https://api.github.com/repos/musescore/MuseScore/issues/2410","repository_url":"https://api.github.com/repos/musescore/MuseScore","labels_url":"https://api.github.com/repos/musescore/MuseScore/issues/2410/labels{/name}","comments_url":"https://api.github.com/repos/musescore/MuseScore/issues/2410/comments","events_url":"https://api.github.com/repos/musescore/MuseScore/issues/2410/events","html_url":"https://github.com/musescore/MuseScore/pull/2410","id":137273721,"number":2410,"title":"Implement scale editor based on discussion from https://musescore.org/en/node/99841","user":{"login":"sraduvictor","id":17430216,"avatar_url":"https://avatars.githubusercontent.com/u/17430216?v=3","gravatar_id":"","url":"https://api.github.com/users/sraduvictor","html_url":"https://github.com/sraduvictor","followers_url":"https://api.github.com/users/sraduvictor/followers","following_url":"https://api.github.com/users/sraduvictor/following{/other_user}","gists_url":"https://api.github.com/users/sraduvictor/gists{/gist_id}","starred_url":"https://api.github.com/users/sraduvictor/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sraduvictor/subscriptions","organizations_url":"https://api.github.com/users/sraduvictor/orgs","repos_url":"https://api.github.com/users/sraduvictor/repos","events_url":"https://api.github.com/users/sraduvictor/events{/privacy}","received_events_url":"https://api.github.com/users/sraduvictor/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":18,"created_at":"2016-02-29T14:43:42Z","updated_at":"2016-03-03T00:26:16Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/musescore/MuseScore/pulls/2410","html_url":"https://github.com/musescore/MuseScore/pull/2410","diff_url":"https://github.com/musescore/MuseScore/pull/2410.diff","patch_url":"https://github.com/musescore/MuseScore/pull/2410.patch"},"body":"The diff is not finished yet, but I'm making a pull request to get early comments."},"comment":{"url":"https://api.github.com/repos/musescore/MuseScore/issues/comments/191506961","html_url":"https://github.com/musescore/MuseScore/pull/2410#issuecomment-191506961","issue_url":"https://api.github.com/repos/musescore/MuseScore/issues/2410","id":191506961,"user":{"login":"mgavioli","id":1420743,"avatar_url":"https://avatars.githubusercontent.com/u/1420743?v=3","gravatar_id":"","url":"https://api.github.com/users/mgavioli","html_url":"https://github.com/mgavioli","followers_url":"https://api.github.com/users/mgavioli/followers","following_url":"https://api.github.com/users/mgavioli/following{/other_user}","gists_url":"https://api.github.com/users/mgavioli/gists{/gist_id}","starred_url":"https://api.github.com/users/mgavioli/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mgavioli/subscriptions","organizations_url":"https://api.github.com/users/mgavioli/orgs","repos_url":"https://api.github.com/users/mgavioli/repos","events_url":"https://api.github.com/users/mgavioli/events{/privacy}","received_events_url":"https://api.github.com/users/mgavioli/received_events","type":"User","site_admin":false},"created_at":"2016-03-03T00:26:16Z","updated_at":"2016-03-03T00:26:16Z","body":"First, a general remark. I would be more confident in making suggestion if I am sure that you do not make changes to the code just because I tell, but because my arguments sound convincing, you agree with them and I didn't overlook some point.\r\n\r\n**1/2)** Scales in themselves do not have any pitch: they can be applied to whatever pitch the performer chooses to use (deriving all other notes supported by that scale from some given reference, according to the ratios defined by the scale).\r\n\r\nAs it is common practice to tune on a given A, it seems to me simpler and, above all, quicker when speed matters (i.e. when creating play note events), to store the scale data as deltas so that the delta for A be 0 (and all other deltas shifted correspondingly). In that way the A will always be 'in tune' and all other notes tuned according to the relationships defined by the scale.\r\n\r\nWhatever scale I apply, regardless I set the MuseScore player for A at 440Hz or at 415Hz or at 392Hz, I'll have A in tune and the other notes according to what that scale requires. There is no need for the scale to be tied to a specific A pitch or even for it to know which A pitch is in effect.\r\n\r\nDo you agree? Am I missing something?\r\n\r\n**3/4)** To avoid ambiguity, can we agree to call expressions like \"5/4\" _fractions_ rather than generically _ratios_, to distinguish them from single numbers like `1.25` which also are ratios (and call only the latter _ratios_)?\r\n\r\nI agree that fractions are informative and it would be nice to keep them. However, in this case, `originalNotes[]` should not store other things than fractions, or we would loose track of what is what. In addition, if a ratio originally expressed as a fraction is modified, the fraction should be deleted, as it no longer represents the new value (unless you find a way to re-create a new fraction out of the new value). So, I wonder it is really worth the trouble. But, if you want to support this kind of fraction management, I would not stop you, for sure!\r\n\r\n\"_... that you can use a scale with 7 notes, select 35 from the combobox ..._\": hmmm, this seems to me both a logic inconsistency and a misuse of the available data (one I myself fell into at the time of the plug-in):\r\n- if the user chooses a scale with 7 notes, he has 7 notes, period. The fact the **internally** we supply a whole set of 35 notes for the sake of the playback system should not concern him. If he applies this 7-note scale to a Bruckner's symphony, he should expect things to go awry; rather he should probably choose a 12-note scale. If you do not need G# to be different from Ab, you may go for a 12-note scale, but if you need (or would like to experiment with) them being (potentially) different, you need a more articulated scale. Data not present in the scale, from the user perspective, should not exist (in fact, they 'really' do not exist as independent data: they are the duplicate of other data for the sake of the playback system).\r\n- we did not \"_actually chose for you_\" anything! We did not chose the fact that G# is an enharmony of F# as well as E##; this is implied by the 'circle' of fifths.\r\n\r\n**6)**: as far as I see it, yes, it should not be possible to 'see' more notes than there are in the scale. Later on, it might be possible (or even desirable) to add to the editor a function to change the scale 'TPC span' (conveniently worded in order to make it comprehensible to the laymen), but making it clear that this creates a new scale, rather than 'unblocking' some 'hidden feature' of the existing scale.\r\n\r\nOr maybe a better way to implement such a function could be a \"Create new scale\" function (which sooner or later we would need anyway) with selectable range, optionally initialized from some existing scale. Usually, however, scales are self-consistent systems and adding arbitrary new notes often makes little sense and requires adjusting (most) existing notes, for sure this happens in many temperaments.\r\n\r\n**7) Scale manager**: No clear idea yet. Really, it seems to me wiser to wait until the current features (on which a scale manager would rely anyway) are settled, debugged and tested, before implementing anything of it.\r\n\r\n**8) fifths vs. ratios**: \"_For the fifths editor, if I want to store ratios, then I can't convert the values back into absolute cents of the note_\": why can't you? what forbid it? can you elaborate where the problem is?"}}