to conman:
as I stated above, the project is set to 48 khz, the loop imported is 48 khz, and this procedure of timestretching is working perfectly in cubase 5 at both 44, 48 and 96 khz. it is not working in cubase 6, using 48 or 96 khz projects and loops.
there is no other change in my hardware, there is only changes in the software.
I use mainly 48 khz for projects, and sometimes 96 khz for some various projects, but the overall standard is 48 khz.
I never use 44 khz. if I get material at 44 khz, I upsample the material to 48 khz in external audio editor before I start to work with it in Cubase.
I tried a few ways to timestretch things in cubase 6 when working in 48 khz, and most ways dont work.
going thru the menu Audio - Advanced - Stretch to Project Tempo = fails
going thru the menu Audio - Process - Time Stretch = fails (at any of the different settings and variables used)
going thru the toolbar - Object Selection and using Sizing Applies Timestretch = fails
however…
open the Sample Editor, selecting tab AudioWarp and enabling Musical Mode = kinda works, there is a small silence in the start of playback (when the cursor is starting from the beginning of the warped loop).
this does seem to work kinda ok, but… the fact that I cannot select the actual length of the stretch is very annoying.
one of the main things I use timestretching for, is to create various other lengths of the same original loops, and to use them in conbinations within each other and to actually discover new rhythmic sounds and samples.
this editing is of course all in the same project tempo, and now as this dont work in 48 khz, am I suppose to downgrade all my samples into 44, and work at 44 ?
dont think so, as it worked just fine in cubase 5…
of course I realize this is a .0 version and there is bound to be some initial bugs and what not, but I dont think this is the case here, unless there has been a major change in the basic timestretch engine. for sake of argument, lets say there is a major change in the timestretch department. I would assume there should be several tests made pre release of such a new enhanced feature before it actually makes it into a product. atleast there should be minimum testing on all sample rates, just to make sure there is no weird things going on anywhere.
the basic idea must surely be to have it work better than it has done in earlier versions. or in worst case scenario, as it did in the earlier version. that should be (atleast) a minimum requirement.
there is an old saying… if it aint broke, dont fix it…
lets take this idea and put it into a different but somehow similar context.
a carcompany makes really great cars, and all seems to work ok.
one day the company comes up with a new idea about brakes. this idea results in mounting new brakes into the cars.
once out on the road, a customer is braking for a red light. and the brakes dont work.
later, the customer asks the company, didnt you try these brakes before you put them into the cars ?
yes of course we did, says the company, how fast were you going ?
I was going around 10 mph, replies the customer.
well, there it is, says the company. we only tested the brakes at 5 mph…