Penrose Possibles (Open Source Sonic Potions Quantizer)

[pld]

Edit - there's a github here: https://github.com/patrickdowling/Penrose

Yep, that's the one, and there's a hysteresis branch.

IIRC (and it's hazy) I could reproduce the behaviour even around 1-3V using something like Shades on the input and nudging the pot, but there were definitely some sweet (sour?) spots where it was more prone to wobble.
And then I just hacked something together... so it's not impossible that there's a flaw in that cunning plan, since I'd kind of assume (yeah, yeah) that the ADC values aren't actually _that_ bad.
Reducing the range seems like another path.

[float32]

I've been overhauling the Penrose firmware in my free time lately, and just stumbled on this thread. I have a couple of things to add, I hope they're useful!

First, I have a couple of bugfix branches in my fork (the rest of my changes are not public yet) - https://github.com/float32/Penrose

The branch "fix-hysteresis-bug" should fix the rapid jumping between notes. It's possible that some alternation will still occur, but that might be fixed by increasing the hysteresis threshold.

Second thing, replacing the 8-bit DAC with a 12-bit one won't make any difference. The firmware calculates the value to write to the DAC as exactly 2 LSBs per semitone, and the user calibrates the output amplifier accordingly. So the output is already theoretically exact, ignoring nonlinearity in the DAC which can't be fixed solely by extra resolution anyway.

[pld]

Haha, I had this on the back burner so long I didn't really expect a resurgence.

First, I have a couple of bugfix branches in my fork (the rest of my changes are not public yet) - https://github.com/float32/Penrose

The branch "fix-hysteresis-bug" should fix the rapid jumping between notes. It's possible that some alternation will still occur, but that might be fixed by increasing the hysteresis threshold.

Yeah, I increased the threshold, and while I was less surgical I think included that fix as well.
The more interesting patch is perhaps "Fix bug causing the module to freeze" on the other branch, which might address the reported crashes (my theory was that it's ISR related but you have a better analysis). Add those two together and you might have a winner.

Second thing, replacing the 8-bit DAC with a 12-bit one won't make any difference. The firmware calculates the value to write to the DAC as exactly 2 LSBs per semitone, and the user calibrates the output amplifier accordingly. So the output is already theoretically exact, ignoring nonlinearity in the DAC which can't be fixed solely by extra resolution anyway.

I think the theory was that the 12-bit ones might have more consistent performance, because in practice it seems a bit hit & miss.
My hand-waving plan was to have a calibration "UI" and use the lower 4 bits for adjustment, which would be ignored by the 8-bit versions.

[float32]

I think the theory was that the 12-bit ones might have more consistent performance, because in practice it seems a bit hit & miss.

Maybe. There certainly will be INL variation between units, but the datasheet suggests that all three versions have the same relative INL.
http://ww1.microchip.com/downloads/en/d ... 22244b.pdf

My hand-waving plan was to have a calibration "UI" and use the lower 4 bits for adjustment, which would be ignored by the 8-bit versions.

You would want to tell the firmware which DAC it's using though, since ignoring the lower bits is a floor operation, not a round. So for example if the ideal 12-bit code is 3FF, the 8-bit DAC will see 3F, when 40 would be closer.

[pld]

You would want to tell the firmware which DAC it's using though, since ignoring the lower bits is a floor operation, not a round. So for example if the ideal 12-bit code is 3FF, the 8-bit DAC will see 3F, when 40 would be closer.

Wouldn't that be user error, not noticing the ~1/2 semitone it became worse during calibration?
Hence the hand waving

[BugBrand]

This is really fantastic to have both pld and float32 pop up here!

I agree that my taking it to the 12-bit DAC is probably pointless - as mentioned, I noticed the non-linearity between chips.

That's very interesting on the crash side of things - I will test with those parameters because I had previously been looking more around crashes based on high input amplitudes and/or external triggering. Though that reminds me that a tester did report that running things at high freqs did lead to a crash also.

I had not realised that Github had these branches.. [I am a bit confused with it all, to be quite honest]


Edit/addition:
- is there anywhere else you guys are discussing your Penrose firmware modifications out of interest? [eg. now that the SP forum is awol]

Crashes - I have tried with fast & high amplitude modulations - crashes appear only to occur when there is also a trigger event & I can get this to crash by, for example, touching the rear of the trig socket. I tried the method mentioned in float32's Invert-matrix branch of pushing the first four buttons but couldn't get this alone to cause a crash.
It is worth noting that an external trigger goes to the micro whether or not the switch is set to ext (or on the orig penrose this is a switched jack) - so I wonder if these is something spurious on the reading of the TG line (PD7)

[batchas]

Thanx pld & float32

By curiosity, a question about:

The more interesting patch is perhaps "Fix bug causing the module to freeze" on the other branch, which might address the reported crashes (my theory was that it's ISR related but you have a better analysis). Add those two together and you might have a winner

I replaced the red lines of code with the green lines of code for Firmware/IoMatrix.c, Firmware/IoMatrix.h, Firmware/MCP4802.c
(cause I don't have or found a firmware version where these changes were done).

Now when I want to compile via terminal/vagrant after having changed a few things to get the makefile to work, I have an error because of the
#include <avr/io.h>
found in the adc.h file.
I don't have any avr directory in all my environnement.

Looking for a solution I read that there's a io.h file related to Arduino to be found in hardware/tools/avr/avr/include/avr/io.h
but I never used Arduino to compile for the avr, cause I don't know how to open a non-ino file in Arduino, that's why I use the terminal under OS X (and a Ubuntu machine in VirtualBox).


EDIT: okay I found /Applications/Arduino.app/Contents/Java/hardware/tools/avr/avr/include/avr/io.h. I'm gonna update path in adc.h and see what happens.

[pld]

EDIT: I guess I should find the avr library, add it to my Arduino libs and update the path in adc.h, then compile with the terminal/vagrant.

There should be no Arduino involved at all.
<avr/io.h> should be part of the compiler package (it's been years, so I'm not sure if that's avr-gcc or crosspack-avr, but they can be installed with brew on OS X) and everything gets compiled on command line (make avr).
And normally you shouldn't have to change the makefile, anything settable can be set from the command line also.
But there was IIRC a .hex file in the linked branch.

[batchas]

EDIT: I guess I should find the avr library, add it to my Arduino libs and update the path in adc.h, then compile with the terminal/vagrant.

There should be no Arduino involved at all.
<avr/io.h> should be part of the compiler package (it's been years, so I'm not sure if that's avr-gcc or crosspack-avr, but they can be installed with brew on OS X) and everything gets compiled on command line (make avr).
And normally you shouldn't have to change the makefile, anything settable can be set from the command line also.
But there was IIRC a .hex file in the linked branch.

Thanx for helping.
I have avr-gcc etc installed.
I'm giving up. Maybe one day I'll ask in a new thread***. I don't want to hijack this here.
Again thx a lot!!!

***EDIT: I'll post in the DIY subforum.

UPDATE:
Thanx again pld for the help about the compiler. Making the hex file works fine now

[BugBrand]

Hey, I can report that float32's hysteresis changes seem to have improved the jitter issues - I can still dial in a few, but seems cleaner.
Further checked - I still haven't had a crash (even at hi-freqs & hi-voltages) without something being plugged into the ext gate input - just realised that, of course, for regular euro version you'll never get the action of a signal connected to the gate input with the 'switch' (on the jack socket) signalling to stay in internal-clocking mode.

[/\/\/\/]

Pretty cool – thanks float, pld, batchas & Tom. Seems that this is pretty close to refined due to your efforts (beauty of open source). I'm pretty excited for *any* BugBrand quantizer, but it sounds like this one is working pretty well.

5 octaves seems like a very usable range. With these fixes, does that mean it may still keep the 10V range?

[pld]

Hey, I can report that float32's hysteresis changes seem to have improved the jitter issues - I can still dial in a few, but seems cleaner.

You should be able to increase the threshold here. 1 step = 10/1024 ~= 10mV unless brainfart.

Further checked - I still haven't had a crash (even at hi-freqs & hi-voltages) without something being plugged into the ext gate input - just realised that, of course, for regular euro version you'll never get the action of a signal connected to the gate input with the 'switch' (on the jack socket) signalling to stay in internal-clocking mode.

My gut feeling was that there's a possible oops when switching between modes (i.e. plugging a cable in euro) but the fix float32 made in the other branch (invert-button-matrix) definitely looks good. Any reproduceable scenario would be useful.

Meanwhile, my AVR programmer is MIA, which shows how often I use it

[BugBrand]

Yes, I'll have a check as to whether the invert-button-matrix helps (and try the threshold change you suggest) - just took me an age to figure how to compile files into a .hex file yesterday!

[batchas]

As I didn't find the hex mentionned with the float32 "Fix bug causing the module to freeze" changes (because the hex I found is 2015) then I compiled with the changes*** and the freeze is the same with switching from external to internal trig.

***changes found here:
https://github.com/float32/Penrose/comm ... 2c0fbca2c6

Now I'm seeing another branche here (I remember being quite fit with Github and today it looks like some weird thing that I find very confusing. I'm getting too old for the game!)
https://github.com/SonicPotions/Penrose ... ton-matrix

It's been a while since I'm not fit anymore in programming and did quit in 2012, so I am going to back off, cause I think I will only bring more confusion in the story. Sorry for not being of any help here.

[BugBrand]

..I'm not fit anymore in programming and did quit in 2012..

I quit in about 2005 so you're doing just fine!

[pld]

I keep trying to quit programming, usually at least once an hour

Ok, found the good ol' stk500 and did a quick & dirty merge of float32's commits, and added a (somewhat brute-force) safeguard between the ISR and the main loop. Call it a hunch.
A similarly quick & dirty test consisted of constantly changing signal to In, then patch/unpatching a clock to Trig. Before: Hang, single LED lit. After: Keeps going. That's a euro version on the bench though, so salt to taste, YMMV, caveat emptor, etc.

Branch here (temporarily, pending cleanup)

That doesn't include a .hex file, having that committed is just awkward IMO.

I also noticed there's a dangling pull request in the main SP repo, but that seems to be cosmetic and unrelated.

[BugBrand]

Cool - will try to try this afternoon.
(all this branching, committing, pulling gets me right confused! - edit & f*** how come I managed to compile things yesterday and now already can't figure it today! --- duh, make avr not just make -- see, this stuff is so confusing!)

[batchas]

Branch here (temporarily, pending cleanup

Looks like you nailed it

Works for me here.

I might test further this weekend, but the switch ext/int freeze is gone

The code change you did looks way too simple. I'm depressed
Je plaisante...

EDIT:
Patrick, your help is very much appreciated in this thread.
The Penrose is a great project for the BugBrand system and Tom made a very nice module out of it.

[batchas]

all this branching, committing, pulling gets me right confused!

TBH now I kind of feel better knowing I'm not alone
Not being into it regularly makes it actually quite challenging.

[batchas]

I might test further this weekend, but the switch ext/int freeze is gone

DAMNED!

It freezed again right now after playing a bit with it. Not even by switching back to internal.
No idea what I did as I was playing (next time I let a camera record). Strange cause the freeze we described earlier does not occure anymore with the manipulation we were talking about in previous posts.

[BugBrand]

Installed and the sort of thing I'd done before to make crashes doesn't seem to make it crash now - but I haven't gone deep...

[pld]

Ah well, so much for the sea shells. It was a bit of a shot in the dark.
Any hints to reproducability and symptoms would be useful to find a thread to pull. It's not much code, but meditating over it and hoping the bugs somehow manifest themselves isn't always effective

[BugBrand]

Well, I could run up to high audio rates with full swing on both modulation inputs, tweaking the Initial dial and switching between Ext/Int triggering... This had certainly previously caused quick crashing so things are definitely better.


Heartfelt thanks ongoing!

[batchas]

I tested again this evening, 15 min long doing all kind of manips without any crash!

[T. Jervell]

I tested again this evening, 15 min long doing all kind of manips without any crash!

Sounds promising