bitflipper

I'd be inclined to suspect the fault lies with a plugin. At least, that's been the case every time I've ever solved a bounce/export problem by switching to/from slow bounce. For me it's always turned out to be a virtual instrument, although I can imagine scenarios wherein any processor could end up with corrupt buffers (e.g. things with big buffers such as reverbs and linear-phase equalizers).

That's exactly why Noel added the "sandbox" option. When the scanner opens a plugin, it's running code within the plugin that Cakewalk didn't write and that the scanner has no control over. If something goes wrong and the plugin hangs, the scanner hangs too, as well as the main Cakewalk application. The sandbox option spawns a new process for each plugin test, assuring that the whole process won't blow up if a single plugin hangs. Make sure Cakewalk is up to date. In an effort to make the software more robust, they made it pickier about what errors to report. Too picky, in fact, resulting in plugins failing that didn't used to fail. To combat that, they've dialed back the sensitivity to make it a little less nit-picky. Lots of problems went away for users with the recent update because of that. If you're up to date and still having issues, follow scook's advice above. Rename the offending plugin (Z3ta+.dll), give it a temporary new suffix, e.g. Z3ta+.xxx. That'll prevent the scanner from opening it. Let the scan run to completion, then change the name back and try again. Sometimes that works. If it fails, enable the scan log. This will create a text file that reports what the scanner saw happening. Sometimes, a clue can be found there. The log file will be %appdata%\cakewalk\logs\vstscan.log and you can just open it with Notepad. Note that each time you do this, the information is appended to the log, so you may need to scroll down to see the relevant entries. Or delete any existing vstscan.log before starting. There can be a lot of reasons for a VST scan to fail. As rbh noted above, sometimes it's not hung at all but just waiting on a dialog box you can't see. Whenever I see a scan hang, I press Alt-Tab to see if that's the case. Other times it's due to a missing dependency, iow some file that Z3ta+.dll needs to reference but isn't there. Sometimes it's a registry key that's missing or inaccessible due to Windows permissions. These, however, are usually associated with new installs only.

Serious suggestion: take one of bat's tunes that is more or less complete but with some space left in it, send it over to Wookie and let him use his own imagination and synth knowhow to add some synth parts. See what happens. It'd be an interesting departure for both parties, opening some creative doors and maybe, just maybe, create something truly remarkable. Or not. Doesn't matter, I'd still like to hear it.

First time I saw an Oberheim was c. 1984, at a studio where I'd been invited to lay down a string part. The engineer suggested I do it on the Oberheim 4-voice instead of my Elka String Synthesizer. I was blown away, and literally dreamed about that synth for many months after. But it cost more than a new car back then, so I never realized my dream of owning one. I did buy a single expander module (which was still ~$700) and slaved it to my Micromoog. I'd never have dreamt that someday regular folks like me and Wookie could own a digital equivalent for $29. Gotta say, you do it justice, my friend.

Bat, you could just hit Rec and start noodling and I'd listen to it. I've been a Superior Drummer user since forever, even before that's what it was called. Started with the Drumkit from Hell, remember that one? Yeh, it sucked, but those folks have been steadily perfecting the tech over the years. To this day SD3 never ceases to impress me with its versatility, whether using a brush kit on smooth jazz or smackin' it for some Batsbrew-style hard rock.

None of these responses have addressed the OP's question. Sure, there are better-sounding sample-based synths out there, but the TTS-1 remains viable. I use it regularly, mostly for percussion but sometimes as a stand-in for a piano or string part that'll later be assigned to a high-end sample library. I do this because the TTS-1 is so efficient that I can stack as many instances as I want while composing/arranging. As to why the synth can't be heard while recording, that's probably just the Echo button. Click it and see.

The .big file is likely an archive that contains multiple files, similar to a .zip file. The plugin's installer should have extracted the files from it. Maybe it did, but put them in an unexpected place. Or maybe the installer failed due to some problem, e.g. Windows permission issue or missing dependency. I'd start with a global search for the dll to make sure it's not been just dropped somewhere unexpected.

ol' pal, have you verified that it's just the one project that won't export? Maybe pull up an old one of similar size and complexity and see if it exhibits the same problem.

It's the never-ending questions that make this a never-ending joy of a hobby. With many pastimes you reach a point where you feel like you pretty much know everything you need to know. That won't happen in this space. At least, that's been my experience. After recording music for half a century I still have questions. I love that.

OK, good, you didn't ask for the short version. There isn't one. But I'll do my best to give you the medium version. When a piece of hardware such as a disk controller or network adapter wants the CPU's attention, it's usually critical that it gets heard right away, before the data it wants to share is gone. In order to deal with such unscheduled demands, a mechanism called an "interrupt" forces the CPU to stop what it's doing and take note. In other words, the device interrupts the normal chain of events like a crying child tugging at Mom's pant leg. Because interrupts can be, um, disruptive to the overall performance of a computer, the system needs to quickly acknowledge the request and get back to business, deferring whatever the controller wants to do until an appropriate time. That's the "D" part of DPC; "deferred". The interrupt handler is a short piece of software that does only the absolute minimum stuff it needs to do so that the CPU can get back to its regularly scheduled program. But the controller is now happy because it knows it's been acknowledged and will be serviced in short order. (Some device drivers are notorious about not adhering to this rule, in particular gaming video adapters, which is why a dedicated DAW build probably won't have a fancy high-end gaming card.) So when the CPU finally gets around to handling the controller's request, it runs a more involved piece of code called a Deferred Procedure Call. You can look at DPC activity using a tool such as LatencyMon, and you'll be shocked at how much time the CPU spends dealing with them. If the DPCs are well-written and efficient, they won't interfere with your most important task, which of course is audio. Problem is, systems make assumptions about what's important to you and they may not always be right. A good example is network traffic, especially wireless networks. Your network card assumes nothing is more important than network stuff. But of course if you're trying to record or process audio, that would be an incorrect assumption. If a network driver hogs the CPU for too long, your audio interface may not get its own interrupts serviced fast enough. When that happens, your audio interface's data buffers can get starved for data, the interface cannot guarantee continuous audio, and you get dropouts. Brief dropouts sound like clicks or pops; longer dropouts can actually make Cakewalk give up altogether and stop the audio engine - leaving you fuming at Cakewalk even though none of this is your DAW's fault. Since you and I have almost no control over how interrupts and deferred procedure calls are handled, the best we can do is avoid or disable those devices that are the most egregious perpetrators of CPU cycle theft. Top of that list is wi-fi adapters, but they're not the only offenders. Download the tool I linked above and give it a go. It will give you way more information than any musician could reasonably be expected to process, but there is some good advice on the Resplendence website to help you sort it all out. Bottom line is to identify which process is monopolizing the CPU with inefficient DPCs and kill it.

An excellent choice for the money. Better - and better supported - than your Alesis, and has a native ASIO driver. That said, your interface probably isn't the problem. There are many reasons for glitchy audio. On laptops, the #1 cause is the high DPC overhead of wi-fi adapters, so make sure you're disabling wi-fi during Cakewalk sessions.

Make sure you are exporting from PT in RIFF WAV format, which is understood by all DAWs.

I'm wondering about the validity of performing such a test with a YouTube video, given that we know YT never presents audio without modification. Using an oscillator plugin such as MOscillator (one of the freebies in the Melda fee pack) might be more trustworthy. I think we obsess over hearing range because a) it's easily measurable, and b) it's something we all fear losing with age. The question that never gets asked: how much high end do you need to hear in order to create a nice-sounding mix? If your kneejerk response is "as close to 20 KHz as possible", that does not reflect reality. If you listen to MP3s, the upper end has been lopped off (IIRC, at 18 KHz). Same for other lossy compression algorithms. If you listen to FM radio, it's limited to 15 KHz. Your guitar amp likely tops out at around 12 KHz. Hammond organs often occupy the upper end of a mix, but a classic Leslie horn only goes up to about 10 KHz. Truth is, we listen to band-limited audio all the time and rarely notice. The real question is where musical frequencies live. Quick, what's the fundamental frequency of the highest note on a piano? How about a piccolo? Think either one goes above 12 KHz? Think again. Sure, there are overtones that are multiples of the fundamental that can run up into the hearing range of bats. But humans can't hear them. But can you tell when they're not there? Try this experiment. Play the highest note on the highest virtual instrument you have on hand. Pipe organ, for example. Nothing goes higher than a pipe organ, AFAIK. Insert SPAN and note where the fundamental frequency is, and where its harmonics lie. Now add a low-pass filter and start cutting those harmonics until you can distinguish a tonal difference. Find some six-year-olds and repeat the experiment with them. When mixing, by far the most important frequencies are the ones everyone can hear with ease, between ~1KHz and ~5KHz. This is why band-limited speakers have long been used by mix engineers; if it sounds good on speakers that don't go much above 8-10 KHz or below 100 Hz, it'll sound good on a full-range system.

Exactly. "Professional" does not directly imply that you are necessarily good at something, just because someone was willing to pay you to do it. I have been a professional musician, a professional hardware engineer, a professional software engineer, and a professional teacher. In each of those roles, I knew plenty of associates - also professionals - who were flat-out sh*t at their jobs. There were others that I knelt at their feet beseeching them to bestow upon me even a little of their vast knowledge and experience. On the other hand, there's such a thing as the passionate amateur, someone compelled to learn everything they can about the subject of their passion. Such people aren't constrained by the narrow needs of a specific job assignment, but are free to branch out into any related field that piques their interest. I am happy to call myself an amateur mixer, and would be considerably less happy if I had to do it as a (shudder) job.

My first personal computer was an RCA COSMAC VIP. Came with 2KB of RAM (had to design and build my own circuit board to bring it up to 8Kb), no operating system, no keyboard (all data entry via a hex keypad), using audio cassettes for storage. My first serious program was a recreation of Space Invaders, which I played with a home-made controller made from Radio Shack parts. In 1984 I got my first real job in the industry, where they foolishly handed me a roomful of million-dollar superminis to play with. It was there that I learned to code in just about every programming language in existence at the time, ultimately settling on C as my native tongue because it ported perfectly to my Apple ][.

^^^ + 1 Might have to brush up on my Singlish, though. Yes, that's a recognized language (unlike similar but unofficial hybrid languages such as Spanglish and Taglish).

It was with some sadness that last week I finally contributed my VS-700 T-shirt to the rag pile. At least it was put to one last musical purpose: cleaning up after my granddaughter, who'd just finished spray-painting her guitar as well as the patio table she'd used as a workspace.

Erroneous indeed. Even adding up a half-dozen paid SONAR upgrades, my investment in the DAW has been a drop in the bucket compared to plugins and virtual instruments. And all that's a small amount compared to speakers, interfaces, multiple displays, microphones, acoustic treatments and musical instruments. A free DAW is like a drug dealer offering the first taste for free.

Mine are mounted one over the other, doubling the screen space without changing the desk space. You just have to get an extra-tall monitor stand. They exist for just that reason.

TVs are meant to be viewed from a distance. There are charts for determining the ideal viewing distance for a given TV. Advice that's often ignored, as evidenced by the many times I've visited people's homes and seen a set far too large for the room it's in. It's OK because you simply don't need ideal definition while watching Netflix, where you're not trying to navigate a mouse to a small spot on the screen or nudge an automation node by 10 pixels. Relegating that TV to its intended application, e.g. showing people standing behind you what you're doing, is a good idea. I do like wide monitors, though. Unfortunately, many actually have too high a resolution, making text difficult to read. At present I have a good compromise, two 34" screens at a modest 2560 x 1080 native resolution (4K is a waste for DAWS, IMO). Lots of room for lots of windows to be open at once, e.g. track view on one and PRV on the other, while presenting legible text. Here's the exact model I'm using. I would not go any larger, lest the displays intrude on my line-of-sight to the more important monitors, my speakers.

I have to say, as a longtime Cakewalk user (since 1986) I have noticed the return to the philosophy of Cakewalk's earlier days. Companies that are under pressure to release a new paid version every 9-12 months tend to throw in a lot of half-baked fluff just so Marketing can add to its features matrix and thus justify charging for the same product over and over. Noel and company, thanks to Meng's patronage, are now free to concentrate on just making the product better. Hats off to Meng, and happy to hear Noel giving the guy the credit he deserves.

BTW, in this podcast, Noel says the BandLab user base is 29 million. Not all of those are Cakewalk users, but holy crap, that's a LOT of people. That's about equivalent to the entire population of Texas.

What would be of more interest to NI would be how many of those users actually care about Komplete Kontrol. A small minority, I suspect. At any rate, NI have always marched to their own drum. They are not exactly the most customer-centric company.

Took me all day, but I finally finished the entire 2 hours. Great stuff, even some new (to me) information. "Wasabi"

It will work fine, assuming the device still works. Might want to blow out the MIDI connector first. But you'll have no issues with USB 1.1.