Designing patches for CPU efficiency
  • Does anyone have tips to improve the CPU efficiency of your patches. Obviously less visual elements and nodes helps but are there any other tricks, like perhaps two ways to do certain things but one chain of modules is actually more efficient than another.

    One thing I have considered is purchasing the expression node as I can probably reduce my overall elements through that.

    Ken
  • One of the reasons I ask this is I am noticing that every patch I create has a much higher base CPU load than any of the demos or any of the other patches I have downloaded. Even though I would consider the overall complexity to be equivalent as far as just a visual analysis. I figure I must be doing something wrong.

    Ken
  • Ken, have you tried using the Timing Mode upgrade? (In the Audulus store) It will tell you the CPU usage of each node in your patch :)

    cheers
    - Taylor
  • I am seeing that might be what I need to do, but I also think there must be some simple guideline I am missing for better efficiency. Even a single "pedal" patch is taking ridiculous resources compared to other patches I have seen with 10 times the complexity.
  • You can post a patch here and I (and other forum members) could take a look :)
  • I might do that. But I think I am finding a pattern. It looks to be using the pitch shifter module is the problem. That seems to be the consistent node I the equation where there is a performance hit. I am thinking a speed up of a sample and hold might be a better solution...
  • Pitch shift is the problem. On a test I just tried I am finding that a single instance of the pitch shift module, with no actual signal feeding it at the time although it is wired in is taking up 15% of the CPU all it's own additional to the rest of the patch.

    Ken
  • Yup pitch shift is the problem. Which basically means I have to scale back the plan and I don't think a POG clone is doable, at least not in combination with much else. Also it means my octave pedals need to be used as the only pitch shift part of the equation because those two pitch shifters are 30% CPU usage without even processing a single note.

    However everything else is pretty low impact so I just have to route things to be more effective for my goals.

    Ken
  • Yes, the pitch shift is quite heavy. There are some things I can do to speed it up though (using a better FFT function for one).

    Also some sort of multi-shift node would require only one analysis phase (FFT) and then do multiple synthesis phases (IFFT). Or, the existing pitch shift node could be made smarter with respect to polyphony, such that a polyphonic (vector) value for the shift amount but a monophonic audio input would result in only one analysis phase. (you have a technical background, right?)

    cheers
    - Taylor
  • Yes, but some of this is stretching my memory of things long forgotten. I was playing with some ideas of how sample and hold could affect pitch depending how you tie it to an oscillator but that really created something closer to a ring mod effect. If there was a way to take a sample, just a momentary one and then play it twice as fast back to back that would be octave up. Basically like a momentary sample and speed up or down and double or half to vary the new length of the retimed sample. That really does not work though. Part of me though a zero cross varying things might get closer. They are all kind of weird solutions that aren't quite there and me trying to just find other ways to sim the effect.
  • So I have come up with basically three solutions to my particular needs. 2 could be general solutions, the other is just being practical for what I need.

    1. I have this kind of paired oscillator with the pitch modifier multiplier affecting the second oscillator frequency, the first oscillator frequency is a multiple of incoming pitch frequency by my attempt at a sample rate. This is working around a sample and hold circuit. It will reliable shift pitch, but it is coloring the original sound because in effect it has some ring mod behavior. In some ways the second oscillator is functioning as almost a carrier wave and its shape will color the original sound based on the shape chosen. CPU efficiency is good, needs more testing and tweaking to see how musical it might be.

    2. Second solution involves sequencers controlling multiple sample and hold circuits. One sequencer controls the capture of each S&H, the other the play back. The clock of the play back sequence is varied by a the pitch multiplier of the capture sequencer and are a ratio of the detected incoming pitch frequency. This is just theoretical at this stage. I haven't finished wiring it. I need a proper counter to redirect the output of the first sequence to each S&H. The funny thing is as I am doing this I think the first module could be a counter that redirects based on an oscillator frequency and does not need to be a sequencer, so that change might occur. I think this might work as a real cheap single wave length sampler by a snap shot from the S&H at a division of points along a single detected oscillation. The sequencer module would limit me to a "16 bit" resolution which would make an octave down an 8-bit playback though. And this is why I think I can do the capture function with an oscillator based on the resolution multiplier of the incoming pitch and a counter to switch down a row of S&H circuits. If I can sort that out then I could capture the original at 32 bit which I think would be better for octave down pitching.

    3. For my purposes how many damn pitch shifts do I need. I mean yes I am going for a sort of stomp box chain series, but I can wire my setup so there are "pre-sets" within a pedal. I mean as a bass player truly I would only really ever want one pitch shift at a time, ok maybe two for one crazy idea I have. But from my math if the pitch shift adds ~18% cpu usage to my chain and everything else all together comes to ~2-3% then at a 20-40% total base load I should be within limits for me needs. Now granted this doesn't solve the problem of "build a better pitch shifter" but obviously would create far less reinventing the wheel type work with superior audio quality results on the pitch shift to any of my other designs yet.

    So I have lightly tested solution 1, it works, but I need to do more experiments to optimize how musically it works. CPU load is very light. I just have to experiment more on how it compares to the unaffected source.

    Solution 2 will take more work to have a working prototype, and audulus has stolen enough sleep from me in the past 48 hours and I do have a day job. More to come on this.

    Solution 3 I have implemented, sort of, but I hard set to only two presets still thinking in a stomp box way. So I am going to revisit it again, probably in a clone of that patch, as a variable preset setup and see where I go there. Again it does hinder dreams of a POG, but that was a very ambitious recreation to even think of. I mean there is a reason that pedal is so expensive....

    Ken
  • With solution 2, I am basically building an A/D -> D/A converter. The only trick is between the two conversions I am changing the rate that each bit is played back effectively rescaling the digitization of the input. So thinking about that some more, my incoming resolution for doing this to an audio input would not be practical to exceed the actual resolution of the audio interface itself. I think I might be stuck at 16 bit for initial capture. But that could be OK. Again for my purposes then I would only need one of the existing pitch shifters for octave down and let this technique do all upward shifts. What I really need to do this though is not the existing sequencer module, but a sequenced trigger module. Single input of a clock signal in, and each output is used to trigger something in my signal chain. I think I need to go build that first and then reapproach this method instead of using the existing seq16 module. Using the sequence 16 module I still need to find a way to parse the output from it to different S&H circuits based on a counter scenario, so I am doing twice the work by using the seq16 in this scenario than a custom seq-trigger module.

    Ken
  • You know, another way to do this is if the sampler module, which is not yet in the IOS version, allowed both capture and play back. I mean in effect solution 2 above is a momentary single cycle sample of the incoming wave form using the multiple S&H circuits as the bits of the sample. Just another thought.

    Ken
  • And I just realized I am using the word bits instead of thinking of it as a "sample rate" which is what it really is. I need to go do some more math. And get some more sleep........................

    Ken
  • hmmm, I think the Spline module might help me in this...