juliamusic / musicmanipulations.jl Goto Github PK

The package https://github.com/ziotom78/CorrNoise.jl has true power-law correlated noise instead of the approximate fractional noise ARFIMA creates. We should add this to humanize! and either replace ARFIMA entirely or just make a new method.

At the moment the argument f of timeseries is limiting because it only takes as an input the property vector instead of the note vector.

For example, you might want the timeseries of the velocity of the notes, but if many notes are in the same bin, you want to choose the velocity of the note with the highest pitch.

It is very easy to do this without it being a breaking change. We add one more call signature to timeseries:

timeseries(notes, property::Symbol, f, grid)
timeseries(notes, f::Function, grid)

Then, for the second signature, one has to change this:

https://github.com/JuliaMusic/MusicManipulations.jl/blob/master/src/data_handling/timeseries.jl#L47-L48

to instead of being

if j > 1
        val = Float64(f(getfield(notes[k], property) for k in i:i+j-1))
    else
        val = Float64(getfield(notes[i], property))
    end

to be

f(notes[i:i+j+1], property) for k in i:i+j-1)

The function f then always takes as an input a Vector{Note} and returns a real number.

Upon trying to quantize the notes of the following file with the grid [0,0.383,0.73,1]:

Piano - OP002.zip

I encountered the following error :

ERROR: LoadError: InexactError: Int64(700.8)

It is due to this line of code (line 118 of quantize.jl) :

final_dur = Int(grid[best]*tpq)

Which for some reason refuses to convert.
I have tried couple of things that didn't work, and for now my solution is to pass false for the argument quantizing length.

I think, separating visualization and MuseScore interfacing features of this repository should be moved to a separate repository so that all the other packages can use that as their dependency.

For example, MusicXML doesn't need any music manipulation features, but it needs visualization and interfacing with MuseScore.

Also, if we separate these features, we can use BinaryProvider to automatically install MuseScore (or other visualization software from other languages). Adding these to MuiscManipulation.jl makes it complex for no reason, but in a separate package aimed specifically at this, we will have much more freedom for providing external software.

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

1. Instead of getting the velocity, add an argument property::Symbol and use the function getfield to get the required property. This would allow the exact same function to give timeseries of pitches instead.
2. Instead of having strings or other things for how to choose which entry to get from multiple ones that are on the same grid, use functions as arguments. Functions could be maximum minimum average, etc.
3. Remove argument about whether to add zeroes or not. Always add zeroes. Users can get "stiched" versions by simply removing the zeroes newts = ts[ts .!= 0]. That makes zero sense in the end anyway though.

A PkgEval run for a PR which changes the generated numbers for randn! indicates that the tests of this package might fail in Julia 1.5 (and on Julia current master). Apologies if this is a false positive.
cf.
https://github.com/JuliaCI/NanosoldierReports/blob/7de24e455342298cbef56826b5827f0d7640d2c1/pkgeval/by_hash/b89e35c_vs_098ef24/logs/MusicManipulations/1.5.0-DEV-71a4a114c2.log

This uses a grid (establishes subdivision). It detects all quarter notes and find their mean modulo tpq. Then shifts all notes by this mean, so that the mean of the quarter notes is on the metronome.

Research shows that human timing fluctuations are not white noise, but instead pink noise with varying exponents from -0.5 to -1.5.

A simple function humanize! could first generate such noise using e.g. ARFIMA.jl and then add it to the note positions.

This change that was introduced in a8420ea can have scary consequences if one rights naive code that by mistake does Notes + something.

Instead, we should change to use different unicode infix operators.

There are many softwares that can print midi notes on a staff, the best of which is probably https://github.com/musescore/MuseScore

can we see their code and make a easy visualizer without much effort?

Having a DAW-like representation of Notes would be really helpful.

The best way is to do what cubase does: Use rectangles with width being the duration and color being the velocity. The height of where the rectangle starts is of course the pitch.

The function should be able to take a keyword argument, which is a dictionary of KEYS: which notes to plot and VALUES: what will be the name of the notes. This way it will be as general as possible because inside the function you can make the y axis only have the keys(dict).

The current version of quantize() excpects a grid to start at 0 and end at 1.

Some players have a systematics deviation, and removing them makes the music sound strange. It would be good to be able to use grids like [0.09,0.33,0.7,1] for example.

Describe the bug

it seems that the function mscore does not have the -n option.

MuseScore4 4.1.1
MuseScore4: Unknown option 'n'.
ERROR: failed process: Process(`mscore -n -T 20 -r 1200 -o bass.png bass.mid`, ProcessExited(1)) [1]

Minimal Working Example

using FileIO # used for loading the midi files
using MusicManipulations # tools for manipulating notes in Julia
using MusicVisualizations # tools for visualizing these notes

midi = load(testmidi()) # read the "test" Doxy MIDI recording.
bass = getnotes(midi, 3)
basstrim = bass[1:50]
musescore("bass.png", basstrim)

mscore -v
MuseScore4 4.1.1

In firstnotes if two quarternotes are apart by more than 1 tpq they are still considered belonging to the same bin.

This is very easy to fix by adding a second boolean operation which is the difference of positions. Then you simply boolean & the existing dif anddifference of positions to be less than<`.

@johncwok

PR #28 introduced the scale_identification functionality. Currently is not yet exported because the following things must be improved / modified:

• tests! The file seranade_full.mid is a recording of serenade to a cuckoo. It should be tested as well. In addition the file testmidi() is Doxy, which should also be tested.
• Improve the algorithm description. Right now the function does not do as it claims. It claims to find the "most probable scale" but this is untrue. It just returns the first scale with a match of the seven notes.
• Consider the return signature in case of failure. What should we return in the case that the function fails to find a scale? You cannot print from within a proper high level function. I suggest the function to simply error saying "we couldn't find a scale" and also show the 7 most frequent notes in the printed string.
• sort(Dict( is deprecated, we have to re-work the code a bit to do sorting after the dict is collected (sort keys and use sort indices on values as well) .