I learned quite a bit from the testing done here on my previous module, Drifter. But, I probably haven’t learned everything. So, with the indulgence of the community, I have here a second module ready to test, called Fuse (as in, blowing a fuse, not fusing things together).
I’m curious about any reactions you might have. Is this redundant? Do the docs make sense? Does it need more examples to make it more intriguing? Whatever your thoughts are, I’m still learning.
Those modules sound like they are cool, and the docs are pretty good. Visual nit: the uneven trimming of the borders of the screen shot images looks pretty sloppy to me.
It is the perfect solution for a patch I was working on a while ago - Block 1st trigger after reset. And I can think of a lot of other use cases.
Squinky has a point about the screen capture - it would look better with a consistent (or nearly consistent) border around the module(s). But I wouldn’t sweat that one much.
I have some ideas to make the “Different Styles” screen capture more meaningful and/or easier to trace and understand
Turn off the grid display and baseline display in the scope. The image will be less cluttered, and the flat line yellow trace will then be visible.
Consider using the square wave as your trigger. Certainly the saw wave works, but it seems more intuitive to use a square.
Color code the cables so it is easy to trace
Use a constant color for the RESET and TRIGGER cables. Maybe purple for both. Or else purple for one and black for the other.
Use cable colors that match the scope output for the IN and OUT of each Fuse
Red for the first Fuse
Yellow for the second Fuse
Green for the third Fuse
Blue for the fourth Fuse
The “blown” label makes sense for your concept. But in the documentation, you might want to state that it is basically an end of cycle trigger.
I also have some ideas for module enhancements:
Consider adding a slew limiter control (and possibly CV input?) that controls the transition from one intensity (multiplier) step to the next. If the Fuse output is modulating an audio signal, it might be nice to smoothly transition between steps instead of having sudden jumps. If you do this, make sure the control allows for 0 slew!
Consider replacing the Style control with four different outputs, so that you can get all four styles simultaneously from one module. I would definitely make use of multiple styles at once. Of course the adaptive graphic across the top would have to change. Perhaps simply make it a a constant bar that shows the percentage of the limit that has been reached. Perhaps also add an LED above each output. Make the intensity of the green LED proportional to the current multiplier, and red when the multiplier is 0
The timing of resets can be tricky. Perhaps have an option (context menu?) to buffer the reset so that the next trigger does a reset. Perhaps if a reset and trigger arrive simultaneously, then reset immediately.
I’ve updated the images, Squinky, thanks for noting that.
Dave, your point about slew control for the transitions that Fuse adds to OUT had escaped my notice, but you bring up an interesting point. It’s different than just putting a slew limiter on OUT, because that would unduly affect desired rapid changes that came in through IN. What Fuse needs here is the option to limit slew on the function F that IN is multiplied by. There are work arounds that would avoid the need for this, but they are not kind to the user.
What control scheme for slew control do people consider canonical (and not require a lot of controls)? What makes sense to me is just to set the length of time for each transition in F, but so far I’ve not seen that kind of control scheme in a slew limiter.
Given that “multiple STYLES in a single Fuse” can be simulated with “multiple identical Fuses with the same inputs (but different STYLES)”, I’d currently like to avoid doing that to the UI. But I am curious; if you can, spell out a little why having multiple STYLEs on the same IN is so appealing that you can immediately see a use for it.
While I’ve not personally seen the reset timing trickiness you mention, it seems easy enough to add (as a context menu option). If set, would that mean the timing would go:
Another way to think about this module: it is basically a Count Modula Event Timer or Nysthi Timex, except it has a built in VCA that attenuates an incoming signal relative to where it is in the timing cycle.
Exactly - I struggled on how to word that. I’m glad you were able to figure out what I was driving at.
As for the implementation of the slew - I think a linear transition is all I would ever need, especially since your widen/narrow styles also use a linear stepped attenuation progression. I think there is benefit to being able to set a specific time, or a time relative to the most recent clock period. For a specific time it could be really short, like a few msec, just to prevent pops when an audio signal is switched on. Or it could be seconds to allow for an audio (or other) signal to gently fade in or out. If relative to the clock period, then simply a value ranging from 0 to 100%. At 100%, the narrow or widen style would result in a constant slope attenuation profile, rather than the stepped profile that no slew would give. Your module can remember the interval between the last clock pulse pair, and assume a regular pulse rate. The problem is what to do with the initial pulse - I don’t know if there is a good solution, but I know other modules have tackled this problem. Also you would have to establish a rule/behavior for when the slew has not completed by the time the next clock pulse arrives.
Absolutely - the same functionality can be gotten by replicating Fuse modules, but that contributes to cable clutter, uses more CPU, uses more space… To me it is analogous to why does a Bernoulli gate have two outputs, when the 2nd can be gotten simply by negating the first? Or why did the old VCV Unity module provide both a normal mix as well as the inverted mix? I dearly miss that feature in the VCV MIX module that is supposed to replace Unity. I just know that I frequently want simultaneous inverse outputs. With Fuse, Blow Closed is the inverse of Blow Open, and Narrow is the inverse of Widen. Are the simultaneous inverse outputs required - no. Are they convenient - yes.
To be honest, I haven’t had to cross that bridge either. I just have run across a number of discussions where it is important to some. If the reset is somehow tied to the same clock, then it should be a non-issue. But if it is manually triggered, I can see how delaying a reset until the next clock pulse could lead to more musical transitions.
There were a couple of additional ideas I had that I forgot to write down.
Have you thought about polyphony? Personally I don’t think a polyphonic clock input is worth the trouble, I don’t think it would be used very often. But I think polyphonic IN/OUT would be used a lot. A monophonic clock would have control over the attenuation of a polyphonic signal.
You might also consider having a constant internal voltage normaled to the Input. If no patch cable is in the input, then a constant value of maybe 10, 5, 1, -1, -5, or -10 could be used. I think that is another good opportunity for a context menu option.
My final idea if you want to get fancy - provide an expansion module that consists only of Input and Outputs (or Input, Output, and Style). That way a single fuse could control any number of signals. And yes, of course that could be handled by multiple Fuse all with the same trigger and reset inputs, and same limit setting. But again it comes down to cable clutter, and convenience.
All that being said - I think I would still use Fuse as it is currently designed. I’m just throwing out ideas.
I lied - one more thing. You should make a conscious decision on what the bypass behavior is, and document it. I guess you have two options for a bypassed Fuse - either the input is passed through unaltered to all outputs, or else all outputs are blocked (0V). I think a case could be made for either choice.
Dave, thanks for making me rethink what this module was. I did add Slew control and the constant internal voltage menu option, and the bypass behavior is now defined in the manual. I’ll save the other ideas as possible 2.0 additions.
