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

Generalize noteNumberToFrequency to use any periodic tuning #26

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

ellapollack
Copy link

  • scale is an array containing the frequency interval of each scale degree, beginning with the first degree above the tonic (1. is implied) and ending with the octave.
  • noteNumberToFrequency(rootNote, rootNote, rootFrequency, scale) == rootFrequency

- `scale` is an array containing the frequency interval of each scale degree, beginning with the first degree above the tonic (`1.` is implied) and ending with the octave.
- `noteNumberToFrequency(rootNote, rootNote, rootFrequency, scale)==rootFrequency`
@ellapollack ellapollack changed the title Add a generalized noteNumberToFrequency for any tuning system Generalize noteNumberToFrequency to use any periodic musical scale May 16, 2020
@ellapollack ellapollack changed the title Generalize noteNumberToFrequency to use any periodic musical scale Generalize noteNumberToFrequency for any periodic musical scale May 16, 2020
@ellapollack ellapollack changed the title Generalize noteNumberToFrequency for any periodic musical scale Generalize noteNumberToFrequency to use any periodic tuning May 16, 2020
Copy link

@adamski adamski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I support this PR!
I would swap the term EDO with TET, as it is the more commonly used term outside of the microtonal community.
I would also add (or replace the above with) a method to pass a complete tuning table to cover all 128 MIDI notes, i.e. float32[128]. This would give ultimate flexibility for e.g. stretched temperaments, giving the host complete control over the tuning of each note. This is also closer to the way MIDI 2.0 will work as I currently understand it.

@ellapollack
Copy link
Author

I support this PR!

❤️

I would swap the term EDO with TET, as it is the more commonly used term outside of the microtonal community.

👍

I would also add (or replace the above with) a method to pass a complete tuning table to cover all 128 MIDI notes, i.e. float32[128]. This would give ultimate flexibility for e.g. stretched temperaments, giving the host complete control over the tuning of each note. This is also closer to the way MIDI 2.0 will work as I currently understand it.

Is it necessary to add a method for this if all it would do is index that array?

@adamski
Copy link

adamski commented May 16, 2020

Ha, I realised this after posting the comment! If a host has the option of triggering a note with a given frequency then yes, I agree, not much point in a method that indexes an array.

@julianstorer
Copy link
Contributor

Sorry, I only just noticed this PR. It's a bit hard to see what you're actually changing because the diff is pulling in thousands of other changes, so you might want to try cleaning it up against the latest version?

Seems like a simple and sensible FR though - this github repo is just a mirror, so have to way to accept PRs directly, but we can add the function manually to our master repo :)

@ellapollack
Copy link
Author

Thanks! Should be all clean now ✨

Strangely `scale[note]` appears to wrap `note` before indexing, despite the Syntax Guide saying that it shouldn't.
Switching to `scale.at(note)` for consistency.
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

Successfully merging this pull request may close these issues.

None yet

3 participants