Why do many points orbiting at different speeds line up in this particular way??? And when? I am a generative artist and I love to make twisty-twirly animated manadala like things.  I discovered a pattern that I keep using in my animations that always produces some really interesting behavior and I don't understand it.
Examples:
https://www.instagram.com/p/Ba3hRAoh1ws/?taken-by=ninjacodeartist
https://www.instagram.com/p/BahgshXAZBC/?taken-by=ninjacodeartist
https://www.instagram.com/p/BYkkAplhOFu/?taken-by=ninjacodeartist
https://www.instagram.com/p/BX-Tez7AI5I/?taken-by=ninjacodeartist
All these examples are made in a similar way: (please forgive the non-mathematical language)
I define some number of points, and then make them rotate where each point has a slightly different speed.  So, for example, if the first point rotates 1 degree per frame, the second would be 2 degrees per frame, and the 3rd at 3 degrees per frame.  (Not exact numbers, but that would do it.)
The points align at very predictable times... every time I make such an animation I get the same pattern... irregardless of the number of points or the exact speeds... but in interesting ways that I don't understand.  Forgive me... I'm not even sure how to describe what I am seeing.  The points align to form different numbers of 'arms' coming out from the center... sometimes 5, sometimes 4, sometimes 3, eventually 2, and if I wait long enough, they all align completely and form 1 'arm' and then continue all over again.  But after hitting 3 there are 4 and 5 and 3 again before it hits 2 and tons of different alignments before it all aligns together.
Why?  And how?  And how can I understand exactly why each alignment occurs when it does?
Thanks!

Edit:
  float t = (float)frameCount;

  for(int i=0; i<numPoints; i++){
    ellipse(sin((t*i)/3000)*i,
          (cos(t*i/3000)*i), 5,5);
  }

This is an example of code that would produce such a thing. The sin() and cos() are defining the x and y coordinates for each point.
 A: Why you get lines appearing:
As the frame count advances, the quantity $t/3000$ in your code takes on different values. Think of $t/3000$ as an angle $\alpha$, and the variable $i$ in your loop as a radius $r$.  Then your loop is effectively


*

*Step 1: Start with radius $r=0$ and $\theta=0$.

*Step 2: Draw a dot at radius $r$ and angle $\theta$ from the centre.

*Step 3: Increase $r$ by $1$, and increase $\theta$ by a constant angle $\alpha$

*Step 4: Jump to step 2 as long as necessary.


When angle $\alpha$ is close to $0^\circ$ (or $360^\circ$ or $720^\circ$ etc), the dots will appear in a straight line. The code draws a dot, moves out a bit without much rotation, draws another dot etc.
When angle $\alpha$ is close to $180^\circ$ (or $540^\circ$ or $900^\circ$ etc), the dots will appear in two straight lines. The code draws a dot, moves out a bit and rotates $180^\circ$ to the other side, draws another dot and rotates $180^\circ$ back near the first dot, etc.
In general, when angle $\alpha$ is close to $\dfrac{360^\circ}n$ (or $\dfrac{360^\circ}n+360^\circ$ or $\dfrac{360^\circ}n+2\times360^\circ$ etc), the dots will appear in $n$ straight lines. The code draws a dot, moves out a bit and rotates $\dfrac 1n$ of a circle, draws another dot, etc.
Why each alignment occurs when it does: 

But after hitting 3 there are 4 and 5 and 3 again before it hits 2 and tons of different alignments before it all aligns together.

This order of these numbers is much harder to pin down.  In your code sample, it depends heavily on the constant 3000.  If you've ever seen a movie with wagon wheels running backward due to the frame rate, or a fast-spinning electric fan appear to spin slowly under a strobe light or fluorescent light (50 cycles/sec in Aust, 60 cycles/sec in USA), exactly what you see depends on the frame rate / flicker frequency.
In short, for any constant you'll see a patterns. The patterns you get will will be symmetric either side of $1$, e.g. if you see $5,4,2,1$ the next things you'll see will be $2,4,5$. But the next time you come near a $1$, it may not be aligned exactly and these differences will pile up over time and produce variations in the patterns.
For any given number, e.g. 3, you could work out the theoretical frame counts that would give you 3 perfectly straight lines, but they could be decimals like "frame 26.27".  If this number was close to a whole frame number, you'd see 3 lines. If it's half-way between frames and the dots are spinning slowly, you'll see something close to 3 lines. If it's half-way between frames and the dots are moving really fast, what you see on either side (at the exact frame boundaries) may not look much like 3 lines at all.
Assuming your $\sin$ and $\cos$ functions are using radians, you'll see a single line roughly when $t/3000 = 2\pi\times k$ when $k=0,1,2,3,\dots$, i.e. when $t=6000\pi\times k$, so around every 18849 frames.  You'll see 2 lines around every $6000\pi/2 = 9425$ frames, 3 lines about every $6000\pi/3=6283$ frames.
If the dots are moving slowly enough, the patterns in the number of lines you see will follow the denominators of the Farey sequence, e.g. if you care about numbers of lines up to 8 you'll see the pattern $1,8,7,6,5,4,7,3,8,5,7,2,7,5,8,3,7,4,5,6,7,8,1$.
