Add signature method for a scale. Closes #89

[dy]

Hi, @matthewconstantine! I’ve implemented, as it seems to me so far, the most logical method of getting key signatures for any scale with any tonic, based on note coordinates. It is quite late here and there might be some mistake, but tests of basic major/minor scales are passed. So please take a look, it should be nice ). It closes #89.

[saebekassebil]

Hey Deema - this looks like a really good addition to the library! Let me just look it through and ponder it a bit, and I'll get it merged!

Cheers!

[dy]

@saebekassebil so what thoughts on that?

[dy]

@saebekassebil I don’t want to bother you, but do you have any considerations?

[saebekassebil]

There might be a problem with this approach. I guess you'd maybe want to use this for drawing the signature for sheet music. If that's what you wanted, then you'd want an abstract "f#" and not maybe "f#3" or "f#8".

This method will return different results for:

teoria.note('A8').scale('major').signature() != teoria.note('A3').scale('major').signature()

What are your thoughts on that?

[dy]

Yes, that’s a good point. Signatures returned should bring abstract meaning, but as far each specific note has that abstract info - that’s ok. However, for sheet music it is probably more handy to return not arbitrary formed key sequence (as it is done now), but a sequence corresponding to a clef. E.g. for the G-clef it’d be handy to have teoria.note('A1').scale('major').signature('treble').toString(); //f#4,c#4,g#4. Description of all the clefs can be found on the wikipedia. So probably it might be a solution - to pass exact clef which it is needed to embody returned key sequence?

//default clef is 'G', or 'treble'
teoria.note('A1').scale('major').signature().toString(); //f#4,c#4,g#4

//other clef can be passed as a param, e.g. 'bass', or 'F'
teoria.note('A1').scale('major').signature('F').toString(); //f#3,c#3,g#3

What do you think?

[saebekassebil]

When we begin to discuss "clefs" and such I think we're slowly progressing into sheet notation area, and I don't think this library should be coupled to sheet notation specifically - that's for another module.

I think maybe what we want is a method that returns the "position" of the signature/scale in the circle of fifths. E.g.:

teoria.note('A').scale('major').signature() === 3
teoria.note('C').scale('major').signature() === 0
teoria.note('D').scale('minor').signature() === -2
// etc

and then we'd want another module that would transform this position into the notes in a given clef position:

var getNotes = require('signature-for-clef');
var getTrebleNotes = getNotes('treble');
var signature = teoria.note('A').scale('major').signature(); // -> 3
getTrebleNotes(signature); // -> ["f#4", "c#4", "g#4"]
getNotes('bass')(signature) // -> ["f#3", "c#3", "g#3"]

What are your thoughts on this?

[dy]

I see, you want to implement the principle of atomizing and functional separation in here. That makes perfect sense, but I felt teoria is rather a somewhat god-object, alike to jquery, including everything possible here at place to work with the music theory. (and it is hardly to find anything bad in that, as the final bundle size is bearable and relatively small). But in case of separation on plugins it ceases to be like that and becomes similar to tonal, which was initially inspired by teoria but has basically plugins-composable architecture. I can implement either approach, whether it is a separate module or teoria-function, but this is architectural decision, and it is up to you) Just please let me know)

[dy]

By the way, considering the SMUFL, what else can be possibly here to complicate the teoria? I hardly can think up of something.

[saebekassebil]

tonal is definitely a step in the right direction! What I'd like to see is that teoria could continue to be a "god-object" or a "programming platform for music theory". But it should consist of many smaller modules, like tonal, pitch, etc. The difference is, that I've been representing notes in a numeric format, while tonal prefers it to be in string format.

I'm not sure how you think SMUFL fits in?

[saebekassebil]

Hi Dima,

I just wanted to know if you're still interested in implementing this feature - have you come up with any good implementation ideas this year? ;)

I think we should go with the modular approach. But maybe including the module in teoria, as to remain "god" status?

[dy]

Hi @saebekassebil! We have chosen the similar approach in audiojs/audio — it is going to be a class consisting of small components, but still monolithic thing, because for high-level apps that makes more sense. I am a bit out of this issue though.

[dy]

@saebekassebil is there any chance to have this PR merged? If not I suggest closing it then.

[saebekassebil]

Hey @dfcreative Thank you for the time invested in this pull - sorry for not being able to return back sooner.

I've closed the pull request since we never came to any conclusion about where to draw the line between sheet music and music theory - and also since you've implemented them in your own module, this seems redundant.

[dy]

@saebekassebil yes, thanks for making decision. It is fine - just wanted to close old unfinished things. I will get back to it if I need it one more time.