It’s called a quincunx. Pronounce it carefully is my advice, having once mispronounced it in a talk about regression to the mean.



You also could’ve called it “pachinko”. Might’ve been catchier(?), but Marbles better describes its function anyway.


Lockheed Martin has a skunk works, Mutable Instruments has a quincunx works.


See So come up to the lab / and see what's on the slab / I see you shiver with antici


So it pairs well with an o_C or two, it would seem.


Does anyone have any thoughts on a good way to record marbles output to “record” the pattern in order to feed it back for later recall? Obviously, the joy of Marbles is discovery, but as a tool, a way to deliberately reload it with pattern data to “restart” from a previous state would be useful!


It’s great when used with Piqued, with the CVs modulating the envelope’s release tails or other parameters. But that’s just one possible use.

If you have a CV recorder then you can do that, but – supposing you are talking about pitch data – a probably better strategy would be to prepare some scales and go from there. It seems a bit off to be able to record the output of a module that is intended to create randomness, chaos and ultimately unexpected things.


You need two Marbles :smiley:


Dual Marbles would be pretty wild. I find Marbles and Teletype work very well together though in many different ways :slight_smile:


I think dual marbles would be an incredible live performance setup. It would create some really beautiful generative stuff, end up making some super dense wall of sound style patches with a ton going on.


Saw AH has one in store on IG. Hope this means they landed in the US. Excited to see how people use it.


well, if Matthias made a alternative firmware for Marbles and called it Warbles, we’d come full circle wouldn’t we?



Apparently there are (unpopulated pads for) serial TX and RX headers on Plaits. Hopefully Marbles has the same, which leaves open the possibility of its firmware being modified, in due course, to permit it to transmit the note value data to some other module, which could store it, and maybe send it back later? Hmmm, sounds like more trouble than its worth. But, as someone pointed out, you could even bit-bang I2C protocol over that serial port, and thus it might be possible to get Plaits and Marbles etc to interoperate digitally with the whole Monome/Whimsical Raps ecosystem using their bus protocol which is layered on top of I2C, I believe.


A Teletype interface would be rad, but even imagining the interface sounds tricky! I will probably write some kind of recorder for Teletype and try feeding that pattern data back and see what mileage I get. It’s a first step anyway.

Now I just need that unit to get here! :smiley:


i2c control of mutable modules is something I looked into a little bit ago.

Based on talking with a few different people, this seems like the way to go. Some sort of translation device for converting the i2c messages to serial, and then updates to the mutable firmware to listen on those pins. One of the core teletype firmware devs mentioned something along these lines here:

It sounds like accessing i2c directly (like the way the er-301 does it), is not really possible with the MI modules, because the i2c bus is being used for other intensive things and having to listen for teletype commands would impact performance.

It’d be cool to be able to access “meta” parameters that aren’t controlled by CV through a teletype OP. Things like Rings’ modes, Plaits’ internal envelope generator’s length, etc.

If anyone is into this idea, I’m happy to help (beta-testing, interface ideas, etc.), but it definitely feels like a project that requires some pretty thorough knowledge of embedded system communication protocols, which I don’t have. Feel free to reach out!


I2C bus/protocol integration with the Monomverse sounds like a big project. However, it might be feasible to attach one of these to the serial port on Plaits (and hopefully Marbles etc): They don’t use much power, so it might be possible to parasitically power it from the 3.3V rail off the module to which it attaches. It uses 3.3V level logic, which is safe with the STM32 chips. Then configure the module firmware to read and write to it at a lowish baud rate (say 19200 baud), just enough to send and receive configuration data without too much overhead (assuming the TX and RX pins on the Plaits, Marbles etc are hardware USART pins). On the other end, you could use an RPi3b (with built-in Bluetooth), or a mobile phone of tablet app. That should then accomodate multiple Bluetooth channels, allowing multiple modules to be controlled by one controller.


mqtthiqs is an expert when it comes to parasites… :face_with_raised_eyebrow:

Edit: naturarerum already pointed that out…


Was listening to the DivKid video on Marbles while riding my bike, and was intrigued by this segment in which he notes that the gate lengths in the coin-toss mode vary:

You can see this in this screenshot (not taken while riding my bike):

The middle trace is the regular clock on t2, and the upper and lower traces are the heads and tails coin tosses gate outputs on t1 and t3.

Given that the module is not clairvoyant (if it is, then it’s wasted in eurorack, and should be taken to the nearest casino), presumably it is storing the results of a series of Bernoulli trials in a buffer, ahead of actually needing them, so that it can look-ahead to determine what the result of the next coin toss will be and output a longer gate if it is about to choose the other side? Or at least it is storing the stream of random numbers one-step ahead, enabling it to performing the next Bernoulli trial using the probability cut-off as it is at one clock tick before the result is concretised as a choice of t1 or t3? Thus the effect of adjusting or modulating the probability is lagged by one clock-tick (which probably makes little or no difference in practice)?

I’m asking because it’s a nice feature, and it started me pondering about how to implement it (and the Bernoulli trial behaviour in general) in the Temps utile module, probably with more than one coin, since there are six gate outputs.

Also, btw, it was a pleasure to hear repeated references to probability distributions by Ben DivKid. First time I’ve heard that in a module review. Here’s to Smirnov sampling! :clinking_glasses: