MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

Penrose Possibles (Open Source Sonic Potions Quantizer)
MUFF WIGGLER Forum Index -> BugBrand Devices Goto page Previous  1, 2, 3, 4, 5  Next [all]
Author Penrose Possibles (Open Source Sonic Potions Quantizer)
BugBrand
I posted Schematic / BOM / Gerbers (PCB & Panel) to the first post.
float32
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 eek!

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
float32 wrote:
Only if you're expecting your user to perform a 120-point calibration eek!
Pfft. Details razz
Ideally there'd be a serial port and a nice automated setup, but...

Quote:
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.

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

Quote:
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 hihi

Hehe, yeah, that is painful.
BugBrand
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
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
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:
Quote:
* 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
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
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
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
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
Wow! Starting at audio rate, the going down. This module handles it like a champ!! w00t
BugBrand
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
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:
Quote:
Changed the quantizer behavior to find the nearest enabled note, instead of the nearest higher.
T. Jervell
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! w00t
syncretism
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
There's a description here: https://www.bugbrand.co.uk/index.php?main_page=product_info&cPath=2_31 &products_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
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. nanners
syncretism
BugBrand wrote:
There's a description here: https://www.bugbrand.co.uk/index.php?main_page=product_info&cPath=2_31 &products_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
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
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
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
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
It's not a buffer, just a transistor switch, so anything above about a diode drop will trigger it. 1V is plenty.
MUFF WIGGLER Forum Index -> BugBrand Devices Goto page Previous  1, 2, 3, 4, 5  Next [all]
Page 4 of 5
Powered by phpBB © phpBB Group