Penrose Erratic Quantization

n0rd

My Penrose build (Full kit with PCB v0.4) has an issue where it can't
seem to make up it's mind what value to quantize to and rapidly changes
between two (or sometimes more) values.

The module seems to work OK when the 'IN' voltage is less than approx
2.5 Volts. It quantizes fine and outputs a single gate on each change.

However, after approx 2.5 Volts or more, Penrose can't quite decide what
quantized value to output and quickly changes between selected notes
before finally locking to one value. Viewing the 'GATE' while this
occurs shows it jumping up and down rapidly a few times before finally
outputing a steady gate. (It's behavior looks similar to "switch bounce").

It seems the higher the 'IN' voltage the worse it gets and at times it
won't lock to a fixed quantized value at all.  I can even get Penrose in
this state using a steady DC voltage in (like from an Intellijel Triatt
or circuit Abbey Invy).

I have tried updating the firmware (v1.2) but the issue remains.

Any ideas on what and how to fix this issue?



Steve

n0rd

After some digging through this forum I found "another thread (click)" which seems to describe my issue.

Quote from that thread:
"anyone up for beta testing a bugfix update for the Penrose quantizer?
In the continuous mode the CV in was too sensitive, so with a CV exactly between 2 notes the quantizer could not decide on a note and rapidly toggles between 2 active steps.. It also could lead to slewed transitions between notes. I added a hysteresis to the CV input processing that should fix this"

As mentioned before, I have tried updating to v1.2 firmware but the issue remains.
Also, there doesn't seem to be any code revisions on Github so I can't see what was changed.

Steve

adnauseam

I've also noticed this. It isn't horrible and sometimes it just means you've gotta attenuate or offset the incoming signal a bit. I've always got my incoming cv coming from an attenuverting-offset mixer so not a problem for me but I see how it could be annoying.

The other solution is to just use the trigger input (which is sort of like a sample and hold) and it will never jump around like that.

Perhaps a better hysteresis is needed.

pld

I'd noticed some weirdness occasionally but was never sure if it was the source (Turing), Penrose, or whatever oscillator that was the issue.

Using Shades as a CV source into Penrose (only the IN patched) I got two LEDs red and the gate permanently on at ~3.8v. At about 4.1v I can get no LEDs red, but gate on? @n0rd seems right that it appears to gets worse at highter voltages, above 4-5v I can almost provoke it between any two notes. Unplugging and re-patching the CV and the state re-appears.

Caveat: my firmware is self-compiled but should be up-to-date from github.

If I find some time on the weekend I can poke around the source and see if there's anything obvious.

pld

Addendum: powering off and on again doesn't resolve the state. At least it's consistent

pld

So I've tweaked my version a bit and it seems to be a lot less sensitive to this issue.

I'll run the changes by Julian, but if anyone is feeling adventurous, drop me a line...

pld

While pondering during the morning traffic jam, I think my changes will avoid the jumpiness but can actually make the current note a bit too sticky for certain boundary cases. Which may or may not be wanted But all I can come up with are increasingly complex add-ons, so there's probably a more elegant approach hiding in plain sight...

n0rd

I've also been playing with the source code and managed to come up with a more stable quantization.

In "quantizer.c"

line 118 (github line number) change the variable lastInput type from uint8_t to uint16_t. Also, change the magic number 2 on line 128 to a 3.

So, original code on line 118 in "quantizer.c" is:

static uint8_t lastInput=0;

change to:

static uint16_t lastInput=0;

Original code on line 128 is:

if(abs(input-lastInput) >= 2)

change to:

if(abs(input-lastInput) >= 3)

Or leave as '2' and make "greater than" only like this:

if(abs(input-lastInput) > 2)

Changing lastInput type from uint8_t to uint16_t stops implicit cast in abs() function on line 128.
Modifying magic number just smooths detection of a new value to quantize a bit more.

Attached is a zipped .wav with the above changes.
Standard disclaimer: Try at your own risk.

Steve

pld

That's close to what I did, I used ADC_STEPS_PER_NOTE/2 as the magic number. Except I also only saved lastInput when an input value causes a new note to be quantized, but I think that might be too much. Changes are here, or there's a .wav with some other bits in my 'current' branch.