August 15, 2006

Reverence Update...

by Chris Randall
 





Pictured above is the AU version of Reverence. (Click that bitch for the full-sized.) Adam sent me the alpha this morning, and all seems right, except for a silly drawing bug we need to chase down. The VST versions are more or less done, so it's really just tidying up at this point, making installers, writing the manual, etc. I finished writing the presets about 20 minutes ago, and those need to be baked in, of course. But otherwise, we're getting close.


I don't want to run any potential release date up the flagpole at this juncture (since I jinxed myself several times when we were making Discord 2) but there's no doubt in my mind right now that the end of August will see Reverence for sale. We're going to put up the store page tonight or tomorrow, with some samples and the typical bullet points, et al. I'll drop a note when that's ready.

 
 
 

17 comments:

Page 1 of 2
 
 

 
Aug.15.2006 @ 2:16 PM
aKido
hey cr

just wondering: which format takes the longest to code? au? vst? windows vst? is one "better", in your opinion?

 
 

 
Aug.15.2006 @ 2:53 PM
Chris Randall
Well, we have a System now, so it's really not that much trouble to do any of the versions. The part that takes the longest is doing the DSP and rigging it for control from the GUI and automation. We do that on Windows machines with VSTs, because it's easier to port from VST to AU than the other way around.

To use Reverence as an example, it took about a month to make a more-or-less alpha version of the Windows VST. Once Adam has a proof-of-concept, I make the user interface and rig it so it can get hooked in to the VST without much trouble. Then he spends a day or two on that, then we begin tuning the controls and such for "feel." (For instance, while a filter frequency can be controlled from a linear value, it doesn't "feel" right, because the freq controls on analog gear are logarithmic. Thus, we have to tune the knob's response so that it feels right.)

Once the Windows VST is pretty much done, Adam then does a build of the OSX VST. This is usually pretty simple, as we've been doing this a while, and our Windows VST code is pre-prepared to build in OSX. Reverence built and worked the first try, for what it's worth. That isn't always the case, but in general, it's pretty easy.

Once we have VST Windows and VST Intel Mac done, Adam begins the port to AU. With Reverence, he stared the port on Friday afternoon. We take Saturday and Sunday off (or at least he does; those are my heaviest days for customer support) and he had a working AU last night, wherein we discovered a bug with one of the VSTGUI controls that needed to be addressed. (Our AudioUnits use the VSTGUI user interface, so we don't have to branch our code.) Having done so, he sent me the AU alpha this morning.

So, as you can see, it's hard to say which one is easier. The first one is always going to take some time, no matter which one we choose to do first. We prefer coding in Visual Studio, because Xcode still has an open source feel to it, and kind of blows in several respects. If Xcode were better, we'd probably use that for the major coding and do the OSX VST first. But generally, it's easier to go from Windows to OSX than the other way around, because Macs can understand most Windows-speak, but the obverse is not true at all.

As for which one is "better," AU definitely has an extensive feature set. It would be technically better. However, we can't use the bells and whistles because we're a cross-platform developer, so it's moot. And Apple keeps changing shit up (with no less than four major "updates" to the AU SDK in two years. Whee!)

I imagine somewhere in there is the answer to your questions.

-CR

 
 

 
Aug.15.2006 @ 4:42 PM
aKido
Yeah, interesting, i know nothing about coding plugins although i've been "tweaking" them since about '98.

The Mac to > Windows thing is very true in other "worlds" also, like the print world. I found that most often networking with modern printers is easy with a Mac, and can be complete voodoo with a PC.

I imagine AudioDamage has a long list of plugins you are planning on doing. Ever thought of doing polls to see which ones would be most wanted by you customer base? (maybe you'd get your plugin ideas stolen though...)

Anyway, i like your plugins a lot, they are reasonably priced. Hope to see more and more...keep 'em coming.

I am currently working on music for 3 movies (overlapping schedules, talk about multitasking!), let's just say the G5 is being used to the fullest. I regularly have Live rewired to Logic, which DP is a slave to, with a .mov running while tweaking a plugin with a Remote SL. Great situation for testing the hell out of a plugin...so if you need some testing help...i'd be glad to help out.

 
 

 
Aug.15.2006 @ 4:59 PM
peterkirn
This looks really great, Chris. I can't wait.

It's interesting to hear about your development experiences, as always. I still lament the lack of an open cross-platform standard.

Peter

 
 

 
Aug.15.2006 @ 5:07 PM
Chris Randall
It'd be a fuck of a lot less annoying if Apple just put VST support back in Logic. Then the only odd ones out would be DP and PT. I could give three shits about PT (don't hate the player, hate the game, right?), and only like 8 people use DP, so it's not really a problem then.

But since that's unlikely to happen, Adam spent months and months developing a method whereby only the actual plugin itself (what we call the "main") is unique to the format. So there's only one chunk of code we need to do twice. That made it relatively trouble-free.

It should be noted that our AU plugins are true AudioUnits. There's no wrapper or layer between you and the plug. We just developed a common parameter manager that could translate to/from VSTGUI for either an AU or VST plugin.

-CR

 
 

 
Aug.15.2006 @ 5:44 PM
emjay2772
Hi, at what point does Diamond Dave103 contribute to the overall design and programming? Or is he less of a micro-manager and more the "vision" guy?
 
 

 
Aug.15.2006 @ 5:55 PM
inasilentway
I was considering picking up Deverb when this was announced, so I have to ask: how would you distinguish the two, especially sonically? If you could only use one, which? (though I do plan on picking both up eventually, considering the bargain prices). I make mainly rock with some electronic elements, for what it's worth.
 
 

 
Aug.15.2006 @ 7:57 PM
Chris Randall
Well, internally, they're very different algorithms. They bear no resemblance to each other whatsoever, other than the fact that they both simulate reverberation.

Personally speaking, Reverence is far better than Deverb, but a lot of our customers are quite fond of Deverb, and it has found a home among a certain type of producer that uses reverbs as a special effect. For a workaday send buss reverb, neither of these are terribly good. As I mentioned on the KvR forum, you really want a room simulation for that, not a plate.

Reverence will have a very familiar and comfortable sound, and you'll immediately know where it needs to go. Deverb, on the other paw, is somewhat weirder, and has its own thing, which you'll have to figure out how to use in your music appropriately.

As soon as Reverence is released, we're going to port Deverb to VST2.4 and AU, and update its GUI to match Discord 2.

-CR

 
 

 
Aug.15.2006 @ 10:51 PM
Adam Schabtach
Dropping in a little of my own view of our development process: I (usually) start a new plug-in on Windows for a pretty silly reason: when we started Audio Damage, my main PC was a much nicer machine than my main Mac. My main Mac was a horrid Quicksilver G4 that, despite me making a number of physical modifications to it, was so noisy it was unpleasant to be around. My PC, on the other hand, was a l33t handbuilt machine that was both faster and quieter (and cheaper) than the G4. It also had two 17" LCDs vs. the Mac's one LCD. Also at the time, Visual Studio was a much nicer environment than CodeWarrior, and Xcode wasn't even usable. So in short I would do the bulk of my side of the work on a new plug-in on Windows simply because it was more pleasant to work on my PC than on my Mac.

Rolling the clock ahead to present day, I start on Windows mostly out of habit and partly because of the same reasons as before. My current PC is another handbuilt machine that's even faster and quieter than the old one. (The old one now does full-time duty as my main music computer.) My current Mac is an ICBM iMac. It's a nice-enough machine--certainly nicer than the three Macs I purchased before it, which were all lemons in one or more ways--but it's still not as nice as my PC and Xcode still isn't as nice as Visual Studio. The iMac would be nicer if I could plug a second monitor into it, but I can't because there isn't room on that desk for a third monitor; the old G4's monitor is still on that desk for compatiblity testing and I can't hook it to the iMac because Apple, in their infinite wisdom, used a weird-ass proprietary cable for that particular LCD.

As for which plug-in format is better, well, AU does have some nice features that VST lacks, mostly having to do with how parameters are presented to the host. There is no theoretical sonic difference: both operate on 32-bit floating-point numbers at whatever sampling rate the host specifies. IMHO there isn't anything about AU that's so dramatically superior to justify its existence, and given the way Apple completely fell down on the documentation job and make life totally miserable for us developers in the beginning, it really would be much simpler for everyone if they had just adopted VST along with the rest of the world. We'd have more time and energy for developing new plug-ins (and supporting our current ones) if we didn't have to cover both VST and AU. But our customers have voted with their dollars--for which we thank you!--and so we do both.

As Chris said, I've put a whole lot of work into developing an architecture that allows us to use the same user-interface code for both, and to move the rest of the code from VST to AU with a fairly small amount of effort. In some sense that architecture is really what describes our plug-ins, and VST and AU are special cases of that description. Yes, it's not a "wrapper". Our AUs are really-truly full-Apple-spec AUs, and at the risk of contradicting Chris's assertion we do take advantage of many of the AU bells and whistles. (E.g. our plug-ins do a much nicer job with the AU parameter-information presentation facilities than Waves products do.) We looked into using wrapper technology in the beginning and decided we'd rather do it by hand ourselves. I'm something of a fanatic about not basing my products on other people's technology.

We do indeed have a list of plug-ins that we plan to do; we have no shortage of product ideas. I suppose polling our customers for their preferences would make some amount of sense, but Chris and I have this selfish habit of building products based on our own preferences and whims rather than being motivated by market considerations. :-) I am partly joking, because obviously we do pay attention to what our customers tell us, but most of our products came into existence because one or the other (or both) of us wanted a particular plug-in for our own musical endeavors and couldn't find it on the market. Happily it seems that many other people share our tastes.

--Adam

 
 

 
Aug.16.2006 @ 1:13 AM
mok
OK - finally some love for the 200... one Q: does the plug do the super-cool infinite reverb like the real thing? I love my 200 for that alone, and its chamber is just the donut's glaze.
 
 

 
Page 1 of 2
 
 

Comment:

 

Sorry, commenting is closed for this blog entry.