elementsdirectory out of the
coredirectory, and then once I actually try it out do my best to mitigate it being a pain, which I'm hoping just means adding some helpers to core that make using it easier. Also possible something to refactor around how the renderer (outside of core) will interface with running events on the grid. Right now that's pretty tightly coupled.
// TODO VDT - Should an Element ever get Audio Input directly i.e. - EventWindow::GetAudio(), I dont know. // maybe - the Element could get a Notice of an Audio Event occurance on the Containing Tile. // BUT, it should be up to the Element currently being processed if it cares about audio input. // maybe - Whatever the thoughts were for processing changes in LIGHT should apply to Audio
been thinking about some options for handling input, likely many I'm leaving out:
The Tile gets an input event and randomly (or specifically) seeds it into the grid
The Tile could be a bit more godly and broadcast an event to all Sites within itself, it could even spread the word tile-to-tile as an intertile input mechanism.
Elements on the MFM could specifically subscribe/listen for events on the Tile they are in through something (but what is it?)
InputEvent type USatoms which stream towards whereever that information is desired.
UrSelf.ulamis like the highest bar to clear in the whole ULAM code base, but that would provide it to every element . Another approach would be have some kind of more narrow base class, like
ULAM/share/ulam/stdlib/EventAware.ulamor whatever, that ulam classes could choose to inherit from, and override methods therein.
Signal? -- would be better for I/O related stuff.
Mosquito(which are both