Started working yesterday on a "small" project.... one mic, multiple performers reading in front of an audience. So I am basically working on a mono audio file which is about 50 minutes long.
 
So, lots of different voices (each having their own tone and dynamics...)I decided to work on this file the following way:
 
1- Inserted an FX chain in that audio file (containing an EQ and a multi-band compressor tweaked to globally improve the audio...)
2- Began splitting that file into multiple clips ( one clip for each performer). Therefore, each of these new "performer" clips also has an instance of the above mentioned FX chain. This to then tweak the clip's FX chain to better suit the performer, based on the original FX chain's settings. (I have NOT bounced the clips to new audio files)
 
I now have about 15 clips with an instance of the original FX chain. Problem is, my CPU meters (in fact, core #1 mainly) is now spiking into the red and I am now hearing artifacts.
 
I thought that clip-based effects were demanding CPU resources only when the clip was "read". It seems not to be presently the case as I have problems no matter what clip I'm playing
 
So, in my case the FX chain seems file-based (and not CLIP based). (in SONAR X1 D prod)
 
Anybody else noted this behaviour? Looks like a bug to me, but my workflow might be wrong here...
 

Hrm, I never thought about it that way, that clip effects would only be "active" when played. I don't think it works that way, as no other effects work that way if there's no data at the Now Time.
 
In your case, just use automation to tweak the effect parameters when needed. then you just use one effect for the track.
 

I believe it's working as intended that splitting a clip with a clip FX (or chain) on it creates a new instance of the FX; it has to because clip FX are by definition independent to allow clip-specific settings. If you want/need to use one instance to conserve CPU, you'll need to put it on the track, and use automation to alter the settings from one clip to the next. Turning off Always Stream Audio Through FX in Preferences may reduce the load, but I don't think so; I think the FX will still be active, waiting for input.
 
Re-reading Michael's post, I see he's pretty much saying the same thing.
 
 

:-)

Thanks for the responses, guys.
 
Indeed, FX automation is a good way to go (and the one I'm using usually), but reading this "old" SOS column written by our friend Anderton made me want to try another workflow.
 
http://www.soundonsound.com/sos/oct07/articles/sonarworkshop_1007.htm
 
I also scanned X1's manual about clip FX. They're mentioned, but only briefly ... and without any comment about CPU ressources...

yummay
Thanks for the responses, guys.
 
Indeed, FX automation is a good way to go (and the one I'm using usually), but reading this "old" SOS column written by our friend Anderton made me want to try another workflow.
 
http://www.soundonsound.com/sos/oct07/articles/sonarworkshop_1007.htm
 
I also scanned X1's manual about clip FX. They're mentioned, but only briefly ... and without any comment about CPU resources...

Well, the problem is that I was wrong. I had tested Samplitude and if you use the effects in its objects, they only draw CPU power while the object is playing. I thought Sonar worked the same way, but I found out long after writing that article that it didn't.
 
VST3 effects can work this way, but only if they're designed to do so. If they are, Sonar X3 will respond appropriately.
 
Sorry 'bout that...

Seems like something for the bakers to fix/implement. I always assumed it worked that way too. Seems kinda dumb it wouldn't (just intuitively from the user's perspective, not hampered by any knowledge of the underlying technology). If Samplitude can do it, why not Sonar?

I would expect the clip's fx to automatically go on bypass once the clip is not being played. Normally this should release resources, right? Apparently something else is going on?

Anderton
 
 
Well, the problem is that I was wrong. I had tested Samplitude and if you use the effects in its objects, they only draw CPU power while the object is playing. I thought Sonar worked the same way, but I found out long after writing that article that it didn't.
 
VST3 effects can work this way, but only if they're designed to do so. If they are, Sonar X3 will respond appropriately.
 
Sorry 'bout that...

 
AAhhhh!   :-) 
 
That explains a lot of things. Ok, thanks for sharing some light on this, Anderton!
 
I wonder how big of a job it would be for the bakers to optimize this? FX automation is a good workflow, but this "alternative" workflow looks definitely promising to me... But hey, I can understand that this would be way down the priority list...  ;-).
 
... wondering what would be Noel's thoughts on this... 

It's not necessarily easy to implement - for example, there have been problems in Samplitude when object-based effects induce a large latency, and there would be issues with reverb/delay extending past the edge of the clip.
 
I could have sworn, though, anyway, that there was some setting in Sonar to make clip based effects process only when necessary - are you sure that it's impossible?

yummay
I wonder how big of a job it would be for the bakers to optimize this? FX automation is a good workflow, but this "alternative" workflow looks definitely promising to me... But hey, I can understand that this would be way down the priority list...  ;-).
 
... wondering what would be Noel's thoughts on this...

 
I'm not Noel, but implementing VST3 does allow for silent buffers that don't use CPU unless the plug-in is active. But as noted above, although Sonar can handle plug-ins that allow for this, the plug-ins have to be designed to do this as well.