Need Help with Dual Gate Latch Feedback Problem
  • Hi Everyone,

    I realize something like this may already exist in the module library. I guess I just enjoy the puzzle aspect of figuring it out for myself. However, in this case, I'm stumped.

    What I want:

    A module with two gate inputs. The gates are on latches, so when you hit one it stays on until you reset the latch. I want the module to send a 1-frame pulse on the output once both latches have been set on, then I want it to reset both latches to off.

    The attached patch has it working up to the reset. The problem is that it only resets one latch, which ever one received the first gate signal. I feel like I must be missing something obvious.

    help me forum masterminds!

    Screen Shot 2017-07-19 at 9.00.45 PM.png
    1324 x 859 - 211K
  • >I want the module to send a 1-frame pulse

    You might try a longer pulse, like maybe .001 sec. I find that audulus does not always register super-short pulses.
  • "I find that audulus does not always register super-short pulses."

    Yeah it needs to be at least within the sample rate - the 1 frame pulse is a good one for shorties. I'll take a look at this tomorrow!
  • Well your patch definitely works if you slow the pulse waaaay down.
    slowed down help.audulus
    Screen Shot 2017-07-19 at 7.49.28 PM.png
    1137 x 989 - 223K
  • yeah ... I managed to get something similar to work using a timer like that. I'm REALLY trying to avoid math expression nodes because they just suck CPU like crazy. Seems that there ought to be a way of doing it without that?
  • Expression node sucks up the CPU?!? But that's like... my favorite one!

    Edit: I found that the trigger needs to be delayed about .1 sec, but the trigger itself can be much shorter in length. Around .001 length and the patch properly resets ~50% of the time.
  • @plurgid @RobertSyrett - there are some improvements to the expression node that Taylor has yet to implement, but when they do VariableA*VariableB will be as efficient as the Mult node, and many other expressions will become more efficient as well. But for now if you can do it with simple methods like these you can shave off bits of CPU, yes.
  • You've been fighting the same issue I've been dealing with regarding feedback loops so I built a little delayed pulse unit to test your patch and found that pulse widths as narrow as .0001 seemed to work reliably but that the pulse needed to be delayed by about 0.2 to work reliably on my mac. @biminiroad that's some interesting information on the expression node. I had been using it in preference to the multiply and add node not realizing there was a difference in CPU load. I'll keep that in mind.
    help modified.audulus
    Screen Shot 2017-07-20 at 2.33.13 PM.png
    1456 x 779 - 154K
  • Well I mean it's not like it's outrageous CPU utilization or anything, it just adds up damn quick, when you're using the expression node for literally everything ... which I am for real guilty of because it's darn handy.

    So ... back to my question ... the problem is entirely the pulse width of the gate?
  • It would seem so, although the degree of minimum latency seems to be dependant on your computer. Reasons remain mysterious.
  • There you go. no timers or something special. Yes, I used expressions, but you can recreate these reset-dominant flipflops with 2 NAND gates. I didn't know that expressions draw more cpus. Me like expressions. I use them a lot in my Metropolis-emulation to rock my eurorack.
    Hope this helps (and I've understanded you correctly, bc I did not dl the above examples).


    Edit: Whoops, I've made that trigger on the falling slope of the two gates... sorry :/
    Double Gate Reset.audulus
    2732 x 2048 - 289K
  • now the other way round, but both pulse and flip flop from library use much cpu%...
    Double Gate Reset 2.audulus
    2732 x 2048 - 265K
  • @experiment1 Your patch runs at 1% on my computer. I'd say that was pretty good. Seems like a minimal number of expression modules is still more efficient thank myriad add and mult nodes as there is less latency.
  • My CPU usage with this patch is at 0%. This is a very clever approach, I think I might be able to use something similar myself. I've been struggling with several feedback loop related problems recently. BTW since we're talking about CPU usage, what about all the simulated LEDs. It would be interesting to know if they introduce any additional CPU load, particularly when they are included in a sub-patch and not actually on screen. They're great for troubleshooting, but I often remove them when a module is done if they don't serve a useful purpose. Maybe I'm wasting my time.
  • Weird... as you can see in the bottom right, my ipad pro cpu load differs as described. I did not test them both on my W10 machine.
    Actually my first move (I'm still the new kid from the block) was generating all kinds of flip flops for my sequencer. Self holding signals, special signals on edges etc.
    Nevertheless it seems for me, that some signals are faster then others. But tbh I'm not totally done with my design review and debugging, so it's only a vague assumption on my side.

    @stschoen Optimizing is always good and I also move my LEDs along the signalway until I'm done reviewing. ;)

  • I checked on my iPad Air 2 and on that hardware your patch is running between 3 and 4%. I believe you are correct regarding the propagation time for various signals. Given that Audulus is a multithreaded program running on a multi-core cpu with all kinds of other background processes occurring, I suspect some timing variation is inevitable. Sometimes avoiding deadlocks is more critical than enforcing rigid lockstep execution. That being said, I have encountered some peculiar timing issues myself, which probably would not have occurred with real hardware. I would love to see your flip-flop collection, I also tend to build from scratch, but there's no point in re-inventing the wheel. Audulus has an excellent user community with some very talented people and I have learned quite a bit about digital synthesis since joining. If you haven't done so already, @biminiroad just updated the patch repository which is definitely worth downloading.
  • Just FYI I haven't updated it yet - I'm still organizing the patches, but will upload it tonight! Probably will take another hour...
  • Thanks for the update, I know it's a lot of work.
  • @Experiment1, thanks!
    I particularly like your 'pulse if changed' module, that's a really neat use of the sample and hold.

    However, again ... like with the timer approach, I've been down this road, and I can get a working implementation using it, but the CPU drag on the expression node is a problem. This solution uses 4 expression nodes.

    This one module uses 3% CPU ... it has to coexist inside a patch with other modules that also need CPU, if I have only 5 of these modules buried in a patch, I'm forfeiting 15% CPU right there, I just adds up so darn quick!

    If I had to venture a guess, I'd say what's happening here is that expression nodes need to be parsed in real time (like a scripting language such as JavaScript), where the add, multiply, etc nodes are 'compiled' if you will ... meaning nothing has to first determine what kind of operation to perform.

    the expression node is also the only way to express if/then logic in Audulus, and I think that's why I keep running into this wall. I keep having to use the expression node for two big things that don't necessarily need the full on horsepower of the expression module:

    1) evaluating comparisons ... ==. !=, > <

    2) switching (i.e. ... (expr)?(expr):(expr)

    Those two things are what keep me throwing expression modules into my patches. If we had just a discrete comparison module that takes two inputs and spits out a 1 or a 0, I believe that might actually solve the CPU problem, in that you wouldn't necessarily need the expression node unless you wanted to do some actual mathematical expressing ...

    Just a humble suggestion :-)
  • I would agree with @plurgid. I also wondered if the expression node was parsed in real time, and if that was the reason for the CPU drag. I find it impossible to avoid comparisons and switching and I see no other way to accomplish these functions.
  • Actually, now that I think of it, the cross fader will do very efficient a/b switching already. Really the only missing piece is a comparison node. If we had that, I could reduce my dependence on the expression node, probably 80%
  • I think as a user experience, the expression node is so much easier to get a handle on than the use of a bunch of crossfade nodes as a logic modules. Personally I hope that the aforementioned cpu optimization of the expression node will preserve the immediacy of the expression node as typing out a function will always be easier to create than a bunch of component nodes.
  • guys, I figured out a hack!

    The key was realizing that I did not actually need to send a new gate signal (the 1-frame pulse), so much as I needed to *pass the gate signal that resets the other latch*. This simplified things immensely. The attached uses no expressions and clocks in at less than 1% cpu!

    2048 x 1536 - 195K
    eureka and gate.audulus
  • I like the Ron Burgandy quote :)
  • I compared 160 instances of your solution and the one with the expressions (see attachment). basically the same cpu % (I'd say 1-2 % in favor for your solution). the expressions cleary help you to understand the signal flow... that's why i think I continue to use them. And when expression notes get an update to optimize them, they're clearly superior then, because they can shorten your program so much.

    PS: If you would implement a "reset in" in your solution to reset both stored signals, you can use them for more applications.
    double gate.audulus
    2732 x 2048 - 184K
  • What platform are you using Audulus on, Experiment1?
    I've noticed that the expression node soaks more CPU on my iPad Air 2 than on my Mac Pro. Maybe that's a CPU optimization?

    160 instances of either would be pretty brutal on my iPad for sure.
  • @plurgid - that would make sense because your iPad Air 2 probably doesn't have as much CPU time as your Mac Pro does. The time % is a measure of what percentage of the total possible CPU cycles are being used by Audulus - the faster the hardware, the less % any given node will use on that CPU. Or did I misunderstand you?
  • @plurgid I've tested it on an ipad pro V1.
    It's usually my bottleneck (at least it seems so), although my W10 PC only has a i5-4200u. I don't run Audulus on my xeon platform. I want to use Audulus as a very flexible (and easy!) solution for sound designing / performing.

    Some things I've also noticed:
    It seems like grouping stuff needs more cpu % (maybe because it's adding more I/Os?). I've also made a version without expressions (only with [mult+crossfade] = NANDs {you can build everything logic with NANDs!}) and it uses far less - around 1/5th... IF I don't connect an output. If I do... it seems to be the same as above solutions.