Add Cellarium: A Cellular Automata Framework for EuroPi #449
Conversation
# Add Cellarium: A Cellular Automata Framework for EuroPi ## Overview Cellarium is a high-performance cellular automata framework designed for the EuroPi platform. It provides a flexible, extensible system for running various cellular automata simulations with CV input/output mapping for modular synthesis integration. ## Key Features - MicroPython-optimized simulation engine with bit-parallel processing - Six included automata implementations: - Conway's Game of Life - Brian's Brain - Rule 30 & Rule 90 (Elementary CA) - Langton's Ant - Water Droplets Physics - Seeds - Real-time CV input/output mapping - Multi-threaded display and simulation processing - Configurable simulation parameters - Stasis detection and response system ## Technical Details - Uses byte-parallel operations for performance - MicroPython optimization with @viper and @Native decorators - Thread-safe buffer management - Memory-efficient bit field operations - Automatic garbage collection management - Configurable CV division ratios ## Controls - B1/B2: Mode selection and configuration - K1: Food value control (population growth) - K2: Tick rate limiter (simulation speed) - DIN: Reset/Feed/Clock input - AIN: Food/Tick rate modulation - CV1-4: Automaton-specific outputs - CV5: Stasis indication - CV6: Simulation tick gate ## Performance Considerations - Optimized for original Pico hardware limitations - Maintains backwards compatibility with older hardware - Careful memory management and buffer reuse - Efficient bit manipulation techniques - Thread-safe simulation processing ## Documentation - Full implementation guide in cellarium.md - Docstrings for all classes and methods - Performance optimization tips - Example patches and use cases - Implementation guidelines for new automata ## Testing - Tested on EuroPi hardware - Performance validated on original Pico ## Labels - CV Generation - CV Modulation - Clock Source - Random - Envelope Generator - LFO - Controller
remove example automata as it's not needed, included scripts are example enough.
|
Just a note, if desired the performance tips included within cellarium.md can be pulled out and instead submitted as a separate .md guide to a more common location with the repository. |
|
My main concerns at the moment revolve around file size, by creating the framework I have circumvented quite a bit of code duplication when adding multiple cellular automata, but the file sizes can still be a little heavy due to some of the optimisations. |
| from ucollections import OrderedDict | ||
|
|
||
| # Local imports | ||
| from contrib.cellarium_docs.automata_registry import get_automata_by_index, get_automata_names |
There was a problem hiding this comment.
Instead of putting the extra modules in the *_docs directory, can you put them in firmware/experimental/automata instead? Generally any shared code/modules get put in experimental. The _docs directories shouldn't contain any executable code, just text and any supporting doc files (e.g. images, PDFs, etc...).
There was a problem hiding this comment.
Thinking about it more, perhaps instead of firmware/experimental it might make more sense to keep it in contrib/automata? Unless you're hoping to share these across multiple contrib scripts they probably don't need to go in firmware.
The CI does a lot more formatting & linting checks on things put in the firmware directory. We turn most of that off for contrib since each program is generally assumed to be self-contained and wanted to keep the barrier to entry low for beginners who wanted to contribute code.
There was a problem hiding this comment.
Hmm that's probably a good idea.
They are quite bespoke to the cellarium script so it makes sense to not have it's presence within firmware mislead people.
I think Contrib/Automata makes sense but do you think it may make sense to have a Contrib/Supplementary/Cellarium folder or other such names sub directory?
I guess it depends on how likely it is for others to take a multi-file script approach.
There was a problem hiding this comment.
Keeping the additional-module directory the same (or broadly similar) to the base script it's from makes sense to me. Currently the only other multi-file programs use experimental for their extra stuff (because it's all shared across multiple programs). I don't think contrib/supplementary/* is necessary at this point.
A couple of years ago when I was first starting to share pieces between scripts (e.g. using the Euclidean pattern generator or quantizers in multiple programs) there was discussion about how to organize things. If we start getting more multi-file contrib programs we can definitely revisit that question, but for now I'm not too concerned.
| def on_b2(): | ||
| show_settings = False | ||
| b2_mode = list(self.MODES_B2.keys())[self.b2_idx] | ||
| if b2_mode == 'D IN': |
There was a problem hiding this comment.
Generally in EuroPi nomenclature we don't include the space in ain or din (or their all-caps equivalents). Not a big deal, but if these strings are ever visible to the user I'd prefer if they used the same formatting as the official docs.
There was a problem hiding this comment.
Acknowledged :) makes sense to match the official docs
| self.din_idx = (self.din_idx + 1) % len(self.MODES_DIN) | ||
| mode = list(self.MODES_DIN.keys())[self.din_idx] | ||
| show_settings = True | ||
| elif b2_mode == 'A IN': |
There was a problem hiding this comment.
As above: consider using AIN instead if A IN.
| self.num_alive = self.num_alive + born_died_diff | ||
|
|
||
| # Atomic swap under lock | ||
| with self._buf_lock: |
There was a problem hiding this comment.
Per the docs the with keyword doesn't appear to be supported by the micropython.native code emitter.
It looks like it's used a few times in this function. Should these be refactored to not use the with keyword?
| self.update_inputs() | ||
| self.reset() | ||
| #Start ASYNC display thread | ||
| if not self._display_thread_started: |
There was a problem hiding this comment.
Why are you checking if the thread's started before starting it? Nothing ever sets this flag to False after initialization, so shouldn't this thread always get started?
| module, clazz = automaton_class_name.rsplit(".", 1) | ||
| return getattr(__import__(module, None, None, [None]), clazz) | ||
| except Exception as e: | ||
| log_warning(f"Warning: Invalid automaton class name: {automaton_class_name}\n caused by: {e}", "cellarium") |
There was a problem hiding this comment.
You don't need to add Warning: to the start of the log strings; the log_warning function automatically adds a [warn] prefix to the messages to make the level clear.
|
Gave the code a quick first-pass. It looks good, but I have a few questions and some suggestions for how to better-organize it. The biggest issue I see is having executable code in the |
|
Nice, thank you for your time! I also wasn't sure on the docs folder, so expected there to need a change there :) |
2 participants
Add Cellarium: A Cellular Automata Framework for EuroPi
Overview
Cellarium is a high-performance cellular automata framework designed for the EuroPi platform. It provides a flexible, extensible system for running various cellular automata simulations with CV input/output mapping for modular synthesis integration.
NOTE: since there is heavy use of Viper decorator tags, this will fail testing until they are included in the test handling.
Key Features
Technical Details
Controls
Performance Considerations
Documentation
Testing
Labels