-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Conway's Game of Life LFO #313
Conversation
… slowly to reliably use an external clock
…ame process and low during drawing. This gives us a reasonable FPS monitor with low impact.
…the whole field. This improves the FPS by a lot, but makes it less stable overall. Decent trade-off, I think.
…V channels do. Use the buttons as respawn or reset
… 3, and 4 to estimate if we've reached stasis. This works much more reliably than the previous methods and prevents the module from stalling if we have CV6 patched into DIN
…of like it, but some may definitely find it annoying
…inverses of each other. Use >>3 instead of //8 to speed up some of the map. Treat the field as a torus, do some minor re-organizing
…ng 1 wasn't enough to store the local neighbourhoods persistently
…ted range of the first 3 outputs based on plugging them into a scope
…; this seems to reduce the rate of false positives dramatically
…should reduce the memory & CPU footprint a little bit. At the very least it means we have less dynamic memory allocation
…ough data to justify the observations i've made as "typical"
…his produces more varied values on this output. Change the random_spawn functionality to _also_ clear spaces. Add the ability to set a byte-array to all 0xff or 0x00. On a respawn just assume the whole field has changed for the first tick
…emove modulo and intdiv operations and replace with bitwise operations
…eld is empty; either causes an exception because we're calculating LOG(0)
…o keep CV6 patched into DIN to keep the module from stalling
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chrisib nice work here. This code is relatively complex, but it is nicely factored, and easy to follow. Some of the math and bitwise operations are a bit much for me, but I think that I followed most of it.
I've added my usual slew of changes, questions, and discussions.
Also, I assume that this code is no longer in 'draft' state, since you requested a review on it.
|
||
# If we've achieved statis, set CV6 & trigger a reset | ||
if in_stasis: | ||
cv6.voltage(GATE_VOLTAGE) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[question] How long does this gate end up being held high? Is it long enough to be useful? Should it be called a trigger rather than a gate? I tried to see the LED light up on my dev module during reset, but I didn't see it. I connected it to a drum sound and let it run while i did this review. I certainly heard it resetting, but not as often as I expected. (anecdotal) I find myself wanting for a reset counter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's long enough that before I added the automatic reset functionality you could self-reset by patching cv6
into din
and trigger the reset that way. So I'd definitely say it's useful, thou definitely as a trigger and not as a gate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So should the signal on cv6 be referred to as a trigger rather than a gate in the documentation? I'm not sure if that would be a source of confusion for users or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed the documentation to describe CV6 as a trigger instead of a gate. The gate duration is based on the amount of time it takes to reset the field, so it's a measurable amount, but is fast enough that using it to gate anything would be pretty hard.
I didn't realize I had requested a review on it. I think that was automatic. But it's probably as ready for review as it will ever be |
… empty spaces when overwriting the field's contents
I was referring to it being number 2 in the list of PRs in the programming discord channel. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still one minor open question, but whichever way you choose to resolve it is fine.
Everything else looks good to me.
Just tested on my module and works great, LGTM! |
Adds a new free-running LFO based on John Conway's Game of Life. The simulation is not clocked externally, resulting in variable FPS based on the density of the playing field. This can result in interesting, swingy gate signals, as well as an accelerating tempo immediately after the game resets.
The OLED shows the current state of the game, making for a fun visualization even if nothing is patched.
CVs 1-3 output stepped semi-random 0-10V signals based on the state of the game:
CVs 4-6 output 5V gates based on the state of the game:
Pressing either button or sending a signal to
din
will randomly reset the field with a density derived fromk1+ k2 * ain
.Based on my testing CV6 is fairly reliable, but can occasionally trigger false-positives. I haven't run into any false-negatives with the current implementation, but there's only so much testing I can do with a single module and a semi-random system.