#301

Yeah, they’re not intended to replace one another, which should be clear: Mutable has no problem replacing modules, and the fact that they’re still producing both is significant.

Lots of good interplay between them, and yes, you could abosolutely “sequence” Max X and Map Y with a number of preset voltage tools. And if you like the proceedural ethos of Grids, TiNRS Tuesday is a great companion - though I will say that I think the module similarly suffers from a “I’m not sure what to expect when I change this value even a microscopic amount”, and even more so, as musical notes track more dimensions that a simple “send a trigger/don’t send a trigger”. Still, a fun module to explore!

1 Like
#302

recently got a Marbles and loving it. Question: is the “scale carving” always mapped over five zones? It seems like the algorithm decides which notes to drop so that there are always five possible “subsets” of a given scale, regardless of how many intermediate scales I attempt to program (i.e. if a scale has pitch classes that appear 2x and 3x, it looks to me like the algo is constraining them to be removed from the available note pool together)

Just wondering whether anyone has been able to, for example, carve out a major scale from 7 to 1 available notes one pitch at a time. thanks!

#303

I’m having some issues calibrating my module – I’m broadly following these instructions https://mutable-instruments.net/modules/marbles/open_source/#dac-calibration (also looked over https://github.com/forestcaver/Marbles-panel/blob/master/marbles-calibration.pdf for more clarification). I’ve pulled https://github.com/pichenettes/mutable-dev-environment, i’m booting and running vagrant and make just fine, writing out to the .wav file, and playing it into the module and all seems well during that process. But then the module restarts when the .wav is done playing, and I can’t detect any changes in the X1/X2/X3 voltages now that I’ve changed the calibration values. I’ve even tried giving the calibration constants very very different values (still within the 10% threshold that FIX_OUTLIER enforces), and still no difference. Has anyone had any luck recalibrating their unit?

EDIT: hard-coding in marbles.cc worked, it’s just hard-coding in settings.cc that wasn’t working. Strange!

#304

The calibration data for the dac is written to a specific area of flash. You wont wite to that area from a wav fw upload (the module is set to a specific “raw” mode after the first boot after a fw erase and flash - checked for in settings.cc). This pevents you from trashing the calibration data when uploading via wav

1 Like
#305

Gotcha. I saw that “fresh baked” stuff in settings.cc and assumed it was something like that, but great to hear exactly what’s going on. I’m in a fine spot now (overriding in marbles.cc), but I would like to know: is there no way to change calibration data at all via a wav upload? You need to do a make -f marbles/makefile upload while connected to the programming lines?

Also just saw you’re likely the same forestcaver who wrote https://github.com/forestcaver/Marbles-panel so thanks so much for that repo, plus your advice here :pray:

1 Like
#306

You could update calibration data via wav (I’d have to double check) but it’d be a bit of a hack - you’d need to modify the code to write it, but then it should then be ok to then do wav updates from other sources without overwriting the calibration data.
(Obviously if it’s a fresh diy build you need to flash the fw and bootloader with a programmer)

1 Like
#307

I’ve also asked this in the MI forums, but I thought maybe someone here could provide some insight too.

I’m really struggling with the behaviour of Bias and Spread.

I’ve got Marbles going into an external quantiser. My quantiser is set to D dorian. Steps is set to 12 o’clock (just a slight nudge beyond 12) - unquantised mode. I’ve got Bias set fully anti-clock wise.

When spread is full anti-clockwise, I get the root D repeated with no other notes. This makes sense to me.

When I turn spread to 9 o’clock and leave bias at full anti-clockwise however, marbles seems to want to avoid the root note at all cost. Is this expected behaviour? From the manual i was expecting the root note to be favoured, but it just doesn’t seem to be the case. The only way I can get the root note to be favoured is to put spread at around 2 o’clock, but this means that the spread of the notes being played is much greater than I want in this particular use case.

The manual doesn’t actually show the various permutations of spread when bias is fully anti-clockwise, but the implication is that the root note is favoured (and this would seem to make sense musically).

I’ve also tested it with Marble’s in built quantiser on C major, with Dejavu set fully anti-clockwise and it seems to never play C.

What’s going on? Am I missing something really obvious?

Edit: If anyone is interest pichanettes has responded on the MI forums. Turns out my assumptions about the probability distribution were faulty.