GSoC Progress: Scale Degree vs Nth Modal Pitch
First phase of Coding Period: 01/06/20 – 03/07/20
Official coding phase begun with us trying to tackle down the centerpiece of the proposal: A scale degree block which actually works like one. There was a lot of going back and forth in this issue, at every step.
First impression was that we require a complete block, just like a pitch block, which takes two arguments, Scale degree and octave but later we toned it down to just an input type / argument block, like solfege and wired it to work with our current pitch block.
So, imagine we started designing a block exactly like the image shown and ended up with just utilising the current pitch block and reduce it down to what you’re seeing as the first argument of the block.
In the initial days I was done with all the trivial stuff related to the block:
- Pie-menu
- Input/Output type
- Working for 7 note systems
Scale degrees are defined from 1 to 7, for a scale, and for every 7 note system each scale degree is defined absolutely, without any ambiguity whatsoever. That is why wiring up its working was trivial.
After this came two extremities to the working:
- Sub-heptatonic frameworks i.e having less than 7 notes. All scale degrees (1-7) are not defined for these cases and therefore the problem faced was what output to produce if someone selects an
undefined
scale degree. - Octatonic frameworks (or any scale with more than 7 notes). For these scales, for each scale degree, there can be more than one candidate. So the problem again lies in what note to play in case of such ambiguous selections.
Initial solution for this was setting a bunch of Fallback modes for all the sub-heptatonic frameworks present in Musicblocks.
A fallback mode is a 7 note framework used for playing scale degrees which are undefined for a certain scale.
And for scales with more than 7 notes, in case of an ambiguous scale degree we always played the major/perfect scale degree.
This worked satisfactorily for most scales but with some peculiar cases like whole-tone for the 1st category and diminished for the 2nd, presented with unexpected behavior. Also, certain notes presented challenges as in whether to include them in one scale degree or the other. [Minor 5th / Augmented 4th]
After struggling for a couple of days with these issues, Devin came up with a robust formula that used Letter Class and Pitch Class Cardinality to determine behavior in these cases. Also it compensated for different ways of expression when moveable-do was present.
Once discussed through, it didn’t took much time to implement in code and the issue was wrapped up in the next 2 days.
A few things that were left / couldn’t be done:
- Having a hat/clarinet over the SD numbers to distinguish them
- Using a Plus block to conveniently create projects using Scale degree block
First thing is something that Musicblocks didn’t allow at that time and the hat displayed on the side of the number rather than top. Second thing is something that slipped off my mind until now. (:p)
Midway through the phase, I attended an online meeting with some of Devin’s colleagues involved with Music as a profession. Devin gave them an idea of how Music Blocks works, combining musical concepts alongside programming concepts and constructs like for loop, repeat, heap/stack.
The outline of my post-session discussion with Devin was how music and maths/programming go hand-in-hand but it is just difficult to people in one field to understand the working of another just because very early in their childhood/adolescence, they picked a path and limited their perspective to it.
For the later phase I worked out on a small (atleast I thought so when I started) issue, related to displaying certain properties related to the note playing. Namely:
- Letter Class
- Pitch Class
- Solfege Syllable
- Scalar Class
- Scale Degree
- Nth Degree
I started right-off, adding separate blocks for each of them, but soon the pitch palette looked exhaustive. There we decided we’d rather have a pie-menu that includes all of this.
Now it seemed easy, but it involved a lot of unexpected behaviours on how block labels and block values work.
Let’s understand by a simple example: In case of any normal block like, say number block: What we see as a label, is in turn the value. E.g we see 5 and we expect 5.
For another class of blocks, which includes some Box blocks, you might have a name for each block, it could be anything, and then you have a value, and the two do not coincide.
Handling the latter case in Music Blocks needs hard coding in a lot of place, from updating labels to export value. After it was done, couple of options were also included in this pie-menu at the last time:
- Staff Y
- pitch in hertz and pitch number, previous blocks which did this function were absorbed into this.
Also, since all these options might be overwhelming, beginner mode only shows a handful of them.
Plugging this block into the status matrix, one can get a lot of metrics for the note being played, which can be used for debugging purposes.