Starship Krupa

That's one of the goals of freezing an instrument/synth track, innit? Not only do you get the benefit of the FX' resources being freed up, you get the synth itself out of the picture as well. Not just the CPU, but I just checked what you said and CbB seems to be pretty good at unloading the synth from memory. I see that even the blessed Ref. Guide (BRG) doesn't do the best job of explaining this. It just says "to reduce the amount of CPU power needed," but thank heaven it extends to RAM as well. That's a dearer commodity around the Krupa household at the moment than CPU cycles. My CPU cores seem to mostly just sit around waiting for me to load an iZotope plug-in. For the benefit of others, from my experience with other DAW's, what's supposed to happen with frozen tracks is you get a fully-rendered audio version of a track so that you can use it for mixing, overdubbing, whatever and not incur the overhead of whatever plug-ins you loaded on the track. The host should "park" any track FX or synths until you unfreeze it, resulting in more CPU and memory for the other tracks to play with. This parking happens in a variety of ways to varying degrees of effectiveness depending on the host. Some hosts even let you decide what quality you want to use for frozen tracks, like you can use .OGG for frozen tracks in Mixcraft I think. It's good for when you want to track a lead vocal at low latency with this huge virtual sampled orchestral backing. Bang, freeze everything to OGG Vorbis and Mixcraft has the resource footprint of an MP3 player while your singer is singing to the LA Philharmonic and a rock band with a zillion effects. My hunch is that freezing an instrument track with FX is probably simple as things go, the DAW just needs to render a single track as it normally would and then unload the plug-ins. But un-freezing an instrument track seems like a task that would be fraught with a bit more danger. Depending on how the host turns the synth off, turning it back on might get weird. I've looked around and the only button for turning a synth plug-in on or off that I could find was in the Synth Rack, not in the Track Header or Console or plug-in UI. And what does this button do, exactly? Does it just grey out the UI or route audio around it or partially unload it from memory or what? It seems to reduce the memory usage a little more than freezing. Do does the host turn on the synth first and then the FX, or the FX first, or what? Lots of decisions. I tried to get some answers to these questions from other companies and crickets chirped. You know, stuff like "when I bypass a VST, does the audio route around it? Should I completely delete a VST from my plug-in rack to get it out of the audio path?"

It doesn't necessarily follow that there was something in the VST3 spec that allowed Melodyne to incorporate ARA, it just means that Celemony went along with the VST3=more advanced technology narrative. It's also a convenient way to filter out older hosts, because no host that only supports VST2 is going to support ARA. They might also have done it to get chummy or remain chummy with friends at Steinberg. I do you a favor now, you do us a favor down the road. As far as Vocal Rider, I just took a peek at it, and as I suspected, it does its thing via sidechaining. VST3 allowed Waves to have a button called "Sidechain" in the VST3 versions of its plug-ins. If you look at the instructions for the AAX and AU versions of Vocal Rider, they give the non-PlaySkool version that most other plug-in companies still use, where the host automatically sees that the plug-in has external inputs and creates routing for them. Nice position Steinberg was in: if the programmers of your host can't or don't want to figure out how to do that, like with Cubase and Nuendo, you can take the easy route (ha ha) and just come out with a new plug-in spec that forces the plug-in manufacturers to build sidechain routing into the plug-ins themselves. Make them do it for you! When I went to Steinberg's page on the (B)ST3 "revolution" and read the part about how plug-ins were now going to support this new thing "sidechaining," I had to stop for a moment and blink because I was wondering if they were talking about the same thing I had been doing for years. Nope, same thing, routing audio from a track to a plug-in on another track. Wow. Look around on the DAW forums, and the only people who think that the advent of the VST3 spec rocked their world are Cubase and Nuendo users who say that sidechain routing used to be a big pain in the....sidechain. Everyone else says they work exactly the same except maybe they crash more, and some people are worried that eventually hosts will stop supporting VST2's and then their favorite plug-ins will be useless. I like the VST3 spec for exactly one reason, and that is because in practice at least, it seems to set a standard location for plug-ins. I don't know how well that works out for people with humongous VSTi sample libraries, but I don't like chasing .DLL's all over the place trying to find ones that wound up in C:\Program Files\Steinberg\Vstplugins or whatever. Waves' installers are great, funny even, for putting their plug-ins in every place a host is likely to look for them.

That is pretty cool, and what I consider "above and beyond the call." Of course every company has to decide how they are going to handle this. Is the issue with the host's code or the plug-in's code? Is the plug-in dev interested in coming up with a patch? How much will it cost to come up with a patch? Do enough users use the plug-in that it's worth bothering with? It's funny what politics can come into play. (cough-cough) years ago I was on the QA team for a high-end photo editing program that was positioning itself as a challenger to Photoshop. Yeah, right? Well, if nobody had challenged Pro Tools, we wouldn't be here today. Our program could host the same plug-ins that Photoshop could, and photo plug-ins are subject to the same kind of weirdness that audio ones are. They could refuse to load, crash, crash us, crash the whole system, etc. Some of these plug-in companies I've noticed, are still around today, doing some amazing work. The thing was, our programmers HATED anything to do with these plug-ins with the fire of a thousand suns. This was for a number of reasons. First, Adobe had "created" the spec to work best with Photoshop just like VST was "created" to work best with Cubase. When did Ableton start supporting VST? Only in their last revision or something? In Pro Tools you still need a 3rd-party wrapper? The truth with these specs is that especially at first they're usually pretty sloppily drafted, and they're drafted after the programmers at the company are already coding plug-ins. These are programmers who have access to every line of code in the host program, so they can do it without the spec anyway. On the host side, what incentive do they have to make things easy for their competition? Just being nice? Is Steinberg going to smooth the waters for Digidesign and Cakewalk and PreSonus and Ableton and ImageLine and Magix? Is it any wonder that so many rejected VST for so long? Cakewalk bet on DX, Digi went their own way, the others have their own proprietary systems and VST support is or was a premium option. So outside Adobe, all we and the 3rd party plug-in devs had to go on was this roughly-drafted spec that may not have been drafted to encourage Adobe's competitors to succeed in the first place, knowhatimean? Second, the people who had made these plug-ins only had Photoshop to work with and test with, and they were not that enthusiastic about possibly having a second program on the scene to make sure their products were compatible with. It was hard enough to work with Adobe. They had little interest in seeing us succeed. Third, third-party add-ons in general are just a pain in the tuchus to deal with. Introducing elements over which you have no control into your system is inviting trouble. What this all boiled down to was they would give us these great state-of-the-art plug-in packs to play with, and when they would crash the snot out of our program, our poor devs had no leverage whatsoever with the plug-in houses and their devs because their code had been burnished to a fine gloss to work smoothly with Photoshop. So any query about bad behavior was answered with "works fine with Photoshop." Whether it obeyed the published spec or not, all that mattered was "works fine with Photoshop." So hard to pinpoint the blame when a VSTi plug-in was coded using the Steinberg SDK and tested in-house and in beta in Cubase and Reaper and StudioOne and then the developer gets a report that CbB chokes after their synth comes out of a freeze. CbB works fine with hundreds of other VSTi's doing the same operation. Sektor works fine with a dozen other hosts (if you flip the VST2/3 coin a couple of times). CbB probably didn't exist in its current form when the synth was developed. Whaddaya bet that the next rev of Sektor fixes this issue?

I'm having a conniption fit over here. That's treating your product as a public beta. No wonder SONAR got a reputation for being a crash test dummy. BandLab seem to be running a tighter ship. You know, developers hate shipping software with bugs in it, it's like if we shipped a master with unwanted digital clipping in it or a dropout or an accidentally muted track or whatever. To me, this would be like if every record shipped with 5 different but similar mixes/masters, and not the "dance remix" or "2019 remaster" but the one the drummer did while the rest of the band was out buying brownies at the dispensary, and the one that the guitar player and his girlfriend liked, then the one that the producer and the record company liked, then one that had a killer feel but Don screwed up on that one part but they left it in, then one that everyone thought sounded good but the hi hat sounded ice-picky in the car, and the consumer is supposed to pick whichever one works the best on their system. If the "Don drops a clam" mix sounds jarring, try the one with the forward guitars. Don't sound good? Try the one that's all drums.

Yes, and I am amazed for the reason I said.

Oh good heavens, things were worse than I thought. Really? Wow. I wasn't kidding when I said that I'd never seen (nor heard of) any software company doing that, and given the egos I encountered when I was in the software biz, I find it astonishing. An OS update, yes, but they're usually touting the latest update as having fixed everything.

I've never seen any software company do that and it's hard to imagine one doing it. You get why: it's the equivalent of saying "we have so little faith in our QA process that we have this handy option for you to get rid of the latest and greatest improved version in case we've fscked it up." It will simply. Never. Happen.

Oh boy, can of worms there. Glad it's working. Cakewalk will substitute a VST3 for a VST2 if the plug-ins have a certain internal identifier set. Not every company uses this, so sometimes both plug-ins will show up in the pick lists in Cakewalk. Meldaproduction famously does not use the matching internal identifier, so I have to disable my 38 Meldaproduction VST2's using the Plug-In Manager. It's kind of funny that they thought that the "more advanced" VST3 would be the one that would have the problem! I'm not surprised, though, as my other DAW, Mixcraft, really doesn't like VST3's, to the point that as much as possible I avoid them when using Mixcraft. A sidenote, I'm just venting and it won't help paolo a bit, but this is the kind of thing that had me spitting nails when I dug more deeply into what was really behind Steinberg's much-touted VST3 spec and how little it actually covered and how little it was likely to improve things. Protecting the host and the plug-in from each other in case of errors, a standard protocol for trapping and handling errors, those are things that could have been part of a new VST spec that might have actually improved things, but instead what the industry got was mostly forced duplication of features that other companies had already implemented like sidechaining and GUI scaling. There was no big revolution where suddenly with VST3 my plug-ins started getting scalable GUI's and sidechaining, they all already had it if it were applicable. All I saw was plug-ins started to be distributed in both formats that worked exactly the same. Except the VST3 versions had more of a tendency to crash. I'm sure that for people who write these plug-ins, they write the code, then the development environment poops out various versions of the plug-in at compile time. We're at the mercy of the development environment and compiler when it comes to whether they're going to work well.

I like to have as much control of the end product as possible, so I prefer to supply all the formats myself as close to the source material as possible. If I let the client do this, they may take the FLAC I supply and make a low bitrate MP3 using a crappy converter, then when someone asks them for an AAC file, they may take their crappy MP3 file and use an even crappier converter to make a low bitrate M4A file and so on. And their converter program may apply its own limiting or compression or EQ or heaven knows what. Most people don't even know the difference between a 320K MP3 and a 120K one, and if a client wants "an MP3," I make sure to supply it as a 320K using the best CODEC I have available (Sound Forge, Cakewalk or MediaHuman). If they just say "send me the mix" I send it as a 320K M4A file, which everything will play these days. I also take the trouble to edit the internal file tags using MP3Tag so that when they play it back, the track name and their name (or my name) as artist scrolls across very nice in their player and my name as engineer, producer, etc. is embedded in the file if I want. This has resulted in clients and friends remarking that stuff I did for them sounded better and "how did you make my name show up on the car stereo?" ? And it just takes 5-10 minutes extra if that.

Wellll, see my snarky parenthetical comment about a person's issue usually being something other than an update to Cakewalk itself. I just do not believe that there are enough instances where an update to the CbB software actually hoses someone's DAW system for it to matter. What usually seems to happen, in my observation, is that an upgrade ships, then someone's setup breaks a few days later and the upgrade is only one of the things that has changed by that time, including updates to Windows 10, plug-ins, drivers, etc. I've noticed that the cries for rollbacks seldom happen right after an upgrade ships, which is when you would expect to hear them if they contained code likely to have great negative effect. To be fair, when someone is in ripping your hair out troubleshooting mode, it could come in quite handy to be able to at least eliminate the Cakewalk update as the source of injury. I'm putting this up as an answer to an oft-asked question, and in case savvy users like you and Mark want to archive older builds. I really, really wish there were a Tips 'n' Tricks subforum on here. I know there is a Tutorials forum, but that is for posting links to offsite tutorials. Steve Cook has already posted it more than once, but not with the flashy title as its own topic. This one can be bump't if we get tired of people asking.? As Mark said, it's for peace of mind. Not what I would consider a necessity. I don't actually do it myself. Each build of CbB is thoroughly raked over by a horde of beta testers, and if there were any further nastiness it would be intercepted instantly by people who automatically let BA have its way and would post on the forum. The devs would code up a patch and push it out right away. So for people in the middle of mission-critical projects and whatnot, simply waiting a few days after each version drops is what I would consider sufficient insurance against bugs. Cakewalk: The Vanishing was about the worst bug I've seen make it into the wild in the BandLab era, and it was squashed pretty quickly.

That is weird with a beard. I tried Googling the error message and got zero results. BandLab support is your best bet. Offhand, I would guess that it will turn out to be a folder permissions issue, that Cakewalk is trying to write to a folder that you as a user don't have access to for some reason. I have no suggestions as to how to fix it from here. It's the weekend, maybe tomorrow you will hear from support.

This is an oft-broached topic, people bemoaning that something doesn't work right after an upgrade or how do I roll back to the previous version, yada yada (before figuring out that it was something else that changed on their system that broke it), so I'll share a tip. Typically when CbB is updated, the major changes only occur in C:\Program Files\Cakewalk\Cakewalk Core (assuming you have installed Cakewalk in the default location, if you have not, adjust accordingly) If you want to upgrade to the latest version of CbB yet also retain the ability to run the previous version, all you need to do is make a copy of Cakewalk Core before you let the upgrade do its thing. If you want to get fancy, you can rename the copied folder to reflect exactly which revision of the program it contains. In this way you could have 2 or 3 revisions of CbB sitting there if you wanted to. To set this up: Right click on C:\Program Files\Cakewalk\Cakewalk Core and select Copy. Right click in the C:\Program Files\Cakewalk folder and select Paste. This will result in there being a new folder with the name "Cakewalk Core - Copy" which you can rename "Cakewalk Core Previous" or whatever. Then let the upgrade run its course. If you want to run the previous version, all you need to do is run the Cakewalk.exe that is inside the "Cakewalk Core Previous" folder, which you can do directly or from a shortcut.

I agree with the others that it sounds as if the client has used a demo version of an audio conversion program to supply different formats for distribution. I gently suggest that this is an issue of client management. Ask them what formats they require for distribution so that you may deliver them in those final formats. Instruct them not to do any conversion themselves, that you will be happy to supply any further formats if required. This will prevent any future such problems. If this is not practical for whatever reasons, I recommend that you supply your files in FLAC format and that the client use MediaHuman Audio Converter to do their conversions. MediaHuman is 100% freeware and does not impose any watermarking. It is easy to use, available on Windows and Mac OSX and handles conversions to and from all popular formats. https://www.mediahuman.com/audio-converter/ I hope this helps!

Go to your Cortana area and type OSK to bring up the Onscreen Keyboard. In the lower right you will see a button for ScrLk. Click it. Thanks for asking this, because I noticed that my Dell Latitude also lacks a Scroll Lock key and it made me figure it out for myself!

And how does that opinion help the OP? Sometimes it is and sometimes it isn't, and sometimes it's a grey area. One thing I suspect, if the OP were to post this screen grab in the plug-in manufacturer's forum, the chorus of "Sektor works just fine in every other DAW" would be deafening.? All we know at this point is that Cakewalk is crashing after paulo unfreezes a Sektor track. What to do? Larry has it right. Contact support, send them the dump file. Maybe there's a configuration or workflow change that can be made in Cakewalk that can prevent this. He should also check with the company who make Sektor to see if anyone else has had similar troubles. The usual troubleshooting questions apply: is this in just one project or any project that uses Sektor, does it happen with a brand new project started in CbB, etc. I have had plug-ins that started working incorrectly after updates to a DAW, and it was determined that the way the plug-in was coded was the problem. The plug-in manufacturer was unresponsive (Sonivox, notorious for this sort of thing). But it worked fine before my DAW made the change, so whose "problem" was it really when my DAW company were the ones who broke the functionality for me and the other users of the VSTi? Next rev of the DAW, they made some changes to other stuff and it mysteriously started working again, so it was all good in the end. No matter what the sins of the plug-in, the host may either trap errors gracefully or fall flat on its face. A correctly-coded plug-in may also expose flaws in a host by making calls to functions that most other plug-ins don't. For these reasons, it's not really helpful to blow it off with "it's probably the plug-in's fault" and leave it at that. Having said that, it's also kind of silly to title the thread "everywhere" a crash when all it is is one plug-in. I mean, come on, it's frustrating, but how about something more descriptive?

Are you going to edit the Wikipedia page on SONAR? If so, it would be great if you could do some tidying in there as well. I don't know who thought it would be a appropriate to list every single plug-in effect, great and small, included with each revision, but they were wrong.?It's historical now, but SONAR deserves better than that mess 1. If you are not 100% sure about the dual monitor thing, write what you are sure of or cheat a bit and say that SONAR was "one of the first" or "the first commercially successful DAW" or "the first DAW to successfully" implement dual monitor functionality. That sort of thing may be frowned upon, but it's more important to give credit where it's due than it is to be 100% ironclad IMO. Besides, if someone reads the entry and suffers from knicker entwistment as a result, they are just as free to revise the entry as you are. 2. If you are not 100% sure, again, you can say "most DAW's" or "all in the top 10 list," with an external cite to Music Radar's yearly Top 10 list, which Wikipedia's reviewers love. It's hard to say "all" about things like software features, because there could be some tiny abandoned freeware program somewhere with a cult following of 25 users that never had dual monitor support.

You were asking a question you knew the answer to and posting the answer to it at the same time. You're too darn sharp for me. I bet I didn't even get the answer right! I do wish you'd take my name off that statement, 'cause it looks like I said something negative about you personally and I do not wish to do that.

I don't want to be "that guy" suggesting a workaround where you made a feature request, but my DAW chops were honed in Mixcraft, where folders and submixes are the same thing. And glory be, you can nest those puppies as deep as you want, which is fantastic, and I wish CbB worked that way. So since it was so easy, I got in the habit of whenever I ran into something like your stray lead guitar, boom, that's another submix/folder, and you can do what you're talking about and export a stem right from that submix/folder. Unfortunately CbB doesn't work this way, but I still do. How I'd emulate this in CbB is that I'd just slap another bus in there called Stem Guitars (which is routed straight to the Master Bus for mixing purposes), and send the Guitars bus and the stray lead guitar to the new bus and it's pretty similar, although maybe not as tidy. Then I can export a "guitars" stem right off that bus. The routing can be accomplished quickly with astute use of the control key to Quick Group your Lead Guitar track and Guitars bus then hold down Ctrl when you route one of them to your new Stem Guitars bus. Both of them should wind up being sent to the new Stem Guitars bus. If you leave ProChannel turned off on the Stem Guitars bus, you should have just what you need. You can even make a new folder and plop all your guitars in there if you like. I dunno, maybe this is how you're already doing it, but that would be my recipe. I'd probably wind up making a template with 17 folders and buses with those stem names on them ready to route everything to if I had to make deliverables that fit that description on a regular basis. They would all be routed to the Master bus. Then all my usual buses for Strings and Drums and Guitars and whatnots would be routed to them as appropriate. When it came time to deliver stems, I'd be able to pull them from those buses, either directly or by muting the other buses. Am I trippin'? Would this work for someone who regularly has to deliver their work in stems? We're doing what you suggest, but using buses instead of folders.

That is a very important type of user, just look at the success of Ableton Live and FL Studio, both of which started as nothing but that and flowered into fuller-featured DAW's. Heck, BandLab's other DAW's, the ones that run in Chrome and on iOS and Android are loop-oriented. And there's the hybrid user, not just "the kids," but people who do backing rhythm tracks of drums and bass with their vocals as audio. MIDI and loop tools need to be strong for them, too. I sometimes compose drum parts using the DAW, then play live to them while recording, using the MIDI track in place of the metronome. I found Admiral BumbleBee's to be a very thorough critique, and one that I couldn't disagree with overall. He may have gotten a detail wrong here or there, and personal opinions are just that. Having worked in the software industry myself for many years, that is one of the basic reasons that bugs persisted in shrinkwrap programs, and in truth, one of the reasons I got out of software development. With the traditional licensing model, there is a built-in disincentive to fix bugs, and it's because no, people don't open their wallets for bug fixes, they open them for new features. Programmers' time costs the company the same amount of money whether it's spent fixing bugs or coding new features. New features=more licenses sold=income. Bug fixes=loss. Businesses exist to generate income. Over a long period of time, a program such as SONAR could lose new licenses by gaining a bad reputation for crashing and having half-assedly implemented features, one I would say after working with the program as it was in April of 2018 not entirely undeserved. But it would also take a long period of time to correct that reputation. A reputation is a difficult thing to change, of course, especially once damaged. How many of us have worked at companies capable of that level of foresight vs. immediate profits? Yeahhh. I'd love to see TPTB reach into the Feature Request bin and pull out a couple. I believe if you don't do that every once in a while, people give up and stop making requests. That's why I was so pleased to see the Ripple Edit Indicator, even though I personally seldom use Ripple Edit. So many people had been begging for it! And they not only got it, but one with multiple modes. Now it seems like the Matrix would be the hot one to put a bit of ingenuity into, since Cakewalk is one of the few programs to offer such a feature. I'd like to learn how to use one of those that is really good.

Please edit your post to remove or correct the false quote attribution. Yes, improvements do require criticism, and I am glad that I experience this new forum as being much more welcoming of comments and viewpoints critical of the software than the old one was. If you look at any of the prominent threads centered around people with grievances, you'll see that "dissenting" voices were anything but silenced, rather the lead developer himself usually drops into the more contentious threads to see if he and the other developers can collect data that can help them fix any That's a very good question, and I'm sure you'll be delighted to know that there's a very good answer. There's a section of this official forum for feature requests and other ideas called The Feedback Loop, and it currently has over 1,200 messages. I've posted in it, and so have others, and oftimes these feature requests come with attribution as to what other program has this feature. So you're right, and it's already happening. It would be great if you'd take whatever constructive suggestions for Cakewalk you have to The Feedback Loop and post them there so that all may benefit.

In my limited experience Waves are pretty good about keeping you up to date with the newest patches; and if you choose to update your licenses to the latest (v10) they're also pretty cheap on the upgrade path.

"Registered Wikipedia editor." It's kind of like being a registered sax offender. ? Hey, you or anyone else could add on to the article, I'm probably one of the least knowledgeable people on here to be doing it. You're a good writer, so I encourage you to take a swipe. I see a @Jim Roseberry byline, maybe he could do a spot of Wikipedia editing in the interest of historical accuracy. While you're at it, put in a paragraph or two in the articles for Los Angeles talking about your role (I'm not worthy!). Seriously, X fans would be fascinated. Not too long ago I added a link to "Gaslighting" in the See Also section of the entry on Steve Jobs' "Reality Distortion Field" in front of a friend of mine and he was astonished that I could change Wikipedia just like that. ? He's a vintage drum enthusiast, along with having other interests, and would make a good Wikipedia editor himself. I told him, just click on the word "edit," and boom, you're editing Wikipedia. You don't even have to register, but it has its benefits. It's easier to make changes "stick" if you have a history of making changes that have been reviewed and have been allowed to stand in the past, so that the people who do the reviewing know that you're not prone to vandalism. My rep is solid, so my edits don't get flagged for immediate review. I clean up vandalism and fix other people's spelling and grammatical errors, so I'm a "good guy."

Oh, it wasn't all that. What you see there is pretty much how it was before the overexcited editors got to it. If you are a registered Wikipedia editor you can go back and see what the edits were and who did them, so I just sort of regressed it. There's an issue with Wikipedia in that it likes references in the form of other publications, so there would ideally be an interview to refer to. I mean, anyone can theoretically write anything they wish, which has resulted in problems with articles on controversial topics such as biographies of politicians and other public figures, but outside citations are preferred. Oddly enough, at one point at least it was apparently considered taboo for someone to edit a page about themselves, so I guess if Mike Nesmith goes into the studio to do some remastering of the First National Band records, he should have one of his fans add that to his Wikipedia page if he wants it on there. On behalf of CbB, I have been going around to the different pages that list DAW's and substituting Cakewalk by BandLab for SONAR where appropriate, or adding it where it's been missing from the lists, and also updating things like file formats that it can handle (which was way out of date) and support for ARA2. Our favorite DAW is now looking more favorable in the comparison tables on Wikipedia. Still, there's no main page for Cakewalk by BandLab. I'm looking forward to outlining the "free subscription" licensing model. ?

I just downloaded and messed about with Visual Mixer and Relay and I haven't tried them on anything else, but for mixing backing vocals, I think I am always going to use this. It's one of those "how could someone not have come out with such a thing 10 years earlier?" things, and I know iZotope has had it around for a while. This is a great promo. The moment my budget increased for plug-ins would be the moment I would plunk down the money for the full iZotope enchilda special (and maybe a Melda bundle). I think their plug-ins sound great, and their UI's are my favorite in the business. As far as the suites go, their presets and wizards have provided me with good benchmarks and starting off points. They're maybe not what I stay with by the time the mix is finished, but they're so nice for throwing up a rough mix after a few hours of tracking.

The article is nice enough as far as being favorable in tone, but as far as grammar errors and content, it reads as if it were written by a high school sophomore, right down to the first 25% of it being lifted almost word-for-word from Wikipedia articles. I know that because I've been going through the Wikipedia articles on Cakewalk, Cakewalk Inc. and SONAR the past couple of months and doing my best to clean up some big messes. They're still ugly, but you should have seen them before I got there. Out of order timelines, random facts stuck in willy-nilly, not to mention plain falsehoods. The most tragic was that someone had trashed the page for the original Cakewalk sequencer by conflating it with Cakewalk by BandLab. The page was originally pretty good compared to the other pages associated with Cakewalk, like the clustercuss that was and is the page for SONAR, but someone had gone in and apparently without reading the page first had deleted large chunks and edited it to indicate that BandLab had bought it and was now developing it. It was as if they were not familiar with SONAR or had not bothered to search for the page on SONAR that already had the information. CbB deserves its own Wikipedia entry, but I'm too busy to start one myself. The entry on SONAR is not a useful starting point. It's an example of how not to write a Wikipedia article about software, IMO.