Open guygastineau opened 5 years ago
I believe that as a learning platform (even if not for music) that it is important for our exercises to involve accurate information.
Yes :heart:
Just an update.
I don't know when I'll have the time to do this, so it could be awhile before I manage a PR.
I like the idea that this exercise be fully correct. However I would suggest that you make a more advanced version of this as a new exercise? Similar to how there a few resistor colour exercises? Also what new coding skills would be gained/tested by this more advanced version that is not covered by other exercises?
@martinfreedman You have good points. I forgot I raised this issue last year ;)
To be honest, I don't know what new coding skills would be targeted by a version of this exercise that presents correctly according to the semantics of western classical music theory... :/ On one hand, the specification would be more complete (due to its accuracy), while on the other hand it would be more alienating for students who lack formal training in western music theory.
Modelling a domain is definitely an interesting skills that might be solidified with a more accurate and complete exercise. However, if it'll just be "more of the same", then I recommend extending this exercise.
@SleeplessByte yeah, I agree that modelling domains is an interesting and important skill, but that is one broad-specturm skill. I meant, I can't just come up with a list of exercise tags that would describe the skills of the exercise. The extended version would also require skills that aren't present in the current tags (I am assuming). For example, something like polymorphic variants are most likely necessary for a very elegant solution to the problem at hand considering we have to associate multiple context sensitive, overlapping sets of identifiers to an underlying finite set of pitche classes derived from one octave. Furthermore, the conventional system allows for several cases of mixing from the identifier sets, and once we reach the synthetic scales the identifier sets are always mixed and there are multiple correct answers even though we should prefer some "right" answers over other "right" answers. Still for many hexatonic scales there are two correct solutions, and which one to use is sensitive to a yet new kind of context which considers less the harmonic intention of the composer than the legibility for the performer.
I do find modelling this in an elegant algorithm exciting, but this extended exercise would go far beyond anything I have done on exercism (including Forth
, React
, Poker
, Zipper
, etc...). So, I don't know how we would quantify the technical challenges both computational and musical for such an exercise... :worried: )
Anyway, I am gonna' be really busy again for a couple of weeks, but I do think it would be fun to make this grand exercise. I don't think it would be fun to correct the inaccuracies of the existing exercise. I do think the existing exercise could be made more correct, but I simply have no will to do the work anymore... :cry: That being said, hopefully some of you will enjoy seeing a future extended version that might not even be suitable as an exercise. If nothing else you all might be able to help rescue me from whatever convoluted mess I make for myself :rofl:
@guygastineau There has been work to improve the exercise lately: https://github.com/exercism/problem-specifications/tree/main/exercises/scale-generator Could you check to see whether the latest version still has issues?
I can find some time later today.
@guygastineau Small bump
I noticed while reviewing a PR for this exercise to the bash track that there are some errors (I am a music composition major).
I believe that as a learning platform (even if not for music) that it is important for our exercises to involve accurate information.
I am willing to make a PR to the scale-generator exercise. This issue is to get the discussion started about the changes, and to act as a placeholder.
Here is the canonical-data.json
We only need the interval specification up to the last scale degree before the octave. The interval distance from the {LT, subtonic, (sub-mediant in pentatonic or unrotated hexatonic)} to the octave is the inversion of distance from tonic to that note. Ie.I realized today teaching a friend interval inversion that I was wrong about this point. It is redundant, but the convention includes the final interval to the octave. Thus the specifications of intervals is already the correct number in these exercises. The other points remain unaffected by this.A
toG
is aminor 7
, thusG
toA
is amajor 2
. This is however irrelevant, because this exercise does not expect the octave to be printed, so the specification of intervals should be one less than the number of total notes printed.flat
version of the tonic as theLT
(leading tone, the note a half step below the tonic). Therefore aD harmonic minor
scale must haveC#
as the leading tone.Db
would be used for a different type of chromaticism. I understand that this 'mixing' of sharps and flats would likely require additional work for the example exercises in each track. I would like to get feedback on everyone's willingness for this change. It would make the difficulty rating of the exercise spike in most tracks I presume.whole-tone
scale. specifically it isWT-1
in pitch set theory when built off ofC#/Db
. The hexatonic scale is a synthetic scale generated by alternating betweenhalf-steps
andaugmented seconds
. I will correct the name of the existing test in the coming PR, and I will add a test for an actual hexatonic scale.I will look over the
canonical-data.json
to see if there are more problems.I also would love feedback from the community regarding willingness to put up with this exercise at a much harder difficulty. with the modes, diatonic major, and natural minor it is true that there will never be sharps and flats mixed; however, when dealing with the melodic and harmonic minor scales there will often be flats and sharps in the same scale in order for the scale degrees to be named correctly.