I just noticed this yesterday - if I apply The Rocket to one of the 4 busses in Harrison Mixbus, it works fine until playback is stopped. If I start playback again the right channel output is muted in the Rocket. If I delete the Rocket from that buss, playback is thru both left & right channels. Someone else verified the same problem.
Is this a problem with the Rocket, or with MixBus?
Well, I certainly don’t know of that problem occurring elsewhere…did you try the betas linked on the front page? downloads.stillwellaudio.com/stillwell/beta/
Those were updated with framework changes and should have incorporated all bug fixes to date.
Let me know…
EDIT: Are you using AUs or VSTs? MixBus is Mac-only, right?
I’ve bought a copy of MixBus and am downloading now. I’ll let you know if I can duplicate the problem. If I can, then I can probably fix it.
I know I got the updated versions after you fixed them for Snow Leopard compatibility. Are these the same betas or are they newer? Yes, these are the AU versions.
I’ve updated as of about a day or two ago…so unless you JUST downloaded them, they’re likely out of date.
Hmmm…I can confirm the problem. Doesn’t happen on the master, but does on a stereo track or a mix buss. As best I can tell without going into full-on debug mode, MixBus is dropping connections to the plugins when the transport stops. When it starts back up, it’s fooling the plugin into thinking it’s on a mono channel by which inputs/outputs are connected. Our plugins try to detect honest-to-goodness mono channels and cut CPU load by only processing the left channel (which is what the mono input & output is routed to).
Now…is this a problem with our plugin(s) (it does happen to other plugins beside Rocket), or is it a problem with MixBus? Depends on who you ask, I suppose. The plugin doesn’t do this on any other host I’m aware of, so I’m tempted to say it’s MixBus’ problem. I’m perfectly willing to work with them to “correct” the issue on my end if they can tell me what they’re doing that’s confusing my plugin.
Worst case, I can try to detect MixBus (or Ardour) as a host and just lie to it and be all stereo, all the time.
If you want to report to Harrison, you can have them contact me at scott at stillwellaudio dot com.
Well, if I disable the check for mono instances, the problem goes away. That tells us where the problem lies, and gives us a worst-case chicken-out mode. I think for the moment I may just look for Ardour and bypass the mono check. I’ll post when I have updated builds.
Argh…operator error. I was testing on the master buss, not a mix buss. Even when I defeat my mono check, it still does it. This pretty much has to be an Ardour/MixBus issue.
I made some updates anyway, and will post them later today.
sigh It annoys me when I make stupid mistakes in public. Incentive to NOT DO THAT anymore.
For what little it’s worth, I’ve posted updated beta builds. They won’t fix the issue in MixBus, but since I was already in there anyway, I cleaned up some code and did some tidying up for thread-safety.
I decided to use Event Horizon instead (needed to bring the vocals up) and it works like a charm. FYI.
Say what??? Every Stillwell plugin I’ve tried so far has exhibited the same problem…at least on a buss. Didn’t try the others on individual tracks, though.
No, I’m using Event Horizon on a buss (mixbus 1) along with SFX Machine RT (using this as a delay line - will you be making a delay plugin anytime soon?). I can start and stop playback with no right channel dropout.
Dude…score. If you put ANY Apple plugin in front of any of mine, the problem doesn’t occur.
Workaround: Put Apple’s AUSampleDelay as the first plugin on a chain. It defaults to zero samples’ delay and thus does nothing, but it lets Rocket or anything else work.