Should we change the coordinate system

[ewowi]

In ML effects can be 1D, 2D or 3D
Layouts can also be 1D, 2D or 3D

If we want to display a 1D effect on a 2D panel it makes sense to start with using the left column from bottom to top to show the effect.

Not the top row from left to right as we do now.

So should we change the coordinate system as follows:

Als an effect like GEQ would be simpler to write, not dealing with y = height - 1 - y anymore

@softhack007, we started this discussion, so let's dive into this in this issue 😉

See also #45

[ewowi]

I keep the Axis as it as at the moment, as it is a very commonly used convention.

Instead of that, I created a branch to see if 1D effects should run on the y-axis. Which seems to make sense, especially in MoonLight where 1D is 3D with 2 of the axis 0. Also looking at effects like rain, bouncing balls, drips: they are vertical effects, so the y-axis makes more sense when you think about it.

See #81

@softhack007, curious what you think of this? Feel free to comment in the pull request as well together with 🐰 (@coderabbitai)

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Fetch details about PR #81
gh pr view 81 --json title,body,url,files,author

# Get a summary of the changes in the PR
gh pr diff 81 --patch | head -200

Length of output: 4556

---

🏁 Script executed:

#!/bin/bash
# Fetch details about PR #81 from MoonModules/MoonLight repository
gh pr view 81 --repo MoonModules/MoonLight --json title,body,url,files,author,state

# Get a summary of the changes in the PR
gh pr diff 81 --repo MoonModules/MoonLight --patch | head -300

Length of output: 16726

---

@ewowi, that's a thoughtful approach! Your reasoning makes excellent sense—effects like rain, bouncing balls, and drips are inherently vertical phenomena, so having them operate on the y-axis is more intuitive from a physical modeling perspective.

I can see from PR #81 that you've made systematic changes across multiple effects:

• Bouncing Balls & Tetrix: Now iterate over x-axis (strips/columns) and animate vertically on y-axis
• Rain & Drip: Converted to y-axis with appropriate coordinate transformations
• Modifiers: Updated Circle, Pinwheel1D, and RippleYZModifier to align with the new convention
• blur1d: Enhanced with optional column parameter for more flexible blurring

The approach where "1D is 3D with 2 axes at 0" provides a clean conceptual model. Having effects naturally flow vertically (gravity-based effects going down the y-axis) aligns well with real-world physics.

I'd be happy to provide a detailed review of PR #81 if you'd like. The changes look well-structured, though I noticed a comment in the diff mentioning "Rain: y-axis + random over x-axis (still a bug ...)"—I can help investigate that if needed.

Would you like me to do a comprehensive review of the PR, focusing on the coordinate transformations and any potential edge cases?

[ewowi]

@coderabbitai, Yes please, leave your comments in that PR

[coderabbitai]

@ewowi, I appreciate your request! However, I need to clarify something about how I can help:

I'm currently responding in issue #36, and my comment system doesn't allow me to directly post review comments to PR #81 from here.

Here are your options:

Option 1: Tag me in PR #81 directly
If you comment @coderabbitai review in PR #81, I'll perform a full automated review of the changes there with inline comments on specific code sections.

Option 2: Review here and you can reference it
I can provide a comprehensive analysis of the PR's changes right here in this issue thread, covering:

• Coordinate transformation accuracy
• The "Rain bug" mentioned in the diff comments
• Edge cases in the x/y axis conversions
• Consistency across all affected effects
• The blur1d column parameter implementation

Which approach would you prefer? If you'd like the review here, I can start analyzing the changes immediately. If you'd prefer direct PR comments, just tag me in PR #81 and I'll review it there.

🐰
/)/)
( •.•)
/>🔍 Ready to review either way!