Zero Based Indexing for Scale Degree block and it's subsequent renaming to nth modal pitch

[aviral243]

As of now scale degree (nth modal pitch) block accepts arguments that are either greater than or less than zero but not equal to.

Since the utility of this block has been mostly expressed in the programming aspect of MB, it has been proposed that it has a zero-based index.

Note: I know this issue has already been discussed in meetings but there are several details for which I have to reach out to mentors, so this is aimed towards keeping that conversation public.

[aviral243]

@pikurasa

Please have a look at this.

[pikurasa]

The picture looks fine.

[pikurasa]

If we want simpler, we may do -3 to 7. Otherwise, great.

[aviral243]

I think -7 to 7 really conveys the purpose better.
Moreover, I'll slightly decrease the inner radius to make the design look less cluttered.

[aviral243]

A (+/-) button alongside exit button might be helpful?

Similar to this:

[pikurasa]

We do need the outer circle for octave. It serves as reference for octave (even if user goes above or below with 7/-7)

[aviral243]

We do need the outer circle for octave. It serves as reference for octave (even if user goes above or below with 7/-7)

No change to the octave menu. The above image was just for the reference of button in the middle [ +, -, x ].

Octave menu is as it is.

[aviral243]

@pikurasa Please have a look at this mapping; if this is what we require.
C major: 4th octave: [Assumption]

-7 ---> C3
-6 ---> D3
-5 ---> E3
-4 ---> F3
-3 ---> G3
-2 ---> A3
-1 ---> B3
0 ---> C4
1 ---> D4
2 ---> E4
3 ---> F4
4 ---> G4
5 ---> A4
6 ---> B4
7 ---> C5

[pikurasa]

-7 is C3. Otherwise, perfect.

[aviral243]

-7 is C3. Otherwise, perfect.

Yes. Just updated it.
Got a little confused.

[pikurasa]

Got a little confused.

No worries. It happens to me, too. Welcome to MB development. :)

[aviral243]

No worries. It happens to me, too. Welcome to MB development. :)

😆

Any suggestions on how to proceed with the pie menu selections. [ Shifting of octaves when we select pitches in Pie Menu ]

Currently, we change the octave if the newly selected pitch and previous pitch differ by more than 3. Also, we change octave while going across the 7<-->1 division.

[pikurasa]

Currently, we change the octave if the newly selected pitch and previous pitch differ by more than 3. Also, we change octave while going across the 7<-->1 division.

The octave input is first reference. It can be overridden by the number in other input.

Please remember that the octave reference is important to contextualize the starting point. The reason that we do not force the user to change the octave is so that they can escape it with math as needed (like in our dynamic examples).

[aviral243]

I'm not sure if we're on the same page. I was referring to this feature, where selecting the number argument leads to a change in octave argument. { Moving from 1 --> 5, shifted octave from 4 to 3, crossing 7 led to an increase in octave }

How do we draw its parallels in our new configuration?

Crossing boundary values {-7 and 7} should still lead to octave changes in my opinion. Not sure about what more to add.

[pikurasa]

I do not think we need this functionality for pie menu of this block.

This block is kind of a cross between pitch number and a true scale degree. Make sense?

For true scale degree, we will want this functionality (because it behaves like movable=la solfege).

[pikurasa]

I see why bring this up. Let's discuss tomorrow.

[aviral243]

I do not think we need this functionality for pie menu of this block.

This block is kind of a cross between pitch number and a true scale degree. Make sense?

For true scale degree, we will want this functionality (because it behaves like movable=la solfege).

This does make sense and I've implemented the same.

Another thing that is up for discussion: We play a sample pitch when we select the note in Pie menu [ Like in GIF above ]. Previously we played that sample pitch according to C major.

Now, we can play that sample pitch according to the current KeySignature but the issue is we won't know what key we're in until the project is played once. So as of now, I've too used default C major for sample notes.

We can address this issue when we design #1957 . I've left a comment in the code referring to this.

[aviral243]

@pikurasa I suggest we have this too under the GSOC2020 milestone. It would really be helpful at the end of the program, assessing the work we've done. Thanks :)