Home » The PARIS Forums » PARIS: Main » Oh ................. HELL YES!!!!!!!!!!!!!
|
|
|
|
Re: Oh ................. HELL YES!!!!!!!!!!!!! [message #73436 is a reply to message #73431] |
Sun, 01 October 2006 19:28 |
animix
Messages: 356 Registered: September 2006
|
Senior Member |
|
|
Looks like each UAD-1 plugin is creating 33ms of latency in Cubase SX (1470
samples).plus the buffer of 512 samples. This will vary by a few, but I
haven't gotten that anal about it yet. Using Delaycomp in SX is just an
PITA. It's do'able, but requires you to route *every* track in the mix
through SX with a large incremental setting on the Delaycomp that is reduced
by 1 increment every time you add a plugin. Here's a quick and dirty
solution I've come up with. It's a few samples off, but it's working with no
audible latency.
To compensate for the 512 sample buffer latency between Paris and Cubase SX,
slide the Paris track to be compensated to the left using editor buttons
10ms and 1ms. then in the Native plugins secion, insert Sampleslide at 48
samples. Now you're sample accurate between Cubase and Paris on the track
you want to process
Take two tracks side by side (I'm using kicks). Now open up a UAD-1 plugin
on the track in SX and enable the insert from Paris through Cubase SX.
Highlight the track in Paris and slide it to the left by 50ms and increase
the Sampleslide increment by 770 samples. You can create a series of presets
using these calculations called 1 x plug, 2 x plugs, etc. and just open up
the on you want to use in Sampleslide, remembering that your incremental
nudge in Paris is 50ms. I use 50ms because it's easy to remember as opposed
to something that would get me within 30 or so samples but require nudging a
bunch of different ms buttons in the Paris editor.
This is all I'm going to do tonight. I'll do some exact calculations later
this week because I'm sure that there are certain sample latencies per UAD
plugin in SX and if a rough estimate (say 33ms/1470 samples) is applied to a
large number of plugs, the latency might drift off into the ms range and
cause sloppy flamming/phasing.
I'm very close here and I'm going to give Tom Freeman a call at UA this week
and get the skinny on the latency differences between these plugins if I can
so we can get anal retentive about this.
I wish I could report some kind of major breakthrough. I thought I had it
for a second there, but using this method, we can definitely do some things
we can't do with UAD-1 plugs in Paris, like automate the plugins and use VST
and outboard processors across Paris submixes, plus the incremental nudges
are much smaller using this method of compensation so it may be a bit easier
to use Paris fader automation while processing with UAD-1 plugs.
Anyway.....I'll post more when I know more.
Deej
"Don Nafe" <dnafe@magma.ca> wrote in message news:4520641a$1@linux...
> Me too Deej
>
> Don
>
> ps. thanks for the help this afternoon...amazing what two great minds can
> accomplish
>
>
>
> "Rob Arsenault" <mani2@nbnet.nb.ca> wrote in message
news:45205a45@linux...
> > Good stuff DJ.., I'm watchin with very closely, im also doin the double
> > DAW shuffle but on a smaller scale. Please do give us a detailed
breakdown
> > once you get her all figured out.
> >
> > Rob
> >
> >
> > "DJ" <notachance@net.net> wrote in message news:4520555f$1@linux...
> >> If you've been fllowing my torturous Xperamentin thread........it looks
> >> like
> >> all of my grief about the latency compensation issues with
> >> nudging/slipping
> >> Paris tracks may be solved by using the UAD-1 Delaycomp in "Cubase" as
> >> the
> >> first insert on the channel that is processing the Paris track. The
first
> >> UAD-1 compensation increment seems to cover the native latency, then
> >> subsequent incremental adjustments cover the plugins. Just adjust it
per
> >> plugin and the track stays in phase. Also, Drumagog seems to have the
> >> exact
> >> same latency as a single UAD-1 plugin so on a kick, I can just insert
the
> >> UAD-1 delaycomp, adjust it to compensate for two UAD-1 plugins (one for
> >> buffer latency, the other for Drumagog), insert Drumagog in the next
slot
> >> and the kick track locks to the rest of the drum tracks that aren't
being
> >> processed.
> >> Now Paris automation can be used without having to worry about the
track
> >> being nudged and the plugin automation features can be used.
> >>
> >> This is too easy......there's gotta be a catch.
> >>
> >> ;o)
> >>
> >>
> >>
> >
> >
>
>
|
|
|
|
Re: Oh ................. HELL YES!!!!!!!!!!!!! [message #73446 is a reply to message #73444] |
Sun, 01 October 2006 20:07 |
animix
Messages: 356 Registered: September 2006
|
Senior Member |
|
|
Yeah.......read my last post. Man, for a second I thought I'd pulled off a
miracle. The thing that makes this kind of experimentiation really screwy is
that at times Cubase will behave inconsistently, and inconsistently for the
better. I have actually had Cubase SX latency compensation working on Paris
tracks that were being streamed into Cubase. It was like it was seeing the
incoming signal and applying a lookahead to the processing. then it would
quit doing this and the latency would return, so all I can say is that
interfacing two DAWs like this which would normally behave in predictable
ways creates a scenario where either or both of them may behave in an
unpredictable way.
Send me your PT HD rig over here and I'll shut up.
;o)
"LaMont" <jjdpro@ameritech.net> wrote in message news:4520816b$1@linux...
>
> ??????????????????????????????????????????????????
> ?????????
> You're kidding right??
>
> "DJ" <notachance@net.net> wrote:
> >If you've been fllowing my torturous Xperamentin thread........it looks
> like
> >all of my grief about the latency compensation issues with
nudging/slipping
> >Paris tracks may be solved by using the UAD-1 Delaycomp in "Cubase" as
the
> >first insert on the channel that is processing the Paris track. The first
> >UAD-1 compensation increment seems to cover the native latency, then
> >subsequent incremental adjustments cover the plugins. Just adjust it per
> >plugin and the track stays in phase. Also, Drumagog seems to have the
exact
> >same latency as a single UAD-1 plugin so on a kick, I can just insert the
> >UAD-1 delaycomp, adjust it to compensate for two UAD-1 plugins (one for
> >buffer latency, the other for Drumagog), insert Drumagog in the next slot
> >and the kick track locks to the rest of the drum tracks that aren't being
> >processed.
> >Now Paris automation can be used without having to worry about the track
> >being nudged and the plugin automation features can be used.
> >
> >This is too easy......there's gotta be a catch.
> >
> >;o)
> >
> >
> >
>
|
|
|
Re: Oh ................. HELL YES!!!!!!!!!!!!! [message #73471 is a reply to message #73446] |
Mon, 02 October 2006 13:11 |
damien.gelee
Messages: 36 Registered: July 2006
|
Member |
|
|
Hello deej,
I had tried SX, and i'm waiting my first Prais rig to be shipped across
ocean...
so i'm interested by your experiences.
At this point, did you simply tried to make your whole mixes in SX ? I
suppose you did it, and decided to go on with Paris.
As you are in an experimental mood, i'm curious too about the internal
signal processing in SX : did you tried to null files going back from cubase
(no processing in SX) with the originals tracks in Paris ? i'would bet they
are different, but maybe not in an audible way.
"DJ" <notachance@net.net> a écrit dans le message de news: 452082b9@linux...
> Yeah.......read my last post. Man, for a second I thought I'd pulled off a
> miracle. The thing that makes this kind of experimentiation really screwy
> is
> that at times Cubase will behave inconsistently, and inconsistently for
> the
> better. I have actually had Cubase SX latency compensation working on
> Paris
> tracks that were being streamed into Cubase. It was like it was seeing the
> incoming signal and applying a lookahead to the processing. then it would
> quit doing this and the latency would return, so all I can say is that
> interfacing two DAWs like this which would normally behave in predictable
> ways creates a scenario where either or both of them may behave in an
> unpredictable way.
>
> Send me your PT HD rig over here and I'll shut up.
>
> ;o)
>
>
> "LaMont" <jjdpro@ameritech.net> wrote in message news:4520816b$1@linux...
>>
>> ??????????????????????????????????????????????????
>> ?????????
>> You're kidding right??
>>
>> "DJ" <notachance@net.net> wrote:
>> >If you've been fllowing my torturous Xperamentin thread........it looks
>> like
>> >all of my grief about the latency compensation issues with
> nudging/slipping
>> >Paris tracks may be solved by using the UAD-1 Delaycomp in "Cubase" as
> the
>> >first insert on the channel that is processing the Paris track. The
>> >first
>> >UAD-1 compensation increment seems to cover the native latency, then
>> >subsequent incremental adjustments cover the plugins. Just adjust it per
>> >plugin and the track stays in phase. Also, Drumagog seems to have the
> exact
>> >same latency as a single UAD-1 plugin so on a kick, I can just insert
>> >the
>> >UAD-1 delaycomp, adjust it to compensate for two UAD-1 plugins (one for
>> >buffer latency, the other for Drumagog), insert Drumagog in the next
>> >slot
>> >and the kick track locks to the rest of the drum tracks that aren't
>> >being
>> >processed.
>> >Now Paris automation can be used without having to worry about the track
>> >being nudged and the plugin automation features can be used.
>> >
>> >This is too easy......there's gotta be a catch.
>> >
>> >;o)
>> >
>> >
>> >
>>
>
>
|
|
|
Goto Forum:
Current Time: Mon Dec 16 03:48:39 PST 2024
Total time taken to generate the page: 0.00971 seconds
|