Considered creating a horizontal key rain design to fit games like Muse Dash and Taiko no Tatsujin?

[yn2aa]

Seeing the vertical key rain made me think of a horizontal version. It would be fantastic if adding support for games like these as well — Dm Note would become even more customizable. Would it even be possible to customize the shape of the key rain, such as circular layouts?

[lee-sihun]

Hi, thanks for the great suggestion!

We've received a lot of feedback asking for more customization options for the note effect, and we've been steadily working to widen the range of available options. Let me answer each of your two suggestions.

1. Horizontal key rain — There's no problem at all, technically or visually. Once the UI/UX review is done, it can be introduced right away. We'll add this option in the update coming in August or September.

2. Customizing the shape of the key rain — This one has a lot of points to think through. In the past, we actually tried to visually implement circular tap notes and long notes extending from a circle, like in rhythm games, but due to structural characteristics there are constraints compared to note effects in actual rhythm games.

The key point is that rhythm game note effects are deterministic. The game knows in advance when each note appears, when it ends, and how long it lasts — so the desired shape can be pre-rendered and sent out. A key viewer is a different situation. DM NOTE's note effect visualizes the time the user holds a key, so we cannot know when a note will start or when it will end. As a result, the point where a note is spawned — or the point where a tap note should be distinguished from a long note — ends up looking very unnatural. (If you turn up the note rounding option, a short press produces a circle-shaped note; try pressing a key briefly vs. holding it and you'll see what I mean.)

In fact, DM NOTE already ships an option that partially works around this: the delayed-note option, which delays the note's appearance slightly so we can determine in advance whether the input was a "short tap", and then draw it as a fixed-length tap note. It's a trade-off — you pay a small display latency to gain shape determinism. Circular notes could partially work the same way, but it would compromise real-time responsiveness, which is the core value of a key viewer.

There's also an alternative that avoids latency: splitting a note into a head (circle) + body (growing segment) + tail (circle on release). But this approach still leaves the same unnaturalness at the seam between the head and the growing body — exactly the tap-note/long-note distinction point mentioned above.

One thing I'd like to clarify: by "circular layouts", do you mean (a) making each individual note circle-shaped, or (b) arranging the key rain itself in a circular layout (notes flowing along an arc)? If it's (b), that's a separate topic from the determinism issue above — more of a renderer architecture question — so knowing your intent would help me give a more concrete answer.

If you have any concrete ideas for solving this, feel free to suggest them!

[yn2aa]

Thank you for your quick reply!

What I meant was option (a): making each individual note circle-shaped. I only noticed the note rounding slider for key rain after you mentioned it, haha. I cranked its value all the way up to the maximum 100px to test the look. Short taps render as rounded rectangles, while long holds turn into perfectly rounded long notes.

I’ve come up with a simple workaround idea. There’s a setting called "Force Short Note Length" (I’m not sure if this exact name is used in the English UI,because im using translator). We could set the circle’s diameter equal to this minimum note length. Then all short taps would simply render as full circles, which would deliver the exact visual effect we want. I ran a quick test: setting the minimum note length to 60 alongside 100px rounding creates a convincing pseudo-circular tap note. The only downside is a slight visual disjoint during the spawn animation, but the final shape looks exactly how I hoped it would.

That said, I guess your team might not want to rely on this makeshift workaround. I fully understand the visual discontinuity issue you brought up — unlike rhythm games, this tool cannot predict how long a key press will last upfront. The three-segment note structure you mentioned sounds far more elegant, and it follows the same logic as many circular UI skins found in PC games. We could render fixed semicircular caps for the head and tail of every note, and only adjust the length of the rectangular middle segment based on how long the key is held. This way, every press would look like a neat circle or capsule shape regardless of hold duration. This is just a mental prototype though, so there might be unforeseen flaws with this design. I believe pairing this segmented rendering with the "Force Short Note Length" option would be necessary to smooth out most unnatural visual artifacts.

From my experience with the current v1.6.0 build, the latency introduced by lookahead is totally acceptable. The tool even recommends a value of 2080 for me. I also stumbled across what might be a bug: the lookahead delay only applies to the key state indicators at the bottom, not the key rain itself. Lookahead values under 50ms are barely perceptible at all.

Of course, circular notes won’t work well for wider key lanes such as the side lanes in DJMax. The current rounded rectangle design already looks great as-is. However, the minimum note length setting applies globally. If we adopt this workaround, it will distort all rectangular notes and make them look overly bloated.

[lee-sihun]

Thanks for running the experiment and sharing the screenshot! Finding and verifying that workaround yourself made this discussion much more concrete.

Before answering your points, let me pin down the most important fact first. The delay behavior you observed is not a bug — it works exactly as intended. DM NOTE actually has two separate delay features with different purposes.

(1) "Key display delay" — this applies only to the key state indicators at the bottom, not to the key rain. Some background on why this feature exists: when using DM NOTE with a keyboard-based rhythm game, you set the note effect to flow top-down, enable this delay, and then apply the auto-calculated delay value to the game capture in OBS (or another recording program). In the final recording, DM NOTE's notes arrive at the judgment line in sync with the gameplay — just like real rhythm game notes. (The video right below the program screenshot in the README shows this in action.) The key rain being not delayed is essential for this to work: notes must spawn immediately and travel down so their timing matches the delayed game footage. By the way, the 2080ms recommendation you saw is exactly this auto-calculated value (track height ÷ note speed).

(2) "Enforce short-note length" — this is the one that delays the key rain itself. It briefly holds back the note's appearance to determine whether the input was a short tap, then draws it at a fixed length — the option I mentioned in my previous reply. If you were looking at these as a single "lookahead" feature, I can see why it was confusing — they're separate settings.

Thinking it over while writing my previous reply and reading yours — for users who know how to set up their recording software as described above, the delay itself shouldn't be a problem. As you suggested, the three-segment structure (head/body/tail) combined with an enforced delay looks like it could achieve the intended visual far more effectively than the current makeshift workaround. (Not a firm commitment yet — it needs some experimentation.)

Your last point about the global setting is also spot on: since the minimum note length applies globally, the circular-note workaround distorts all rectangular notes too. This is exactly why, even once the technical breakthrough is in place, making it easy to use will take additional time — it needs to be separated from the current delay features, likely scoped per key/lane, and wrapped in a UX that stays simple and smooth. So I expect this feature to take longer than the horizontal key rain from my previous reply. At best it might land in the same version; otherwise it may come later.

[yn2aa]

I now understand that the Key display delay parameter is designed to mimic the falling note timing of rhythm games. I mistakenly thought it was used to introduce delay for better note length rendering,thats why i used"lookahead". I often keep this key viewer plugin running during my live streams, which is why I mentioned that a delay of around 50ms is barely noticeable. For people recording videos, even 500 or 5000 ms of delay would be totally fine, haha.

Thank you so much for taking the time to read my lengthy feedback patiently. I’m really looking forward to seeing these features implemented someday!

[yn2aa]

By the way, I have a separate question unrelated to the topic we’ve been discussing. The border effect used to display JS compatibility looks absolutely stunning, yet I’m unable to describe it clearly enough to get an AI to generate the corresponding code. Would it be possible to share the JS styling code for this effect in the project library?