I usually record a piece and then use ‘convert to region in place’ to create beats to cut & paste. Some tracks are littered with these region pastes and I’ve notice I can expand each pasted region to be the full original. It struck me that this probably takes loads of resources. The whole system’s creaking.
Is my editing process at fault?
I’ve got 10 tracks on the project, a sprinkling of pre plug-ins and a bit of post eq.
@ Benjamin & hogiewan: My latency settings on jack were default. I’ve set it to 1024 and it brought the DSP down to below 10%. There were options for jack latency on both the input and output side - what’s the difference & relevance wrt working with Ardour?
Just going back to peder’s point about no docs being available on plug-in CPU use, I’ve been hunting around and found a really useful page on exactly this. It relates to SWH’s plug-ins only, but since a whole bunch of his plugins come recommended on the Plugins page here, it’s a good start:
I’d guess broadly speaking, plugins with similar purposes from other developers will deliver similar CPU usages.
Here’s the data sheets for the *CAPS plug-ins (NB it’s a PDF) http://quitte.de/dsp/caps-0.4.2.pdf
I’ve now completely solved my sluggish PC problems. So if you’re lacking CPU power, definitely learn to use buses & sends first. If there are still issues, check the DSP rates your plugins are clocking up - look at SWH’s guide to identify likely culprits.
Can’t help you here pal, but I guess anyone who can would want to know what kind of machine you’re running;
a 1GHz Pentium 3 with 128MB RAM or a Core2Duo with 8GB RAM?
Also: what’s grinding to a halt? DSP power, hard drive speed or something else?
You can check out how much DSP is used in the top right corner of Ardour. I guess the figure should be below 70-80%, otherwise you have to reduce the plugins, perhaps by putting some effects on a bus and route the tracks to that instead of having them on each separate ones.
Ah, of course. The machine has 3GB of RAM running a 2Ghz AMD Athlon.
DSP at 80.4% and buffers are showing both “p” & “c” at 100%.
The whole system becomes sluggish; I don’t hear the HD swapping madly.
Yes, I’d read about buses - but can this be happening with just 10 tracks & 26 pre plug ins & 3 post plug ins between them?
I’d try removing some plugins and see if the load drops, perhaps you can switch from, say, one reverb to another one that is less CPU hungry.
See my reply in this thread (http://ardour.org/node/2371) as well
Wow - I deactivated the lot and things are swimming happily - DSP @ 10%. Thanks for the insight, peder.
I now want to track down the culprits. I’m generally using the TAP and C* delays, reverbs preamps and eq’s.
Is there any documentation on how CPU hungry individual plugins are? Anyway to tell other than trial & error?
No particular docs I’m aware of.
I’d generally stay away from the TAP plugins. They haven’t been updated since 2004 and are known to have some problems.
You have seen this (http://ardour.org/plugins) ?
Excellent link - thx for that
It’s also on the top right tab of this site 
If you have two or more tracks with the same plugin and nearly the same settings, you should set it up on a bus and control the wet/dry mix via sends. This also gives a lot more control.
Can I vary the wet/dry across different tracks or does the bus have to send the same parameters for every track using it?
Hi,
you’ve got plenty enough ram, but a single core 2 GHz CPU is a bit slow. I had the same AMD and updated to the Phenom X4 2.5 GHz, it’s very good 
But what I wanted suggest: Have you tried to increase the frames of jackd? If you set it too low (low latency), you will run out of DSP power very soon. You probably don’t need low latency when mixing, so try to set it higher (maybe 1024) if you have a low setting and have a look if it works better.
Benjamin
have the plugin on the bus output NO dry signal. The dry will be your track volume, the wet will be the amount you send to the bus.
What I really like about this setup is that you can pan the dry signal left, but send to the right so the effect is on the right side
also, benjamin makes a good point. Use low latency settings for tracking, and raise it for mixing so that you can use more effects without hitting a wall
Exactly what hogiewan said.
We are getting very wasteful with processing power, because we can get away with it
If you have ever worked on an analog desk before you will know how it works. Effects are placed on a bus, and applied with 100% wet. The sends from the channel to the effect will control the level of the effect.
I recently worked on an intense 26ch multitrack mix, and I put my busses to use. I had enough power to run a session of jamin on top of all my applied effects so I could do a “master” right after completing the mix, and check back and alter the mix on the fly.
I still had enough power left to read my emails and check my forums while the track rendered - faultlessly, and I am only running an Athlon X2 3800+
It can be done…
Some great tips on managing processing power; in fact on developing a decent process.
Thank you to all
Fully agree with qharley - I’m very much into elegant use of computing resources; it’s a major reasons why I switched to Linux.
Haven’t even noticed those before…
From looking at the qjackctl tooltip, I guess those are settings to compensate for external devices with a known latency and have nothing to do with the internal jack latency.
The way to increase the internal latency is by selecting a higher frames/period (though I imagine raising the in/output latency might achieve a similar effect)
From what I understand the magic jack latency formulae is :
“periods per buffer” * “frames per period” * 1000 / “sample frequency”.
Ardour, however, calculates it as “frames per period” * 1000 / “sample frequency”. Dunno why.