CPU load optimization
  • What nodes have the heaviest CPU hit? What are some tips for minimizing CPU load?
    (My patch on the iPad 2 maxing at about .65 was breaking up pretty badly. I bought the Mac version just so I could keep building!)
  • The Oscillator is pretty heavy, especially when run polyphonically. Other than that, Reverb is kinda heavy. I think most other nodes are pretty light. You can get an idea of how heavy a node is by creating a few of them and seeing how much the CPU load goes up by (though that won't work in the future after I've added a few more optimizations).

    I think you'll like this: for the next version of Audulus I'm adding a feature that allows you to see the percentage of time spent on each node, so you can optimize your patches. I've also spent time making nodes scale back their computation when some inputs aren't changing.

    For those thinking of getting the Mac version, harnessing the power of your Mac is a great way to build bigger patches ;-).

    - Taylor
  • Are there advantages or disadvantages to packing functional groups of nodes into sub-patches?

    As for the Mac, it's great to have all that power but I find the touch interface on the iPad more fun.
  • In terms of performance, there should be very little overhead for using sub-patches. In the future I'm going to try to get that down to zero overhead.

    Yep, the touch interface is a lot of fun, and as I continue to squeeze more speed out of the Audulus engine, we'll be able to build more complex patches on the iPad. There are limits of course, but I have some ideas to continue speeding things up.

    - Taylor
  • A little analysis shows me that your "Note to Hz" sub-patch is a hungry fellow. And the 4 of them driving my little quartet require a whole lotta juice! (A diabolical plan to get me to buy the Mac version? ; ))
    I guess I will rethink my design. I was trying to avoid the hassle of pre-calculating and programming in a complete set of Hz values. I see the runtime computational wisdom of it now. (Though I can't quite envision how to implement the selectable key function.)

    I'm going to try applying simple Pythagorean ratios to a base Hz value to calculate diatonic frequencies instead.

    It is difficult to communicate to others how much fun I have playing with Audulus.
  • I fiddled with this for weeks, literally pushing the limits of my understanding of math!
    I want to be able to quantize smoothly changing values to hertz to create a note quantizer for my Frankensteinian self playing mega patches.
    Damn! Shoulda stayed in school! Lol
  • @JDRaoul, glad you're having fun!

    Yeah, my "Note to Hz" is basically a hack to get around not having an exponentiation node. Its quite inefficient. In the next release, we'll have the math expression node, which will make that stuff a lot easier and more efficient. I'm putting the finishing touches on it now :-)

    @Dcramer, I think with the expression node it will be relatively easy to implement a note quantizer too.

    - Taylor
  • I'm using the Spline as a table to store values which works well on a small scale. The difficulty arises when trying to assign fine-grained values to the spline node nodes. Is there some way to enter values accurately?
  • More control over the spline would be great.
  • Yup, I managed to make a little note quantizer by using the spline but setting up the values was tough!
  • Still thinking about CPU optimization: I'm seeking a simple way to multiply and/or divide the frequency of a pulse wave. I've found elaborate ways to do it but I feel like there is a simple solution that is eluding me.

    I did a reasonable facsimile of a spline-driven generator for a Pythagorean major scale (using 2 splines) but plugging the values for a chromatic scale into a spline is just too mind-numbingly fiddly.