Not sure if the author is around here or not but I might have something interesting for them in the next few weeks: an ESP32 implementation of AppleMIDI/rtp-midi for sending and receiving MIDI over Ethernet. I’ve put a reminder in my calendar to reach out once I’m ready to release it.
You're aware that there are already a couple of these, right? First one that pops up in a platformio search:
% pio pkg search rtpmidi
Found 1 packages (page 1 of 1)
lathoub/AppleMIDI
Library • 3.3.0 • Published on Sat Aug 27 11:57:15 2022
AppleMIDI (aka rtpMIDI) MIDI I/Os for Arduino. AppleMIDI (aka rtpMIDI) is a protocol to transport MIDI messages within RTP (Real-time Protocol) packets over Ethernet and WiFi networks. This major rewrite is faster, more stable and uses less memory. Read the Wiki page when migrating
.. is pretty stable and fast. I've used it in an ESP8266 project ..
Of course, the existence of some implementation is no reason not to write or share another one.
In fact, it's good for the ecosystem to have different people/teams exploring the problem space and it's good for individual developers to hone their craft on delicate technical problems even when they're ostensibly already covered.
Yes, I’m specifically targeting Zephyr. It’s actually less of an ESP32 thing and more of a Zephyr thing, I just happened to have an ESP32 LyraT Mini kicking around to do the project with.
And in general the Arduino/Platformio ecosystem causes me to break out into hives…
- Reproducibility: often enough I'll come across a straightforward issue like "using an extra serial port" that already has the pins broken out on the board but isn't set as a serial port by default. The solution is almost inevitably "go into this directory deep inside your Arduino install and edit this header file". That results in two issues:
- It's not project-specific so other projects on my machine now also get the modified header
- If someone else checks out my project, they have to go in and edit that file themselves, spreading the modification like a virus.
- The abstractions are often overly simplistic and hide what's going on under the hood too much. I don't remember which board/chip it was off the top of my head but one board I was working on was having weird timing issues. As it turned out, the whole BSP for Arduino-on-that-board was running FreeRTOS under the hood and was context switching out of my loop() function arbitrarily (causing the delay between, say, two digitalWrite() statements to be dramatically different sometimes)
- The code quality of 3rd-party libraries that are commonly used varies dramatically.
I ultimately settled on Zephyr. It does a fantastic job of doing hardware abstraction and configuration behind a DeviceTree setup, it exposes really nice and consistent RTOS primatives, it has a ton of device driver support baked-in and has generally quite good code quality for all of them. I can do multiple stack-allocated threads with priority instead of having to do ugly polling hacks in a single superloop.
> I can do multiple stack-allocated threads with priority instead of having to do ugly polling hacks in a single superloop.
I think most of your issues are because you haven't escaped the impositions of the Arduino runtime/execution environment, and are sitting on top of a layer of stuff that was designed for students.
The real value of platformio is when you move beyond this, accept responsibility for your executive runtime, and have full control over things. Its not enough to run into the brick wall of the init()/loop() abstraction and then complain that stuff is too simplistic - that is the point, after all, of the Arduino ecosystem. But platformio sits separately from this, and if you do take care to administer your runtime properly - i.e. bypass the Arduino student layer - you can solve pretty much every problem you've noted, better.
>Zephyr
Definitely interesting, but I don't like the idea of a DeviceTree blob, personally. This isn't future proof. But I guess everyone has different requirements for this, going forward. I've taken 5 projects, originally based on Arduino/Platformio, through 3 different hardware design iterations, and the sue of platformio tooling and methodology was definitely a key factor in the ease with which we did that.
Not sure if you meant the wood side panels are an intentional reference to the Deluge, but if so you may want to know that wood side panels are a common design touch for desktop synths, hearkening back to some of the first compact consumer synths (like the Roland SH-1000), which also had wood side panels.
For a similar device (with a different UI) check out the Woovebox. I love mine as a portable groovebox and I'm experimenting with having it be the brain of my dawless setup.
This is very cool. I'm very interested in using ESP32 for MIDI/Audio/Synth projects, I have one of my own on the go: https://doug.lon.dev/fourays ;)
I hope to get confident in doing PCB layouts in KiCAD and manufacturing my own synth modules on a budget. I'm currently a bit stuck on how to get the front panels designed and manufactured, and coupling that with the correct "UI" hardware (pots, buttons, sockets) in order to make the thing assemble correctly.
That's good advice; I had thought of doing this, and it requires a little bit of project refactoring, but you are correct that I do seem to already have the tools. Adding a few more unpopulated PCBs to the order would be pretty cheap as well, I guess around $1 per panel.
PCM5102A has 32 bits, why is it still synthesized by lofi? If you only need lofi, can you consider an esp32 dac? edit, it looks like sr is a bottleneck...
Just got a PO-33 and very psyched with it, though I've had some thoughts about whether you couldn't leverage the LCD a bit better to shift it from semi-serious to fully serious. E.g. right now in the sequencer it's impossible to know which specific instrument is playing. Anyway, it would have been really cool to have the OS be open and flashable and spend a little bit of time to make little papercuts like that better. I was looking into how hard it would be to put something like csound in a tiny board and make my own, but when I look at how minimal that single header file synth is, I'm left wondering if that's too much.
I don't know about CSound, but Faust works well on microcontrollers, in fact that's one of its main use cases. Note that Faust focuses more on DSP, synthesis and effects, not so much on sequencing and higher-level music organization. I've found combining Faust (for low level) with any general-purpose language (for high level) works well for a lot of things.
Theres some in-depth breakdowns for the PO 12,14,16 here(http://hackingthepo.weebly.com/) if you're interested!
I have no idea about the po33 and if the juice is worth the squeeze, but they're cheap enough to tear apart so go for it.
Very neat, thanks - probably this is just enough beyond my abilities that it'd probably be me bricking my PO rather than accomplishing anything useful :-)
The screen is the least of the differences. Looks cool, but not as closely related as you'd think. The PO33 is much more of a toy with all the good and bad that comes with that. I can hand it to my 8 year old and she can enjoy it, but it also makes a great sidekick on a commute or in a waiting room.
Look Mum No Computer[1] is the most creative and inspirational guy in this space IMO and he goes through much of his projects in further detail on his site.
