Home » The PARIS Forums » PARIS: Main » OK........I've been doing some Xperamentin'
| OK........I've been doing some Xperamentin' [message #73400] |
Sat, 30 September 2006 22:36  |
animix
Messages: 356
Registered: September 2006
|
Senior Member |
|
|
Using Cubase SX as a standalone FX processor for Paris only:
I set the latency in my RME control panel to 1024 so I could add send VST FX
to Paris auxes without having too much latency (predelay) in a reverb while
not stressing the Cubase VST engine to the point of getting dropouts during
processing when using my dualcore 4400 CPU on lots of tracks being processed
thru Paris inserts.
InCubase SX, create a mono input and output bus
Add a mono track and assign this bus to the input and output
Patch a Paris ADAT I/O to an RME ADAT I/O
Add an audio track to a Paris channel and set up an external insert on this
track
Route the Paris ADAT I/O that is interfacing with the RME I/O to the inserts
on that channel in the virtual patchbay.
In Cubase SX, enable monitoring with FX on the audio channel you will be
using to process the Paris track
Insert a UAD-1 plugin on the Cubase audio channel and enable it for
processing.
Slide the Paris audio track back (to the left) by 50ms and hit play
The track will be looped through the Cubase audio channel and the UAD-1
processor without audible flamming/phasing
Add another UAD-1 plugin to the Cubase insert rack on this channel and slide
the Paris track back another 50 ms
The Paris track should still play back without flamming/phasing and now it
is being processed by two plugins.
Basically, what I *think* I've found here is a way to compensate Paris
tracks by a known (and small-50ms) increment *per UAD-1 plugin* without
having to chase it around with Sampleslide while giving Cubase SX enough
buffer to keep from choking down while processing audio in real time as a
standalone processor.
Increasing the buffers in SX results in more latency *per
plugin*.........and inversely, decreasing the buffers results in less. For
my particular rig/CPU capabilities, 1024 seems to be the magic number for
achieving a very simple means of latency compensation using Paris and UAD-1
plugins without having to stream all tracks in a project from Cubase to
Paris in order to process them with VST plugins with zero latency in Paris.
Doing this is very time consuming and mixing on two DAWs, even with the
incredible flexibility, it just such a hassle sometimes that I just sit
there an look at it and don't want to go there sometimes. Another cool thing
is, so far, my testing shows that Drumagog is exhibiting the same latency in
Cubase SX as the UAD-1 plugins. This *may* be indicitave of a *set latency
increment* that may apply to all VST plugins. That may not be such a big
deal since Paris handles VST plugins pretty easliy, but I'm running Win ME
on my Paris rig and some more recent VST plugins only run on XP. This gives
me a means of using these plugs in Paris with a known (and simple) latency
increment to work with.
I have processed a kick drum with Drumagog in the first Cubase insert, the
Neve 1073 in the second one and the Fairchild in the third one and sliding
the Paris track 3 x 50ms. No audible flamming when running a parallel copy
of the track unprocessed.
Also, a very generous Parisite offered to loan me 3 x EDS cards and an IF
442 today and another smart Parisite may have just come up with a solution
to getting multiple ADAT cards happening reliably with multiple MECs so me
an Igor are gonna' be in the lab next weekend with the beakers bubbling.
;o)
|
|
|
|
| Re: OK........I've been doing some Xperamentin' [message #73401 is a reply to message #73400] |
Sat, 30 September 2006 23:12  |
animix
Messages: 356
Registered: September 2006
|
Senior Member |
|
|
OK.........this is cool. It appears that by lowering my buffers in my RME
control panel from 1024 to 512, the latency in increments in Paris can be
adjusted in 25ms increments per plugin rather than 50ms. Makes sense, but I
sometimes don't expect things to make sense with Paris and it's screwy
millisecond increments so this is a welcome revelation. I'm just using my
ears at this point, not doing any actual bounces in order to achieve *exact*
sample accuracy between tracks, but if I'm close enough that I don't hear
any flamming/phasing, then I'm happy so far. I'm going to have to try this
on a project with heavy track count to see if things start sounding sloppy
though. My 4400 x 2 dual core is handling these chores nicely in Cubase at
512ms latency. That seems to be the break point on my system. I'll be
getting my head around exactly how I want to configure Cubase sends with
Paris auxes in this particular working scenario tomorrow.
Deej
"DJ" <notachance@net.net> wrote in message news:451f53e9@linux...
> Using Cubase SX as a standalone FX processor for Paris only:
>
> I set the latency in my RME control panel to 1024 so I could add send VST
FX
> to Paris auxes without having too much latency (predelay) in a reverb
while
> not stressing the Cubase VST engine to the point of getting dropouts
during
> processing when using my dualcore 4400 CPU on lots of tracks being
processed
> thru Paris inserts.
>
> InCubase SX, create a mono input and output bus
> Add a mono track and assign this bus to the input and output
> Patch a Paris ADAT I/O to an RME ADAT I/O
> Add an audio track to a Paris channel and set up an external insert on
this
> track
> Route the Paris ADAT I/O that is interfacing with the RME I/O to the
inserts
> on that channel in the virtual patchbay.
> In Cubase SX, enable monitoring with FX on the audio channel you will be
> using to process the Paris track
> Insert a UAD-1 plugin on the Cubase audio channel and enable it for
> processing.
> Slide the Paris audio track back (to the left) by 50ms and hit play
> The track will be looped through the Cubase audio channel and the UAD-1
> processor without audible flamming/phasing
> Add another UAD-1 plugin to the Cubase insert rack on this channel and
slide
> the Paris track back another 50 ms
> The Paris track should still play back without flamming/phasing and now it
> is being processed by two plugins.
>
> Basically, what I *think* I've found here is a way to compensate Paris
> tracks by a known (and small-50ms) increment *per UAD-1 plugin* without
> having to chase it around with Sampleslide while giving Cubase SX enough
> buffer to keep from choking down while processing audio in real time as a
> standalone processor.
>
> Increasing the buffers in SX results in more latency *per
> plugin*.........and inversely, decreasing the buffers results in less. For
> my particular rig/CPU capabilities, 1024 seems to be the magic number for
> achieving a very simple means of latency compensation using Paris and
UAD-1
> plugins without having to stream all tracks in a project from Cubase to
> Paris in order to process them with VST plugins with zero latency in
Paris.
> Doing this is very time consuming and mixing on two DAWs, even with the
> incredible flexibility, it just such a hassle sometimes that I just sit
> there an look at it and don't want to go there sometimes. Another cool
thing
> is, so far, my testing shows that Drumagog is exhibiting the same latency
in
> Cubase SX as the UAD-1 plugins. This *may* be indicitave of a *set latency
> increment* that may apply to all VST plugins. That may not be such a big
> deal since Paris handles VST plugins pretty easliy, but I'm running Win ME
> on my Paris rig and some more recent VST plugins only run on XP. This
gives
> me a means of using these plugs in Paris with a known (and simple) latency
> increment to work with.
>
> I have processed a kick drum with Drumagog in the first Cubase insert, the
> Neve 1073 in the second one and the Fairchild in the third one and sliding
> the Paris track 3 x 50ms. No audible flamming when running a parallel copy
> of the track unprocessed.
>
> Also, a very generous Parisite offered to loan me 3 x EDS cards and an IF
> 442 today and another smart Parisite may have just come up with a solution
> to getting multiple ADAT cards happening reliably with multiple MECs so me
> an Igor are gonna' be in the lab next weekend with the beakers bubbling.
>
> ;o)
>
>
>
|
|
|
|
| Re: OK........I've been doing some Xperamentin' [message #73403 is a reply to message #73401] |
Sat, 30 September 2006 23:36 |
animix
Messages: 356
Registered: September 2006
|
Senior Member |
|
|
Wellll......it gets even wierder and it appears to be an issue with Cubase
SX. The latency of the individual plugins seems to change at random after
adding another one in a channel. Closing the project and re-opening it puts
the latency back where it should go, sorta', but the more plugins you add,
the less accurate the Paris fixed increments become so the Cubase fixed
increments appear to be shifting more drastically as more plugins are
added........at least at lower buffer settings. I sorta' halfway expected
this and may go back to the larger and seemingly more stable 1024 buffer
settings. Chasing latency increments around like this is no better than just
using the UAD-1 cards in Paris and chasing Sampleslide around.
Well........back to the lab.
;o)
"DJ" <notachance@net.net> wrote in message news:451f5c8e@linux...
> OK.........this is cool. It appears that by lowering my buffers in my RME
> control panel from 1024 to 512, the latency in increments in Paris can be
> adjusted in 25ms increments per plugin rather than 50ms. Makes sense, but
I
> sometimes don't expect things to make sense with Paris and it's screwy
> millisecond increments so this is a welcome revelation. I'm just using my
> ears at this point, not doing any actual bounces in order to achieve
*exact*
> sample accuracy between tracks, but if I'm close enough that I don't hear
> any flamming/phasing, then I'm happy so far. I'm going to have to try this
> on a project with heavy track count to see if things start sounding sloppy
> though. My 4400 x 2 dual core is handling these chores nicely in Cubase at
> 512ms latency. That seems to be the break point on my system. I'll be
> getting my head around exactly how I want to configure Cubase sends with
> Paris auxes in this particular working scenario tomorrow.
>
> Deej
>
>
>
> "DJ" <notachance@net.net> wrote in message news:451f53e9@linux...
> > Using Cubase SX as a standalone FX processor for Paris only:
> >
> > I set the latency in my RME control panel to 1024 so I could add send
VST
> FX
> > to Paris auxes without having too much latency (predelay) in a reverb
> while
> > not stressing the Cubase VST engine to the point of getting dropouts
> during
> > processing when using my dualcore 4400 CPU on lots of tracks being
> processed
> > thru Paris inserts.
> >
> > InCubase SX, create a mono input and output bus
> > Add a mono track and assign this bus to the input and output
> > Patch a Paris ADAT I/O to an RME ADAT I/O
> > Add an audio track to a Paris channel and set up an external insert on
> this
> > track
> > Route the Paris ADAT I/O that is interfacing with the RME I/O to the
> inserts
> > on that channel in the virtual patchbay.
> > In Cubase SX, enable monitoring with FX on the audio channel you will be
> > using to process the Paris track
> > Insert a UAD-1 plugin on the Cubase audio channel and enable it for
> > processing.
> > Slide the Paris audio track back (to the left) by 50ms and hit play
> > The track will be looped through the Cubase audio channel and the UAD-1
> > processor without audible flamming/phasing
> > Add another UAD-1 plugin to the Cubase insert rack on this channel and
> slide
> > the Paris track back another 50 ms
> > The Paris track should still play back without flamming/phasing and now
it
> > is being processed by two plugins.
> >
> > Basically, what I *think* I've found here is a way to compensate Paris
> > tracks by a known (and small-50ms) increment *per UAD-1 plugin* without
> > having to chase it around with Sampleslide while giving Cubase SX enough
> > buffer to keep from choking down while processing audio in real time as
a
> > standalone processor.
> >
> > Increasing the buffers in SX results in more latency *per
> > plugin*.........and inversely, decreasing the buffers results in less.
For
> > my particular rig/CPU capabilities, 1024 seems to be the magic number
for
> > achieving a very simple means of latency compensation using Paris and
> UAD-1
> > plugins without having to stream all tracks in a project from Cubase to
> > Paris in order to process them with VST plugins with zero latency in
> Paris.
> > Doing this is very time consuming and mixing on two DAWs, even with the
> > incredible flexibility, it just such a hassle sometimes that I just sit
> > there an look at it and don't want to go there sometimes. Another cool
> thing
> > is, so far, my testing shows that Drumagog is exhibiting the same
latency
> in
> > Cubase SX as the UAD-1 plugins. This *may* be indicitave of a *set
latency
> > increment* that may apply to all VST plugins. That may not be such a big
> > deal since Paris handles VST plugins pretty easliy, but I'm running Win
ME
> > on my Paris rig and some more recent VST plugins only run on XP. This
> gives
> > me a means of using these plugs in Paris with a known (and simple)
latency
> > increment to work with.
> >
> > I have processed a kick drum with Drumagog in the first Cubase insert,
the
> > Neve 1073 in the second one and the Fairchild in the third one and
sliding
> > the Paris track 3 x 50ms. No audible flamming when running a parallel
copy
> > of the track unprocessed.
> >
> > Also, a very generous Parisite offered to loan me 3 x EDS cards and an
IF
> > 442 today and another smart Parisite may have just come up with a
solution
> > to getting multiple ADAT cards happening reliably with multiple MECs so
me
> > an Igor are gonna' be in the lab next weekend with the beakers bubbling.
> >
> > ;o)
> >
> >
> >
>
>
|
|
|
|
| Re: OK........I've been doing some Xperamentin' [message #73417 is a reply to message #73403] |
Sun, 01 October 2006 10:39 |
LaMont
Messages: 828
Registered: October 2005
|
Senior Member |
|
|
Hey DJ, I know you're just experimenting. But, this law called the Law of
Diminishing Returns". :)
How much has all of your testing cost you in time which is $$$$$
???
After a while, you have to just conceed and go with a proven solution that
works.
I have suggested to you that a PTHD 2axcel would be great. he Axcel 2 has
tons of DSP power and it stable and sounds great.
And considering that you don't need a $$expensive workstaion to run it on,
but of course, just like Paris, if you have he power, then it would benifit
you running native (RTAS) plugins.
Lokk, I know this is a Pro-Tools bashing forum, but it really is a total
working solutions, that works right..
"DJ" <notachance@net.net> wrote:
>Wellll......it gets even wierder and it appears to be an issue with Cubase
>SX. The latency of the individual plugins seems to change at random after
>adding another one in a channel. Closing the project and re-opening it puts
>the latency back where it should go, sorta', but the more plugins you add,
>the less accurate the Paris fixed increments become so the Cubase fixed
>increments appear to be shifting more drastically as more plugins are
>added........at least at lower buffer settings. I sorta' halfway expected
>this and may go back to the larger and seemingly more stable 1024 buffer
>settings. Chasing latency increments around like this is no better than
just
>using the UAD-1 cards in Paris and chasing Sampleslide around.
>
>Well........back to the lab.
>
>;o)
>
>"DJ" <notachance@net.net> wrote in message news:451f5c8e@linux...
>> OK.........this is cool. It appears that by lowering my buffers in my
RME
>> control panel from 1024 to 512, the latency in increments in Paris can
be
>> adjusted in 25ms increments per plugin rather than 50ms. Makes sense,
but
>I
>> sometimes don't expect things to make sense with Paris and it's screwy
>> millisecond increments so this is a welcome revelation. I'm just using
my
>> ears at this point, not doing any actual bounces in order to achieve
>*exact*
>> sample accuracy between tracks, but if I'm close enough that I don't hear
>> any flamming/phasing, then I'm happy so far. I'm going to have to try
this
>> on a project with heavy track count to see if things start sounding sloppy
>> though. My 4400 x 2 dual core is handling these chores nicely in Cubase
at
>> 512ms latency. That seems to be the break point on my system. I'll be
>> getting my head around exactly how I want to configure Cubase sends with
>> Paris auxes in this particular working scenario tomorrow.
>>
>> Deej
>>
>>
>>
>> "DJ" <notachance@net.net> wrote in message news:451f53e9@linux...
>> > Using Cubase SX as a standalone FX processor for Paris only:
>> >
>> > I set the latency in my RME control panel to 1024 so I could add send
>VST
>> FX
>> > to Paris auxes without having too much latency (predelay) in a reverb
>> while
>> > not stressing the Cubase VST engine to the point of getting dropouts
>> during
>> > processing when using my dualcore 4400 CPU on lots of tracks being
>> processed
>> > thru Paris inserts.
>> >
>> > InCubase SX, create a mono input and output bus
>> > Add a mono track and assign this bus to the input and output
>> > Patch a Paris ADAT I/O to an RME ADAT I/O
>> > Add an audio track to a Paris channel and set up an external insert
on
>> this
>> > track
>> > Route the Paris ADAT I/O that is interfacing with the RME I/O to the
>> inserts
>> > on that channel in the virtual patchbay.
>> > In Cubase SX, enable monitoring with FX on the audio channel you will
be
>> > using to process the Paris track
>> > Insert a UAD-1 plugin on the Cubase audio channel and enable it for
>> > processing.
>> > Slide the Paris audio track back (to the left) by 50ms and hit play
>> > The track will be looped through the Cubase audio channel and the UAD-1
>> > processor without audible flamming/phasing
>> > Add another UAD-1 plugin to the Cubase insert rack on this channel and
>> slide
>> > the Paris track back another 50 ms
>> > The Paris track should still play back without flamming/phasing and
now
>it
>> > is being processed by two plugins.
>> >
>> > Basically, what I *think* I've found here is a way to compensate Paris
>> > tracks by a known (and small-50ms) increment *per UAD-1 plugin* without
>> > having to chase it around with Sampleslide while giving Cubase SX enough
>> > buffer to keep from choking down while processing audio in real time
as
>a
>> > standalone processor.
>> >
>> > Increasing the buffers in SX results in more latency *per
>> > plugin*.........and inversely, decreasing the buffers results in less.
>For
>> > my particular rig/CPU capabilities, 1024 seems to be the magic number
>for
>> > achieving a very simple means of latency compensation using Paris and
>> UAD-1
>> > plugins without having to stream all tracks in a project from Cubase
to
>> > Paris in order to process them with VST plugins with zero latency in
>> Paris.
>> > Doing this is very time consuming and mixing on two DAWs, even with
the
>> > incredible flexibility, it just such a hassle sometimes that I just
sit
>> > there an look at it and don't want to go there sometimes. Another cool
>> thing
>> > is, so far, my testing shows that Drumagog is exhibiting the same
>latency
>> in
>> > Cubase SX as the UAD-1 plugins. This *may* be indicitave of a *set
>latency
>> > increment* that may apply to all VST plugins. That may not be such a
big
>> > deal since Paris handles VST plugins pretty easliy, but I'm running
Win
>ME
>> > on my Paris rig and some more recent VST plugins only run on XP. This
>> gives
>> > me a means of using these plugs in Paris with a known (and simple)
>latency
>> > increment to work with.
>> >
>> > I have processed a kick drum with Drumagog in the first Cubase insert,
>the
>> > Neve 1073 in the second one and the Fairchild in the third one and
>sliding
>> > the Paris track 3 x 50ms. No audible flamming when running a parallel
>copy
>> > of the track unprocessed.
>> >
>> > Also, a very generous Parisite offered to loan me 3 x EDS cards and
an
>IF
>> > 442 today and another smart Parisite may have just come up with a
>solution
>> > to getting multiple ADAT cards happening reliably with multiple MECs
so
>me
>> > an Igor are gonna' be in the lab next weekend with the beakers bubbling.
>> >
>> > ;o)
>> >
>> >
>> >
>>
>>
>
>
|
|
|
|
| Re: OK........I've been doing some Xperamentin' [message #73419 is a reply to message #73417] |
Sun, 01 October 2006 13:13 |
animix
Messages: 356
Registered: September 2006
|
Senior Member |
|
|
Hi La Mont. I appreciate your post......really.....and I'm not really a PT
hater per se. I think it sounds very good. I just cannot financially justify
it and I do my experimentation on my own time. It's really not slowing thing
down as far as billable hours are concerned......and it interests me.
I've got a scenario working here wherein I can apply VST reverbs/external
processors in Cubase SX to individual Paris channels channels on any Paris
submix and return them via an aux on any Paris submix I want. This Paris aux
will function globally so applying an external hardware reverb is no longer
tied to a single Paris submix.......basically I have defeated the submix
limitation for auxes in Paris now whether using Cubase SX as a standalone
processor for inserts and auxes (this involves some minor manual latency
compensation and I'm getting this sussed right now) or using it as a
playback engine into Paris in which case Cubase handles the latency on it's
own.
I'll post up the routing scenario for the auxes in a little while.
Cheers,
Deej
"LaMont" <jjdpro@ameritech.net> wrote in message news:451ffd48$1@linux...
>
> Hey DJ, I know you're just experimenting. But, this law called the Law of
> Diminishing Returns". :)
>
> How much has all of your testing cost you in time which is $$$$$
> ???
> After a while, you have to just conceed and go with a proven solution that
> works.
> I have suggested to you that a PTHD 2axcel would be great. he Axcel 2 has
> tons of DSP power and it stable and sounds great.
> And considering that you don't need a $$expensive workstaion to run it on,
> but of course, just like Paris, if you have he power, then it would
benifit
> you running native (RTAS) plugins.
>
> Lokk, I know this is a Pro-Tools bashing forum, but it really is a total
> working solutions, that works right..
> "DJ" <notachance@net.net> wrote:
> >Wellll......it gets even wierder and it appears to be an issue with
Cubase
> >SX. The latency of the individual plugins seems to change at random after
> >adding another one in a channel. Closing the project and re-opening it
puts
> >the latency back where it should go, sorta', but the more plugins you
add,
> >the less accurate the Paris fixed increments become so the Cubase fixed
> >increments appear to be shifting more drastically as more plugins are
> >added........at least at lower buffer settings. I sorta' halfway
expected
> >this and may go back to the larger and seemingly more stable 1024 buffer
> >settings. Chasing latency increments around like this is no better than
> just
> >using the UAD-1 cards in Paris and chasing Sampleslide around.
> >
> >Well........back to the lab.
> >
> >;o)
> >
> >"DJ" <notachance@net.net> wrote in message news:451f5c8e@linux...
> >> OK.........this is cool. It appears that by lowering my buffers in my
> RME
> >> control panel from 1024 to 512, the latency in increments in Paris can
> be
> >> adjusted in 25ms increments per plugin rather than 50ms. Makes sense,
> but
> >I
> >> sometimes don't expect things to make sense with Paris and it's screwy
> >> millisecond increments so this is a welcome revelation. I'm just using
> my
> >> ears at this point, not doing any actual bounces in order to achieve
> >*exact*
> >> sample accuracy between tracks, but if I'm close enough that I don't
hear
> >> any flamming/phasing, then I'm happy so far. I'm going to have to try
> this
> >> on a project with heavy track count to see if things start sounding
sloppy
> >> though. My 4400 x 2 dual core is handling these chores nicely in Cubase
> at
> >> 512ms latency. That seems to be the break point on my system. I'll be
> >> getting my head around exactly how I want to configure Cubase sends
with
> >> Paris auxes in this particular working scenario tomorrow.
> >>
> >> Deej
> >>
> >>
> >>
> >> "DJ" <notachance@net.net> wrote in message news:451f53e9@linux...
> >> > Using Cubase SX as a standalone FX processor for Paris only:
> >> >
> >> > I set the latency in my RME control panel to 1024 so I could add send
> >VST
> >> FX
> >> > to Paris auxes without having too much latency (predelay) in a reverb
> >> while
> >> > not stressing the Cubase VST engine to the point of getting dropouts
> >> during
> >> > processing when using my dualcore 4400 CPU on lots of tracks being
> >> processed
> >> > thru Paris inserts.
> >> >
> >> > InCubase SX, create a mono input and output bus
> >> > Add a mono track and assign this bus to the input and output
> >> > Patch a Paris ADAT I/O to an RME ADAT I/O
> >> > Add an audio track to a Paris channel and set up an external insert
> on
> >> this
> >> > track
> >> > Route the Paris ADAT I/O that is interfacing with the RME I/O to the
> >> inserts
> >> > on that channel in the virtual patchbay.
> >> > In Cubase SX, enable monitoring with FX on the audio channel you will
> be
> >> > using to process the Paris track
> >> > Insert a UAD-1 plugin on the Cubase audio channel and enable it for
> >> > processing.
> >> > Slide the Paris audio track back (to the left) by 50ms and hit play
> >> > The track will be looped through the Cubase audio channel and the
UAD-1
> >> > processor without audible flamming/phasing
> >> > Add another UAD-1 plugin to the Cubase insert rack on this channel
and
> >> slide
> >> > the Paris track back another 50 ms
> >> > The Paris track should still play back without flamming/phasing and
> now
> >it
> >> > is being processed by two plugins.
> >> >
> >> > Basically, what I *think* I've found here is a way to compensate
Paris
> >> > tracks by a known (and small-50ms) increment *per UAD-1 plugin*
without
> >> > having to chase it around with Sampleslide while giving Cubase SX
enough
> >> > buffer to keep from choking down while processing audio in real time
> as
> >a
> >> > standalone processor.
> >> >
> >> > Increasing the buffers in SX results in more latency *per
> >> > plugin*.........and inversely, decreasing the buffers results in
less.
> >For
> >> > my particular rig/CPU capabilities, 1024 seems to be the magic number
> >for
> >> > achieving a very simple means of latency compensation using Paris and
> >> UAD-1
> >> > plugins without having to stream all tracks in a project from Cubase
> to
> >> > Paris in order to process them with VST plugins with zero latency in
> >> Paris.
> >> > Doing this is very time consuming and mixing on two DAWs, even with
> the
> >> > incredible flexibility, it just such a hassle sometimes that I just
> sit
> >> > there an look at it and don't want to go there sometimes. Another
cool
> >> thing
> >> > is, so far, my testing shows that Drumagog is exhibiting the same
> >latency
> >> in
> >> > Cubase SX as the UAD-1 plugins. This *may* be indicitave of a *set
> >latency
> >> > increment* that may apply to all VST plugins. That may not be such a
> big
> >> > deal since Paris handles VST plugins pretty easliy, but I'm running
> Win
> >ME
> >> > on my Paris rig and some more recent VST plugins only run on XP. This
> >> gives
> >> > me a means of using these plugs in Paris with a known (and simple)
> >latency
> >> > increment to work with.
> >> >
> >> > I have processed a kick drum with Drumagog in the first Cubase
insert,
> >the
> >> > Neve 1073 in the second one and the Fairchild in the third one and
> >sliding
> >> > the Paris track 3 x 50ms. No audible flamming when running a parallel
> >copy
> >> > of the track unprocessed.
> >> >
> >> > Also, a very generous Parisite offered to loan me 3 x EDS cards and
> an
> >IF
> >> > 442 today and another smart Parisite may have just come up with a
> >solution
> >> > to getting multiple ADAT cards happening reliably with multiple MECs
> so
> >me
> >> > an Igor are gonna' be in the lab next weekend with the beakers
bubbling.
> >> >
> >> > ;o)
> >> >
> >> >
> >> >
> >>
> >>
> >
> >
>
|
|
|
|
| Re: OK.......How to use VST plutgins on Paris auxes "live" [message #73420 is a reply to message #73400] |
Sun, 01 October 2006 14:18 |
animix
Messages: 356
Registered: September 2006
|
Senior Member |
|
|
Follow the routing instructions for setting up paris to work with inserts in
SX that I previously posted. The disappointing part is that even if you
don't use a VST plugin on the insert, and even if you are using an outboard
FX processor, you will still have to compensate for latency unfortunately
due to the buffers. If your goal is to just be able to use an outboard FX
processor to cross submixes and your Cubase DAW has the mojo to run at 64k
buffers (1.5ms) the this would probably be of some use to you, but higher
buffers in SX will induce audible latency as low as 3ms (and I hear it
clearly at 1.5 ms) so anyway........
In the Paris patchbay, assign a pair of I/O to an aux send/return. It can be
on any submix that you have a corresponding analog or digital I/O on a
native DAW running Cubase SX so that they can be crosspatched.
In Cubase SX create a stereo input and output bus for the I/O that you will
be interfacing with the Paris I/O.
Then create an FX channel in SX and in the audio channel you will be using
toi send/return the audio from the Paris track, add this FX as a send
effect, enable it and crank it
That's really all there is to it. You can further control the send/return
levels by using th Paris aux controls.
I'm done for the day. I was hoping for something a little more elegant but
in Paris world, that's impossible when it comes to latency compensation
unfortunately.
Deej......out
"DJ" <notachance@net.net> wrote in message news:451f53e9@linux...
> Using Cubase SX as a standalone FX processor for Paris only:
>
> I set the latency in my RME control panel to 1024 so I could add send VST
FX
> to Paris auxes without having too much latency (predelay) in a reverb
while
> not stressing the Cubase VST engine to the point of getting dropouts
during
> processing when using my dualcore 4400 CPU on lots of tracks being
processed
> thru Paris inserts.
>
> InCubase SX, create a mono input and output bus
> Add a mono track and assign this bus to the input and output
> Patch a Paris ADAT I/O to an RME ADAT I/O
> Add an audio track to a Paris channel and set up an external insert on
this
> track
> Route the Paris ADAT I/O that is interfacing with the RME I/O to the
inserts
> on that channel in the virtual patchbay.
> In Cubase SX, enable monitoring with FX on the audio channel you will be
> using to process the Paris track
> Insert a UAD-1 plugin on the Cubase audio channel and enable it for
> processing.
> Slide the Paris audio track back (to the left) by 50ms and hit play
> The track will be looped through the Cubase audio channel and the UAD-1
> processor without audible flamming/phasing
> Add another UAD-1 plugin to the Cubase insert rack on this channel and
slide
> the Paris track back another 50 ms
> The Paris track should still play back without flamming/phasing and now it
> is being processed by two plugins.
>
> Basically, what I *think* I've found here is a way to compensate Paris
> tracks by a known (and small-50ms) increment *per UAD-1 plugin* without
> having to chase it around with Sampleslide while giving Cubase SX enough
> buffer to keep from choking down while processing audio in real time as a
> standalone processor.
>
> Increasing the buffers in SX results in more latency *per
> plugin*.........and inversely, decreasing the buffers results in less. For
> my particular rig/CPU capabilities, 1024 seems to be the magic number for
> achieving a very simple means of latency compensation using Paris and
UAD-1
> plugins without having to stream all tracks in a project from Cubase to
> Paris in order to process them with VST plugins with zero latency in
Paris.
> Doing this is very time consuming and mixing on two DAWs, even with the
> incredible flexibility, it just such a hassle sometimes that I just sit
> there an look at it and don't want to go there sometimes. Another cool
thing
> is, so far, my testing shows that Drumagog is exhibiting the same latency
in
> Cubase SX as the UAD-1 plugins. This *may* be indicitave of a *set latency
> increment* that may apply to all VST plugins. That may not be such a big
> deal since Paris handles VST plugins pretty easliy, but I'm running Win ME
> on my Paris rig and some more recent VST plugins only run on XP. This
gives
> me a means of using these plugs in Paris with a known (and simple) latency
> increment to work with.
>
> I have processed a kick drum with Drumagog in the first Cubase insert, the
> Neve 1073 in the second one and the Fairchild in the third one and sliding
> the Paris track 3 x 50ms. No audible flamming when running a parallel copy
> of the track unprocessed.
>
> Also, a very generous Parisite offered to loan me 3 x EDS cards and an IF
> 442 today and another smart Parisite may have just come up with a solution
> to getting multiple ADAT cards happening reliably with multiple MECs so me
> an Igor are gonna' be in the lab next weekend with the beakers bubbling.
>
> ;o)
>
>
>
|
|
|
|
| Re: OK.......How to use VST plugins yadda yadda.........."-Epilogue [message #73423 is a reply to message #73420] |
Sun, 01 October 2006 15:17 |
animix
Messages: 356
Registered: September 2006
|
Senior Member |
|
|
I've been playing around with a 28 track mix using the routing scenarios I
have been yakking about here. I don't think it's my imagination when I say
that keeping the audio in Paris during playback and routing it through
inserts to/from Cubase SX produces a much larger sounding mix than just
streaming the tracks from SX to Paris channels and summing them there. I
have no idea why, but the sound is just HUGE when working this way and my
latency compensation scenario is working pretty reliably when using 512k
buffers. I've done enough mixes streaming from SX to Paris to know the sonic
footprint. Though I liked it, there was something about it that was *similar
to, but less than* an ITB Paris mix. Keeping the tracks in Paris anl looping
them through the inserts and back is retaining more of the Paris mojo to my
ears. At 512k buffers, the first native plugin will require a 50ms nudge in
Paris whereas adding more will add less than 50 ms. Three VST plugins on a
drum track works best with 65ms adjustment in Paris. In any event, it's not
hard to work this way really once you get your head around it and the sonic
advantages are huge.........and routing any Paris channel you want to any
hardware or VST processor you want is a nice scenario as well.
I thought I had just wasted a lot of time and bandwidth until I got into
this a bit on a full mix. It may just be worth the effort.
Deej
"DJ" <notachance@net.net> wrote in message news:452030fd$1@linux...
> Follow the routing instructions for setting up paris to work with inserts
in
> SX that I previously posted. The disappointing part is that even if you
> don't use a VST plugin on the insert, and even if you are using an
outboard
> FX processor, you will still have to compensate for latency unfortunately
> due to the buffers. If your goal is to just be able to use an outboard FX
> processor to cross submixes and your Cubase DAW has the mojo to run at 64k
> buffers (1.5ms) the this would probably be of some use to you, but higher
> buffers in SX will induce audible latency as low as 3ms (and I hear it
> clearly at 1.5 ms) so anyway........
>
> In the Paris patchbay, assign a pair of I/O to an aux send/return. It can
be
> on any submix that you have a corresponding analog or digital I/O on a
> native DAW running Cubase SX so that they can be crosspatched.
>
> In Cubase SX create a stereo input and output bus for the I/O that you
will
> be interfacing with the Paris I/O.
>
> Then create an FX channel in SX and in the audio channel you will be using
> toi send/return the audio from the Paris track, add this FX as a send
> effect, enable it and crank it
>
> That's really all there is to it. You can further control the send/return
> levels by using th Paris aux controls.
>
> I'm done for the day. I was hoping for something a little more elegant but
> in Paris world, that's impossible when it comes to latency compensation
> unfortunately.
>
> Deej......out
>
>
>
>
>
>
>
> "DJ" <notachance@net.net> wrote in message news:451f53e9@linux...
> > Using Cubase SX as a standalone FX processor for Paris only:
> >
> > I set the latency in my RME control panel to 1024 so I could add send
VST
> FX
> > to Paris auxes without having too much latency (predelay) in a reverb
> while
> > not stressing the Cubase VST engine to the point of getting dropouts
> during
> > processing when using my dualcore 4400 CPU on lots of tracks being
> processed
> > thru Paris inserts.
> >
> > InCubase SX, create a mono input and output bus
> > Add a mono track and assign this bus to the input and output
> > Patch a Paris ADAT I/O to an RME ADAT I/O
> > Add an audio track to a Paris channel and set up an external insert on
> this
> > track
> > Route the Paris ADAT I/O that is interfacing with the RME I/O to the
> inserts
> > on that channel in the virtual patchbay.
> > In Cubase SX, enable monitoring with FX on the audio channel you will be
> > using to process the Paris track
> > Insert a UAD-1 plugin on the Cubase audio channel and enable it for
> > processing.
> > Slide the Paris audio track back (to the left) by 50ms and hit play
> > The track will be looped through the Cubase audio channel and the UAD-1
> > processor without audible flamming/phasing
> > Add another UAD-1 plugin to the Cubase insert rack on this channel and
> slide
> > the Paris track back another 50 ms
> > The Paris track should still play back without flamming/phasing and now
it
> > is being processed by two plugins.
> >
> > Basically, what I *think* I've found here is a way to compensate Paris
> > tracks by a known (and small-50ms) increment *per UAD-1 plugin* without
> > having to chase it around with Sampleslide while giving Cubase SX enough
> > buffer to keep from choking down while processing audio in real time as
a
> > standalone processor.
> >
> > Increasing the buffers in SX results in more latency *per
> > plugin*.........and inversely, decreasing the buffers results in less.
For
> > my particular rig/CPU capabilities, 1024 seems to be the magic number
for
> > achieving a very simple means of latency compensation using Paris and
> UAD-1
> > plugins without having to stream all tracks in a project from Cubase to
> > Paris in order to process them with VST plugins with zero latency in
> Paris.
> > Doing this is very time consuming and mixing on two DAWs, even with the
> > incredible flexibility, it just such a hassle sometimes that I just sit
> > there an look at it and don't want to go there sometimes. Another cool
> thing
> > is, so far, my testing shows that Drumagog is exhibiting the same
latency
> in
> > Cubase SX as the UAD-1 plugins. This *may* be indicitave of a *set
latency
> > increment* that may apply to all VST plugins. That may not be such a big
> > deal since Paris handles VST plugins pretty easliy, but I'm running Win
ME
> > on my Paris rig and some more recent VST plugins only run on XP. This
> gives
> > me a means of using these plugs in Paris with a known (and simple)
latency
> > increment to work with.
> >
> > I have processed a kick drum with Drumagog in the first Cubase insert,
the
> > Neve 1073 in the second one and the Fairchild in the third one and
sliding
> > the Paris track 3 x 50ms. No audible flamming when running a parallel
copy
> > of the track unprocessed.
> >
> > Also, a very generous Parisite offered to loan me 3 x EDS cards and an
IF
> > 442 today and another smart Parisite may have just come up with a
solution
> > to getting multiple ADAT cards happening reliably with multiple MECs so
me
> > an Igor are gonna' be in the lab next weekend with the beakers bubbling.
> >
> > ;o)
> >
> >
> >
>
>
|
|
|
|
| Re: OK.......How to use VST plugins yadda yadda.........."-Epilogue [message #73424 is a reply to message #73423] |
Sun, 01 October 2006 15:40 |
animix
Messages: 356
Registered: September 2006
|
Senior Member |
|
|
.........oh........and one other thing that may be of importance........when
mixing this way with Cubase SX slaved to Paris ADAT sync, it is possible to
use the plugin automation in SX as they process Paris tracks. This is not
possible to do when using UAD-1 plugins in Paris so that's an advantageous
scenario, even if it is still necessary to manually compensate for latency
in Paris using nudge/slide
Deej.
"DJ" <notachance@net.net> wrote in message news:45203ebc@linux...
> I've been playing around with a 28 track mix using the routing scenarios I
> have been yakking about here. I don't think it's my imagination when I say
> that keeping the audio in Paris during playback and routing it through
> inserts to/from Cubase SX produces a much larger sounding mix than just
> streaming the tracks from SX to Paris channels and summing them there. I
> have no idea why, but the sound is just HUGE when working this way and my
> latency compensation scenario is working pretty reliably when using 512k
> buffers. I've done enough mixes streaming from SX to Paris to know the
sonic
> footprint. Though I liked it, there was something about it that was
*similar
> to, but less than* an ITB Paris mix. Keeping the tracks in Paris anl
looping
> them through the inserts and back is retaining more of the Paris mojo to
my
> ears. At 512k buffers, the first native plugin will require a 50ms nudge
in
> Paris whereas adding more will add less than 50 ms. Three VST plugins on a
> drum track works best with 65ms adjustment in Paris. In any event, it's
not
> hard to work this way really once you get your head around it and the
sonic
> advantages are huge.........and routing any Paris channel you want to any
> hardware or VST processor you want is a nice scenario as well.
>
> I thought I had just wasted a lot of time and bandwidth until I got into
> this a bit on a full mix. It may just be worth the effort.
>
> Deej
>
> "DJ" <notachance@net.net> wrote in message news:452030fd$1@linux...
> > Follow the routing instructions for setting up paris to work with
inserts
> in
> > SX that I previously posted. The disappointing part is that even if you
> > don't use a VST plugin on the insert, and even if you are using an
> outboard
> > FX processor, you will still have to compensate for latency
unfortunately
> > due to the buffers. If your goal is to just be able to use an outboard
FX
> > processor to cross submixes and your Cubase DAW has the mojo to run at
64k
> > buffers (1.5ms) the this would probably be of some use to you, but
higher
> > buffers in SX will induce audible latency as low as 3ms (and I hear it
> > clearly at 1.5 ms) so anyway........
> >
> > In the Paris patchbay, assign a pair of I/O to an aux send/return. It
can
> be
> > on any submix that you have a corresponding analog or digital I/O on a
> > native DAW running Cubase SX so that they can be crosspatched.
> >
> > In Cubase SX create a stereo input and output bus for the I/O that you
> will
> > be interfacing with the Paris I/O.
> >
> > Then create an FX channel in SX and in the audio channel you will be
using
> > toi send/return the audio from the Paris track, add this FX as a send
> > effect, enable it and crank it
> >
> > That's really all there is to it. You can further control the
send/return
> > levels by using th Paris aux controls.
> >
> > I'm done for the day. I was hoping for something a little more elegant
but
> > in Paris world, that's impossible when it comes to latency compensation
> > unfortunately.
> >
> > Deej......out
> >
> >
> >
> >
> >
> >
> >
> > "DJ" <notachance@net.net> wrote in message news:451f53e9@linux...
> > > Using Cubase SX as a standalone FX processor for Paris only:
> > >
> > > I set the latency in my RME control panel to 1024 so I could add send
> VST
> > FX
> > > to Paris auxes without having too much latency (predelay) in a reverb
> > while
> > > not stressing the Cubase VST engine to the point of getting dropouts
> > during
> > > processing when using my dualcore 4400 CPU on lots of tracks being
> > processed
> > > thru Paris inserts.
> > >
> > > InCubase SX, create a mono input and output bus
> > > Add a mono track and assign this bus to the input and output
> > > Patch a Paris ADAT I/O to an RME ADAT I/O
> > > Add an audio track to a Paris channel and set up an external insert on
> > this
> > > track
> > > Route the Paris ADAT I/O that is interfacing with the RME I/O to the
> > inserts
> > > on that channel in the virtual patchbay.
> > > In Cubase SX, enable monitoring with FX on the audio channel you will
be
> > > using to process the Paris track
> > > Insert a UAD-1 plugin on the Cubase audio channel and enable it for
> > > processing.
> > > Slide the Paris audio track back (to the left) by 50ms and hit play
> > > The track will be looped through the Cubase audio channel and the
UAD-1
> > > processor without audible flamming/phasing
> > > Add another UAD-1 plugin to the Cubase insert rack on this channel and
> > slide
> > > the Paris track back another 50 ms
> > > The Paris track should still play back without flamming/phasing and
now
> it
> > > is being processed by two plugins.
> > >
> > > Basically, what I *think* I've found here is a way to compensate Paris
> > > tracks by a known (and small-50ms) increment *per UAD-1 plugin*
without
> > > having to chase it around with Sampleslide while giving Cubase SX
enough
> > > buffer to keep from choking down while processing audio in real time
as
> a
> > > standalone processor.
> > >
> > > Increasing the buffers in SX results in more latency *per
> > > plugin*.........and inversely, decreasing the buffers results in less.
> For
> > > my particular rig/CPU capabilities, 1024 seems to be the magic number
> for
> > > achieving a very simple means of latency compensation using Paris and
> > UAD-1
> > > plugins without having to stream all tracks in a project from Cubase
to
> > > Paris in order to process them with VST plugins with zero latency in
> > Paris.
> > > Doing this is very time consuming and mixing on two DAWs, even with
the
> > > incredible flexibility, it just such a hassle sometimes that I just
sit
> > > there an look at it and don't want to go there sometimes. Another cool
> > thing
> > > is, so far, my testing shows that Drumagog is exhibiting the same
> latency
> > in
> > > Cubase SX as the UAD-1 plugins. This *may* be indicitave of a *set
> latency
> > > increment* that may apply to all VST plugins. That may not be such a
big
> > > deal since Paris handles VST plugins pretty easliy, but I'm running
Win
> ME
> > > on my Paris rig and some more recent VST plugins only run on XP. This
> > gives
> > > me a means of using these plugs in Paris with a known (and simple)
> latency
> > > increment to work with.
> > >
> > > I have processed a kick drum with Drumagog in the first Cubase insert,
> the
> > > Neve 1073 in the second one and the Fairchild in the third one and
> sliding
> > > the Paris track 3 x 50ms. No audible flamming when running a parallel
> copy
> > > of the track unprocessed.
> > >
> > > Also, a very generous Parisite offered to loan me 3 x EDS cards and an
> IF
> > > 442 today and another smart Parisite may have just come up with a
> solution
> > > to getting multiple ADAT cards happening reliably with multiple MECs
so
> me
> > > an Igor are gonna' be in the lab next weekend with the beakers
bubbling.
> > >
> > > ;o)
> > >
> > >
> > >
> >
> >
>
>
|
|
|
|
| Re: OK........I've been doing some Xperamentin' [message #73445 is a reply to message #73419] |
Sun, 01 October 2006 20:08 |
LaMont
Messages: 828
Registered: October 2005
|
Senior Member |
|
|
DJ, not to prey ino your $$financials, but, since 1998 or 99, I know that
you;re inversted some serious dough into your studio gear. Are you really
saying that 7k or 8k is out of your $$range??
"DJ" <notachance@net.net> wrote:
>Hi La Mont. I appreciate your post......really.....and I'm not really a
PT
>hater per se. I think it sounds very good. I just cannot financially justify
>it and I do my experimentation on my own time. It's really not slowing thing
>down as far as billable hours are concerned......and it interests me.
>
>I've got a scenario working here wherein I can apply VST reverbs/external
>processors in Cubase SX to individual Paris channels channels on any Paris
>submix and return them via an aux on any Paris submix I want. This Paris
aux
>will function globally so applying an external hardware reverb is no longer
>tied to a single Paris submix.......basically I have defeated the submix
>limitation for auxes in Paris now whether using Cubase SX as a standalone
>processor for inserts and auxes (this involves some minor manual latency
>compensation and I'm getting this sussed right now) or using it as a
>playback engine into Paris in which case Cubase handles the latency on it's
>own.
>
>I'll post up the routing scenario for the auxes in a little while.
>
>Cheers,
>Deej
>
>"LaMont" <jjdpro@ameritech.net> wrote in message news:451ffd48$1@linux...
>>
>> Hey DJ, I know you're just experimenting. But, this law called the Law
of
>> Diminishing Returns". :)
>>
>> How much has all of your testing cost you in time which is $$$$$
>> ???
>> After a while, you have to just conceed and go with a proven solution
that
>> works.
>> I have suggested to you that a PTHD 2axcel would be great. he Axcel 2
has
>> tons of DSP power and it stable and sounds great.
>> And considering that you don't need a $$expensive workstaion to run it
on,
>> but of course, just like Paris, if you have he power, then it would
>benifit
>> you running native (RTAS) plugins.
>>
>> Lokk, I know this is a Pro-Tools bashing forum, but it really is a total
>> working solutions, that works right..
>> "DJ" <notachance@net.net> wrote:
>> >Wellll......it gets even wierder and it appears to be an issue with
>Cubase
>> >SX. The latency of the individual plugins seems to change at random after
>> >adding another one in a channel. Closing the project and re-opening it
>puts
>> >the latency back where it should go, sorta', but the more plugins you
>add,
>> >the less accurate the Paris fixed increments become so the Cubase fixed
>> >increments appear to be shifting more drastically as more plugins are
>> >added........at least at lower buffer settings. I sorta' halfway
>expected
>> >this and may go back to the larger and seemingly more stable 1024 buffer
>> >settings. Chasing latency increments around like this is no better than
>> just
>> >using the UAD-1 cards in Paris and chasing Sampleslide around.
>> >
>> >Well........back to the lab.
>> >
>> >;o)
>> >
>> >"DJ" <notachance@net.net> wrote in message news:451f5c8e@linux...
>> >> OK.........this is cool. It appears that by lowering my buffers in
my
>> RME
>> >> control panel from 1024 to 512, the latency in increments in Paris
can
>> be
>> >> adjusted in 25ms increments per plugin rather than 50ms. Makes sense,
>> but
>> >I
>> >> sometimes don't expect things to make sense with Paris and it's screwy
>> >> millisecond increments so this is a welcome revelation. I'm just using
>> my
>> >> ears at this point, not doing any actual bounces in order to achieve
>> >*exact*
>> >> sample accuracy between tracks, but if I'm close enough that I don't
>hear
>> >> any flamming/phasing, then I'm happy so far. I'm going to have to try
>> this
>> >> on a project with heavy track count to see if things start sounding
>sloppy
>> >> though. My 4400 x 2 dual core is handling these chores nicely in Cubase
>> at
>> >> 512ms latency. That seems to be the break point on my system. I'll
be
>> >> getting my head around exactly how I want to configure Cubase sends
>with
>> >> Paris auxes in this particular working scenario tomorrow.
>> >>
>> >> Deej
>> >>
>> >>
>> >>
>> >> "DJ" <notachance@net.net> wrote in message news:451f53e9@linux...
>> >> > Using Cubase SX as a standalone FX processor for Paris only:
>> >> >
>> >> > I set the latency in my RME control panel to 1024 so I could add
send
>> >VST
>> >> FX
>> >> > to Paris auxes without having too much latency (predelay) in a reverb
>> >> while
>> >> > not stressing the Cubase VST engine to the point of getting dropouts
>> >> during
>> >> > processing when using my dualcore 4400 CPU on lots of tracks being
>> >> processed
>> >> > thru Paris inserts.
>> >> >
>> >> > InCubase SX, create a mono input and output bus
>> >> > Add a mono track and assign this bus to the input and output
>> >> > Patch a Paris ADAT I/O to an RME ADAT I/O
>> >> > Add an audio track to a Paris channel and set up an external insert
>> on
>> >> this
>> >> > track
>> >> > Route the Paris ADAT I/O that is interfacing with the RME I/O to
the
>> >> inserts
>> >> > on that channel in the virtual patchbay.
>> >> > In Cubase SX, enable monitoring with FX on the audio channel you
will
>> be
>> >> > using to process the Paris track
>> >> > Insert a UAD-1 plugin on the Cubase audio channel and enable it for
>> >> > processing.
>> >> > Slide the Paris audio track back (to the left) by 50ms and hit play
>> >> > The track will be looped through the Cubase audio channel and the
>UAD-1
>> >> > processor without audible flamming/phasing
>> >> > Add another UAD-1 plugin to the Cubase insert rack on this channel
>and
>> >> slide
>> >> > the Paris track back another 50 ms
>> >> > The Paris track should still play back without flamming/phasing and
>> now
>> >it
>> >> > is being processed by two plugins.
>> >> >
>> >> > Basically, what I *think* I've found here is a way to compensate
>Paris
>> >> > tracks by a known (and small-50ms) increment *per UAD-1 plugin*
>without
>> >> > having to chase it around with Sampleslide while giving Cubase SX
>enough
>> >> > buffer to keep from choking down while processing audio in real time
>> as
>> >a
>> >> > standalone processor.
>> >> >
>> >> > Increasing the buffers in SX results in more latency *per
>> >> > plugin*.........and inversely, decreasing the buffers results in
>less.
>> >For
>> >> > my particular rig/CPU capabilities, 1024 seems to be the magic number
>> >for
>> >> > achieving a very simple means of latency compensation using Paris
and
>> >> UAD-1
>> >> > plugins without having to stream all tracks in a project from Cubase
>> to
>> >> > Paris in order to process them with VST plugins with zero latency
in
>> >> Paris.
>> >> > Doing this is very time consuming and mixing on two DAWs, even with
>> the
>> >> > incredible flexibility, it just such a hassle sometimes that I just
>> sit
>> >> > there an look at it and don't want to go there sometimes. Another
>cool
>> >> thing
>> >> > is, so far, my testing shows that Drumagog is exhibiting the same
>> >latency
>> >> in
>> >> > Cubase SX as the UAD-1 plugins. This *may* be indicitave of a *set
>> >latency
>> >> > increment* that may apply to all VST plugins. That may not be such
a
>> big
>> >> > deal since Paris handles VST plugins pretty easliy, but I'm running
>> Win
>> >ME
>> >> > on my Paris rig and some more recent VST plugins only run on XP.
This
>> >> gives
>> >> > me a means of using these plugs in Paris with a known (and simple)
>> >latency
>> >> > increment to work with.
>> >> >
>> >> > I have processed a kick drum with Drumagog in the first Cubase
>insert,
>> >the
>> >> > Neve 1073 in the second one and the Fairchild in the third one and
>> >sliding
>> >> > the Paris track 3 x 50ms. No audible flamming when running a parallel
>> >copy
>> >> > of the track unprocessed.
>> >> >
>> >> > Also, a very generous Parisite offered to loan me 3 x EDS cards and
>> an
>> >IF
>> >> > 442 today and another smart Parisite may have just come up with a
>> >solution
>> >> > to getting multiple ADAT cards happening reliably with multiple MECs
>> so
>> >me
>> >> > an Igor are gonna' be in the lab next weekend with the beakers
>bubbling.
>> >> >
>> >> > ;o)
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>
>
|
|
|
|
| Re: OK........I've been doing some Xperamentin' [message #73448 is a reply to message #73445] |
Sun, 01 October 2006 20:10 |
animix
Messages: 356
Registered: September 2006
|
Senior Member |
|
|
It is right now.
"LaMont" <jjdpro@ameritech.net> wrote in message news:45208299$1@linux...
>
> DJ, not to prey ino your $$financials, but, since 1998 or 99, I know that
> you;re inversted some serious dough into your studio gear. Are you really
> saying that 7k or 8k is out of your $$range??
>
>
> "DJ" <notachance@net.net> wrote:
> >Hi La Mont. I appreciate your post......really.....and I'm not really a
> PT
> >hater per se. I think it sounds very good. I just cannot financially
justify
> >it and I do my experimentation on my own time. It's really not slowing
thing
> >down as far as billable hours are concerned......and it interests me.
> >
> >I've got a scenario working here wherein I can apply VST
reverbs/external
> >processors in Cubase SX to individual Paris channels channels on any
Paris
> >submix and return them via an aux on any Paris submix I want. This Paris
> aux
> >will function globally so applying an external hardware reverb is no
longer
> >tied to a single Paris submix.......basically I have defeated the submix
> >limitation for auxes in Paris now whether using Cubase SX as a standalone
> >processor for inserts and auxes (this involves some minor manual latency
> >compensation and I'm getting this sussed right now) or using it as a
> >playback engine into Paris in which case Cubase handles the latency on
it's
> >own.
> >
> >I'll post up the routing scenario for the auxes in a little while.
> >
> >Cheers,
> >Deej
> >
> >"LaMont" <jjdpro@ameritech.net> wrote in message news:451ffd48$1@linux...
> >>
> >> Hey DJ, I know you're just experimenting. But, this law called the Law
> of
> >> Diminishing Returns". :)
> >>
> >> How much has all of your testing cost you in time which is $$$$$
> >> ???
> >> After a while, you have to just conceed and go with a proven solution
> that
> >> works.
> >> I have suggested to you that a PTHD 2axcel would be great. he Axcel 2
> has
> >> tons of DSP power and it stable and sounds great.
> >> And considering that you don't need a $$expensive workstaion to run it
> on,
> >> but of course, just like Paris, if you have he power, then it would
> >benifit
> >> you running native (RTAS) plugins.
> >>
> >> Lokk, I know this is a Pro-Tools bashing forum, but it really is a
total
> >> working solutions, that works right..
> >> "DJ" <notachance@net.net> wrote:
> >> >Wellll......it gets even wierder and it appears to be an issue with
> >Cubase
> >> >SX. The latency of the individual plugins seems to change at random
after
> >> >adding another one in a channel. Closing the project and re-opening it
> >puts
> >> >the latency back where it should go, sorta', but the more plugins you
> >add,
> >> >the less accurate the Paris fixed increments become so the Cubase
fixed
> >> >increments appear to be shifting more drastically as more plugins are
> >> >added........at least at lower buffer settings. I sorta' halfway
> >expected
> >> >this and may go back to the larger and seemingly more stable 1024
buffer
> >> >settings. Chasing latency increments around like this is no better
than
> >> just
> >> >using the UAD-1 cards in Paris and chasing Sampleslide around.
> >> >
> >> >Well........back to the lab.
> >> >
> >> >;o)
> >> >
> >> >"DJ" <notachance@net.net> wrote in message news:451f5c8e@linux...
> >> >> OK.........this is cool. It appears that by lowering my buffers in
> my
> >> RME
> >> >> control panel from 1024 to 512, the latency in increments in Paris
> can
> >> be
> >> >> adjusted in 25ms increments per plugin rather than 50ms. Makes
sense,
> >> but
> >> >I
> >> >> sometimes don't expect things to make sense with Paris and it's
screwy
> >> >> millisecond increments so this is a welcome revelation. I'm just
using
> >> my
> >> >> ears at this point, not doing any actual bounces in order to achieve
> >> >*exact*
> >> >> sample accuracy between tracks, but if I'm close enough that I don't
> >hear
> >> >> any flamming/phasing, then I'm happy so far. I'm going to have to
try
> >> this
> >> >> on a project with heavy track count to see if things start sounding
> >sloppy
> >> >> though. My 4400 x 2 dual core is handling these chores nicely in
Cubase
> >> at
> >> >> 512ms latency. That seems to be the break point on my system. I'll
> be
> >> >> getting my head around exactly how I want to configure Cubase sends
> >with
> >> >> Paris auxes in this particular working scenario tomorrow.
> >> >>
> >> >> Deej
> >> >>
> >> >>
> >> >>
> >> >> "DJ" <notachance@net.net> wrote in message news:451f53e9@linux...
> >> >> > Using Cubase SX as a standalone FX processor for Paris only:
> >> >> >
> >> >> > I set the latency in my RME control panel to 1024 so I could add
> send
> >> >VST
> >> >> FX
> >> >> > to Paris auxes without having too much latency (predelay) in a
reverb
> >> >> while
> >> >> > not stressing the Cubase VST engine to the point of getting
dropouts
> >> >> during
> >> >> > processing when using my dualcore 4400 CPU on lots of tracks being
> >> >> processed
> >> >> > thru Paris inserts.
> >> >> >
> >> >> > InCubase SX, create a mono input and output bus
> >> >> > Add a mono track and assign this bus to the input and output
> >> >> > Patch a Paris ADAT I/O to an RME ADAT I/O
> >> >> > Add an audio track to a Paris channel and set up an external
insert
> >> on
> >> >> this
> >> >> > track
> >> >> > Route the Paris ADAT I/O that is interfacing with the RME I/O to
> the
> >> >> inserts
> >> >> > on that channel in the virtual patchbay.
> >> >> > In Cubase SX, enable monitoring with FX on the audio channel you
> will
> >> be
> >> >> > using to process the Paris track
> >> >> > Insert a UAD-1 plugin on the Cubase audio channel and enable it
for
> >> >> > processing.
> >> >> > Slide the Paris audio track back (to the left) by 50ms and hit
play
> >> >> > The track will be looped through the Cubase audio channel and the
> >UAD-1
> >> >> > processor without audible flamming/phasing
> >> >> > Add another UAD-1 plugin to the Cubase insert rack on this channel
> >and
> >> >> slide
> >> >> > the Paris track back another 50 ms
> >> >> > The Paris track should still play back without flamming/phasing
and
> >> now
> >> >it
> >> >> > is being processed by two plugins.
> >> >> >
> >> >> > Basically, what I *think* I've found here is a way to compensate
> >Paris
> >> >> > tracks by a known (and small-50ms) increment *per UAD-1 plugin*
> >without
> >> >> > having to chase it around with Sampleslide while giving Cubase SX
> >enough
> >> >> > buffer to keep from choking down while processing audio in real
time
> >> as
> >> >a
> >> >> > standalone processor.
> >> >> >
> >> >> > Increasing the buffers in SX results in more latency *per
> >> >> > plugin*.........and inversely, decreasing the buffers results in
> >less.
> >> >For
> >> >> > my particular rig/CPU capabilities, 1024 seems to be the magic
number
> >> >for
> >> >> > achieving a very simple means of latency compensation using Paris
> and
> >> >> UAD-1
> >> >> > plugins without having to stream all tracks in a project from
Cubase
> >> to
> >> >> > Paris in order to process them with VST plugins with zero latency
> in
> >> >> Paris.
> >> >> > Doing this is very time consuming and mixing on two DAWs, even
with
> >> the
> >> >> > incredible flexibility, it just such a hassle sometimes that I
just
> >> sit
> >> >> > there an look at it and don't want to go there sometimes. Another
> >cool
> >> >> thing
> >> >> > is, so far, my testing shows that Drumagog is exhibiting the same
> >> >latency
> >> >> in
> >> >> > Cubase SX as the UAD-1 plugins. This *may* be indicitave of a *set
> >> >latency
> >> >> > increment* that may apply to all VST plugins. That may not be such
> a
> >> big
> >> >> > deal since Paris handles VST plugins pretty easliy, but I'm
running
> >> Win
> >> >ME
> >> >> > on my Paris rig and some more recent VST plugins only run on XP.
> This
> >> >> gives
> >> >> > me a means of using these plugs in Paris with a known (and simple)
> >> >latency
> >> >> > increment to work with.
> >> >> >
> >> >> > I have processed a kick drum with Drumagog in the first Cubase
> >insert,
> >> >the
> >> >> > Neve 1073 in the second one and the Fairchild in the third one and
> >> >sliding
> >> >> > the Paris track 3 x 50ms. No audible flamming when running a
parallel
> >> >copy
> >> >> > of the track unprocessed.
> >> >> >
> >> >> > Also, a very generous Parisite offered to loan me 3 x EDS cards
and
> >> an
> >> >IF
> >> >> > 442 today and another smart Parisite may have just come up with a
> >> >solution
> >> >> > to getting multiple ADAT cards happening reliably with multiple
MECs
> >> so
> >> >me
> >> >> > an Igor are gonna' be in the lab next weekend with the beakers
> >bubbling.
> >> >> >
> >> >> > ;o)
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >
> >
>
|
|
|
|
Goto Forum:
Current Time: Sun Dec 15 23:58:21 PST 2024
Total time taken to generate the page: 0.01507 seconds
|
The PARIS Forums
Search
Help
Members
Register
Login
Home
