ozankasikci / rust-music-theory

A music theory guide written in Rust.

Hi there 👋

Hi there, I'm Ozan, a software engineer and entrepreneur with a passion for programming and building awesome games as the co-f of Longhorn Games.

I'm driven by the belief that we can help humanity take a step forward through innovation, and I'm committed to doing my part to make that happen.

More...

Programming Languages

                       

CI/CD

         

DevOps Tools & Libraries

             

Databases & Queues

         

BackEnd Tools & Libraries

     

FrontEnd Tools & Libraries

           

My Open Source Projects

Project	Stars	Forks	Issues	Pull Requests
Rust Music Theory
Vim Man!
Dockerfile Generator
Go Image Merge
Phaser Coffeescript Gulp
Unity Cheat Sheet

rust-music-theory's Issues

Running the scale command with any argument gives an error

Command line output:

❯ rustmt scale D Locrian
error: Found argument 'D' which wasn't expected, or isn't valid in this context
USAGE:
    rustmt.exe scale <SUBCOMMAND>

For more information try --help

Same thing happens when using something like rustmt scale C Minor

Installed on a Windows 10 machine using cargo install.

Pentatonic and other non-heptatonic scales (and their modes)

I feel like, when wanting to add more complex scales and modes, a small rework of ScaleType and Mode has to be done.
Both are targeted at 7-tone scales and I guess it would need enums for mode and scale for each n-tone scale. Or maybe I'm missing some music-theoretical concept.
I'm willing to add these features, but might need a bit more direction.

Scope of Project: meter and time

Is there any plan to add measures, time signatures, note value, etc?

Incorrect enharmonic spellings for chord / scale notes

Hi everyone! This project looks neat. I'm noticing in the examples, however, that the enharmonic spellings for the note names are incorrect. For example,

rustmt scale D Locrian
is shown with this output:
Notes:
1: D
2: D#
3: F
4: G
5: G#
6: A#
7: C
8: D

But it should be notated as follows:

1. D
2. Eb
3. F
4. G
5. Ab
6. Bb
7. C
8. D

In other words, each letter name in a scale (and in chords) should be notated with the correct name relative to the interval.

What is needed for melodic+harmonic minor scales?

Hi there!

I'd like to contribute to finishing this bullet point on the README:

Add missing modes for Melodic & Harmonic minor scales

However I can't seem to find which modes are missing. Those both seem to be in the Mode enum?

It would be nice to have tab representation for the chords.

As a guitar/bass player I would really appreciate to have also tab representation of the crods depending on root not string.
I am new to rust but I would be glad to help.

Make chord representation consistent

This is tricky! :P I really appreciate your hard work on this crate!

In

rust-music-theory/src/chord/chord.rs

Line 92 in 86591a1

intervals: vec![],

, the default chord is erroneously missing its intervals.

The easiest way to fix this is to use ::new and call it a day, but imo that keeps the design open for a similar problem happening elsewhere.

Another viable approach:
What if we make Chord a trait instead, and make several concrete representations for it?
For example a vector of intervals could be considered a chord, albeit without a root pitch class. Chord quality and whether it's a triad/seventh /something exotic could be inferred from the intervals.

We could still construct chords from quality, string, etc but my point is we should ideally only represent it with one unique and flexible data point, because right now it's possible for the Chord struct to contain invalid data, where the fields mismatch each other and go out of sync.

If we consider performance, I'd personally vouch for being able to compute each thing from each other thing, e.g. string representation from intervals, quality from string, etc.

What do you think?

Proper inversion generation

Is that correct that there are only n inversions generated where n is the number of notes in the chord?

rust-music-theory/src/chord/chord.rs

Line 191 in 2e09fa3

notes.rotate_left(self.inversion as usize);

As far as I understand, there should be n! of them to produce all the permutations.

AFAIK, according to the music theory, there only exists the invariant that the notes in chords shouldn't contain spaces more than one octave and this reduces the number of inversions of a given chord starting for a given octave exactly n!

Builder pattern for scales and chords

I would propose to use the builder pattern for those, because for most fields there are good defaults, we could add new ways to build them and especially for the case of calculating the inversion from a bass_note. I would like to expose that feature to the library side and not only have it in the CLI.
I suggest the typed-builder crate for this, as there is no need to write the boilerplate by hand and it also brings the compile time check.

Converting frequency (Hz) to notes and back

I was just wondering, is it possible to convert a frequency in Hertz to the nearest note, and vice versa? If not, how would I go about doing this?

Dsus4 gives D-G-D

I was expecting this to output "DGA", but it outputs "DGD". But then I'm new to rust and basically cobbled together stuff from the tests I didn't understand. Where am I going wrong here?

extern crate rust_music_theory as rustmt;
use rustmt::note::Notes;
use rustmt::chord::Chord;

fn main() {
    let chord = Chord::from_regex("D sus4").unwrap();

    for note in chord.notes().iter() {
        print!("{}", note)
    }
}

Install option.

I think it will be nice to mention that cli can be installed with cargo like this:

$ cargo install --git https://github.com/ozankasikci/rust-music-theory

and used as

$ rmt scale D Locrian

However, there is old rmt Unix/Linux command,so maybe it is better to rename it.
But I've installed on Ubuntu in WSL and and it worked fine.

Missing ♭ in accidental regex

rust-music-theory/src/note/pitch_class.rs

Line 70 in 12983c2

'b' | '♭' => {

Could be nice when copy pasting, so I vouch to keep check and add in regex, instead of removing.

PRE-PR: structopt

I would like to rewrite the CLI part with structopt, if you're fine with that. I think it would make the whole command & argument thing a lot easier to look at, understand and expand on.
Also I would like to resolve the panics occurring, when you're missing arguments, along with that.

(Independent from this specific Issue, I think it would make sense to have some kind of discussion platform for the further library design. I would like to contribute some more, but am very unsure if others would be fine with the changes or how I'd do them. And opening an issue for each possible feature I can think of seems a bit much. GitHub Discussions is still in Beta sadly..)

Need help with improving the documentation

The documentation is a bit outdated atm, after merging #20, the API will change dramatically and the gap will be even larger. We need to;

• Update that crate documentation
• Update the README file

If someone would like to pick that up please let the community know. Otherwise, I'll be working on that in the coming days.