Penrose Possibles (Open Source Sonic Potions Quantizer)

BugBrand · Post by **BugBrand** » Mon Sep 23, 2019 8:27 am

I posted Schematic / BOM / Gerbers (PCB & Panel) to the first post.

float32 · Post by **float32** » Wed Sep 25, 2019 4:40 pm

pld wrote:Wouldn't that be user error, not noticing the ~1/2 semitone it became worse during calibration?

Only if you're expecting your user to perform a 120-point calibration

pld wrote:
BugBrand wrote: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.

Yeah I would suggest increasing the hysteresis to 4, which is about half a semitone.

pld wrote: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.

Yeah that's a really good idea. I doubt that much of the codebase is reentrant, especially the drivers. One thing you can do is to set a flag in the trigger ISR instead of calling process() directly. Then in main() you call process() if trigger is disconnected OR if that flag is set (and then clear the flag).

In my refactor, I use a sample rate based approach, triggering the ADC with a timer and then performing the DSP in the ADC completion interrupt. This also allows us to sample at a much higher rate since we're not busy waiting for the ADC anymore. I'm cleaning up my code now, hopefully I can push a release to github soon.

pld · Post by **pld** » Thu Sep 26, 2019 12:59 am

float32 wrote:Only if you're expecting your user to perform a 120-point calibration

Pfft. Details

Ideally there'd be a serial port and a nice automated setup, but...

Yeah that's a really good idea. I doubt that much of the codebase is reentrant, especially the drivers. One thing you can do is to set a flag in the trigger ISR instead of calling process() directly. Then in main() you call process() if trigger is disconnected OR if that flag is set (and then clear the flag).

Yes, a flag would be a bit more subtle.

In my refactor, I use a sample rate based approach, triggering the ADC with a timer and then performing the DSP in the ADC completion interrupt. This also allows us to sample at a much higher rate since we're not busy waiting for the ADC anymore. I'm cleaning up my code now, hopefully I can push a release to github soon.

Nice. I guess you have a bit of a head start

Putting things on a fixed timebase might also minimize the slight LED dimming depending on whether there's a cable in Trig...

float32 · Post by **float32** » Thu Sep 26, 2019 4:52 pm

Okay I published my changes so far: https://github.com/float32/Penrose

You can grab hex/wav files directly from here: https://github.com/float32/Penrose/releases

Hopefully the 'make load' command works properly. I don't have an AVRISP so I can't test it. I've been flashing my chip using the bootloader only. Yes, it's pretty annoying

pld · Post by **pld** » Fri Sep 27, 2019 1:14 am

float32 wrote:Okay I published my changes so far: https://github.com/float32/Penrose

Nice work. I'll try and find time to give a whirl, at first glance it looks pretty similar to the direction I'd have gone...

Hopefully the 'make load' command works properly. I don't have an AVRISP so I can't test it. I've been flashing my chip using the bootloader only. Yes, it's pretty annoying

Hehe, yeah, that is painful.

BugBrand · Post by **BugBrand** » Fri Sep 27, 2019 3:24 am

Ah, cool -- so, curious what fundamental differences there are between pld's last version from a few days ago (which he described as needing cleanup?) - that has proved to work well for me.

I'll see about trying float32s shortly too.

Cheers all!

batchas · Post by **batchas** » Fri Sep 27, 2019 8:09 am

BugBrand wrote:I'll see about trying float32s shortly too.

I tested it and this one crashes like it did earlier :(
I can make a video if needed, but it's the same manip I did.
Internal trig, then external, then internal, then turn Initial pot = crash.

pld · Post by **pld** » Fri Sep 27, 2019 9:29 am

BugBrand wrote:Ah, cool -- so, curious what fundamental differences there are between pld's last version from a few days ago (which he described as needing cleanup?) - that has proved to work well for me.

Well mine was more like bandaids for the original code (*), float32's release is a rewrite that should avoid some of the issues outright.
From the README.md:

* Moved to a sample-rate-based architecture instead of loop-based. The sample rate is 8 kHz, and the theoretical maximum is 10 kHz (limited by the ADC).
* Optimized drivers.
* Fixed a lot of bugs, some that caused crashing and some that only caused misbehavior.

(*) Not to diss the nice fixes that got merged in though

batchas wrote:I tested it and this one crashes like it did earlier :(
I can make a video if needed, but it's the same manip I did.

Yeah, a video that shows the resulting state of the module might help. Is just the UI stuck, or what happens at the outputs?

pld · Post by **pld** » Fri Sep 27, 2019 1:30 pm

I guess the question is, should we maybe open issues on github?
Anywho, quick & dirty test on the bench, blinkenlights are blinking and I can't get it to hang by plug and unplugging something to Trig.

It does feel like the Gate LED is on more often than expected and if I unplug the "other" end of the Trig cable (i.e. leaving it in module but floating) it's permanently lit.

Giving the code a quick peek: ProcessDAC() only gets called if there's something to do, won't that delay the call to FinishWrite()?

float32 · Post by **float32** » Fri Sep 27, 2019 2:02 pm

pld wrote:I guess the question is, should we maybe open issues on github?
Anywho, quick & dirty test on the bench, blinkenlights are blinking and I can't get it to hang by plug and unplugging something to Trig.

It does feel like the Gate LED is on more often than expected and if I unplug the "other" end of the Trig cable (i.e. leaving it in module but floating) it's permanently lit.

Giving the code a quick peek: ProcessDAC() only gets called if there's something to do, won't that delay the call to FinishWrite()?

You're right, good catch. We should probably just move the code from ProcessDAC() into ADCCallback() and then split it up appropriately. It feels inelegant though. I want to write a Quantizer class that will handle all this logic internally.

The issue tracker is a good idea too, I've enabled it on my repo.

BugBrand · Post by **BugBrand** » Wed Oct 02, 2019 5:19 am

batchas wrote:I tested it and this one crashes like it did earlier :(
I can make a video if needed, but it's the same manip I did.
Internal trig, then external, then internal, then turn Initial pot = crash.

Strange - I've tried both of float32's new versions (another one came a couple of days later - https://github.com/float32/Penrose/releases - v0.1.1) and have not been able to make either crash.
I haven't overly compared it against pld's version from a week or so ago, but all seem to function nicely in my view!

batchas · Post by **batchas** » Thu Oct 03, 2019 3:55 am

Yesterday I was unable to reproduce.
Weird.
This + the fact that nobody's gonna switch back and forth between int/ext gates and turn the offset right after anyway, makes me think as you say that all is fine.

T. Jervell · Post by **T. Jervell** » Thu Oct 03, 2019 7:48 am

Wow! Starting at audio rate, the going down. This module handles it like a champ!!

[video][/video]

BugBrand · Post by **BugBrand** » Thu Oct 03, 2019 10:16 am

So, think I'm ready to send out the first ones - basic listing online here.
Email me for ordering.

This first batch uses float32's latest code (v.0.1.1)

pld · Post by **pld** » Fri Oct 04, 2019 12:59 am

Thanks for testing. I did mean to post that float32 fixed the gate issue, so 0.1.1 is probably the best version right now.
Also, one small tweak in behaviour vs. the original is now mentioned in the README:

Changed the quantizer behavior to find the nearest enabled note, instead of the nearest higher.

T. Jervell · Post by **T. Jervell** » Fri Oct 04, 2019 4:16 am

OK! Had to try to make a random/S&H patch with the Penrose today. While patching I also decided it would be a nice idea to try the dual filters (ch.1) abillity to slew incoming CV. So Noise out from DRM2-> Penrose Mod1 input, Chirpers osc 2 -> Penrose trig input and gate input on the Dual Env. Penrose out to both the input on dual filter ch. 1 and V/oct on dual filter ch. 2. Output of osc -> input filter ch.2. The slew’ed penrose CV signal from filter ch.2 is sent the both the VCO’s v/o input and CV A input on filter ch.2. Another compact VCO in LFO mode is modulating Dual filter ch.1. Also sent a copy of the osc voice to the PT delay module. PT out to mixer and LPG. Penrose gate out to HIT input on the LPG, and LPG out to Feedback input on the PT. Effectively the LPG is gating the feedback. Loads of fun with these modules, and I’m pretty much just scratching the surface at the moment!

[video][/video]

syncretism · Post by **syncretism** » Fri Oct 04, 2019 4:00 pm

Forgive me, I’d like to ensure I understand how this works.

“Mod” inputs 1 and 2 are each what I might call an “input” on another quantizer, and they can be mixed freely with the switched, polarized attenuators.

There’s a positive offset providing an additional voltage. Is that also quantized, or just a free voltage?

There’s a CV input that triggers a sample and hold. External seems self-explanatory, but what about internal? Is that normalled to the two “mod” inputs, which I’m guessing have comparators like the EGs, dividers and other BugBrand modules?

Sorry if these seem elementary, but the Penrose is different from other quantizers I’ve used, so I’d like to make an informed purchase.

BugBrand · Post by **BugBrand** » Fri Oct 04, 2019 4:37 pm

There's a description here: https://www.bugbrand.co.uk/index.php?ma ... cts_id=149

Effectively I added a DC mixer on to the front end - it is limited to a range of 0 to +10V (ie 10 octaves). So the initial control covers this full range and then the two mod inputs add or subtract from this - of course within the bounds of the 0 to +10V range.

For Internal triggering the module is constantly reading the inputs and changes as soon as the input voltage changes.

BananaPlug · Post by **BananaPlug** » Fri Oct 04, 2019 4:40 pm

BugBrand wrote:Effectively I added a DC mixer on to the front end - it is limited to a range of 0 to +10V (ie 10 octaves).

That alone puts it ahead of anything I had before.

syncretism · Post by **syncretism** » Fri Oct 04, 2019 5:09 pm

BugBrand wrote:There's a description here: https://www.bugbrand.co.uk/index.php?ma ... cts_id=149

Effectively I added a DC mixer on to the front end - it is limited to a range of 0 to +10V (ie 10 octaves). So the initial control covers this full range and then the two mod inputs add or subtract from this - of course within the bounds of the 0 to +10V range.

For Internal triggering the module is constantly reading the inputs and changes as soon as the input voltage changes.

Aye, I’ve read it, thanks! Just wanted some additional clarification. Okay, so all three voltage sources are summed before the quantizer, it sounds like. Let’s say I switch off a mod input. Does that also turn off the internal trigger from that mod input?

BugBrand · Post by **BugBrand** » Sat Oct 05, 2019 1:27 am

Yes, the voltages are summed.

There isn't really an internal 'trigger' - the central ATMega chip is just always reading for change on the input voltage. So 'triggering' depends on the summed input voltage changing.

syncretism · Post by **syncretism** » Sat Oct 05, 2019 5:15 am

BugBrand wrote:Yes, the voltages are summed.

There isn't really an internal 'trigger' - the central ATMega chip is just always reading for change on the input voltage. So 'triggering' depends on the summed input voltage changing.

And that’s true only when “int” is switched; if set to “ext,” the module operates as a sample-and-hold, ignoring voltage fluctuations between triggers. Is there a threshold for the incoming “trigger?” I ask because some of my modules (not BugBrand) seem to produce hotter pulses than others.

Thanks again, Tom!

BananaPlug · Post by **BananaPlug** » Sat Oct 05, 2019 10:23 am

syncretism wrote:Is there a threshold for the incoming “trigger?”

My guess is you won’t have a problem with that. Tom usually sets up trigger inputs to respond to inputs as low as 1 volt.
^Nevermind. See next post...

BugBrand · Post by **BugBrand** » Sat Oct 05, 2019 1:05 pm

Not on this! It just has a basic transistor buffer input - no comparator.
So hit it with a 5V or 10V trigger/gate signal (sure +/-5V waveform with sharp rising edge would also work but haven't tried)

float32 · Post by **float32** » Sun Oct 06, 2019 8:22 pm

It's not a buffer, just a transistor switch, so anything above about a diode drop will trigger it. 1V is plenty.

MUFF WIGGLER

MUFF WIGGLER

Penrose Possibles (Open Source Sonic Potions Quantizer)