Elastic Audio//Xform//Whats REALLY happening?-- DigiTechSupport?

[whatsprotools]

First off let me say, that I use Elastic Audio/Xform frequently, especially on drums, and I have found a way to work with it that is great for me, and I think sounds good too.

BUT, I'm dying for someone to shed some insight on how it processes things/what exactly its doing, and why??????

What I mean, is that I can find absolutely no common thread b/w how long it takes to render/xform things. Sometimes, it takes a really long time to render a lot of regions, with a lot of warp markers, sometimes, it takes no time to render a lot of regions, with a lot of warp markers. Furthermore, I'm even further stumped by a small region with few warp makers, that seems to take forever.

I've been using EA pretty darn consistently, since about July, and I have to say I'm completely at a loss for understanding what makes it tick (ie-what determines how long the rendering will take)

I should mention that I generally try to either get rid of any/all warp markers on alt playlists, or remove all the alt playlists altogether.


Anyone have any insight into the process?
Digi?


C.

[DigiTechSupt]

Are you only using X-Form or are you possibly using Mono, Poly, Rhythmic or other versions?

X-Form can be rather slow - maybe that's what you're seeing? Most of the others are considerably faster than X-Form.

[whatsprotools]

Thanks for the speedy reply Digi.

Just to clarify, I'm not so much wondering why Xform takes longer then the other algorithms, I understand that Xform is a much higher quality TCE then the others. I'm confused on why sometimes it takes a really long time, or not any time at all, to either Xform, or commit the processing.

I generally work at the same session settings (48k, 24bit) so there is no variable there. And I always work of brand new Glyph drives for each project, so i can't imagine that its something as simple as drive speed.

I'm just baffled by how sometimes it goes so fast, and other times it take suuuuper long.


C.

[sinukus]

When commiting XForm (or other rendered modes) if there is an existing rendered file it will not re-render. This being said, commiting will attempt to render in handles on either side of the region if available (which render mode does not).

So if your region is a partial file region and you select commit it will indeed re-render. Where as if it is a whole file region it will re-use the existing render, as its cannot add handles.

S

[whatsprotools]

not sure I'm following....

could you elaborate?

thanks
C

[barismanco123]

If you have made an edit selection and try to process only the edit selection it will also try to process the other sides of that selection provided anchors are not there to prevent it I think.

However if you were to press CTRL B after making the selection and therefore creating a new file in the regions bin you should find that the processing should only occur at that area as oppsed to the entire track.

Thats what I do - I've been away from PT for a whilefor various reasons so I also advise that you go to the site to confirm it.

Baris

[sinukus]

Basically it comes down to whether the region has been trimmed or not by the time you commit. If it hasn't been trimmed then the commiting process can't add handles (a couple of seconds of audio on either side of the region boundary).

S

[barismanco123]

So does breaking the region also mean a form of trimming?It seems like that - I would like to know as it will refresh my memory.

Thanks

[sinukus]

Yes.

Any operation that reduces the region in size from the originally recorded length will do the same thing.

S

[barismanco123]

Neat - thanks, good to know the old tickers still ticking.