A) Set yourself a path

When I started working on the project I had a few strong idea to guide the developement:

• bring together all the great opportunities offered by the arduino/maker/IoT ecosystem in scope of creative applications
• make a project that does not need coding and is flexible => can be (re)configured through a graphical user interface
• keep the project as durable as possible and run open source code

B) Go all over the path

Being a rather technical person, I also had many other ideas and technical wishes which I was willing to try out. Way too many ! The first concept I worked on turned out to be way to complex. And while I knew this common engineer bias, it is sometime very difficult to find what is the essence of what you are trying to do. But I knew the first design would not be the one, still it got me an excellent experimenting platform to identify core features.

Hence the first concept was to make a generous I/O board packed with features. A bit like a sound card, which can connect with all kind of peripherals. The interface would allow to set input or output types, condition the signal, and propagate it between different kind of I/Os, like a virtual web patcher, but running on the chip.

The hardware had:

• 12 GPIO which could be configured as ADC, Touch, or connect to any I2C module
• Hardware midi port
• Ethernet with PoE
• DMX
• and more...

After couple of month of design and development time, I got a partially working demonstrator (of course missing a bunch of features), but enough to put it against real world use cases.

C) Make it real

I decided to develop this proof of concept with circuitpython on an esp32-s3. This allowed me to create a mock-up very quickly. I could setup a webserver with web-sockets pretty quickly, perform asynchronous tasks with asyncio, etc... I could find libraries for almost anything I needed, and the community is very responsive.
I was also rather surprised by how good the overall performance was. In my scope of a proof of concept, it saved me so much development time that I could definitely bear some of the drawback associated with circuitpython.
On the long run, I could also realize why some more experienced developers do not recommend it when things get more serious, and had myself to move away from it for the next iterations. The biggest struggle I faced in my case was the fact it is was evolving too quick. The newer releases causes the previous ones not to be truly finalized, but newer versions would then break some libraries compatibility. But I am definitely eager to see how this environment stabilizes over the years.

The interface was developed in vue.js. Not having much experience in web development back then I followed some friend recommendation. The practical component structure of vue.js and its accessibility made it a good choice. The resulting page was lightweight and had good performance on the esp.

And that's how you get yourself a working proof of concept which you can start testing in real life.

To be continued