kjossul / licksterr Goto Github PK
View Code? Open in Web Editor NEWA platform that matches songs with scales, chords and other musical concepts.
License: MIT License
A platform that matches songs with scales, chords and other musical concepts.
License: MIT License
At the moment, each form includes notes up to two frets below the leftmost root (to solve the 'Gb` issue where open strings would not be counted) and one fret above the rightmost root.
Instead, each box should include notes in scale order, preferring notes that are inside the root shape. This can be easily fixed by introducing a "simplify" function that removes redundant notes from the shape (e.g. by giving a score to each note, the farther from a root fret-wise the worst). Comparison should be done considering two strings at a time.
The key finder is not perfect, users should be able to change wrongly identified keys
Currently, two endpoints are up for getting tracks and single measures info. This works fine, but the list of matching form for each measure is huge.
Here is an idea: create an endpoint for track analysis that instead of returning single ids in the measure field, it returns measure matches giving a greater score to the forms that appear across multiple measures (a simple average and a threshold should work, the value probably needs some tuning but 20% should be a good start)
A list of other key profiles is described here.
Maybe combining all of them will yield better results.
A lot of guitarpro tabs have side tracks that are not really interesting. An option should be present in the endpoint to allow parsing only for the given indexes.
In this way color transitions will be seamless, instead of having 5 fixed values.
This should be done by considering chord progressions
This is an interesting research paper over optimal guitar fingering.
The amount of time has yet to be defined, but a full measure should be sufficient.
It's useless to build them every time. Even a json file to store the shapes should be sufficient.
Also, refactor the form construction into analyzer.py
for the same reason.
E - 0 -- 2
B - 0 -- 2
Should be considered a single M2 interval, even though it's played on multiple strings.
Rules:
Licks at the moment are just stored as a bunch of notes. This is wrong, though, since a lick is also related to note duration. For this reason, it is more convenient to use a measure as the "atomic element" to compare against forms. Considering full measures is also easier to practice and combine licks.
Currently all the forms are stored inside a json file, while these should be moved into the DB now that models are up.
Consider refactoring of guitar.py
to directly interface with db.Model classes.
Currently, the parser simply stores for each note the amount of time that it was played. While this should be enough to determine the key at the end (the note played the most is likely the key), a more advanced analysis can be done, considering that usually licks start/end on roots, thirds and fifths. This kind of manual feature extraction could waste a lot of time though, so better considering it in the future only if the first methods fail consistently.
This would be a nice addition but probably useless at the moment. Needs research from experts to see if it could be useful.
Intervals will be done in the future (and maybe not even that useful for the purpose of this project)
The analyzer should be able to identify forms even on partial shapes and on different octave.
For example, in the G Ionian the first 4 frets [0-3] are part of the G form transposed one octave below, even though the form is not in its full shape (the M7 on the G string is missing).
Currently, each note is yield individually and this could result in multiple notes recognized in different scale. I think the solution is to yield notes in group, in such a way that the whole lick is returned.
The analysis on the forms should be done in a different function: first I should match a whole scale, and then look at what forms inside that scale are played more.
How should modulations be handled efficiently? Currently, the song updates the possible keys while it parses the song, so a modulation would not be detected.
Currently there are 11 supported scales, with 12 keys each and 31 forms (combinations of different sizes of CAGED), for a total of roughly 4k forms to compare every time we find a lick.
Since we want to narrow down this number, I think the best way is to keep a dictionary similar to
d[note] = {set of forms that contain this note}
And update the possible scales by intersecting sets at each note. This should work as a first implementation, further ideas will be collected instead better performance is needed.
Chords should be used as separators (i.e. if we have note - chord - note no interval should be computed).
"Long pauses" should be used as separators as well, but this might be hard to determine so it will be done in the future.
Creating new images for each FormMeasure might not be feasible, so I have to find a way to directly change the svg.
EDIT: actually, there is no need to store svgs at all. We can fix a small size for PNGs and compress that way, easily staying in the MB range for the space needed.
Move all drawing methods for a single form on this class.
Complete list here
Since parser set up takes some time, it's moment to set up an endpoint to handle song parsing. This will be a feature of the application in the future anyways.
A possible use case can be to recognize intervals only inside a single box (i.e. setting prev = None
when a note out of the box is played).
Note that with boxes I am referring to patterns (shapes) not positions. Explaining video
There is other stuff aside from CAGED, such as 3 notes per string, Segovia and so on.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.