1-Frame Delay and 1-Frame Pulse
  • While working on my patches I seem to always need these a lot, but I couldn't figure out a way to make them until now. These are going to make life a lot easier for me. Hopefully someone else can use them as well.

    The 1-Frame Delay file has a demonstration showing that there's a single frame difference between when the button is pressed and when it passes through the unit.

    The 1-Frame Pulse file has a demonstration showing that it only activates for a single frame.
    1-Frame Delay.audulus
    1-Frame Pulse.audulus
    2048 x 1536 - 175K
    2048 x 1536 - 230K
  • Thanks a lot, I see this being very useful.
  • Very nice. I've taken the liberty of optimizing your design. While this appears different, it is actually identical. I just simplified the arithmetic.
    1 frame pulse optimized.audulus
    2048 x 1536 - 249K
  • Alexander, you're always coming up with stuff that I've desperately wanted for a long time. Thank you!
  • I might be wrong but isn't this what unit delay is supposed to do? But it's kind of buggy right now?
  • @JDRaoul - Thank you, that looks so much cleaner!

    @biminiroad & @SansNom - No problem. : )

    @drewyeah - Yes, in fact I had been using a delay node in place of this up until now. The difference is that my module will always delay the incoming signal exactly one frame since the design is future-proof. The delay node requires you to calculate the time required for one frame to pass, but if Audulus's inner-workings are ever changed then that calculation could become incorrect. My unit exploits the Feedback Delay node to guarantee that it will always be a single frame.
  • @alexander - thanks for the response! I'm sorry if I'm not getting it. Is there a difference between one frame and one sample? Is that why the Unit Delay node requires you to do a calculation? I thought you just feed it a signal and delays the output by 1 sample. Thanks for your patience man!
  • @drewyeah - It's cool. : ) I actually did not notice that the Unit Delay node existed until you mentioned it just now! I'm going to check to see if there's any difference between the two. One sample should be the same as one frame.

    *edit* I checked and they are not the same thing. I'm actually not entirely sure how the Unit Delay even works, to be honest.
  • @Alexander - it's because the Unit Delay node doesn't work, Taylor is fixing it as we speak ;p.

    Not sure about the difference too... Since this is cpu friendly and the unit delay node isn't I'm intrigued.
  • @Alexander - so I did some testing too. From the counter it seems like "1 frame" is calculated 345 times a second, so its not sample based which is 44100 time a second. It seems like maybe Audulus does its calculations in blocks of 128 samples. For instance you couldn't use this to make a filter, but its great for ordering calculations. All of this has been very informative. Thanks for posting this!
  • @drewyeah - thanks for the tests and explanations.
  • Out of interest where do you find a need for something like this? The only use I ever found for the unit delay was in designing filters. Interested to see how else it could be applied
  • Yes filters or patches where unit delay feedback is needed (for example the phaser I'm working on, I'm stuck because of the unit delay node not working).
  • @SansNom - yeah I'm in the same boat with a state variable filter I'm working on.

    @afta8 - FFT maybe?
  • @drewyeah + @afta8 - I built an FFT unit in Audulus for my Spectral Panning Filter. It's basically just sorting and algebra and doesn't require any feedback stuff, fortunately. I have attached an image of the inside of the unit. The highlighted region is the FFT logic.

    2048 x 1536 - 553K
  • @Alexander - thats awesome! I'm downloading it now.
  • @Alexander that looks intriguing.. judging also by your Pong and Mandlebrot patches, you certainly got some skills :)

    Would love to see that Spectral Panning filter one day, FFT stuff is currently way over my head so always useful to learn from examples
  • I found this thread because I was trying to understand the FeedbackDelay node, and what exactly is going on when you get a 'z' on an input of a node or patch. Can someone explain this to me? The "Sub-Patches 1-Frame Delay and 1-Frame Pulse" looks like something useful, but I have no idea what it does or what I should be feeding to its input or what the meaning of its output is. For that matter, I don't understand the input and output of the FeedbackDelay node. Can someone give me an example of where it's useful?
  • @WeirdoLoudypants I think it was MacroMachines that explained in another post how to build a LPF with UnitDelay. This is probably the most visual way to understand what it is anywhere in the web.

    Audulus signals have a 44100 clock. Every 1/44100th of a second, the signal gets a chance to change. 1/44k is such a short time, that Audulus tends to calculate things in chunks, like 124/44k.

    Like when walking, you move at maybe 2 feet per step. If you moved at 1 inch per step it'd be very slow. But moving at 1 inch steps is what the Unit Delay does, remembering the past smallest possible step, 1/44k of a second later.

    The Feedback delay kind of remembers the last step, so at any step, you have information about your current step and the past step. Why you need this? To design echos, reverbs, etc.

    Every instrument in real life is a delay fest. The strings interact with other strings, with the bridge, with the body of the instrument, with any air cavity (guitar, violin, bells, etc). As time takes time to travel, all these interactions mean that every single acoustic instrument you hear is an ensemble gigantic army of delays. If you then consider your room and environment, it's another huge factory of delayed signals.

    Audulus has ready made modules for Most common uses, but you also have FeedbackDelay and UnitDelay nodes, the building blocks of anything that needs the past signals interact with the new ones.

    The "z" tell you at which "tollgate" Audulus is remembering something. If you see a "z", you are using those nodes, or creating a feedback loop. but if the loop does not include a Delay, the present is interacting with the present, which creates a new present that is again another new present, and so...infinitely, a circular reference of sorts. So when you want a signal to interact with itself, you almost always want the interaction happen with it's past (a Chuck of it's past, or just the tiniest closest past- 1 Unit).

    With "z" you can recognize unwanted feedback loops, or if intended, you can now identify exactly at in what part of the signal flow the delay happens.
  • @alexander, how hard would it be for you to generalize your FFT parts into a module. For example you could do like Jasuto (look for Spectral / FFT)


    This would mean separate into two modules: FFT divides signal into many signals, and iFFT does the inverse. Or maybe someone else can take the FTT logic in the Spectral patch and do it? I am at a loss, but FFT seems interesting if you want to adjust the spectrum of a signal, for example, try to approximate the resonance of a body. Or selectively delay part of it, etc.

  • I've been reading a bit about the DFT and it's obviously extremely powerful in terms of things that can be achieved it also comes with huge challenges. The most important one is that once you have a transform like this, you want to expose arrays (in the frequency domain), you probably want to offer loops in math (at least a "for" iterator) and variables (ideally).And before trying to do anything in the frequency domain, one would likely first need samples (which are in the time domain, which aren't yet available).

    It's just as powerful as it is complicated to make simple, let alone the fact that exactly what is offered by any FTT functionality, has the same trade off.

    I think that a sampler node if really powerful (how to make it record, pause, play, and how to access or process it as an array in a math module) and if math module where to have an iterator, then a lot of different thinks could be built from scratch. But I can imagine how to do it in the Audulus philosophy wouldn't be trivial.
  • We are working on it :p. I pester taylor for the data node on a weekly basis. I genuine,y believe with expression, data (array with read and write controls) and knob you could make just about any effect or synth.

    Also I made a bunch of "data" module abstractions from the delay. I basically canceled out the read increment by using a phasor to drive it's time knob in exact opposition to the inherent per sample read head increment. This results in nothing coming out of the delay line, which is good, because then you add an offset and fract wrap expression to end up with the ability to manually index through the delays memory buffer. I have a huge collection of granular samplers and such that I have made around this, and you will all have access to them very soon. I did post one on here.
  • Here is one of rhem
    2732 x 2048 - 766K
  • seems very clever and exciting. Hope I'll be able to understand it, but it seems you turned delay into a kind of buffer from what I read, and while you can't address by index, it iterates. Will have to wait, see and try to figure how you do this rec, play, seems very interesting due to the possibilities.

    One of the things I like most about Audulus is the "first principles", and things like filters and almost everything, you can see how they are done from scratch. A visual programming of sorts that is very educational
  • Yeah you can address it by index
  • I am now worried my ability to understand patches is now much lower than your (and bimini's) ability to design cool new ones.
  • @ffterreres I've been patching for about 16 years, it takes some time to get a deep understanding of this stuff, but that's not important at all, what is important is just enjoying what you are doing and not worrying about understanding everything right away, the mystery is part of the fun!
  • Great advise, and humbled/fortunate to be here watching these patches and zooming on your work. Thanks!