movies

pjbmp2avi.exe seems to work fine, with the CinePack codec at 100% (default) it's about 11MB for 36 seconds.

Storing snapshots with window size at 720x480 (DVD fullscreen) yields 80K snaps on average, with no appreciable slowdown: 80 * 25 * 60 = 120MB @ minute. This seems better than storing bitmaps.

Actual date rate test: demo speed = 975, 18.4 minutes, size 1.256 GB, rate = 73MB @ minute

Random waveform bug can be demonstrated using new OscTest, settings: random, .01, .5, .05, .1

almost there

During crossfade, random waveform's frequency change glitches horribly, fix this. Also fix a minor glitch when patch is switched without crossfade: in this case clear the view's previous parameter info to prevent interpolation. Ring growth and master speed glitch too but it's less noticeable.

Overall it looks gorgeous and feels incredibly powerful and exciting, it's a different whorld. Master speed of 901 is very nice, maybe use this speed for demo? Maybe a bit too fast, 603 is good too...

Random waveform bug can be demonstrated using new OscTest, settings: random, .01, .5, .05, .1

more on clumping

oscillator must move into view so it can be subclocked (non-integer clock increments). See 1.0.69c.

clumping

The clumping problem goes all the way back to the beginning. It occurs when master speed and/or ring growth) are big enough to cause multiple rings per timer tick. When the view's timer hook adds multiple rings, the rings all share the same properties, which causes those rings to form an easily distinguishable group or "clump".

The worst offenders are rotation and skew (AKA shift). Both of these are zeroed at birth, and then incremented by the view's draw function. A major reduction of clumping can be obtained simply by offsetting each ring's initial rotation and skew. The offset is a delta multiplied by a fraction. The fraction is calculated by dividing the ring's index by the total number of rings that will be born for this timer tick. If four rings will be born, the fractions for the rings will be 0, .25, .5, and .75 respectively, and if the current rotation delta is .2, the initial rotations for the rings will be 0 * .2, .25 * .2, .5 * .2, and .75 * .2.

The only complication is that the rings are generated in reverse order. This means the indices have to be inverted, e.g. by using (count - 1 - i) instead of i, which means the count must be computed before the ring-adding loop begins. The count can be computed as:

int(m_st.RingOffset / m_Parms.RingSpacing) + 1;

Also note that the resulting offsets must be multiplied by RingGrowth to be effective.

The next-worst offenders are the LFOs. The LFOs are outside the view, but they only modify the view parameters on timer tick boundaries. This means that any LFO has the potential to cause clumping. The high road would move the oscillators into the view but this is a drastic change and has many side effects. The low road is to interpolate between the current and previous parameter values. In practice interpolation seems to work very well for all parameters except ring growth and ring sides. The view timer hook must calculate a delta between each parameter's current and previous values, like so:

for (int j = 0; j < 16; j++)
    delta[j] = (((double *)&prevparm)[j] - ((double *)&m_Parms)[j]) / count;

And then within the ring-adding loop, overwrite m_Parms with interpolated values:

for (j = 0; j < 16; j++)    // NOTE: don't do this to ring growth or # sides
    ((double *)&m_Parms)[j] = ((double *)&prevparm)[j] + delta[j] * (count - 1 - i);

And finally, restore m_Parms.

Interestingly, this seems to work perfectly with sine LFOs, but exhibits a noticeable periodic discontinuity with triangle LFOs. This seems to indicate an undiscovered problem with the above method, or possibly a bug in the oscillator object.

The final offender is the ring color. This is calculated in the view's timer hook, which means all the rings in a group will have the exact same color. This can probably be solved by interpolation as well.

front page image

1896x1038x72
canvas size to 1280x700
save for web at 50% jpeg high
result 640x350 +/- 35K

reverse and per-ring draw mode

In reverse, innermost ring fill test must be steps < minimum size AND steps < previous radius. This prevents possible holes when switching from forward to reverse, e.g. in lotus light.

The new freedoms must have a price, let's see:

250 iters of default patch, total time spent in Draw:

1.0.64:
.2269
.2237
.2263
.2251
AVG=.2255

1.0.63:
.2256
.2255
.2271
.2273
AVG=.2263

It got faster? Not likely. Try again using 250 iters of Pinwheel No Rand:

1.0.64
.5856
.5863
.5852
.5857
AVG=.5857

1.0.63
.5876
.5854
.5850
.5874
AVG=.5863

Very strange. Try a longer test? 1000 iters, window maximized, Pinwheel no rand with Ring Growth = 3 and Canvas Size = 300:

1.0.64
17.779
17.784
17.770
17.762

1.0.63
17.780
17.780
17.797

1.0.61 (no reverse or per-ring draw at all)
17.789
17.776
17.793

Well, somehow it got faster...

mouse sensitivity

Overall much better now that ranges are correctly accounted for.
Speed, zoom and hue all feel about the same.

Trackball is too twitchy at sensitivity = 100%, it feels best around 65%.
Maybe nominals should be lower? Try some other devices and average the results.