While I much appreciate the new folder editing (i.e. using the [=] button to enable multi-track editing) I have a problem with it that I hope can be worked around:
If I have tracks from two mikes which happen to be at different distances from the instrument, I may need to realign them in the project to avoid phasing problems. If I do this by moving or slip-editing one of the events, synchronisation of these events fails.
It also fails if you trim an event in the sample editor.
Any workarounds out there?
Crotchety, who is definitely off to bed this time!
It’s a pain, why does sync get lost so easily?
In fact I’d really like to know what are the conditions to having tracks in sync.
I bounce the tracks (making sure the project is set to 32fp) seems to restore sync.#
Bounce to re-synch? Sounds like a good idea! Why the 32fps, though?
+1 to seeing some synching rules. What are they based on? Time code? I’ve just spent a while on the KB but as usual it didn’t turn anything useful up. No articles on “Group Editing”? I find that hard to credit.
Ideally, I would also like to see a way of telling Cubase that, whatever it thinks, the tracks are in synch, which would be preferable to having to bounce.
Good workaround, though. Thanks.
I think it’s important to have the project set to 32bit for operations such as bounce and offline processing because as far as I understand it cubase will render the files at the set project bit depth. As such it would reduce any loss of precision.
Does that mean you’re having to change project settings everytime you want to do this? I think you’re right about bouncing using the project settings. I have a bounced section in my current project and it is indeed of the project resolution. Makes sense, I suppose.
Na… I just keep it at 32 these days as disk space is so plentiful, I used to track at 24 then switch to 32 but I find it to much of a bother now as I’m fundamentally lazy
Think I have workaround which I spell out here: http://www.steinberg.net/forum/viewtopic.php?f=19&t=9945&p=65791&hilit=sync#p65791
Not so much a workaround, I suspect, as the way SB intended it to be used!