-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use more specific don/ka types when writing to fumen (ド, コ, ドン, カッ, カ) #41
Comments
I assume that the logic goes like this: This was mostly wrong -- see PR for the real logic
For example:
Groupings seem to include any set of notes with identical durations between them, e.g.: (Note the katsu at the end, even when notes are spaced out) I will have to be quite careful when keeping track of note groupings (tracking between-measure groupings, making sure to properly identify when a grouping ends, etc.). |
It looks like there are a handful of approaches for clustering in 1D (see this SO answer). Many of them are using numpy / scipy, though, whereas ideally I would want to implement something in pure Python to keep the distributed binary size small. I do think that the 1D clustering problem here is quite a bit simpler than the cases described on SO:
So, maybe I can come up with some sort of simplified algorithm to group the notes, given some assumptions. For example:
|
This should match most fumens. Some exceptional cases I've seen: - [x] ~In official fumens, even-numbered clusters of 4 notes will sometimes be ドドドド or カカカカ. Right now, my converter will always use ドドドドン or カカカカッ, since I don't really understand the rules behind it.~ Fixed: Now, all 16th notes and above in groups of 4 will no longer use the don/kat ending character. - [X] ~In official fumens, sometimes isolated notes will be grouped together, but sometimes they will be treated as single clusters of 1. Right now, my converter will always try to cluster isolated notes.~ Fixed: Only 4th/8th/16th/etc. notes will be clustered. Whole/half notes will not be clustered. - [x] ~Right now, my logic always treats big notes as their own cluster. But, sometimes you get a cluster like `ddddD`, and right now my converter treats this as (ドドドドン) + big DON instead of do-ko-do-ko-DON.~ Fixed: Now big notes are included in clusters. - [x] ~For high-level Oni songs with complex groups of dense notes (e.g. (12th/16th/24th) notes mixed with (16th/34th/32nd) notes), official fumens seem to group them together even though they technically have different timings. Right now, my converter will group the 32nd notes, but treat the 16th notes as their own separate group.~ Fixed: Now anything above an 8th note will be clustered together. - [X] Songs with BPM gimmicks. e.g. the TJA has low base BPM, but then everything is doubled/tripled except for one section. I can't remember which songs have this? Something like RNG Cinderella? - Maybe solved by 1f640c1? Fixes #41.
Since TJA files use only a single number to represent dons and kas (1 and 2 respectively), I have only been writing a single type of don/ka to the converted .bin file.
However, official fumens actually have 3 types of dons and 2 types of kas. And, different types will be used depending on how the dons and kas are grouped together:
Theoretically, my converter could track if a note is part of a triplet/quad/etc. and write the different notes accordingly. But, it might be quite tricky to programmatically detect groupings of notes.
Maybe what I could do is track "time since last note". If the time decreases (i.e. notes are closer together), we enter a "grouping". If the time stays the same, then we're still within the grouping. If the time increases (i.e. notes are further apart), we have exited the grouping. But, I don't know how foolproof that is if we consider BPMCHANGE commands, etc. 🤔
The text was updated successfully, but these errors were encountered: