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  
Author Penrose Possibles (Open Source Sonic Potions Quantizer)
BugBrand
Slowly I built a pair of these - the Sonic Potions Quantizer but in BugFormat and with built in DC mixer::::



Minimal testing so far and unsure what will happen -- I shall open source the gerbers, but maybe do a small run sometime.


***Edit - adding design files::::
chrisdermo
Oh dang! Sign me up!
lud
Looks excellent, would definitely like one!
BananaPlug
And there they are! Very nice indeed.
soup
Nice! I was curious about the green 1 space penrose you made but this is way better. I love the dc mixer.
a100user
Very cool Tom, interested thumbs up
batchas
Looks ace thumbs up

And you were right about the horizontal buttons, it will make it indeed more playable (this and all what was added to the original like the mixer).
BugBrand
Fun plays last night!
I want to check whether a 12bit DAC improves accuracy.
Minimal circuit changes needed (couple of minor re-routes).
The design is single board and small SMD - 0603 passives, MSOP, TQFP - so really production only (not DIY) - some of the soldering is tiny.
Flexyflier
Wow Tom!,would pick these up if/when available

Bryce
deltaAquarii
beautiful !
moket808
Nice one Too, would love to get one please
/\/\/\/
DC Mixer is a brilliant idea for a quantizer... modulation for sequence variation, or constant offset for harmonic shifts.

This looks like another essential.
Corbeau
Would love to have this too! woah
Vcoadsr
Very interested in this too!!
radams
Yes
I’d love this
The Barton is ok but this looks much better
rico loverde
would def want one
jjsynth
+1
Is it possible to switch off the quantizer and just use the dc mix? It would make a great front end to the vcos in the synth voice?
BugBrand
Good to hear there's lots of interest! I've continued to enjoy playing with the initial protos & changed one over to 12-bit DAC (orig spec is 8 bit) - need to check that some more.

It isn't possible to use it as a standalone DC Mixer - it is very much integrated into the design (schematics will come when I publish Gerbers etc) - but I have got a proto DC Mixer design going, just need some tweaky changes having tried the 1st version. Yes, utility mixing is definitely called for - as are a bunch of other ideas rolling round my head!
rico loverde
I love those buttons!
Voltage_Controller
applause looking forward to this
chrisdermo
Finally built a penrose after having the kit for a ridiculously long time. Wow! So good for generating sequences and patterns that are related to other things going on (lfos and envelopes and whatnot) but in an unexpected way. Nice balance between intentional and unintentional results. Would definitely love to see these make production in some way or another, dc mixer is a much needed addition too.
bunkdata
Looks great! Count me in as well! SlayerBadger! Guinness ftw!
lud
Really hope you make some more for sale Tom!
BugBrand
lud wrote:
Really hope you make some more for sale Tom!


I didn't make any for sale yet!
I did send a proto to Robert but there have been some strange behaviours which I/we haven't been able to sort as yet.
But I am tempted just to get a short run done up, kind of to test at a slightly larger scale.
Personally I'm really enjoying the module - I have 3 protos in various systems and find it great.

Oh yes, and there is a DC mixer module (1FW) designed awaiting production.
chrisdermo
BugBrand wrote:
lud wrote:
Really hope you make some more for sale Tom!


But I am tempted just to get a short run done up, kind of to test at a slightly larger scale.
Personally I'm really enjoying the module - I have 3 protos in various systems and find it great.

Oh yes, and there is a DC mixer module (1FW) designed awaiting production.


thumbs up
otoskope
Oh, totally missed this thread. They look great, Tom. I hope you can make a batch, I'd definitely be interested.
BugBrand
Just got the blessing from Julian!
otoskope
Great news!
chrisdermo
BugBrand wrote:
Just got the blessing from Julian!



AWWWWWW YE nanners
anadeji
Very excited for this !
/\/\/\/
hyper hyper hyper hyper

Always excited for new designs, but this one really gets the imagination going.
And that DC mixer built in ... great great great!
BugBrand
Before rolling these out properly I'd like a few people to help as testers - ideally UK, but Europe would probably work too. I've got a few built so once confirmed things should get going fairly soon.
rico loverde
BugBrand wrote:
Before rolling these out properly I'd like a few people to help as testers - ideally UK, but Europe would probably work too. I've got a few built so once confirmed things should get going fairly soon.
excited for this one!
chrisdermo
This is me raising my hand enthusiastically SlayerBadger!
a100user
happy to help if needed Tom as I have a vested interest in these becoming available, I want one smile
T. Jervell
Guess I’m a bit late to the party... also not a UK resident...but still hihi
But, very excited that the quantizer is near complete It's peanut butter jelly time!
sungja
I have the barton you did but this one looks more playable so put me down for one of these please. thumbs up
sensanalog
I so can't wait for this Tom!
Vcoadsr
Hi Tom, I'd happily do some testing for you, done my fair share of alpha & beta testing for Matthew at ALM over the years, cheers Phil
tIB
Always here if needed!
BugBrand
So, having had more of a check last night (+ help from Batchas) I wanted to mention the current issues. They appear to be based on the original design rather than my version as I've checked similar on my original 1FW Penrose adaption - as such, I'm not quite sure what to suggest.

1) Jittery behaviour - when using larger spans (3+ octaves) you can get some instances where the Penrose isn't quite sure which note to settle on, so you get trilly/jittery results. In my own usage I've tended to stick anyways to a few octaves, so I've not overly noticed this.

2) Crashes - This was flagged up by Batchas - I'd not come across it due to my usage, but I was finally able to replicate it repeatedly and also find that it occurred too on the original Penrose. As such I believe it might be firmware related. If the combination of CV ins and Initial are relatively high (I think summing to over 10V but haven't id'd exactly) then having an external trigger connected to the input (whether or not it is switched to use it) can cause the Penrose to latch up which then requires a power reset.

3) Accuracy - so I did move to the 12bit DAC but it is noticeable that these have some variance unit to unit. Mostly they seem pretty good, though I did have one testing yesterday which was really quite out just on the first octave. I guess I'll find out more through testing - might have to swap out some of the DACs if particular ones are inaccurate.

I've got a few built and flashed - shared one to another UK user, so hopefully there'll be further comments this weekend. Can equally share a few more around, but I'm still somewhat wary due to these points & that I'm unsure whether they can be sorted.

One point - I use an IDE programmer on these, but in theory you can use an audio file to update (haven't tested this yet). I'm not overly keen on sending loads out if users can't perform any firmware update.

Anyways - curious what people think?
T. Jervell
Well, I guess you already know where I stand Tom hihi
But regarding your point. Jittery/trill-behaviour I’ve experienced with more than three different euro quantizers, so I don’t know if this is a «common» problem that is hard to solve?
The crashing bit is of course unfortunate, but I guess as long as it’s know, and specific to what you just said then no problem.

So my opinion would to go for it. I don’t mind jitter/stutter, I’ve several times used it intentionally with my previous quantizers. But not all would agree with me, I know hihi
otoskope
Well, you know my willingness to test things, Tom.... Looks like a great module, and I hope you get the issues sorted. I remember we discussed DC offset and attenuator already on the old dual Barton Quantizer. So useful!
Vcoadsr
BugBrand wrote:

One point - I use an IDE programmer on these, but in theory you can use an audio file to update (haven't tested this yet). I'm not overly keen on sending loads out if users can't perform any firmware update.

Anyways - curious what people think?


Hi Tom, I’ve got a PICKIT 3 programmer that I use to update The Harvestman modules so if that’s what’s also needed to update the firmware on this then I can definitely help test - let me know what you think ... Cheers Phil
BananaPlug
I wonder if this is a case where rigorous attention to grounding, bypassing, power filtering makes the difference even if no particular “cause” is discovered.
batchas
T. Jervell wrote:
The crashing bit is of course unfortunate, but I guess as long as it’s know, and specific to what you just said then no problem.

It happened while testing (switching + increasing offset) but this kind of manip that brings it to crash is definitely not something I ever did in a "normal" situation when playing with the other Penrose(s).

Tom found out it's also on the original Penrose, which we did not know and it proves as said that it's really not a usual/normal manip!
DickMarker
Just to chip in my twopence regarding jitter, every quantiser I've ever used has, when fed a wide cv range, been a little prone to jitter/trills as you described. So in that respect, it doesn't seem like something that necessarily needs correcting as it's to be expected and the key to avoiding it is in the hands of the user trimming the input to a usable range.
Cool module btw - like what you've done with the design.
pld
So this isn't my usual format haunt, but...

BugBrand wrote:
1) Jittery behaviour - when using larger spans (3+ octaves) you can get some instances where the Penrose isn't quite sure which note to settle on, so you get trilly/jittery results. In my own usage I've tended to stick anyways to a few octaves, so I've not overly noticed this.

FWIW there was some discussion on the (currently MIA) SP board about adding hysteresis to avoid the indecisive oscillation.
I know I implemented a naive version at some point (without looking deeper at the underlying adc resolution etc.) but then got distracted by other shiny things smile I assume I kept the code somewhere though.
BugBrand
pld wrote:
So this isn't my usual format haunt, but...

FWIW there was some discussion on the (currently MIA) SP board about adding hysteresis to avoid the indecisive oscillation.
I know I implemented a naive version at some point (without looking deeper at the underlying adc resolution etc.) but then got distracted by other shiny things :) I assume I kept the code somewhere though.


Ah, are you Patrick Dowling then? I did come across your firmware version and it did seem better than the original..
The strange thing remains that stability is good on for about 3 octaves - hardly any jittery behaviour.
I've not looked at code for ..years.. so unsure whether this project should be my route back in!

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

Yes, it is a shame that the Sonic Potions forum vanished..
BugBrand
So I didn't get much focus on this last week - hoping to move forward this week.

As mentioned above, the idea of delving into programming is not something I necessarily relish.

I have wondered about scaling everything down by a factor of 2 - I don't overly see the call for 10 octaves of range - 5 would seem more than enough. I'll have to have a check as to whether this reduces the potential for crashes etc. As mentioned it should reduce the scope of jittery behaviour and it does sound like for most users it wouldn't really alter usual usages.
pld
BugBrand wrote:
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.

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

Quote:
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
Quote:
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/devicedoc/22244b.pdf


Quote:
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
float32 wrote:
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 smile
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 thumbs up

By curiosity, a question about:
pld wrote:
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
batchas wrote:
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
pld wrote:
batchas wrote:
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 thumbs up
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
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.

Quote:
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 smile
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/commit/5a029161f57c793374f51620ced7 5f2c0fbca2c6

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/compare/master...float32:inver t-button-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
batchas wrote:
..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 wink

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
pld wrote:
Branch here (temporarily, pending cleanup

Looks like you nailed it applause

Works for me here.

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

The code change you did looks way too simple. I'm depressed help
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
BugBrand wrote:
all this branching, committing, pulling gets me right confused!

TBH now I kind of feel better knowing I'm not alone smile
Not being into it regularly makes it actually quite challenging.
batchas
batchas wrote:
I might test further this weekend, but the switch ext/int freeze is gone w00t

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 smile
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
batchas wrote:
I tested again this evening, 15 min long doing all kind of manips without any crash!


Sounds promising applause
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.
syncretism
Very, very cool. Thanks, all!
MUFF WIGGLER Forum Index -> BugBrand Devices  
Page 1 of 5
Powered by phpBB © phpBB Group