More DiLithium Crystals (Or Maybe More Efficiency) AUM @ 80+%

Vmusic

Hi,
So….my AUM Session is around or just over 80% (Houston we may have a problem). See below

I am trying to get some recommendations on efficiency here……because….yeah, there’s more fx to be had, more colors on the palette, more gravy on the taters…..oh well, you get the idea.

I listed below each channel and it’s purpose in my session. I have a screen snapshot as well. In general my session does two things
1) Violin - Natural sound for lead, I have harmonizer for chords, I have some ‘out there’ fx as well
2) Synth - I generate a ambient string pad sound and play the violin on top of that

Any IDEAS would be greatly appreciated

See the actual session screen snapshot below. This is my music flow thoughts.

Violin Fx
Synth Pad

Violin Fx
* Channel A (create a natural sound; used for natural violin lead)
* to forge the natural violin sound ::
*) FabFilter Pro C (Compressor) to even out the volume
*) Thafknar - Violin IR - takes out the peizo quack from acoustic pickups
*) Send Bus A - takes the natural violin sound and sends to other channels
* still in Channel A under the above ::
*) 4 Pockets Harmonizer (not thrilled with it)
*) AltiSpace 2 Reverb (love it)
*) FabFilter Reverb (beautiful)
*) Send to Bus B (for Recording in AUM)

• Channel B (for playing chords on the violin) - input from Bus A

  • Eventide Vox (4 voice harmonizer)
  • Eventide Chorus (rarely used-not sure it adds much)
  • AltiSpace 2 Reverb (love it)
  • FabFilter Reverb (beautiful)
  • Send to Bus B (for Recording in AUM)

• Channel C (test harness for other/new fx on the violin) - input from Bus A

  • Filterstation - Envelope filter as a Wah-Wah
  • FabFilter ProQ (not used much - sometimes various Fx change the EQ, this is for correction)

• Channel D (for looping violin) - input from Bus A

  • Enso Looper (I used it, but it’s not all it’s cracked up to be)
  • Send to Bus B (for Recording in AUM)

• Channel E (for recording in AUM) - input from Bus B
  no fx here….. this is record in AUM anything from any other channels

Synth Pad :: feed from the Violin Channel, turn it to MIDI, send it 4 synth channels
* Channel F ::: Used to receive and convert audio to MIDI
* FabFilter Gate - to avoid unwanted notes being converted to MIDI
* A2M to turn Audio into MIDI
there no bus send here - the MIDI routing from A2M sends the MIDI to Mozaic

• Channel G ::: Mozaic

  • Mozaic Script -
    * Turns a single MIDI note into a chord 1,3,5,8, maj 7
    * Also uses LFOs to oscillate the volume for notes 3 and 5
    • MIDI Monitor - a utility to see what MIDI messages are being sent (more for debug)
      NOTE: In order to use LFOs to oscillate the volume of certain notes in the chord; I had to use SEPARATE instances and/or separate channels of the Synth(s) playing the 1,3, 5, 8 and maj7 chord

• Channel H ::: 1st of 4 Synth Channels

  • Synth (right now Moog Model 15)
    this plays notes 1 and 8 of the chord
  • Send to Bus C (master volume control for the synth pad chord as a whole)

• Channel I ::: 2nd of 4 Synth Channels

  • Synth (right now Moog Model 15)
    this plays note 3 of the chord
  • Send to Bus C (master volume control for the synth pad chord as a whole)

• Channel J ::: 3rd of 4 Synth Channels

  • Synth (right now Moog Model 15)
    this plays note 5 of the chord
  • Send to Bus C (master volume control for the synth pad chord as a whole)

• Channel K ::: 4th of 4 Synth Channels

  • Synth (right now Moog Model 15)
    this plays note 7 (maj 7th) of the chord
  • Send to Bus C (master volume control for the synth pad chord as a whole)

• Channel L ::: Master Volume Control for the entire Synth/String Pad
  There are no fx on here right now; it takes the sound from all 4 synths (Bus C) and acts as a master volume control for the overall synth or string pad

espiegel123

What are your buffer settings?

AltiSpace and the Moogs are CPU hungry. There are good sounding algorithmic reverbs that are lighter on the processor. There are less CPU hungry synths that sound good also.

Try increasing your buffer size to 512 or 1024

AlmostAnonymous

That isn't a very accurate cpu meter. It displays the highest cpu over a section of time, so it might have hit 82% for a brief second because of some background task.

I generally have no problem on older iPads pegging that meter and not getting clipping or dropout.

Pay no mind to the meter, just use your ears. When you get clipping or drops, then work on making your project more efficient.
(Personally I wish I could just hide the meter altogether, but I've gotten good at ignoring it)

Edit: to what espiegle123 states, he is correct. Increasing the buffer will help a lot. I generally still run 256 tho

j_liljedahl

@AlmostAnonymous said:
That isn't a very accurate cpu meter. It displays the highest cpu over a section of time, so it might have hit 82% for a brief second because of some background task.

Yes, highest cpu time usage of the last N buffer cycles, because one buffer overrun is enough to create a glitch. Showing the average would show lower values, and be even more useless

I think the biggest reason it's not so useful is because of iOS cpu frequency scaling. CPU speed is adjusted on demand, so the meter only tells you the percentage of available time slice at the current speed.

Some background task should normally not eat cpu time from the audio thread though.

I generally have no problem on older iPads pegging that meter and not getting clipping or dropout.

Pay no mind to the meter, just use your ears. When you get clipping or drops, then work on making your project more efficient.
(Personally I wish I could just hide the meter altogether, but I've gotten good at ignoring it)

Maybe I should add an option to not show any numbers, just a visual small bar graph, to avoid users caring too much about dsp percentage. Also it would be nice to see dsp % for individual nodes/plugins. That would give a meaningful number when comparing plugins.

jolico

@j_liljedahl said:

@AlmostAnonymous said:
That isn't a very accurate cpu meter. It displays the highest cpu over a section of time, so it might have hit 82% for a brief second because of some background task.

Yes, highest cpu time usage of the last N buffer cycles, because one buffer overrun is enough to create a glitch. Showing the average would show lower values, and be even more useless

I think the biggest reason it's not so useful is because of iOS cpu frequency scaling. CPU speed is adjusted on demand, so the meter only tells you the percentage of available time slice at the current speed.

Some background task should normally not eat cpu time from the audio thread though.

I generally have no problem on older iPads pegging that meter and not getting clipping or dropout.

Pay no mind to the meter, just use your ears. When you get clipping or drops, then work on making your project more efficient.
(Personally I wish I could just hide the meter altogether, but I've gotten good at ignoring it)

Maybe I should add an option to not show any numbers, just a visual small bar graph, to avoid users caring too much about dsp percentage. Also it would be nice to see dsp % for individual nodes/plugins. That would give a meaningful number when comparing plugins.

Dsp% per node would be awesome.
As long as displaying these doesn’t eat significant dsp.

jacou

@espiegel123 said:
What are your buffer settings?

AltiSpace and the Moogs are CPU hungry. There are good sounding algorithmic reverbs that are lighter on the processor. There are less CPU hungry synths that sound good also.

Try increasing your buffer size to 512 or 1024

Same goes for Fabfilter Pro-R. I can recommend using Audio Damage Eos 2 instead of Altispace and Pro-R. That should make quite a difference.
Audio Damage plugins in my experience are very cpu efficient.

uncledave

Just a couple more suggestions:

• Are you actually using two reverbs in series? Can't you get the desired result from one? My choice would be Virsyn's AudioVerb.
• The conventional way to economize on reverb is to put it on a Send bus. The individual send levels determine the amount of reverb for that channel, and the bus level fader sets the overall reverb level. You set the reverb app mix to fully wet in this case.
• DRC and Zeeon are a couple of subtractive synths that might replace Model 15.
• You should be aware that bypassed modules (pulled left in your pic) still use CPU. They're still running, but their output goes nowhere.

AlmostAnonymous

@j_liljedahl said:
Maybe I should add an option to not show any numbers, just a visual small bar graph, to avoid users caring too much about dsp percentage. Also it would be nice to see dsp % for individual nodes/plugins. That would give a meaningful number when comparing plugins.

being able to see a cpu on a node would be far more useful. comparing plugins, or just even knowing if you need to bounce that channel down to a stem and bring it into the file player to free up some resources. bonus points if you can just toggle it on when needed and off when you don't.

love that you still think of improvements after all these years when you could have easily called it a done project and just kept up with OS bug fixes and such. many thank yous!

krassmann

Try to replace Model D with Viking. The UI looks ugly but the synth is so similar to a Minimoog that it is easy to replicate Model D patches. Of course it sounds different but you can get very close. It is very CPU friendly. Otherwise sample it. AudioLayer has quite decent modulation, filters and envelopes so you can still have a lot of expression. AL also comes with an auto sampler.

uncledave

@krassmann said:
Try to replace Model D with Viking. The UI looks ugly but the synth is so similar to a Minimoog that it is easy to replicate Model D patches. Of course it sounds different but you can get very close. It is very CPU friendly. Otherwise sample it. AudioLayer has quite decent modulation, filters and envelopes so you can still have a lot of expression. AL also comes with an auto sampler.

I agree about Viking, though it's mono while the current Model D app is 4-voice. But the OP is using Model 15, not Model D. Viking might be a good alternative, if he can get the effect he wants.

Carnbot

@j_liljedahl said:

@AlmostAnonymous said:
That isn't a very accurate cpu meter. It displays the highest cpu over a section of time, so it might have hit 82% for a brief second because of some background task.

Yes, highest cpu time usage of the last N buffer cycles, because one buffer overrun is enough to create a glitch. Showing the average would show lower values, and be even more useless

I think the biggest reason it's not so useful is because of iOS cpu frequency scaling. CPU speed is adjusted on demand, so the meter only tells you the percentage of available time slice at the current speed.

Some background task should normally not eat cpu time from the audio thread though.

I generally have no problem on older iPads pegging that meter and not getting clipping or dropout.

Pay no mind to the meter, just use your ears. When you get clipping or drops, then work on making your project more efficient.
(Personally I wish I could just hide the meter altogether, but I've gotten good at ignoring it)

Maybe I should add an option to not show any numbers, just a visual small bar graph, to avoid users caring too much about dsp percentage. Also it would be nice to see dsp % for individual nodes/plugins. That would give a meaningful number when comparing plugins.

Yes this would be really useful for individual plugins
I'm always pushing the DSP to the max and so it would be really handy to see which are the most taxing plugins in the session.

Vmusic

HI Everyone,
Thank you; Thank you; Thank you;
This is REALLY a GREAT forum!

Some great ideas too (toggling a channel on/off - to save CPU)

There’s no glitching sounds….. so I’m not pressed to fix things, but I will try a few of these and let you know.

AlmostAnonymous

@Vmusic said:
This is REALLY a GREAT forum!

This is everyone elses doing. Not mine.