In search of a consistent reset input
  • I realized that I have pretty much stopped using the reset inputs on Audulus sequencers because they work inconsistently. The main problem is that the reset message needs to be sent when the gate input is low, meaning it doesn't always reset. I would propose adding a timer node and an expression to the module in order to force the reset whenever the message is received to create consistent intuitive results when patching around the reset feature.

    Also, didn't there use to be a sequencer category in the help section?
    Screen Shot 2017-11-05 at 9.29.03 PM.png
    953 x 644 - 101K
    Revising the reset on the counter module..audulus
  • Recently I’ve tried to design my resets so that if reset is held high during one clock (gate) cycle you get a reset. I’ve found that trying to arrange it so that you can get a reset while the gate is held high often requires adding pulse circuits that seem to cause as many problems as they solve. The timer is an approach I haven’t tried so it’s certainly worth keeping in mind.
  • Yes, this one has been straining my brain. Have been trying to figure this out for my own sequencer. Thanks for sharing!
  • Having no problems with it. I sometimes use this little guy. I'ts based on the classic Count^. The first cycle starts always at 0 - and if you wish you can start the other cycles at 1.

    I've also added basic Signal processing for you: Basic Signal Processing
    So you can choose, which signals are dominant, when they occur at the same time.
    Just look at my stuff.
    Reset Dominant.audulus
    Reset Dominant.PNG
    733 x 307 - 31K
    Basic Signal Processing.audulus
    Basic Signal Processing.PNG
    1312 x 538 - 52K
  • @Experiment1 Thanks for the examples, I enjoy your sequencer designs so I'm glad you are a part of the conversation. The thing about the reset method you employ is that it will sometimes hold on a step rather than reset. I'm not sure why, as you clearly have the fundamental logic there, but I have revised your patch to show you what I am talking about.

    @RileyGuy I'm right there with you, that's why for so long I just gave up on reliable resets.

    @stschoen That is very interesting, I will have to go back and take a closer look at your counter module :)
    Reset Dominant Critique.audulus
  • Hey @RobertSyrett, you're right, I can clearly see what you're describing! The problem is the Sample & Hold: It only revises its value on the rising edge - so I've put a positive edge before it and it works as your default design now. I usually convert a gate signal to an edge signal, when I use it as a clock... that's maybe the reason why it did not occur to me.
    I really don't like to work with timer in sequencers, because everything should have a clear state at anytime, right? ...BUT I'm quite sure that I've used timers somewhere before to solve the problem with the priority of signals. :P

    I would use the SR-flipflops like in this picture:

    Set it somewhere right after the the clock input so that the clock signal won't go through as long as reset is high (oh and reset should also reset your internal S&H memory).
    That way you can prioritize signals ...or make a nice burst generator. ;P
    Did somebody made something like a One Shot rhythm generator? A module like Variatic Erumption from Noise Engineering?
    Reset Dominant Critique revised.audulus
    Burst generator.PNG
    763 x 372 - 54K
  • Very nice. Even though I'm using a timer, it's really being used as a gate interrupt on the input to the S&H (almost the inverse of how you are using the delta node actually) and will only cause a glitch if you are running the counter at audio rates. So don't use the timer method as a sync function your wavetable oscillator.

    There should definitely be more burst generators in Audulus (~-_-)~

    Also, I was looking at your design, it would be possible to jump to any value with your design, no? Just switch out 1 with a variable that can be clamped between 0 and max. Could be useful for all sorts of creative sequencer designs.
  • I'll look at it tomorrow. I'd say you have to edit the term

    I've found that my design without the timer isn't quite stable enough, sometimes on high rates it still glitches and holds. I'll overhaul it eventually...
  • I built a d-type flip-flop with an unconditional set and reset for the original shift register I used in the first version of my Turing machine model. It worked fine, but each flip-flop needed a pulse generator, two S&H nodes, and several expressions. Because of the pulse generator, the flip-flop wouldn’t clock at audio rates. I later replaced it with a simpler design without the pulse generator. I lost the unconditional reset, but gained simplicity and faster, more stable operation. As I’ve gained more experience with Audulus I’ve gotten a bit leery of pulse generating circuits. The timer works well at low frequencies but it does limit the maximum data rate.
  • @stschoen Gotcha, I seem to remember that now. This was the issue where everything looked correct but the due to audulus not having a separate signal path for dsp lead to things seizing up. I must confess as long as the reset input works reliably between 60bpm and 200bpm I am 100% AOK.
  • Here is a demo of how the timer-based counter can be used to loop bits of a 16-step sequence in a not totally random way. The top row of outputs on the sequencer sends a gate when the the step is active (just a copy of the clock signal) and the row of inputs below the knobs reset the sequence to that step.

    The plan is to connect the pulse outs to earlier steps and create a shorter loop, but have that connection active only some of the time to create a recognizable over all pattern that is nonetheless non repeating.

    An accompanying melody is created by adding an sts uTuring machine output to this signal.
    Screen Shot 2017-11-07 at 12.44.10 AM.png
    980 x 427 - 120K
    jump seq 2 voice.audulus
  • @RobertSyrett, I agree, and I've kept the original shift register design for use in situations where high speed operation is less important than an async reset. I've also incorporated your timer-based reset circuit into the counters I'm using for the up-down arpeggiator and intend to retrofit the other models. I doubt anyone will find it necessary to clock the arpeggiator at 10K. (Hmmm, I wonder?)