Begging for improved timestretch

[GaryG]

I rather have it exactly like it is now (non-destructive), but with a better algo.

agreed.

I don't think i'm alone in creating my stuff 'on the fly', not just recording and mixing but playing with effects creatively, trying out daft timestretches etc. I want (need) to hear how things will finally sound as I go along, I don't want an approximation, makes judging how other elements sit with the timestretched material impossible.

.g

[cbit]

I don't think i'm alone in creating my stuff 'on the fly', not just recording and mixing but playing with effects creatively, trying out daft timestretches etc. I want (need) to hear how things will finally sound as I go along, I don't want an approximation, makes judging how other elements sit with the timestretched material impossible.

i work in a similar way, but i dont see the problem with offline stretching.

I would just render the part, and re-render with diff settings if it sounded wrong/bad. for me the price of a few extra seconds (?) of waiting inbetween renders is worth it if the results are noticeably smoother than realtime stretching, or if the choice of rendering options is greater.

[vikse]

i create my stuff on the fly too, still, i prefer a shitty sounding algorithm in realtime and intuitive way of sequencing, with an option to render it in super highquality.

i mean all you do when pitch shifting is checking you get the right chord when matching loops, therefor the quality at the time doesnt matter.

[cbit]

i mean all you do when pitch shifting is checking you get the right chord when matching loops, therefor the quality at the time doesnt matter.

don't forget about timestretching though. for ppl who 'mix as they go' like me (and lalo, and others) it might be very important to hear how the 'real' stretch sounds straight away.

but i agree, the ideal situation would be a rough realtime preview function incorporated into a system that would also allow a higher quality offline render.

[Lunch Money]

I think some of the people who think 'offline' means 'time consuming' are getting it wrong. All it means is that once you've picked your region to timestretch, you get a wee little wait (depending on the length of the part, of course... even 'good' timestretch isn't that time-consuming, so it'd be wee indeed).

It likely wouldn't even feel like anything other than a particularly slow graphics re-draw. You know, when you click a button on your browser or in an app, and it takes a few seconds to respond?

The only reason to use 'realtime' -anything- is during live performance. That means either an actual 'performance' (ie. in front of people) or while tracking so that you can hear what you're recording as you record it. From what I can see, GaryG DOES know what he wants, which is 'realtime', and I'm sure others do, too. Personally, I don't trust realtime human movement for pitch-shifting anyhow, so I'd never use it that way.

But I'm willing to bet that some people reading this thread (and possibly some of the people responding) are getting the impression that 'offline' processing would be clunky or time-consuming, when in fact it would be quite transparent.

Greg

[GaryG]

ok, I'm actually stopping and thinking about this now...

so if a process stretched a clip offline like Lunch describes then the clip has been destructively edited? Won't that affect quality if you then change the tracks tempo or something and have to stretch it again? Or is the original preserved and a stretched version subsituted in the arrangement?

I'll have to admit I tend to associate 'offline' with something like the timestretch in sound forge where you have to specify the ratios etc. manually. Mental block yada yada...

Maybe if offline is transparent and just causes a short delay then I don't understand why you'd bother with a rough preview...

.g

[Lunch Money]

I'm not saying my reasoning IS the right way, I'm just suggesting that it's a possible implementation.

Ideally, there'd be even more 'transparent' stuff going on, and your original clip would be retained, and the destructive edit would be applied to a copy.

Greg

[vikse]

the way i see it you use the shittysounding realtime timestretch functions, the way it is today.
BUT, somewhere you can hit a "Render timestretched audio"-button, which renders the timestretched clips to new files using a high quality algorithm, which are played instead of the original file. However, if you timestretch these clips even more, it reverts to the original file and uses the realtime algorithm again.

More choices for buttons would be; "render track" or "render clip"

I'm pretty convinced this is the absolutely best way, a halfdecent sounding realtime algorithm simply wont do it in the long round.

I would trade of all of the included plugins\vstis for an implementation of the mpex algorithm like this.

[Warmonger]

Have you listened to the different algorithms in T1? Going from the low quality to high quality makes a tremendous difference in the sound. If a clip is rendered with an algorithm that hasn't been heard, chances are good that the result will be disappointing. The only way this would be workable is if the high quality option is also selectable for real-time preview.

[Lunch Money]

Not necessarily true. EVERYTHING depends on what you're trying to accomplish.

Greg

[IIRs]

so if a process stretched a clip offline like Lunch describes then the clip has been destructively edited? Won't that affect quality if you then change the tracks tempo or something and have to stretch it again? Or is the original preserved and a stretched version subsituted in the arrangement?

Thats sort of how editors like Soundforge work: although you may end up editing destructively, all your edits are actually performed on a temp file until you hit save. I can't imagine something like that being beyond Jules, he is God after all.

[Sleepwalker]

You dont need timestrech if you have seperate temposhift on every channel, and rex suport. This is eighter totaly crazy or briliant, I havent had time to evaluate all ideas that pop up in my head latly! But hey, thats why I love tracktion as a tool, its dedicated us "crazy-lazy" people.

...this is not intended arrogant! Heck I cant even write the word!

[Lunch Money]

Rex won't do diddly-squat for your vocal parts.

Greg

[clueless]

the way i see it you use the shittysounding realtime timestretch functions, the way it is today.
BUT, somewhere you can hit a "Render timestretched audio"-button, which renders the timestretched clips to new files using a high quality algorithm, which are played instead of the original file. However, if you timestretch these clips even more, it reverts to the original file and uses the realtime algorithm again.

More choices for buttons would be; "render track" or "render clip"

I'm pretty convinced this is the absolutely best way, a halfdecent sounding realtime algorithm simply wont do it in the long round.

I would trade of all of the included plugins\vstis for an implementation of the mpex algorithm like this.

i must be missing something here, but...why??!

wouldn't the best and simplest way be 'final' quality realtime processing? i don't understand why people seem to be aiming for something more time-consuming than that and for poorer results

[haydxn]

a realtime stretching algorithm is ALWAYS going to be a compromise. yeah, a really excellent one would be teh shi7z0rZ but one that doesn't require real-time processing will sound better (if it is a good one of course! an inefficient crap sounding one would be shit).

the ultimate quality would come from one that could process it in its own time, and so it makes sense to be able to have a button to 'final stretch' it. a nice real-time one would be good to preview with; yeah of course processes can have a strange effect that you'd like to be able to preview and you might go "oh that doesn't sound quite right" with an offline one, but at the end of the day, real-time stretching (especially the high-quality invisible types everyone wants) is a CPU drainer and no mistake. having a button to render the clip as a high quality stretch will free up the cpu required to get it how you want it.

a single button could render all your stretched ones in one pass, and wouldn't be much more intrusive than a 'freeze'. it's definitely going to be quicker to do that than to load it up in an editor with a good quality algo, stretch it (with parameters etc..) and then update the clip in T.