just experienced this and don't know what to think of it:
played with clipeffects on an 8 bar guitarclip.
had three clipeffects on it going, 1) stepvolume , 2) a simple delay plugin, 3) a reverb.
nothing special or cpu demanding going on, but then i noticed that it took 50% of cpu (taskmanager) from my core2duo 3 ghz processor (i am on win8 32bit).
and this is always!, regardless of play or stop state (the option "audio engine running in background" is switched off).
i had to flatten that clip to stop the waste of cpu.
it seems something is going wrong there. these effects should have taken a few percent.
also clipeffects seem to render all the time, as every change in effects dropout the sound, while updating the layer. so it's even more weird.
any input?
on a sidenote: these dropouts when adjusting clipeffects are a big showstopper for me. why is this necessary? can't this be in realtime, all the time? or is it only meant for short clips, that update fast?
T7 Bug?: Unusual Cpu Hit with Clipeffects
-
- KVRist
- 473 posts since 1 Feb, 2006
-
- KVRAF
- 1790 posts since 30 Dec, 2012
The CPU usage is odd, you should only see a spike whilst actually rendering the effects (which is usually very quick for small clips like this).
Plugins are even unloaded from memory when you close the editor (Hide Effects) to free up system resources.
Clip Effects are definitely not in real time, they work by rendering each layer in sequence which is how they build up the effect chain. The dropout should only be short as the new file is rendered. We might be able to make this dropout even shorter in a future update.
The easiest way to think of clip effects is having the source file open in another application and making edits to it, saving by rendering the edits. Once the render has finished and the file has been saved it will play back the new file.
If we did this in real time it would consume a lot of system resources and we wouldn't work with the time-stretching (e.g. auto-tempo) features of Tracktion. We also couldn't show you the waveforms of the rendered files which are extremely useful.
Plugins are even unloaded from memory when you close the editor (Hide Effects) to free up system resources.
Clip Effects are definitely not in real time, they work by rendering each layer in sequence which is how they build up the effect chain. The dropout should only be short as the new file is rendered. We might be able to make this dropout even shorter in a future update.
The easiest way to think of clip effects is having the source file open in another application and making edits to it, saving by rendering the edits. Once the render has finished and the file has been saved it will play back the new file.
If we did this in real time it would consume a lot of system resources and we wouldn't work with the time-stretching (e.g. auto-tempo) features of Tracktion. We also couldn't show you the waveforms of the rendered files which are extremely useful.
-
- KVRist
- Topic Starter
- 473 posts since 1 Feb, 2006
thanks for the answer!
i understand the advantages of the rendering approach and yes, the waveforms are very helpful in many regards.
maybe you could get rid of the dropouts by playing the non-updated file until the render is finished? it is quite distracting, if you finetune effects and the audio drops out all the time you changed a parameter a little.
i tried to replicate the cpu-thing i explained above, but i was not able to. seemed to be a random occurrence.
if it happens again, i'll let you know.
one question: will we ever see clipeffects audioprocessing extend over the border of a clip (reverb, delays).
i guess you can imagine the benefits of this easily. shouldn't it be easily possible with the renderapproach now?
i am hoping for this
regards, mathias
i understand the advantages of the rendering approach and yes, the waveforms are very helpful in many regards.
maybe you could get rid of the dropouts by playing the non-updated file until the render is finished? it is quite distracting, if you finetune effects and the audio drops out all the time you changed a parameter a little.
i tried to replicate the cpu-thing i explained above, but i was not able to. seemed to be a random occurrence.
if it happens again, i'll let you know.
one question: will we ever see clipeffects audioprocessing extend over the border of a clip (reverb, delays).
i guess you can imagine the benefits of this easily. shouldn't it be easily possible with the renderapproach now?
i am hoping for this
regards, mathias
-
- KVRAF
- 1790 posts since 30 Dec, 2012
No, it's not possible to extend clip effects beyond the border of a clip, that doesn't fit with the "render as source file" paradigm. It's kind of like asking an audio file to continue playing after the end of the file. What would happen if you're looping a clip with Clip Effects on? How would the tail affect the next loop iteration?
We might be able to add effects that are just added to clips (as you've always been able to) extend past the clip boundary but it's not a trivial change so can't give any promises on timeline.
We might be able to add effects that are just added to clips (as you've always been able to) extend past the clip boundary but it's not a trivial change so can't give any promises on timeline.
-
- KVRist
- Topic Starter
- 473 posts since 1 Feb, 2006
dRowAudio wrote:No, it's not possible to extend clip effects beyond the border of a clip, that doesn't fit with the "render as source file" paradigm. It's kind of like asking an audio file to continue playing after the end of the file. What would happen if you're looping a clip with Clip Effects on? How would the tail affect the next loop iteration?
in my simple understanding (which may very well be obsolete, because i am not a programmer
) it would go like this: when playback is looped or the clip is set to loop, the "tail" that was rendered is just not "read" from the file. only the part that fits the clipborders is read from the file and played in the edit. that does assume, that the rendered files are some sort of "audiopool" in the background, from where clips can read out whatever they need, depending on their clipborders (i picture it like, a clip being a window into an audiofile that may be larger than the clip itself).
so in this case the tail is just ignored. this would incorporate loop playback and looped clips. in all other cases it would be played, when the playback is running over the clipborders and there is some sort of reverb or delay.
your suggestion to maybe add that feature in the future for simple clipeffects, that already exist in tracktion since a long time, would be totally sufficient for my needs.
just want to emphasize again (i know i repeat myself
), what an important workflowfeature this could be. although i can very well accept, that it may not be possible technically. btw, i am overall very happy with t7, thanks for all the good things you already coded into it
regards, mathias
-
- KVRAF
- 1790 posts since 30 Dec, 2012
Thanks for the feedback, whilst almost anything is technically possible, it's always a trade-off between popularity and implementation time whilst keeping features and behaviour predictable.
I hear what you're saying about only playing effects for non-looped clips (and the "window onto a file" is a good way of visualising this) but it's not quite that simple. The clip effects audio file is rendered at the same tempo as the loop file so when the effect gets applied it will be at that tempo. After the source is rendered there is the additional stage of creating a time-stretched proxy. This could speed up or slow down if it covers any tempo changes. So really we would also need to render the proxy file with this additional effect tail. At this point, it gets a bit complicated and I still don't really like the idea of source files appearing outside the clip borders, that's kind of the reason they're there.
But yes, adding a plugin to a clip, which is rendered in real time is a lot easier to apply to a clip after all the source and proxy file generation has been completed.
I hear what you're saying about only playing effects for non-looped clips (and the "window onto a file" is a good way of visualising this) but it's not quite that simple. The clip effects audio file is rendered at the same tempo as the loop file so when the effect gets applied it will be at that tempo. After the source is rendered there is the additional stage of creating a time-stretched proxy. This could speed up or slow down if it covers any tempo changes. So really we would also need to render the proxy file with this additional effect tail. At this point, it gets a bit complicated and I still don't really like the idea of source files appearing outside the clip borders, that's kind of the reason they're there.
But yes, adding a plugin to a clip, which is rendered in real time is a lot easier to apply to a clip after all the source and proxy file generation has been completed.
-
- KVRist
- Topic Starter
- 473 posts since 1 Feb, 2006
i can certainly see the complexity in this matter.
thanks for taking the time to explain things from the developer point-of-view.
for me, the indicated "simple" solution for a clipeffects tail feature would be totally sufficient.
if it will not materialize, there is still enough in tracktion to love it and make it work for me
all the best,
mathias
thanks for taking the time to explain things from the developer point-of-view.
for me, the indicated "simple" solution for a clipeffects tail feature would be totally sufficient.
if it will not materialize, there is still enough in tracktion to love it and make it work for me
all the best,
mathias