Penrose Possibles (Open Source Sonic Potions Quantizer)
Only if you're expecting your user to perform a 120-point calibrationpld wrote:Wouldn't that be user error, not noticing the ~1/2 semitone it became worse during calibration?

Yeah I would suggest increasing the hysteresis to 4, which is about half a semitone.pld wrote:You should be able to increase the threshold here. 1 step = 10/1024 ~= 10mV unless brainfart.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.
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).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.
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.
Pfft. Detailsfloat32 wrote:Only if you're expecting your user to perform a 120-point calibration![]()

Ideally there'd be a serial port and a nice automated setup, but...
Yes, a flag would be a bit more subtle.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).
Nice. I guess you have a bit of a head startIn 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.

Putting things on a fixed timebase might also minimize the slight LED dimming depending on whether there's a cable in Trig...
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
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

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...float32 wrote:Okay I published my changes so far: https://github.com/float32/Penrose
Hehe, yeah, that is painful.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
I tested it and this one crashes like it did earlier :(BugBrand wrote:I'll see about trying float32s shortly too.
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.
-----------------------------------
FS: KESAKO Player & Reverb for Serge and Buchla
FS: KESAKO Player & Reverb for Serge and Buchla
Well mine was more like bandaids for the original code (*), float32's release is a rewrite that should avoid some of the issues outright.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.
From the README.md:
(*) Not to diss the nice fixes that got merged in though* 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.
Yeah, a video that shows the resulting state of the module might help. Is just the UI stuck, or what happens at the outputs?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.
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()?
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.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()?
The issue tracker is a good idea too, I've enabled it on my repo.
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.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.
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!
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.
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.
-----------------------------------
FS: KESAKO Player & Reverb for Serge and Buchla
FS: KESAKO Player & Reverb for Serge and Buchla
- T. Jervell
- Wiggling with Experience
- Posts: 485
- Joined: Thu Feb 07, 2013 2:13 pm
- Location: Norway
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)
Email me for ordering.
This first batch uses float32's latest code (v.0.1.1)
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:
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
- Wiggling with Experience
- Posts: 485
- Joined: Thu Feb 07, 2013 2:13 pm
- Location: Norway
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]

[video][/video]
-
- Morbidly self-aware and liking it
- Posts: 1631
- Joined: Sun Jan 25, 2009 7:05 pm
- Contact:
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.
“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.
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.
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
- Super Deluxe Wiggler
- Posts: 2713
- Joined: Wed Dec 05, 2007 10:37 pm
- Location: PHL USA
-
- Morbidly self-aware and liking it
- Posts: 1631
- Joined: Sun Jan 25, 2009 7:05 pm
- Contact:
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 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.
-
- Morbidly self-aware and liking it
- Posts: 1631
- Joined: Sun Jan 25, 2009 7:05 pm
- Contact:
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.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.
Thanks again, Tom!
- BananaPlug
- Super Deluxe Wiggler
- Posts: 2713
- Joined: Wed Dec 05, 2007 10:37 pm
- Location: PHL USA
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.syncretism wrote:Is there a threshold for the incoming “trigger?”
^Nevermind. See next post...
Last edited by BananaPlug on Sat Oct 05, 2019 1:17 pm, edited 1 time in total.
