Skip to content

Generalize noteNumberToFrequency to use any periodic tuning#26

Open
ellamenop wants to merge 6 commits into
soul-lang:masterfrom
ellamenop:patch-1
Open

Generalize noteNumberToFrequency to use any periodic tuning#26
ellamenop wants to merge 6 commits into
soul-lang:masterfrom
ellamenop:patch-1

Conversation

@ellamenop

Copy link
Copy Markdown
  • 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

ellamenop added 2 commits May 15, 2020 22:08
- `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`
@ellamenop ellamenop changed the title Add a generalized noteNumberToFrequency for any tuning system Generalize noteNumberToFrequency to use any periodic musical scale May 16, 2020
@ellamenop ellamenop changed the title Generalize noteNumberToFrequency to use any periodic musical scale Generalize noteNumberToFrequency for any periodic musical scale May 16, 2020
@ellamenop ellamenop changed the title Generalize noteNumberToFrequency for any periodic musical scale Generalize noteNumberToFrequency to use any periodic tuning May 16, 2020

@adamski adamski left a comment

Copy link
Copy Markdown

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.

@ellamenop

Copy link
Copy Markdown
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

adamski commented May 16, 2020

Copy link
Copy Markdown

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
Copy Markdown
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 :)

@ellamenop

Copy link
Copy Markdown
Author

Thanks! Should be all clean now ✨

ellamenop added 2 commits May 25, 2020 22:59
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.

3 participants