grid controlled 8x8 switched matrix mixer

[staysh]

Its built…

Original Post

@24Franks suggested we post this in the forum to 1) get some feedback and 2) check for overlap with other projects that could speed this up. tldr warning.

Our intention is to have a grids control a switch matrix (any signal: audio, cv, gate, trig, etc) that could be daisy chained 8x8 i/o modules controlled via i2c. (Ansible? Teletype? or Other?)

Why 8 x 8? (and not 8 x 16)
It seems more beneficial to use half the space on the grids for ui (saved routings, paging between different 8 x 8 blocks, sequencing?, etc…)

i2c
with the trend of sending i2c via differential signal it appears this can travel over some distance now without too much interference. even the cheapest mcus have i2c support.

current landscape
we are aware of the SSSR 8x16 which seems like a relatively easy integration (read on another forum this was intended from the outset) but the i/o is not buffered and to my knowledge while it is fairly comprehensive (12vpp) it is not totally “safe” for more, shall we say, impromptu, patching (a voltage outside the range could damage the switch ic).

some options
option 1 (arm based)
we originally thought just run everything through an mcu running at audio rate and while this is definitely being experimented with it poses certain drawbacks:
1. likely an ARM based MCU with 32 bit FPU support which aren’t really widely available at the moment… (unless you know of a place?)
2. inclusion of 2 relatively expensive (and also possibly hard to find) DAC/ADC ICs

The benefit as we see it to using this approach you could use some fast compression algorithms and handle the problem of summing voltages. To me this seems really comprehensive and interesting but is this necessary though? perhaps someone with more EE knowledge could fill in…

option 2 crosspoint ic + atmega168/368
there is an 8x8 version of the ic in the SSSR switch matrix. one could potentially just add buffered i/o to safely scale input and output to always within the range the ic can accept. the ic can be controlled via a cheap atmega (like the sssr) which can also receive instructions via i2c.

the drawbacks here are that, to my knowledge, if at any moment two signals summed adds up to > +/-12 its possibly not good for gear… (am I conceiving this correctly? or is this a non-issue?)

the obvious perks here are the price and availability of the ics. ~ $25 for the ics ( < $10 if you ditch the buffers and basically just make an 8 x 8 ssri clone with the grids as the interface )

questions

1. are there any current undertakings happening here?
2. is there someone with more of an ee background that could clear up the necessity/triviality of “compression” on the summed signals for euro?
3. for those that think this would be cool… is it worth being a bit more careful (pre-scaling voltages using other modules) for the benefit of it being cheaper and done sooner?

we’ve started some minor prototyping and should have some demo pcbs done soon for both versions. in lieu of having an ansible/teletype at the moment we’ll probably be using a teensy 4.1 to connect the grids to euroland/i2c (pcb also available soon)

[andrew]

wow, I don’t have any skills to contribute but this sounds super cool !

@staysh

for those that think this would be cool… is it worth being a bit more careful (pre-scaling voltages using other modules) for the benefit of it being cheaper and done sooner?

yea, personally I would be happy to both wait & pay more for less possibility of blowing up my other modules. I assume with the ARM-based approach you have the option of adding an “audio mode” or something with crossfades/envelopes (?)

& fingers crossed for small-ish hp size if it’s possible

[Dewb]

Great idea! I have thought about another take on the Matrixarchate for a while, because while the matrix ICs it uses are designed for video and should pass high-bandwidth signals cleanly, the Matrixarchate unfortunately doesn’t. It’s not 100% clear why it fails, probably something in the board design since the signal path is passive.

Using a teensy+grid to implement the UI would simplify the hardware quite a bit. You have to use a MCU to drive the matrix ICs anyway, so this doesn’t add much complexity (USB does comes with a whole pallet of cans of worms, but the teensy USB host mode seems pretty good.)

Going from passive to active and adding DAC/ADC definitely opens up a ton of options but that starts to seem like a whole new module, one that would be wasted just on matrix routing, but I guess that’s the point: be a one-stop preset modulation system? Much easier to do one thing well that all the things. But I understand the impulse!

[staysh]

@andrew

I assume with the ARM-based approach you have the option of adding an “audio mode” or something with crossfades/envelopes (?)

Oooh okay, that is a really fun idea. Yes it seems like you’re only limited by the imagination and the “MIPS” of the mcu. This adds a whole new dimension when thinking about how to use the other half of the grids…

@andrew

yea, personally I would be happy to both wait & pay more for less possibility of blowing up my other modules.

Same. I’m really trying to make something that is forgiving to wild improvisation and safe to all the gear attached… which is kinda leading us to build for this. apparently just buffering an analog crosspoint switch would go pretty far if you a) aren’t combining hella signals and b) run everything into attenuation first… but to us the whole point is to be combining 8 lfos and not be cluttering up racks with tons of utility modules…

@andrew

& fingers crossed for small-ish hp size if it’s possible

Definitely. Kinda our m.o. in general. I personally set a constraint of two 84hp rows that fit in a suitcase for live use and am not trying to lug gear around…

So, also, after digging a bit more, the chip shortage is most definitely a real thing and unless someone can let me in on some secret you just can’t get a hand solder-able arm chip for the foreseeable future… so we have that as an initial hurdle.

We were tossing ideas around yesterday and think that a “lo-fi” version is possible to run based off a teensy (3.5/6 or 4.0/1). They are dsp capable (fpu) and as someone in another thread posted can host the monome with a bit of library tweaking. In order to reduce parts we can use the built in adc which will exclude the 4.0/1 probably due to having only 10 bit usuable coversion. The 3.5/6 can get up to 13 which should fall somewhere between an 80s sample/drum machine and a CD.

We plan on copying the ornament and crime schematic for DAC (“16 bit” but likely closer to the 13 of the input) and buffers (and well pretty much everything) because of it’s similarity and the 3.3v bus (iirc most all mutable modules are 5v).

So basically something very similar to an o_C but with 8 cv audio ins, 8 cv audio outs, a usb port in the middle to hook up a grids and maybe exposed i2c on the back for later expansion.

Being a teensy you could obviously create other firmware or uses as this seems pretty open ended, and as of right now all the necessary parts for this are obtainable (though not totally cheap ~ $100).

We’re starting on the pcb and can post it here as soon as it’s done as well as a bom.

@jroo here comes some more beta testers for your library!

[jroo]

Hey, great, let me know how it works out. @Dewb’s already had some influence on it and I’m curious to see how useful/simple it is to use for others. I was driving a Disting EX looper via i2c and a grid the other day using the library. It’s a thin wrapper on top of the monome serial protocol so any UI on the grid you’ll need to build yourself.

[andrew]

@staysh

In order to reduce parts we can use the built in adc which will exclude the 4.0/1 probably due to having only 10 bit usuable coversion. The 3.5/6 can get up to 13 which should fall somewhere between an 80s sample/drum machine and a CD.

oh man… I’d be a really big fan of the sound quality limitation, haha. if half the use case is CV anyway I don’t think it’s all that much of downside, especially if it improves price/availability (even post-shortages). this sounds like a really cool recipe for another community platform

more spit-balling from me, a ball of spit:

• if all the teensy I/O hasn’t been taken already an extra front panel CV jack might be cool for stuff like addressing / stepping through presets (like a crazy sequential switch)
• now I kinda wanna code a grid-interface version of let’s splosh for this thing I really love the idea of an OSS platform conceived around routing

[staysh]

what if you could route any of the channels (or composite of channels) into internal parameters?

there’s likely room for more inputs tho…

@andrew

oh man… I’d be a really big fan of the sound quality limitation, haha. if half the use case is CV anyway I don’t think it’s all that much of downside, especially if it improves price/availability (even post-shortages). this sounds like a really cool recipe for another community platform

Due to not being able to even locate a 8 channel 24 bit DAC… I decided to keep with the 13 trend and found a more or less inexhaustible supply of 14 bit DACs that loose 1 bit to noise… so 13 in 13 out… seems like an omen and a fun “sound character” to explore.

@andrew

I really love the idea of an OSS platform conceived around routing

Well here we go i guess…

[kbra]

Sounds like a really fun idea! Some completely random technical thoughts, sorry for the TL;DR:

Teensy or other proto / eval board seems to be the easily available way to go at this point. Even then, I think 4.0 and 4.1 are more readily available, 3.6 is out of stock from PJRC until summer because of chipageddon, and they recommend 4.0 or 4.1 for new designs. If you have one or more 3.6s around or in stock in the nearby store, that won’t matter for prototyping though

The thing I’d prepare to spend most sweat and tears on would be getting something up that runs at sufficient sample rate and bit depth for relatively neutral audio (not necessarily even full “CD quality”), and also has enough DC accuracy to actually work for CV crosspoint routing and/or summing. That is not a trivial issue, as you’re usually looking at actual audio codecs like the one in Norns for higher fidelity, higher performance audio, and precision DC codecs such as the one in O_C for CV signals. There will be tradeoffs regarding both how efficient they’ll be to use / read for the purpose, and how well they will actually handle AC or DC signals. It may be there isn’t a part that’s really good for both, at least without additional trade-offs.

The “lo-fi” version sounds fun though, and it sidesteps most of those potential design issues by the simple decision that the audio side doesn’t need to be high fidelity at all

Getting the audio side to work decently even as somewhat lo-fi version with 8 channels in and 8 channels out may still require some trial and experimentation depending on which MCU board and which ADC/DAC you choose. Eg. I think in Teensy 3.6 what you get internally is two ADCs that are theoretically 16 bit, in practise at most 12-13 bit without trickery, that are simply multiplexed to a lot of pins on the board. So probably good for 2 channel audio rate signals when used directly (you can use DMA and double buffering), or reading 8 channels of “control rate” signals with a slower method when using the internal multiplexing and some averaging added in - but maybe a stretch for 8 channel (even lo-fi) audio? Possibly worth looking into SPI ADCs as well?

Eg. the O_C design runs at around 1KHz (effective) on the AD side, and 16KHz out, so it isn’t something you’d actually use for routing audio thru as is. I suppose they had good resource constraint related reasons for not running the system at a higher rate - MCU speed on the older Teensy 3.1/3.2 and having to handle all the timer interrupts / not being able to use DMA for everything might limit things, the internal ADCs are apparently kind of noisy so you might need some averaging, and I think they’re running both the display and DAC in same SPI bus (?) which may complicate things (and which you won’t have to worry about if you don’t need a display). Then again, the vastly speedier 3.6/4.0/4.1 may help with this somewhat as well.

Finally, of course, you’ll have to figure out a good calibration scheme so that the device can pass and sum DC accurately, even with the required offset and attenuation before the ADC + amplification and offset after the DAC, but for that you won’t have to reinvent the wheel - eg. O_C has a nice simple method for that already.

(FWIW I don’t know if it would be worth going anywhere over 16-bit with AD/DA anyway - it may be a good idea for accurate DC calibration because you get more “steps” to do away with the nonlinearities - but you can always use a decently linear 14-bit DAC and have a calibration procedure for that. And unless you are / have a very good electronics designer or a lot of time to iterate, you’re likely to be limited to max. 12-13 bits of actual information anyway.)

[staysh]

Love the TLDR!

@kbra

The thing I’d prepare to spend most sweat and tears on would be getting something up that runs at sufficient sample rate and bit depth for relatively neutral audio (not necessarily even full “CD quality”), and also has enough DC accuracy to actually work for CV crosspoint routing and/or summing. That is not a trivial issue, as you’re usually looking at actual audio codecs like the one in Norns for higher fidelity, higher performance audio, and precision DC codecs such as the one in O_C for CV signals. There will be tradeoffs regarding both how efficient they’ll be to use / read for the purpose, and how well they will actually handle AC or DC signals. It may be there isn’t a part that’s really good for both, at least without additional trade-offs.

@kbra

Possibly worth looking into SPI ADCs as well?

I’ve been drowning in datasheets coming to a conclusion in these whereabouts. I did not realize that about the internal ADCs but now that line in the spec table makes more sense. I did find a 14 bit ADC (SPI) that suitable for bipolar signals. It’s old and unfashionable and pretty readily available and unfortunately I could not find an open-source driver for it so that will definitely be on the to-do list. It’s a TLC3578 and if anyone knows I’m barking up the wrong tree please share.

On the DAC side there is more or less an 8 ch version of the one in o_C and have 12/14/16 bit versions that are pin compatible… so there’s a “hot rod” mod option maybe.

@kbra

and I think they’re running both the display and DAC in same SPI bus (?) which may complicate things (and which you won’t have to worry about if you don’t need a display). Then again, the vastly speedier 3.6/4.0/4.1 may help with this somewhat as well.

Ya last I heard a major limitation on the rate was sharing the bus with the OLED.

3.2 didn’t have an FPU either, so we’re saving time on DSP instructions already.

@kbra

Teensy or other proto / eval board seems to be the easily available way to go at this point. Even then, I think 4.0 and 4.1 are more readily available, 3.6 is out of stock from PJRC until summer because of chipageddon, and they recommend 4.0 or 4.1 for new designs. If you have one or more 3.6s around or in stock in the nearby store, that won’t matter for prototyping though

Yes, was shooting for 3.6 for the M4F and 13 bit ADC then realized it’s sold out. I think the 4.1 would be the way to go for the 6Mb extra room for software and the added convenience of not having to pogo pin the usb host.

@kbra

(FWIW I don’t know if it would be worth going anywhere over 16-bit with AD/DA anyway - it may be a good idea for accurate DC calibration because you get more “steps” to do away with the nonlinearities - but you can always use a decently linear 14-bit DAC and have a calibration procedure for that. And unless you are / have a very good electronics designer or a lot of time to iterate, you’re likely to be limited to max. 12-13 bits of actual information anyway.)

Totally. The more I dug into going “hi-fi” the more lost I got. I am not an engineer. I can use kicad and look for red flags in data sheets and maybe actually test a circuit (currently reading more books on this). I’m more adept with CS than EE.

With the parts as I have them now:
DAC8168 (14 bit DAC)
TLC3578 (14bit ADC bipolar -10/+10V in)
Teensy 4.1

…These should allow for oversampling and averaging unless 200kSps is supposed to be divided by 8 then idk… and running at audio rate but I guess we’ll see…

@kbra

additional trade-offs

Design is so fun

But thanks for the informative reality check! Keep em coming if you can!

[staysh]

hey @kbra or anyone with an opinion… why not accept 20vpp on the input, say -10v to 10v without saturating the buffers? I know the, “10vpp” rule, but… why?

It seems at every range you are loosing out on some other aspect…
-5 to 5 you get audio, anywhere from -5 to 10 cv seems to slide around in and envelopes apparently go 0 to 8…

I would love to create a more agnostic circuit. But it must be a naive idea because I don’t see any in practice (at least in modules that share their schematics). What’s the downfall here?

If I just said “whatever doepfer…” and set the i/o at -10v to 10v what’s the worst that could happen?

[kbra]

I guess the obvious tradeoff is that of resolution (and noise).

Eg. if you think purely mechanically with an example of pitch CV, you’ll have less DAC values / steps for covering a semitone or an octave if you have to sample and output values in ±10V range, than in ±5V.

Or, thinking the other way if that’s easier, if you want to output a ±5V signal, and you’ve set up the output gain and offset so that the maximum swing is ±10V, you’ll have much less precision / bit depth to work with in half of the possible range, than if you had the output gain set for roughly ±5V output and could use full range of the DAC for that.

So that’s kind of the point where you’ll have to figure out whether the ADC/DAC are high resolution enough and the whole system noiseless enough, that you can actually sample and output the whole range cleanly and linearly - eg. if you use ±10V, can you still accurately output 1/12V changes over the whole range? And, vice versa, if you think you are mainly going to want to handle voltages in certain range, it pays to sort of optimize the offsets and gains for that range so you’ll have less worries in ADC/DAC accuracy and calibration.

I suppose it’s worth experimenting with if you’re patient (and can find suitable parts for the task), as it’s certainly nicer if the input and output aren’t limited by some “arbitrary” range due to technical reasons. However, it’s also possible that at some point you realize that for eg. accurate V/oct summing and generation, you’ll want to limit the ranges to some degree anyway. Or maybe not

[staysh]

Okay, this issue is clearing up for me.

The way I’ve always conceived of this working was that if I took a -5/5 LFO and routed it to an output that output would be a -5/5 LFO, as well as a 8V envelope, just being the same 8V envelope.

The intention of mixing in software was to allow for the summing of many signals by applying some creative software compression and not have to worry so much about attenuation. Put another way the collage being more important than the precision at some level.

So, I think I’m going to be naive and try to make this work at 20vpp -10V to +10V on the input and output and try to be as agnostic and “unshaping” as possible to the incoming voltages.

Since it will have much software in the middle I imagine it would be possible to develop a quantizing “magnet mode” to only output volts in 1/12th volt after calibration for those concerned with pitch. With 10 bits across 20vpp you effectively have only 4 DAC codes per semitone, by 13 bits you have approx 32 DAC codes per semitone… How that plays out when you want continuous signals I guess we’ll see…

On the hardware side I would like to report that I finally figured out how to calculate all these buffer circuits! And bad news being the 200k samples a second IS only for one channel one sample in all these ADCs… In an effort to get a Nyquist frequency somewhere near 15k I’m still on the hunt for a good ADC. My standards are the thousands or 10s of thousands are available… but perhaps there will be so few of us building these that settling on a chip with only dozens or hundreds left will be passable?

[staysh]

Had a semi-revelation regarding this project. Feel free to chime in…

I was thinking about using this in practice and realized that audio isn’t the fun thing here. Or perhaps its convenient but it doesn’t interact with other signals the way CV does. It would mostly be for creating badly mixed busses with basically options to mute tracks…

With cv you can apply all different types of algorithms and get interesting results… perhaps something to keep in mind for the interface…

All the parts to get this to run at audio rate are not cheap (dac/adc aren’t cheap in general) and the tight scheduling required in the drivers might be more headaches than it’s worth.

So, as the few of you on this thread have alluded to, it seems like the focus will be on cv. With plenty of room for all kinds of grids magic.

With that in mind I can wander safely out of 10vpp to 13vpp (note the 13) and catch -5 to +8 so the bottom end of lfos and the top of envelopes. Doesn’t seem to be too risky…

Oddly enough I thought “what the heck” let’s see if there are any 13 bit ADCs… lo and behold… There is a rather incorrectly labeled ADC that fits the bill… Its 4 differential or 8 single ended and it’s filed under 4 channel, so my searches never brought it up. It’s 1/4 of the price of all the other ADC candidates at around $5 and a similar line to lower res ones in arduino land, so maybe even some luck on quickly adapting a driver…

Just to make sure 13 bits would be sufficient… I ditched the last two LSBs and calculated the steps per semitone and guess what it came out to… 13! Kinda freaky…

The DAC is pin compatible with its own 12, 14 and 16 bit versions and also it’s an 8 ch version of the one in o+C far as I can tell from the datasheets, so again… possibly some luck here porting some code to get a proof of concept up and running with low overhead.

…because all this spec-ing is madness and I just want to jam…

Finally getting back to the PCB

[staysh]

Rough draft of the schematic here:

staysh/schematics/blob/main/grids_matrix.pdf

Anyone who is confident enough to suggest improvements and considerations to any part (particularly the psu) please do!

It’s peppered with comments where I’m kinda scratching my head about the right thing to do.

[staysh]

I got a little jaded on DSP and decided to make an off the cuff analog version. This way audio is “in the mix” from the get go, also getting more into feedback just like everyone else here so there will be no scanning to break through and hopefully it will get wild.

It borrows from a lot of CGS/Serge designs, kinda like a Hinton SwitchMix (a post he made on another forum gave me some clues) so kind of a combo of a UNI33 and an Analog Switch Matrix.

8 attenuverters, can me tuned for CV or audio depending on the build.

Clock in for sequencing saved settings. CV in for ??? probably voltage addressed settings?

Option to normal all 8 channels to a small precision voltage coming from a DAC for CV pitch addition/sequencing/programming. Though due to the nature of analog switches precision will take some effort on the user, if it is at all possible.

Gonna get started on the software. One half of the grid will control the 8x8 matrix the other will probably facilitate switching pages, column mutes, precision normal control, and some other stuff I can’t remember right now.

Best,

[staysh]

Built!

[staysh]

After a long hardware debugging journey, and the most abstract soldering techniques I’ve ever tried… I got to fire it up today in a functional state…

Pretty boneheaded example: one dual oscillator with sin and tri and a noise source patched back into each exp fm. So an analog feedback algorithm programmer or something…

just that osc and a looping envelope… perhaps I was too eager lol

spud first spin

[staysh]

okay one more… forgive the spam!

basic dual vco + noise
6 waveforms + 2 noise signals
2 outputs to fm, 2 through a vca to the mixer

cv selectable pattern
+
clocked step through pattern memory

This one is the lower impedance audio version, but I’m going to see how it takes to cv before building the “100k” version.

there is a dac normalled to input 1, and all subsequent inputs so this can be an 8 channel programmer (possibly 1 v/oct sequencer) too… more examples to come.

spud sequencing

[staysh]

Some good and bad news regarding this project, if anyone is following along…

The good news
Having built the CV version I can gladly say it adds very precisely even with up to 8 inputs being summed. Here is a video demonstrating some additions without quantization. It’s quite difficult to compose that way, or rather, making sure a + b (or a + b + … + h) is still in the scale is not an easy mental task for me, hence the pretty limited demo. However, on most channels (and this does vary due to the ic) the error doesn’t exceed 1% with all 8 inputs being summed.

spud precision adding

The “bad news” …
It’s not quite as open ended as I originally thought. Mainly, you can’t accurately mult signals to multiple outputs. Many to one: easy. One to many: not without caveats. This is a limitation of the circuit and I’m not aware of any workarounds without a total redesign. Basically, to use CMOS style switches with euro signals, you have to keep the switch in the amplifiers feedback loop (virtual ground) to avoid going outside of the limited range and damaging the ic. And thus, until I find out otherwise, this means that when you send one input to multiple outputs you are shorting the output amplifiers inputs together, creating some mysterious effects.

Combined with other attributes of this circuit, at audio rates this can create some interesting wave shaping possibilites…

spud wavefolding

The audible clips and pops in the beginning are due to the fact that this configuration results in 3x gain by my observation, so with the pots turned all the way CW/CCW there can be a significant change… kept around a gain of 1 (approx 3 o’clock) you don’t hear nearly as much of that.

So…
I’m inclined to leave this one as is. I’m working on the software and having a “safe mode” active by default that will only allow one output per input. This can easily be turned off. Again this cybernetic chaos doesn’t harm anything except your plans… Here’s a pitch sequence exploiting the wild effects, sent to two outputs and quantized.

[staysh]

I took some time to create slightly more produced videos that demonstrate more clearly some of the possibilities of this device. It really opens up small setups.

spud: rhizome explorer I

spud: rhizome explorer II

The wave folding mentioned above turns out to be a non issue, I was using a control board from my lower impedance build which created some funky gain ratios and merely forgot the R values were different. That’s all sorted after ordering some more pots. Gain of -1 to 1 which makes setting up a precision adder easy.

To be honest, I was hoping to manufacture a small number of these, perhaps little batches of 10. So I made these videos gearing up for that. I prototyped this on the teensy 3.6 which is overkill but it wouldn’t be limiting to try out various things (sampling 8 channels for the i2c bus, for instance). The 3.6 aren’t discontinued but have no restock estimate. To find a mcu with usb host supported on the chip, as well as sufficient ram, a DAC, etc etc… that is 1) available and 2) not buried in some annoying proprietary tool chain is way more non-trivial than my initial assessment. After finding one, it still has to port over to that platform… So, I’ve got a bit of work to do. Please share recs if you have them, open to mcus or even strapping another dev board on here.

In the meantime, if anyone is interested in this and has a teensy 3.6 lying around (very out of stock) I’d be happy to mail out PCBs/BOMs/Panels for this prototype version.