Possible Digi Evil

[RobertS2003]

Ok so maybe this post should be on the DUC but this forum is much better. So here it goes!
1)There are alot of people using PT and mixing in the box.
2)Seems more and more delay compensation for insert I/O and plug ins
is the big gripe (mix bus aside)
3)Seems most users use or want to use better converters (i.e: Apogee)
4)Digi wants users using Digi boxes
What if Digidesign actually releases a new version of PT with I/O delay compensation but does not allow offsets for users using converters other than Digidesign?


If different units have different latency values this could be a fairly big issue if I am not mistaken.
Of course this is all fiction and I hope I don't get flamed here.
Of course everyone could just keep nudging files and using time adjuster.
Anyone have any thoughts or insights?

[nlc201]

Wellsir,

There are relatively few boxes that can actually qualify as Digidesign interfaces (Agogee Rosetta 800 or AD8000s, Prism Dream, perhaps the Myteks). Therefore, if a user is using a converter box that is not classified as an "interface", I don't think Digi would be responsible for providing latency compensation. Those users who used non-interface boxes connected digitally would incur further delays anyway from the digital transfers from the Digi "interfaces". There are a whole slew of different converters and latencies out there. I have a feeling Digi is NOT going to include latency comprensation for all of them.

But, I feel that a lot of the gripe of latency compensation comes not just from using hardware I/Os but plugins and internal bussing. I'm getting kind of tired of using only RTAS plugs for my individual drum tracks to keep them in phase. It seems a waste on an HD3 and RTAS does not support bussing which means that sidechains and key inputs are disabled. So much for my gates. So, in going TDM I guess its time adjuster. But, you add a plug on one track, all your other tracks go out the window and need to be readjusted.

The bussing is an issue as well. To those of us who use a lot of mults and parallel processing the bussing latency is very annoying. Processing a track with different plugs on different mults runs into the same problem as the drums. Only this time, RTAS plugins do not work on the Aux inputs (TDM bussing). You can duplicate the track itself but then you increase your hard disk strain as well as make editing of that particular track much more difficult by having to remember to be in the proper grouping at all times.

Most of the time, the latency incurred by running a track through a hardware insert doesen't bother me. We're talking about 2 ms here so MOST often (not always), the feel and groove of the song is not really affected. Obviously phase coherency is an issue, but if you've got completelyu isolated overdub tracks (live tracks with bleed is a different story) then that's not really a huge issue, save drums or stereo material. As long as any 3rd party converter kept these specs realistic (not 1000 samples or some crap like that), I don't think this will be a problem.


My belief is that Digi will first correct TDM bussing latency (good for the mult guys), then perhaps include a fix for plugin latency (good for the drum guys and the big latency plugs). If there's any hardware latency compensation at first, I'd be shocked. Any at all would probably be limited to DIGI interfaces. Perhaps in the interface profile for 3rd party "interfaces", they will allow the inclusion of a modifier to allow latency compensation. That's a BIG maybe. Anyone who uses 3rd party converters hooked up to their Digi interfaces digitally is most likely on their own. Including a feature in PT where a user could program their only latency values as per their individual converters would most likely not be high on Digi's priority list. Especially since it has been so difficult to get Delay compensation happening in the first place.


This is the price you pay for using a system designed for telephone communications.........

[Bob Olhsson]

Originally posted by RobertS2003
...
Anyone have any thoughts or insights?

Most of Digi's customers don't use better converters just like most of Studer's customers don't replace the wimpy stock power supplies. I wouldn't worry about them locking high-end customers out of using better converters.

[Kenny Gioia]

Originally posted by Bob Olhsson
Most of Digi's customers don't use better converters just like most of Studer's customers don't replace the wimpy stock power supplies. I wouldn't worry about them locking high-end customers out of using better converters.

Hell, I wouldn't worry about any of it.

They've been promising Delay Compensation since George Dubya's Dad was in office.

[RobertS2003]

Very good points! Internal bussing delay compensation is definately an issue as well I/O compensation. The only reason I started this post is because Digi is highly likely to release such an upgrade due to the fact that they follow the trends.

Considering Nuendo/Cubase have paved the way with plug/buss delay compensation DIGI has to answer the same way they answered to sample rate upgrades. If you asked a Digi representative just a couple short years ago if they had higher sample rates in the works they would argue that there was no plans. Maybe because they did not want the cat out of the bag but most would believe there was no admitting it due to the fact that another company had done it first.

Still waiting for the heat :)

[oudplayer]

Originally posted by RobertS2003
Ok so maybe this post should be on the DUC but this forum is much better. So here it goes!
1)There are alot of people using PT and mixing in the box.
2)Seems more and more delay compensation for insert I/O and plug ins
is the big gripe (mix bus aside)
3)Seems most users use or want to use better converters (i.e: Apogee)
4)Digi wants users using Digi boxes
What if Digidesign actually releases a new version of PT with I/O delay compensation but does not allow offsets for users using converters other than Digidesign?

Buncha different issues here.

Digi has repeatedly claimed that the reason they don't implement delay compensation is because 3rd party plugin developers don't consistently encode it into their implementations of RTAS plugins. It's a cop-out rationale, but it would appear that it offers an infinite scapegoat.

They've also denied (repeatedly, to the point of banning users from the DUC) that there's any issue with their mix buss. This would suggest they have little plans to address this, either.

Some of my biggest gripes with Digi's software have always been the antiquated code leading to inefficient use of hard drives. Nuendo offers unlimited undo; other applications don't care if you use IDE, SATA, Firewire, or SCSI (offering high track counts on all of them), but Protools is the one with the stringent requirements yet no extra performance features to boot.

I so happen to know that developers at Digi have actually written new hard drive code, including features such as unlimited undo, etc., but that they haven't been bundled with releases for whatever reasons (though the code was completed well over a year ago). Furthermore, it's feasible that these features would never be released. It just hasn't appeared to be a priority yet, I guess.

Typically, at these mid-sized software companies there are hundreds of already-coded features floating about waiting for an appropriate release, and product management cobbles together the smallest-possible package (the easiest to test, that is) that will keep the product competitive, answer the show-stopper concerns (like the track-count problems with Protools and the G5 computers when running at 192k), and suggest future directions for the software (networked collaboration, integration with video suites, etc.). I wish they were more responsive to these concerns, which have been voiced on all the forums, but they seem to have their own product lifecycle in mind.

[andre tchmil]

all of the above thoughts are the true, except for one thing:
IMHO, if you haven't enough with a dozen of undos, then you better look out for another....... " hobby".

[andre tchmil]

all of the above thoughts are the true, except for one thing:
IMHO, if you haven't enough with a dozen of undos, then you better look out for another....... " hobby".

[andre tchmil]

all of the above thoughts are the true, except for one thing:
IMHO, if you haven't enough with a dozen of undos, then you better look out for another....... " hobby".

[Bob Olhsson]

Latency is the "gotcha" of all digital gear. It's easier to deal with in some applications than others but don't let anybody ever kid you into thinking it doesn't always need to be watched. Sometimes it makes a HUGE difference in the feel of the music and sometimes it makes little difference at all. I've occasionally needed to put the exact same plug-ins on every single track in order to make things feel right because compensation for the number of samples didn't cut it.

Saving all the money is cool but digital can also be a royal pain in the butt because you've always got to keep watching over your shoulder at keeping rhythm and "balls."

[Duardo]

Digidesign didn't allow Apogee or Prism to develop interfaces to connect directly with their HD systems (as they did with Apogee for the Mix systems), those companies reverse-engineered the interface.

As I understand it, Digidesign waited so long to jump on the higher sampling rate bandwagon because the consumer demand wasn't there (and arguably, it sill isn't).

-Duardo

[stealthbalance]

[quote]Originally posted by Bob Olhsson
[ I've occasionally needed to put the exact same plug-ins on every single track in order to make things feel right because compensation for the number of samples didn't cut it.

------------------------------------
oh man , are you saying even to compensate with the value shown in the latency window that it is inaccurate?? what a violation !
s
grudge

[Ruairi]

Originally posted by oudplayer

Some of my biggest gripes with Digi's software have always been the antiquated code leading to inefficient use of hard drives. Nuendo offers unlimited undo; other applications don't care if you use IDE, SATA, Firewire, or SCSI (offering high track counts on all of them), but Protools is the one with the stringent requirements yet no extra performance features to boot.

I am a PTHD user but certainly not a digi apologist or evangelist. Digi do restrict your options as regards drive usage and interface options but they also guarantee certain levels of performance, something the other software companies don't match (as far as I'm aware). My understanding is that they limit the potential combinations of gear to a finite number that they can test and approve thereby offering the pros who use their gear the stability and predictability they require (or at least I require),

cheers,
Ruairi

[oudplayer]

Originally posted by andre tchmil
all of the above thoughts are the true, except for one thing:
IMHO, if you haven't enough with a dozen of undos, then you better look out for another....... " hobby".

The main use of unlimited undos is in quickly auditioning multiple plugin combinations or mixing settings. You can go back 30 steps, change a compressor setting, and not have to redo all the edits or whatever that came in between. I've seen people work really quickly in Nuendo because of this feature. It's not so crucial to me - I brought up the issue just to demonstrate the lag time between feature development and deployment (which can be infinite). It's a feature that works flawlessly in other platforms...

Regarding Digi's guarantee of a level of performance - it's all fine and dandy and smooth until you get a DAE error. As a long-term computer programmer, I find Digi's error handling to be perhaps the most abyssmal of any application I have ever seen, period. When we decided to switch to samplitude, it was based on a cumulative frustration with losing large amounts of work from sudden DAE errors; being locked into expensive proprietary hardware (HD3 systems, etc.); and application inefficiency. These appear to be inherent to their design and release process, however.

I really wish they'd deal with these problems - I am comfortable editing and working in a Protools environment (been with them since "SoundTools," and nearly took a job at Digi), and in general prefer Mac platforms, but we couldn't justify the expense of over $22,000 for a glorified and buggy 24-track recorder and editing box...

again, YMMV.

[mitgong]

Originally posted by RobertS2003

What if Digidesign actually releases a new version of PT with I/O delay compensation but does not allow offsets for users using converters other than Digidesign?

What if Digi rented a car and used it to run over your dog? That's "possible", and it sure is evil!

Angry Mob! Angry Mob! Light the torches! Summon the Angry Mob!

[HypocritePro.]

Question is then... How many years would it take before DigiDesign could find my dog.... and then how long would it take for them to actually run him over? .... I figure by the time they get to that stage, he will have already died of natural causes

[davemc]

[quote]Originally posted by stealthbalance

Originally posted by Bob Olhsson
[ I've occasionally needed to put the exact same plug-ins on every single track in order to make things feel right because compensation for the number of samples didn't cut it.

------------------------------------
oh man , are you saying even to compensate with the value shown in the latency window that it is inaccurate?? what a violation !
s
grudge

I did some testing a last year and found phase problem with different plugins at the same sample latency. I did not test all of them and thought to myself great. Must be rounding to the nearest sample. Pretty easy to test for yourself.
Two tracks phase invert one.
Add plugs on one and other to the second.

Every one knows autotune delays more then it says?

Might test this again for myself.
Auto comp would be really nice, I use a lot of outboard now and sometimes reach for a plugin instead of outboard..

[RobertS2003]

Poor Fluffy!...Oh no!

[sharpeleven]

Originally posted by stealthbalance


oh man , are you saying even to compensate with the value shown in the latency window that it is inaccurate?? what a violation !
s
grudge

in my experience the latency window was never accurate. A while ago I measured all my plugs using a Mix + system .

the following list applied to PT 5.0.1, TDM Mix plus and is probably a handy thig to have for all the MIB (mix in da box) guys. Does anyone have the exact numbers for HD ?


Plug-in: latency in samples

ChannelStrip: 42
Amp Farm: 3
Aural Exiter: 3
Auto-Tune: 33
Big Bottom Pro: 3
DINR (BMR): 1538
Bruno: 3
CompressorBank: 2
D-verb: 3
Dither: 5
de-esser: 5
Compressor: 5
Limiter: 5
Expander: 5
Gate: 5
1-BandEQII: 5
4-BandEQII: 5
Filterbank: 2
ƒƒd2: 5
ƒƒd3: 5
LexiVerb: 3
Maxim: 1027
Mic Modeler: 3
short delay: 4
slap-delay: 4
medium-delay: 4
Long-delay: 4
Reso: 3
SansAmp: 3
Signal Generator: 5
TC|Chorus: 3
TC|MegaVerb: 2
TC|VoiceStrip: 3
Time Adjuster: 3
Audio Track: 3
C1c/g: 343
C1comp/sidechain: 343
C1comp: 3
C1gate: 3
C4 Multiband Param: 67
Doppler Auto: 3
Enigma: 3
IDR: 3
R-Compressor: 67
Renaissance EQ: 3
Renaissance Reverb: 3
SuperTap: 3
TrueVerb: 3
UltraPitch: 3600
DeEsser: 3
DLA: 3
C1-DLA: 343
UltraPitch-DLA: 3600
L1-DLA: 67
PAZ Frequency: 3
PAZ Meters: 3
PS22 Spread: 5
PS22 Split: 7
PS22 Spread (10): 5
PS22 X-split: 7
Q1-Q10: 3
L1: 67
MaxxBass: 3
MetaFlanger: 3
MondoMod: 3

ProTools Bus latency: 9

[sound and form]

nic201 said

I'm getting kind of tired of using only RTAS plugs for my individual drum tracks to keep them in phase. It seems a waste on an HD3 and RTAS does not support bussing which means that sidechains and key inputs are disabled. So much for my gates. So, in going TDM I guess its time adjuster. But, you add a plug on one track, all your other tracks go out the window and need to be readjusted.

I'm really curious about this statement. It's not immediately clear to me how using RTAS keeps your tracks in phase compared with TDM. An equivalent algorithm in either TDM or RTAS will have the equivalent sample delay.

Steven

[sharpeleven]

Originally posted by sound and form
nic201 said

I'm really curious about this statement. It's not immediately clear to me how using RTAS keeps your tracks in phase compared with TDM. An equivalent algorithm in either TDM or RTAS will have the equivalent sample delay.

Steven

I guess latency also depends on what hardware an algorithm is running on. RTAS is using your G3/G4/G5, tdm is running on digi's own tdm chips, 2 different systems each with their own bandwith, bus and processor speed...

[nlc201]

Originally posted by sound and form
nic201 said

I'm really curious about this statement. It's not immediately clear to me how using RTAS keeps your tracks in phase compared with TDM. An equivalent algorithm in either TDM or RTAS will have the equivalent sample delay.

Steven

The algorithm may be the same, but it's the way the data is handled that makes the real difference here. I won't get into the real specifics of it (mainly cause I don't know what I'm talking about) but the way TDM architecture handles audio is what really creates the latency.

TDM (Time Division Multiplexing) is basically a form of data handling where the audio is split up into little chunks and sent down the "pipe", taking turns with other data. This allows the use of this one "pipe" or data buss to carry the data of multiple channels of audio (or other data) at the same time. The problem with this is that there is time incurred between the point of breaking the audio up, sending it down the pipe along with a bunch of other audio data (from other tracks). This time incurred is latency. It is completely inherent to the system. This is the same technology that allows the phone company to send many different phone calls down the same wire simultaneously. Plugins and bussing are working in a realm where audio comes down the wire in incomplete packets rather than a continuous stream. DSP Chips also have to deal with the fact that they are processing multiple streams of audio at different intervals, etc.


RTAS is simply a form of DSP that uses the host processor (like VST, directX, etc.). Without the rigidity of the synchronous TDM architecture, data can be bussed and processed much quicker (asynchronous to the DAW). A DAW using native plugins (that aren't too DSP intensive) can theoretically be run without latency because there are less restrictions (save processor and buss speed) on when the data can be moved around and how fast. With this dynamic system, data can be read earlier from the drive and basically sent into a memory buffer for processing and then back into a buffer to be spit out at the proper moment as audio. The latency between the drive reading the data and the actual output of the processed signal can be small or great. But even more important is that the processing time can be changed as DSP power on the host becomes available or unavailable. TDM is very rigid in that everything operates on a clock.

So, an RTAS plugin (with relatively low DSP needs) can be operated dynamically using the overhead of the host CPU and can thus be played back in time with all other tracks. A TDM plugin has to go through the elaborate time based bussing and processing where audio is split up, delayed, and put back together.


This is a very basic and possibly incorrect or incomplete assesment of the situation as I understand it. If any fellow slutz can shed more light on this, I'd love to get it a bit clearer.

[Playback]

What a difference a year makes.
Delay Compensation was added in 6.4.
So forgetttabout It!!!

[Jules]

HOW-EVER!

I DO belive that the option to tweak the latency correction for NON Digi interfaces MAY NOT BE 100% workable... that is jsut a hunch, I understand the differences are possible to tweak in MILISECONDS - and perhaps not SAMPLES (as would be really handy)

Anyone know for sure?

Rail?

[animix]

[quote=davemc]

Originally posted by stealthbalance
[b]

I did some testing a last year and found phase problem with different plugins at the same sample latency. I did not test all of them and thought to myself great. Must be rounding to the nearest sample. Pretty easy to test for yourself.
Two tracks phase invert one.
Add plugs on one and other to the second.

Every one knows autotune delays more then it says?

Might test this again for myself.
Auto comp would be really nice, I use a lot of outboard now and sometimes reach for a plugin instead of outboard..

The way to fix this is........

Acquire enough ADAT I/O to lightpipe at least 64 tracks to/from Pro Tools and make sure the interface can send sample accurate ADAT sync to the second DAW that you're going to build. Nothen, build a separate PC (or buy a Mac) and a Magma chassis for your native DAW and load it up with an RME MADI rig or 3 x HDSP 9652 interfaces so you can get at least 64 tracks happening between the two DAWs. Also get yourself 4 x UAD-1 DSP PCI cards and a couple of the Powercore cards as well (once you jump through the IRQ hoops, PCI cards probably will be more stable on a PC than the FW interface-you won't have enough PCI slots on either rig to pull this off without an expansion chassis anyway). Now buy Nuendo or Cubase SX and load it to the native DAW. Set up a template in PT to send/receive live audio from the native DAW. Set up a 64 track template in SX or Nuendo to bus audio tracks to the DSP processors of choice, which will be sending these processed tracks to Pro Tools (if you choose SX, I'll send you my mix template). Now either record your PT project straight across to the Nuendo/Cubase DAW (essentially cloning it to the native DAW) or render the individual tracks in PT and fly them over to your native DAW via LAN and import them to your template (same thing, bigger hassle-trust me on this). Now, since both systems are sample accurately sync'ed using ADAT sync so that the native DAW is slaved/timelinelocked to the PT rig, just set it to receive live incoming audio from the Native DAW. You can process all of your tracks with the UAD-1/POCO DSP cards prefader, then apply additional plugins in PT as needed in real time, or use some of the incoming tracks from Cubase/Nuendo and others in PT, or both in PT. Nuendo/Cubase is seeing the incoming timecode and compensating for it automatically so, in effect it is also applying ADC to Pro Tools.

See????? So simple!!!!!!!