Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scales should support getindex #18

Closed
dpsanders opened this issue Jan 7, 2024 · 6 comments
Closed

Scales should support getindex #18

dpsanders opened this issue Jan 7, 2024 · 6 comments

Comments

@dpsanders
Copy link
Collaborator

Scales should support getindex in addition to iteration.

Proposed in #17

@stevengj
Copy link

stevengj commented Jan 7, 2024

(Arguably it should take any integer, positive or negative, i.e. it should act like a doubly infinite array.)

@dpsanders
Copy link
Collaborator Author

Done in #21

@dpsanders
Copy link
Collaborator Author

dpsanders commented Jan 20, 2024

Changed to be 1-based in latest main.

scale[2] gives the 2nd scale tone, i.e. moves up by a 2nd from the tonic.
scale[-2] moves down a second from the tonic.

Does that seem reasonable to you @stevengj ?

@stevengj
Copy link

I'm confused, what are scale[0] and scale[-1]?

You surely want to preserve the property that scale[i - n] is n tones below i.

@dpsanders
Copy link
Collaborator Author

scale[-1] is the same as scale[1] since it's "go down by a unison".

scale[0] is an error.

You surely want to preserve the property that scale[i - n] is n tones below i.

Right, that's why I previously was using scale[0] to be the tonic instead of scale[1].
I don't think having scale[0] to be "the note before the tonic" makes much sense.

@dpsanders
Copy link
Collaborator Author

OK I think you're right, that would be better even if it doesn't preserve the symmetry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants