I made some good progress on the design of an early prototype forlast week’sJET data structure design. So far, it’s all working out well (I’m coding this in C), with some useful refinements:
the gadget + wiring configuration can be serialised to a binary format, this can be used as data exchange format when sending a setup to a µC
there is now also an extension to the GC’d memory manager, which allows storing structures compactly in ROM
What this all means, is that I think I now have an early-but-working starting point for implementing the Pd-like JET engine, which can fit in small µCs and support a flexible message-based dataflow design.
I realise that all these deliberations and notes about “JET” will mean very little to most people. It’s all based on a vague idea I’ve been toying with for several years now.
Here’s a little example to show how the different ideas will hopefully come together later on. This is a “circuit” to control the brightness of an LED via a rotary encoder:
A few notes to clarify this diagram:
- each block and circle is a “gadget” in JET terms and the wires carry msgs, usually flowing from top to bottom
- the rotary encoder is tied to 2 GPIO pins, and would use a “driver gadget”
- likewise, the LED is tied to a GPIO output pin which can be set and cleared by sending the proper msg
- “
metro 25” is a “metronome” gadget which ticks every 25 ms - “
delay 1” sends msgs coming in on the left inlet to its outlet, after a delay - we can change the delay by sending a new (int) value to the right inlet
- “
within 1 24” limits incoming ints to the range 1..24 and passes them on - “
onload” sends a message on startup, to start the metronome ticking - everything runs using the dataflow mechanism, parallelism is built-in
At this stage all of this is imaginary, i.e. pure vapourware. And I don’t even have any practical experience with Pure Data, so many, many details are bound to change.
I also want to implement a visual diagram editor in the browser, so that the above is literally the way circuits are constructed. With a set of “gadgets” to allow building interesting stuff. But that’s for later…
The reason this keeps me hooked, is that it could all excel in terms of modularity and scalability, IMO. The “gadgets” are self-contained modules, and the messages flowing between them clearly define the interfaces. Anyone can add more gadgets, and they can expose all the intricacies of the underlying hardware.
These circuits are self-documenting and trivial to extend. Also, since everything is message- (i.e. event-) based, intercepting them will allow convenient debugging.
The Node-RED project has numerous similarities, but its engine is JavaScript and intended to run on much heftier systems than what I’m aiming for. Then again, I wouldn’t be surprised if JET could be made usable in combination with Node-RED.
Is JET ambitious? Heck, yes - I’m not sure it’s even possible to get it all working across remote links and pared down enough to fit in a small µC. But it’s a worthy goal, IMO!
And with that, dear reader, we’ve reached the end of 2017. I’m going to make some changes to my posting frequency - starting right now - by announcing a break for the coming month. I need some time off (for a number of reasons, not all related to me or this weblog) and want to be able to work on things which take a bit longer to complete.
Allow me to wish you a peaceful, healthy, and fulfilling 2018, with lots of creative energy. I’ll post again in February, 2018!