davidryan59 / ji-rcn Goto Github PK

Ought to strip out all Unicode, or suitably convert the notation, before parsing.

• Add a decent set of tests for KG2 algorithm (see paper)
• Write the new function
• Link it up to primeToComma

Is there anything I can change here, which will make this package install better in / work better with ReTuner app? After all, ReTuner was one of the main reasons ji-rcn was developed.

For example:

- C𝄪4 for C##4  U+1D12A
- C♯4 for C#4   U+266F
- C♮4 for C4    U+266E
- C♭4 for Cb4   U+266D
- C𝄫4 for Cbb4  U+1D12B

Items to cover

• 'x' should parse the same as '##'
• '(x5)' should parse the same as 'xxxxx'
• Need a display option as to whether 'x' is used in output notation

There are three types of thing:

• Fractions (1/1, 5/3, 16/5...)
• Frequencies (256 Hz, 440 Hz...)
• Notations (C4, E'6 Bb[7]2...)

Need to be able to map between them by a specification similar to:

1. C4 = 256 Hz = 1/1
2. A4 = 440 Hz = 5/3
3. Eb2 = 77 Hz = 16/5

Currently item 1. above is the default, and there is no way of being able to change it.

Make it possible to independently assign a notation (C4) and a frequency (256Hz) to 1/1 so that the notation can be retuned into any key.

e.g. 256 Hz

• Add a decent set of tests for SAG algorithm (see paper)
• Write the new function
• Link it up to primeToComma

It would be nice to minimise the size of the download.

Investigate using minifying...

Want mult and pow functions to be mirrors of those on the Peo class

Currently the README doesn't contain any of the display options. Fix this.

At the moment eight different brackets are parsed: [] () {} <>

This leads to complex regex, and slow parsing of notations.

Not sure this feature would ever be needed, so probably better to reduce it to only one bracket for each kind of entity, thus:

• (b234)
• (.99)
• (m50)
• (_ERR) or (__ERR)
• [7]
• [11^2 13 / 17 23]

So:

• Get rid of {} and <> entirely
• Only use [] for higher prime commas
• Use () for all shorthand bracket notations

At the moment everything in the GitHub repo is also in the npm package.

However, examples should be in GitHub, but not in npm.

Fix this.

Currently can do jint.mult(jint2)

Also want to be able to do jint.mult(peo) (which multiplies jint.ratioPeo() by peo)

At the moment the JInterval class is great for ratios such as 5:6, 11:13, but less useful for chords such as 4:5:6 or 1/(13:11:9:7).

Investigate what the best way is of representing chords, compound ratios, using maybe a new class JChord inside ji-rcn package, so that notation can easily be calculated for these chords.

Check if the specs make it into the bundle.js file? They are currently 10kB.

If so, consider using an .npmignore file to exclude them. Check interactions between .gitignore and .npmignore first.

Eslint has all options as extra npm modules to install, with a little config file.

Is it possible to do this for the JInterval setup?

• Can comma algorithms be factored out into separate npm modules?
• Same for parsing options?
• Same for display options?

At the moment, getPeo returns a copy of the peo.
However, that means a lot of functions called on the peo don't get cached when they are called multiple times.

Does anything break (apart from tests) if getPeo returns the actual peo?

Is there a compelling reason to return a copy, rather than the original?

Otherwise, switch it so that getPeo returns the actual peo.

Want to be able to specify things like base frequency, base notation on construction, not just through setting them later.

Rather than trying to pass them all in as separate arguments, best solution is probably to make a new style of object something like:

{
  peo: <any peo>,
  baseFreqHz: 123,
  baseNotation: "G4"
}

This would be a new category in the Jinote initialiser, and would allow separate specification of each component of the Jinote.

Current badge is fuzzy.

For a non-fuzzy badge, see: https://github.com/nachoaIvarez/flexbox-react

If fixed, do in my other npm modules.

The most common notation that doesn't yet have a shorthand are the commas [7] and [1/7]. For 7-limit music, giving these shorthands would mean [a/b] notation becomes unnecessary. For any JI music, this means that only 11-rough commas need the full [a/b] notation, which is probably helpful in many circumstances.

The only problem is - what shorthand to use? Here are some options:

F[7]4    as  Fi4  F^4  F74  F/4  F*4 
D[1/7]4  as  D!4  Dv4  DL4  D\4  D@4

Preferred option is probably ^ and v. Main difficulty is that ^ is an arithmetic symbol, already used in comma notation.
Likewise, / and \ have other uses, / is used in commas already.

• and @: * is arithmetic, and @ when pasted elsewhere sometimes turns into an email address
  i and ! - its less obvious that these have any relation to the number 7. Also ! is factorial.
  7 and L - can't use 7, it makes the octave number above look like 74. This really won't work.

If a suitable (ASCII) option can be found, want to implement:

• Two new characters in the constants
• Parsing them on inbound notation
• Display option for whether to display them on outbound notation
• Implement the outbound notation.

See new calc on API in Peo.

Want to start development on initialiseFromNotation which will take in a text string such as Bb[7]6 and return a new Jinote.

This is like the reverse process of 6/5 -> Jinote -> Eb.4.

It involves text parsing. May want to find an npm package to help with text parsing.

It is probably a fairly large job. Want a separate development branch for this, and a robust set of tests up front.

Want 1/1 to be (normally) C4, but what if we want it to be G4?

Solution will probably be for C4 to secretly equal 1/1, but if you specify a different base notation (e.g. G4) then 3/2 hides in the background and divides out of each Peo so it looks like G4 is 1/1.

e.g. change inputPitchNotation to something like iPN so that the whole thing runs faster

Currently to set the base frequency or notation, need to do getEndFreqHz(startFreqHz)...

Make a parallel method for setStartFreqHz(startFreqHz), and same for notation. These make API more obvious.

In order to use JInterval in some other applications:

• May need to amend algorithm whilst using
• May need to amend tuning whilst using
• May need to set position using output of parseNotation(...), instead of the notation itself. (Because parsing notation is slow: if there are many JIntervals which start at the same notation, want to parse that notation one time only, and use the output of parseNotation many times.)

Need to expose to the API:

1. A method to get a peo from a Jinterval and a notation
2. A method to set the starting peo for a JInterval as this input peo
3. A method to change the algorithm
4. A method to change the tuning

Note - items 3 and 4 above require recalculation of positions. This can be forced by removing the positions, which is compressing the JInterval, so that the previous position info (frequency and notations) are no longer available.

Given a Jinote jn, then jn.copy() should return a deep copy that copies all the sub-objects, in particular the Peo.