Ratcheting Sequencer Work in Progress


I just took the brute force approach to get my stuff started on beat one of progression step one.

I have been using a startup timer in which a constant expression (any positive number), representing the delay time feeds a timer and a test expression. When the project initially loads, the timer is triggered by the constant appearing at its input and holds a reset output high until the time is reached*.

For the project startup timer, I used the Frequency output of my tap tempo patch to generate the startup pulse (freq is zero until enough taps have been averaged). The thing works with a 1 sec delay. Hardly elegant.

*(Mine seems like an unstable approach, as I believe it was just dumb luck that the test expression was “alive” before the constant value was “applied.” For all I know this could have gone the other way, unless there’s some “Prime Directive” of Computer Science or of nature that states otherwise.)

2 2 loop polyrhythm tone seq chord apregg v 11.28.18-2.audulus (2.7 MB)

The thing hooked up (at lower left):

Its guts:


Timing issues have always been one of the thornier problems for me in Audulus. Form personal experience I can say that designs that depend on a certain order of execution can be unpredictable. I can recall several instance where adding a light or value node caused the circuit behavior to change significantly, apparently because the underlying execution order changed. There may also be differences in the different platforms or versions of the Audulus app. I’ve always attempted to prevent these by appropriate use of feedback delays and z-1 nodes. Any time two events have to happen “at the same time” you have a potential for problems. It drove me nuts while I was designing my first few sequencers.


That was what was happening with the segmented envelopes as well, wasn’t it?


I think so.