Imagining basically a mixer circuit where outputs of amps can be routed back to inputs to create feedback. Possibly multiple. Include a mcu with ADC to detect levels at certain points, then control the feedback via digital pots with the mcu. With detecting level + ability to control feedback, I'm imagining a sustained tone could be created that would be kind of dynamic. Depends a lot on how the amp circuits are made. Would probably include some filtering in the analog realm too. DAC possibly as well, to do some DSP. But the main focus would be controlling feedback by detecting levels and dynamically adjusting gain. Could have an input too.

Pots and buttons could be a good place to start. They're really simple (almost too simple. lol), but it would be a place to start coming up with some standards maybe.

WaveShare has code examples for their displays, including a C one for Pico. Its documentation is a little confusing, because China. But the code is pretty self explanatory. The weirdest thing with either of those drivers is all the register writes to cryptic things that are required for starting it up. You can dig in the datasheet to see what they do and how they could be changed, but just using/repeating what they do in the examples for initialization, works good.

The demo code is linked at the bottom of the wiki page for the WaveShare 1.28" circular display.

Yeah I think the large size of the dome will actually make it easier to engineer something to hold it.

Yeah, any USB Audio Class compliant device will work in VCV rack. That's sort of why I think this idea is viable. I haven't yet actually tried audio over USB with the TinyUSB stack, but it's an option and it should just work. Like, I don't know if any component-level hardware beyond what's on a Pico would be needed for this project. If so, it's pretty minimal, I think.

Just adding Simon's "prototype".

Just a simple way to get CV in and output of a computer. Essentially a USB audio interface, but without stupid DC coupling like 99% of typical audio interfaces have.

There are modules already on the market that do this (Expert Sleepers ES-8, for example), but they're all stupid expensive for what they do, imo. There is a module that is like $100 for USB MIDI-to-CV/Gate (2 CV and 2 gate), but most stuff is like $200+ or $300+. I feel like there is a niche for a less-than-$100 thing that does something useful in the realm of CV in and out via USB. So hitting sub-$100 is one project idea:

• Audio quality targeting CV purposes only. Sample rate of 48k is max and it could maybe be slower if that's cheaper for any reason. Bit depth of 8bits might be fine. 16-bits might be more than necessary. Stuff that is needed for recording actual nice audio (oversampling, sigma-delta, etc) is not needed. Simple ADC.
• The max amount of analog I/O possible while staying under $100. If that's 1 CV in and 1 CV out, then so be it. But I bet it could be more.
• No serial MIDI jacks if it costs too much
• No display, no buttons, no pots, no encoders, and maybe even no LEDs. lol

If we could figure out how to be competitive with price, it might be fun to later do a more full-featured thing that has serial MIDI jacks is good enough for recording audio (i.e. using a codec).

I just know I've done a little experimenting with just slamming dc audio signal into a simple ADC, and it doesn't sound as good as what I expected. I suspect the causes were accuracy of the timing, effective dynamic range (i.e. not matching the input level properly with what the ADC expects and there possibly being some bias), and just accuracy of the actual reads. Normal audio devices that use ADC will employ oversampling, sigma/delta, and other stuff to address all that. If you've used some kind of ADC shield with something like a pico before, and it sounded normal, it was because of stuff like that. This is something we're starting to get into with the codec on Round 2: It's got a lot more going on that simple ADC/DAC.

I think a kind of crappy DAC is a little more usable because, if there is no audio coming in, there is nothing to recreate, so the dirtiness of the DAC is just part of the nature of the sound rather than an immediately obvious lack of fidelity (ahem, Round Robin 1. lol).

We do need to find a solution for decent audio ADC and DAC just in general for many projects (Round 2 and beyond). So it is something we have to do anyway. I only bring it up kind of negatively up in this specific context because it's a potential (somewhat likely, I think) complexity that might delay the lua part of this project. Unless this project was ok doing like an intentionally low-fi effects pedal. which, honestly could be pretty cool.

I guess the assumed complexity there is that we haven't yet done anything with an ADC for actual audio. We've just done ADC for reading control values. If we set up an ADC for audio and it doesn't sound good, and we don't care about that, then the ADC would be pretty simple. There's a chance a simple ADC setup will just sound good. But if it doesn't, there is hardware and software experimenting involved in figuring out why and solving that.

I'm not saying we shouldn't do that. We definitely should. Just specifically in the context of the "minimum viable" part of this topic, that could potentially be a source being not-so-minimal.

It's also possible I'm still not completely apprehending the MVP thing. My approach is to only work on things that are planned for release and make mistakes over and over until I get it right. Which I understand is not a viable way to work for everyone. lol

I think your first idea is the best thing for a MVP, if the point is to reduce the non-lua-associated complexities. Having audio input adds about the same amount of complexity as the M2M, I think. I sort of thought M2M was pretty simple, but the overhead of USB device hosting and interpolating the various possible things a user could connect is a distraction from the lua part (in terms of learning). A simple synth engine would be pretty easy. We could do that with a pico and a breadboard. No other hardware needed. We could even do PWM for output.

Yeah, it would be cool to be able to look at a user script and be able to tell if it's going to use too much memory. But to start out with, I think just a simple log message of "You ran out of memory" would be good enough.

I'm not totally sure, but it seems like the way to customize how much memory Lua uses is all just about that one allocation function. I was about to say it doesn't even need to be in the repo you're making, but then I remembered it's called pico-lua, so I guess it would make sense to include a basic allocator. Like even if it's one that uses like 50% of the memory or something. Then we just document how to tweak it.

We haven't gotten to the point of this mattering yet, but it could potentially matter as we get something more substantial working. The default memory management for Lua is dynamic without any limit. For things where the user is inputting arbitrary Lua, this makes it pretty easy to muck up memory. We might want to consider a custom static allocation strategy so we can at least fail gracefully if the user puts something crazy in the device.

The process for doing that seems pretty straight forward. Just have to define a single function and pass it to the lua_newstate() call.

https://www.lua.org/manual/5.4/manual.html#lua_Alloc

There's also the concept for "wash" of spinning, and for "dry" of tumbling, thinking of the actual machines...

This is a tough one to stick with the analogy and remain in the realm of useful audio processing. Not that it's a bad idea. I love the metaphorical approach as an inspiration / challenge. There is the aesthetic/subjective interpretation of the adjectives and the technical one, which sometimes differ.

1. "wet", to me, means reverbation/delay. "clean", to me, means less "noise".

2. "dry", to me, means lacking in reverbation/delay. "crisp", to me, means boosted higher frequencies and maybe also attenuated lower frequencies.

3. "fold" does immediately make me think of wave folding, yeah. I guess if you thought of it as a way to prepare the sound to be "put away" or "stored", if could be lossless encoding too. haha. It could also be some concept of smaller pieces of the original sound (the loose concept of "folding time"), like some kind of creative delay that plays back little chunks of past input in some interesting way that isn't just a plain old delay.

Obviously, these stages kind of contradict themselves logically as a real time process, but that's ok. It's not like you'll get the exact same thing on the output if you set everything right (Unless we're elite DSP masters. lol). Would it necessarily be hardwired with one input and one output like > Wash > Dry > Fold >? Might be more flexibility in design it was like

> Wash >
> Dry >
> Fold >

Yeah yeah yeah