OSX Tattoo updated to 1.0.1
From the original Analog Industries archive. Some links and images from that era no longer resolve.
Okay, the two biggest problems have now been stomped. We’ve revved the OSX side of Tattoo to 1.0.1 to match the Windows side. This fix is primarily meant for users of PPC (G4 and G5) Macs, and it fixes a problem those users were having with the AU not validating, and the VST causing crashes.
If you’re an Intel Mac user and you aren’t experiencing any issues, there is no need to install this update.
In related news, it appears that all our products work fine in Logic 9.1 via the 32-bit bridge. We therefore officially add this host to our supported hosts. We will port the Mac side of things to 64-bit at the same time we do the Windows side. We have no timeline for that, except to say that it is In The Not-Too-Distant Future. We will almost certainly cease support for PPC Macs when we rev the products, and only offer 32- and 64-bit Intel versions, but we need to have further discussions before we commit to that course of action.
I will say that while the better G5 machines can certainly hang with the lowest Intel machines, and are still viable platforms for music creation, we are a small company, and thus we have to triage, and it is increasingly obvious that 64-bit plug-ins are more important to the consumer base than PPC-based plug-ins.
10 comments
Is the 64-bit thing really getting to be important? What hosts support it (or require it) right now?
I don't read too many other blogs, so this might have been discussed to death elsewhere. If so, maybe someone can point me to the discussion. I'm still running Leopard and XP on my 3+ year old Macbook Pro.
Well, I use Logic 9 and have an 8-core Mac Pro running Snow Leopard. And the damn thing uses one CPU for almost everything. I'm hoping that gets fixed soon, perhaps with 64-bit? Their grand central technology was supposed to fix that but no change that I can see. Maybe you need to be 64-bit to use that tech? But my interface doesn't support that yet, and I assume all of my plug-ins will break?
Also, I'm running giant sample libraries so 64-bit works for me. But I can host my plug-ins with something like VSL Vienna Ensemble Pro, I don't need the DAW to be 64-bit for that.
Tattoo crashed Live on my Intel Mac so hopefully this update will stop that too.
Actually important? Only if you make or use big-ass sample libraries.
But that doesn't stop consumers from, on the whole, buying the bill of goods if it's packaged nice enough. Witness the prevalence of the front-wheel drive car. Manufacturers found a cheaper way to make cars, and sold 'em as the end-all-be-all of vehicle safety and ease of driving, very little of which is demonstrably true, and consumers bought it hook, line, and sinker. If FWD was shit-hot, all the best cars would be made with it, no? But they're all RWD, AWD, or mid-engined. Essentially everything _but_ FWD. No good car is FWD. But somehow the auto manufacturers got everyone to believe that FWD was the shit, and there you go.
This all started when Cakewalk decided to swing for the fences and try to give Sonar a leg up on the competition by making it 64-bit. That was the birth of the Bill Of Goods known as "64-bit summing." Naturally, Steinberg, Ableton, Apple, and Digidesign have to keep up. Don't want to have any weak-ass 32-bit shit, do we?
If our customers say they won't buy plug-ins unless they're 64-bit, then we'll make 64-bit plug-ins. Ours is not to reason why, and we have mortgages and rent to pay. So ultimately, because Hans Zimmer wants to run _all_ of the Vienna Symphonic Library on one computer (and he's one of like 3 people that needs to) and because Cakewalk wanted to sell a few more copies of Sonar, the entire industry is about to get embroiled in confusion and despair.
All that said, these sorts of changes ultimately benefit us. They weed out a shit ton of freeware every time they happen, and this drastic a change has not occurred on Windows since it became a viable platform for professional music. So we're in pretty good shape, overall.
Like I often say, if it was easy, everyone would be doing it.
-CR
I'm actually not all that familiar with the "64 bit summing sounds better" argument. I don't even think I've ever heard Cakewalk push it, and I've read articles by Noel about 64 bit and spend time on the Sonar forums. But I can see how that myth might have propagated itself among less savvy DAW users.
But 64 bit is legit when it comes to me wanting to run BFD2 and a few instances of Amplitube with a Kontakt piano library on the same machine, and I don't consider that Zimmer-esque in terms of usage. Right now I've got 2GB of RAM in XP and I'm freezing tracks as a workaround to the RAM bottleneck, and it'd be nice not to.
My thing is this: my next computer will run Windows 7 64 bit, and frankly, as long as my AD effects work in a bridge program I'm fine. I just don't get the whining about non-64 bit effects and VA synths. You're right in that it won't sound demonstrably better, and as long as you have the RAM headroom to run Kontakt and similar RAM hogs, then I don't see the problem with using bridge technology for the things that don't consume large amount of RAM.
One of the big issues I can see with 64-bit plugins is dealing with SIMD assembly. I know that many plugin developers have coded operations in 4-way floating point SIMD, in order to speed things up. This works great assuming that you have 32-bit signals as inputs, but if you have 64-bit signals, what do you do?
You could cheat, and covert your input signals to 32-bit floats, do your processing, and then convert back to 64-bit doubles for your output, but I could see people getting all in a tizzy fit about this. Loss of information, and all that. Of course, any processing you perform upon a signal will result in a change of the information within the floating point number (except for pure gain changes by a power of 2, which would theoretically only change the exponent, while leaving the mantissa alone), so it would be really hard to tell if the plugin is using "true" 64-bit processing inside.
Jesus christ. I make audio plug-ins for a living and I understood that only inasmuch as it was apparently in English and not, say, Crylic.
I'm gonna have to get a nerdLeash for Sean.
-CR
so, does this mean my VW is not 64 bit?
Here's the gist of it. To convert your existing 32-bit plugins to 64-bit, do the following:
convertDoubleToFloat(in, tmp, blockSize);
yourOldRenderCode(tmp, tmp, blockSize);
convertFloatToDouble(tmp, out, blockSize);
where in and out are your standard pointer to pointers for your input and output channels (double **in, double **out), and tmp is a floating point pointer to some temporary (floating point) buffers that you allocate when initializing your plugin.
Is this a good solution to the 64-bit issue? Not really. It is more of a "fuck it, let's get this out the door so our plugins don't crash in the godawful bridge" solution. It ain't true 64-bit, but it should run like a 64-bit plugin, with the same render function, parameters, code efficiency, etc., as your existing 32-bit plugins.
The only disadvantage is that you will lose some audio precision, but for the plugins that most of the people reading this care about, this won't matter. Flangers, distortion algorithms, beat slicers - all of them mangle the audio. So why worry about the stuff being mangled that is several tens of decibels below the threshold of audibility? All of the super expensive old hardware reverbs used 16 to 18 bits of fixed point processing internally, and they still sell for bank on eBay.
For mastering limiters and EQs, sure, run everything in double precision. Most of the existing ones do this anyway, and probably do the reverse process as the above pseudo code (i.e. convert the floating point inputs to double, do the processing in double precision, and convert to single precision floating point for the outputs).
Instantly inspiring. It smells like acid to me.
Comments are closed on this post.