My specs: Pro Tools LE 7.4.2 / Mac Pro - 2 x 2.8 GHz Quad-Core Intel Xeon - 3 GB 800 MHz DDR2 FB-DIMM Memory / OS X 10.5.4

I just downloaded and installed a demo of Tube Saturator today, and I really love the way it sounds- I have never been instantly thrilled with any saturation plugs (I have tried many), so this was a big first for me.  I want to purchase it, but immediately I was experiencing an issue…

I’ve found that wherever I put an instance, be it a stereo or mono track, I get sporadic issues with any audio passing through the plug-in.  Basically, I sometimes get a loud pop right when I try to begin playback, and then no audio outputs from the plug-in (although playback continues and has never ground to a halt). It does not seem to be CPU-related, and thus far it does not seem to be predictable in any way.

Right now I have an instance on my master bus, and also an instance on my mono bass guitar track, and sometimes the issue only occurs with the bass track but not the master bus, so I just don’t hear any bass guitar; sometimes it occurs on the master bus, so I hear no tracks at all.  Stop playback…start playback, same issue (maybe); stop playback…start playback, everything is fine until I stop playback and try to restart it (maybe), but again, there is no pattern to this.  The issue also occurs without the mono instance in the session.  If I wait for reverb tails to die out before attempting to start playback, this does not seem to help. 

Also, less frequently when this problem occurs, the DAW meters on the track with TS will stay slammed into the red after stopping playback, as if there is some internal feedback occurring (which Pro Tools automatically mutes internally), and there is no way to stop it (including removing the TS instance) except for restarting the session.

If there is a remedy to this I will buy the plug-in immediately!  I might buy it anyway because I like it so much, but certainly I wouldn’t be able to put up with this forever

Thanks.

Hi Aaron, what sample rate are you running your projects at?

Ah yeah I forgot to mention that…  This is 24 bit/44.1 kHz

Sorry for the delay, I wanted to also ask what your audio buffer size is (and if the behavior changes when you change it to different settings)

No worries…  I’ve tried setting the buffer high and low, as well as adjusting the amount of cores that Pro Tools is allowed to access, and it makes no discernible difference.  Also, I “trashed the prefs” the other day, which can sometimes clear up buggy plug-in behavior in Pro Tools, but unfortunately there was no change in this case.

A little bit more to add to this…  I normally always work in 44.1 but I just finished some mixes in 48, and the same issue exists.  Also, I previously reported that when the meters stay slammed into the red, the only way to stop it is to close the session and go back in (deactivating or even removing Tube Saturator doesn’t stop it); I realized today that if I deactivate the entire track, then reactivate, the meters return to normal.  Also, the same pop sound I hear when audio gets stopped, also occurs when deactivating the track.  Hope this helps…

Hi Aaron,

Hard to know what’s going on. My fear is that it is a numerical instability in
the algorithm itself, which is overflowing when you start playback. Hence
you get a pop and clipped meters. But… if this only happens at playback start
it could be something more mundane, a software bug related to RTAS implementation
which causes the plug to start up in a bad state.

My question is: does it only happen on playback start? Seems like yes.

Also, every time this happens, is there a pop and the meters are clipped?

Thanks,

Bill

Yes, it only occurs when playback is already stopped and then I try to start it.  And yes, the pop always causes the meters to clip, although the pop of course doesn’t always create the “permanently slamming meters/deactivate then activate track to clear” scenario.

Aaron, do you have the Ignore Errors During Playback and Record enabled in your Playback Engine Settings?

Also, I’ve found that I can improve Tube Saturator performance (i.e. more plug-in instances) by DECREASING the Host Processors setting way down.  But even on a fast multi-core system, the heavy CPU requirements of the plug-in’s circuit modeling is going to make it difficult to run more than 2 or 3 Tube Saturators in a project.

Sorry for getting back so slow this time.  I gave it a shot for a while with the “Ignore Errors…” enabled, and it made no difference.  At this point I’ve kind of tried every combination I can think of as far as CPU and buffer settings go, and it seems to behave the same way no matter what.

Anyway, my demo ran out but I’m gonna buy the plug regardless.  I’m gonna be ditching the Digi002R for a Lynx Aurora and PT9 soon anyway, so since I haven’t seen any other Pro Tools users making note of this issue, I’m assuming it won’t materialize with a different version of PT.

Thanks for the responses!

Just wanted to chime back in here again.  I just finished a big system overhaul- I’m now running OS X 10.6.3 (previously 10.5.4) and Pro Tools 9.0.2 (previously 7.4.2), now with 11 GB of memory (previously 3 GB)...and I’m sorry to report that the same problem is still alive and well.

I did buy the plug back in February, because I absolutely love the sound of it (across the master bus especially), but it’s quite a pain to work with it for a bit, then get tired of dealing with the pops and blockage, deactivate it for a while, and repeat the process again, eventually making the final bounces through it.

Anyway, if there’s some way you guys could diagnose and address the problem, or if I could be of any help by testing betas of updates or something, please let me know!

Hi Aaron,

Thanks for the update. We haven’t had any similar reports, but it seems likely there is a bug in Tube Saturator causing this. It’s reminiscent of a bug we had in the vintage compressor, which was very hard to reproduce, that we finally tracked down to a bug in the Mac C compiler. Our only hope to track this down would be if we can reproduce the problem in house (so far not), or alternatively we could build a special version to capture a trace of the offending behavior and have you run it and send back a log file for diagnosis. We’re too busy this week but we can try to do something next week. Please ping us and remind us.

Thanks,

Bill

Thanks for the quick reply, Bill.  I will check back and hopefully be able to help you guys figure this thing out!

I can at least reproduce the problem it seems- so I’m doing some profiling of the CPU usage and investigating further to see what I can find out.

Ah, right on!  Again, I appreciate the timely personal correspondence on this, very cool.