The ramping approach does seem like a really good idea, I hadn’t considered that- It’s entertaining to think about it as the module getting impatient.
But, yeah, I think start simple, just do a manual binary search to see if we can find one good epsilon value and force it to transition regardless of pops and clicks- that way we can hear how bad it might actually be.
@gc3 have you started this at all yet? I got busy and this sorta fell of my radar for a bit… oops ._.
haha me too. Other stuff + pushing the keyboard patcher along has held this off for me too. Still very interested and had a few design thoughts here and there; will collect those & start coding once TapPatch is in alpha 
Cool 
TapPatch is pretty awesome too
Thx @Vega! Love to have you in the alpha or beta round if you’re interested–no time commitment required, just play around with it and share thoughts
Am looking forward to getting on to this, though. TapPatch is already enough code that refactoring is getting a bit tedious…
Sure, I’m interested in the beta
Yeah, sometimes it helps to write code for more than one thing at once anyway- helps think in multiple ways and not get stuck in a rut, maybe find a new way to approach a bug.
I’ve started work on my own collection of modules, learning as I go. Sulafat and γ Lyrae are done, a multi-mode wavefolder and ring-mod with inverted output and offset respectively. Vega (the module, not me) will be this thread’s module.
I was thinking about how to do the switching between stages, and while I may still have to do some interpolation, through-0 detection, or other wizzardry, I think I’m going to see if a simple crossfade of the modulation signals works first.
Would a slew applied on the change not work? Probably won’t be desirable in many circumstances but it could be used only if the difference is more than x and have a slower rate the more difference in voltage there is? I don’t know if that’s even possible though.
it’s possible, and I considered it. The problem is that difference itself is also time varying, and with audio rate modulation makes significantly less sense
This has no morphing of stages, not extra modes, no lin/exp controls, etc. - still very early stages but it does work. I’m absolutely going to have to redo the panel a bit as the attenuation knob so close to the input is highly frustrating and a few extra controls are going to be necessary - namely offset and attenuation controls for the global ring input
Nice work! Sorry I had to bail on helping out with this, but you seem to have it well in hand, and I look forward to trying it out as soon as it’s released! It’s a great idea.
Added a few hp, but it’s significantly less cramped, plus I added some indicator lights.
For some reason the global ring attenuation and offset knobs really don’t want to show up. Not sure what’s going on there, but also running out of time and energy to work on this tonight. Here’s the code rn, https://github.com/VegaDeftwing/LyraeModules/tree/VegaADSR it’s a real mess, but I wanted to hammer it out then refine as I go
Nice!
On a quick glance I think they’re just falling out of the bounding box to the right? At 15HP you’ve got mm2px(Vec(76.2, 128.5)) to work with and those are flying in at X==106.448 and X==113.94.
This is the kind of bug you see within 15 seconds of reopening a project after a break 
that does look nicer! I’ve started to prototype all my panels in a drawing program where it’s much easier to move the knobs and jacks around. Saves me a lot of time (trial and error). Then when it looks ok I put al the knob and jack positions into my code, then output the reset as a panel SVG. Maybe you are doing something similar already.
I’m using the helper.py that in the rack SDK. It’s less than ideal, as it has a plethora of things that makes it freak out and crash, but it works.
odd. I wonder how that happened given I used the helper.py to generate the panel.
edit: the dimensions were just flipped, x was y and y was x, not sure how that happened!
Weird! I haven’t used helper.py but I noticed this in the svg:
<circle
style="display:inline;fill:#ff0000;"
id="path118814-0-2-3-45-79-0-2-1-5"
cx="106.44804"
cy="29.572687"
r="1.0004772"
inkscape:label="GlobalRingAtt"
transform="matrix(0,1,1,0,0,0)" />
<circle
style="display:inline;fill:#ff0000;"
id="path118814-0-2-3-45-79-0-2-1-5-1"
cx="113.94044"
cy="29.572687"
r="1.0004772"
inkscape:label="GlobalRingOffset"
transform="matrix(0,1,1,0,0,0)" />
Those look like the only two under the 90-degree rotation matrix (0,1,1,0,0,0). My guess is that they show up correctly in Inkscape b/c of the transform but that helper.py isn’t factoring in the rotation and is just applying the raw cx and cy coordinates. Just a guess!
ahh! That makes total sense. Glad to know to avoid this in the future. I was trying to make some things equi-distant to make things pleasing to the eye and so did a rotation not thinking about how in vector land the rotation itself is baked into the svg, not the result.
By the way, I’m by no means attached to these modules being all mine, if you’d still like to contribute (either of you I guess) by submitting a PR it’d be more than welcome!
edit: yep [from helper.py]:
elif el.tag == "{http://www.w3.org/2000/svg}circle":
cx = float(el.get('cx'))
cy = float(el.get('cy'))
c['cx'] = round(cx, 3)
c['cy'] = round(cy, 3)
I’m sure you’re not the first one to get hit by that! Easy to fix in the SVG but it might be a useful feature request for helper.py (no reason why it couldn’t apply the transform and then feed that to the code gen, although I don’t know the SVG spec well enough to say whether parsing all legal transforms would be annoyingly complex).
Probably the “correct” solution would be to import a python SVG parser and let it determine the final coordinates of everything, but that adds not just complexity but a dependency. The easier feature request would be for the Panel doc, to note the limitation.