Enigma :: FFR Batch Submission
Rapta - Enigma - Pixel Terror & Aviella [6 / 10]
Sept/Oct 2020
PublicEvents
Rejected
Monstercat Blanket Permissions
From a Monstercat Uncaged album.

Simfile Folder Name

Enigma (Rapta)

Note Count

916

Chart Length

1:36

Average NPS

9.762

Estimated Difficulty

83.22

First Note

0:03

Ending Note Delay

0:03

Hand Bias

x 34

Framers

0 - 0 1 - 0 2 - 1 3 - 31 4 - 50

Jumps

x 207

Hands

x 28

Quads

x 0

Color Jumps

x 2

Color Hands

x 0

Color Quads

x 0

Most notes in:

1/3 of a Second
9 - 27.00 nps 0.5 Seconds
13 - 26.00 nps 1 Second
21 - 21.00 nps 2 Seconds
35 - 17.50 nps 5 Seconds
72 - 14.40 nps 10 Seconds
135 - 13.50 nps 30 Seconds
373 - 12.43 nps 1 Minute
700 - 11.67 nps

Color Count

x 361 (39.41%)
x 220 (24.02%)
x 17 (1.86%)
x 94 (10.26%)
x 6 (0.66%)
x 134 (14.63%)
x 16 (1.75%)
x 10 (1.09%)
x 58 (6.33%)

Largest Note Gaps

2.47s0.83s0.63s0.57s0.43s0.43s0.43s0.43s
35
28
21
14
7

Removed the .old again

A new chart file was uploaded with the following changes:
----------
Hand Bias changed: 32 => 34

Enigma 6
I think it's basically one major problem that I have with the file, and that is the burst patterning.

The main issues are:
1) it inconsistently represents the same sounds with differently patterned bursts; e.g. at 42.394 vs 49.155 have very different denominations for what sounds like the same sample;
2) unnecessarily abrasive; e.g. the 3 column in the burst starting 27.183 - you have a cameljack on the rh leading into another cameljack...that slows down. Then at 31.408s there is another burst where the right hand is playing [34]343[34] on 142bpm 32nds and 48ths. In my opinion it's just really hard to justify that kind of note density and hand bias for the sounds that you're stepping to. 42.183 is even more stressful, with the fast uneven 343 pattern leading right into a speed-up-and-down anchor jack on the 4.
Then there's stuff like 57.605, which while not wrong under your structure, just feels...mean. the sound here is pretty smooth - it's hard to imagine a random player going "that was a cool 212 [at 284bpm 16ths]". 60.986 is even harder, and there’s no real musical justification for why the two are any different from each other, or from the other 32nd bursts that are played straight without hidden minijacks (eg 67.746).
3) because of [1] and [2] you have extremely wild difficulty swings from burst to burst. For instance, 67.746 is exactly the same sound as 57.605, and similar to 74.507 without additional bass kicks on the 8th, but because you've decided to start out with a [34] instead of the [23] previously, you don't have any fast minitrill on either hand here. This sort of difference I think usually leads to a frustrating player experience - as the patterning and difficulty control feels quite random (even if it isn't) and hard to relate to the music.

- Also not really sure why the ending is offset like this and has 32nd note syndrome - would just adjust the bpm after the note at 80.704 so that the major chords afterwards land properly on 4ths.

Despite what I've said about the bursts here, I actually think this file has incredible potential to be a very memorable release. The idea of a file that is speedup-and-down burst driven is quite compelling and unique - even in FFR which is basically walmart for bursts of all kinds. I think that all this file really needs is some careful polish and control. For instance, one immediate suggestion I'd have would be not to try to layer jumps at the start/middle/end of very dense bursts; that alone would go a long way to creating a more reasonable player experience in my opinion.