Starship Krupa

Exponential Audio'd

So does editing the raw Cakewalk.ini file have the same effect as making entries in the "initialization file" preference pane?

As a heads-up, the dialog looks like this: I have some confusion about Cakewalk's INI files. According to the documentation, this entry would be under the WINCAKE section in the file C:\Users\<username>\AppData\Roaming\Cakewalk\Cakewalk Core\Cakewalk.ini. But the file that gets edited in Preferences is AUD.INI, isn't it?

Sure. One of my favorite uses is for reality checking plug-ins or chains of them that boost level. Everything sounds better louder, so it can be hard to tell if my processing is really doing something good or if I'm being seduced by a simple level boost. It doesn't help that so many plug-ins' presets toss a bit of boost in there.

Okay, with my new system build, I guess it's time to pull the trigger on Chromaphone at $79. I think that's an all-time low for a non-upgrade price. 2 synths for the price of one.

Is that Master bus' meter peaking around -3 to -6? There are a couple more possible choke points between that Master fader and your (presumably powered) monitors. First is Cakewalk's Hardware Outputs. That's the slide-out panel to the right of the Bus Panel in Console View. Make sure that the meter for the hardware output you're using is showing a nice, hot level. Second, there should be some kind of output level knob(s) on your interface. Is that cranked up as well? If there are output level meters on your interface, are they also showing a good strong level? I use a 20W per channel power amp (honest, 1970's-style RMS, not this "intermittent peak power" stuff we often see on power amps now) with a pair of passive Event 20/20's, and I can turn my monitoring system up to the point where it's painful and neighbors will start throwing rocks at my windows. Whatever powered monitors you have, provided that they are studio monitors from a reputable manufacturer, should be able to give you all you want and more.

Sometimes I get stuck notes with my soft synths. Not blaming Cakewalk for this, it just happens sometimes. However, when it DOES happen, I want to be able to stop them. I mean all of them, regardless of how they were initially triggered or whatever. There have been multiple times when I've hit the "Reset MIDI and Audio" button and yes, the sounds stopped, but as soon as I hit the button to restart the audio engine, the stuck notes came back on. I imagine that the existing panic button sends out All Notes Off to every synth track, but apparently not all of them respond correctly to All Notes Off. Is there some way to have a button or menu command to absolutely, for sure, definitively, terminate all playing notes, short of closing and reopening the project? And I mean, terminate. With extreme prejudice. By any means necessary. If it means sending individual "note off's" to all 127 notes on every MIDI track, so be it. I don't know, I just want all the notes to stop sounding and stay that way until I hit Play again.

Not sure what was happening in your situation, but I'm going to request that Cakewalk implement a more robust MIDI panic button. We can call it "No, Really, I Mean ALL NOTES OFF." Or "What Part Of 'ALL NOTES OFF' Don't You Understand?"

If I understand the steps, then I'm getting different results, and it's behaving as I would expect it to. Check Check Check Check Result on my system: it does. The MIDI data is going from Cakewalk to the synth (via the MIDI interface), and the audio data is coming from the synth into Cakewalk (via the audio interface). If this worked in some other way, it would not be practical to overdub vocals or any other audio source with a MIDI track playing. Cakewalk doesn't care (or even know) what device its audio is coming from, be it a hardware synth or microphone or whatever. All it knows is that one (or more) of the inputs on the interface is taking in audio. That audio could be from any sound-producing device, a microphone, a turntable, a hardware synth, or whatever, so how could the fact that it's coming out of a hardware synth that happens to be driven from a Cakewalk MIDI track make any difference? There's nothing at all special about audio coming from a hardware synth as opposed to coming from a microphone. The MIDI track and the audio track don't even know about each other. If you set this up in the same way but also set up a second audio track and plug a mic in and arm that track with the mic as input, are the input level (recording monitor) meters also dead? If so, then something is going really wrong. If they work for the mic, they should work for the synthesizer's audio outs. Are you 100% sure that you have your synthesizer's outputs plugged into the correct inputs on your interface? Are you able to hear the synth correctly on that audio track when it's playing back, and are you sure that what you're hearing is coming from the Cakewalk track rather than realtime monitoring on your interface?

Thank you. There is unfortunate confusion about the terms "USB C" and (less so) "USB 3." And then of course there's "Thunderbolt." They all relate to each other, but they also get confused for each another. I didn't pay it much notice until last December, when I bought a Dell laptop that has a Thunderbolt 3 port. At that point I started wondering what exactly I could connect to such a port. I also wondered where the docking station connector was on my new computer, turns out the answers are related. One way to remember it with USB is numbers=protocol, letters=connector. There's no such thing as a "USB 3 connector," nor is there such a thing as the "USB C protocol." A USB C port on a given bit of hardware might only be for USB 2 protocol connections. A USB 3 port may use a USB A connector. Thunderbolt is yet another protocol, and it's also a term for a certain type of port that always uses USB C connectors. A Thunderbolt 3 port is, physically, USB C. Protocol-wise, it can handle DisplayPort video, charging, and USB 2 and 3 and Thunderbolt data. The way to tell whether your system has a Thunderbolt 3 port is that it will be a USB C connector with the image of a lightning bolt (of course they would use lightning to muddy the waters even further) printed or molded next to it. So rather than using a traditional docking station, if I want to connect my laptop to an external monitor, that will be done via its Thunderbolt 3 port. My understanding is that if I had a charger with enough current capacity, I could even charge the laptop via its Thunderbolt 3 port. There's a LOT of confusion. The statement "USB 3 uses the USB C type connector" is only true some of the time. Any current USB protocol may use any type of USB connector. My Presonus Studio 2|4 uses USB 2 and has a USB C connector. So the only way you know what's provided by a USB C connector (aside from the fact that it will include some kind of USB) before plugging something into it is if you see the lightning bolt indicating it's a Thunderbolt 3 port. Going forward, it's a good idea when buying USB C-to-USB C cables to get only ones that are rated to work with Thunderbolt 3. This is because Thunderbolt 3 uses "smart" connectors that help the devices on each end know who they're talking to. My understanding of the term "jitter" relates to variances in clock frequency. I assume that jitter on the MIDI clock results in slight variations in delay? I suspect that will take a very long time. Speaking strictly for myself, I'm not dumping any of my MIDI 1 gear in favor of MIDI 2 gear. I mean, not just for the sake of being able to use the new protocol. This discussion has made me wonder what we'll see 20 years from now, once MIDI 2.0 has really taken hold, and CPU's have gotten even faster at executing instructions, With a resultant reduction in the amount of latency and timing variations. will we start to see plug-ins that imitate the current imperfections? People will claim that the variations induced by timing inaccuracies were an important part of what made late 20th and early 21st century electronic music sound like it does. "That's why sequenced music that you hear today sounds so mechanical and robotic. Back then, since the tech wasn't as advanced, there were all these little imperfections." Just like we have "analog" buttons on compressor and EQ and delay plug-ins that induce noise, roll off highs, add subtle compression, etc. we'll have "MIDI 1.0" buttons that induce latency and timing variations. And they'll do the same kind of tests that we do, put a dozen instances of the vintage-izer on a track just to see how their effect adds up and what they're really doing.... Seems funny, but we make music in a world where pretty much every producer and mix engineer has some sort of "bitcrusher" plug-in that they can use if they want to get the cool grainy sound of the earliest samplers. Not saying that we all use them, but I bet if we looked in our plug-in collections, somewhere in there, as part of a bundle or whatever, we could find a bitcrusher. That would have seemed hilarious to me 25 years ago. But bitcrushed sounds have become part of the musical language of some genres. Turns out that we like it when music bangs up against technological limitations. Take away those limitations and some of them we want back.

I definitely understand “if it ain’t broke,” but the truth of the matter is that there is a tradeoff. The longer you wait, the more painful the transition will be, and the greater the likelihood of running into trouble, and the greater the potential of that trouble will be annoying. Windows 10 has been around long enough that it’s clear that it’s a safe upgrade from 7. And I have found that in every case, even the aforementioned Core 2 system with 4G of RAM, 10 ran better. Of course it was initially on the despised Vista, but Vista wasn’t all that different from 7 once they ironed out the issues. Cakewalk itself is no longer tested on or guaranteed to work with Windows 7. When the devs announced that years ago, that was my tipping point. There are many hidden benefits to doing a new system build. Not insignificant, you’ll weed out a TON of software you’re not using. I posted a topic in the Computer Systems sub about doing a new build and what I ran into, good and bad. One thing to be aware of is that Windows 10, when first installed, takes about 24 hours to settle down. Somehow it analyzes your system and fine tunes itself. There’s a lot of communication with Microsoft’s servers. So if you do anything heavy with it in the first day or so, it may look like performance is degraded. Yeah, machine-dependent authorizations are a pain in the cases where you must contact the manufacturer once you get past a certain number of authorizations. Plugin Alliance has a good system, all you have to do is go to their website and deauthorize your previous system. WA Production is one of the ones you must contact after you run out of authorizations.

I have no tech help to offer, I just want to give you a tip of the hat for getting it done on a wheezy old system. Some people like to brag about how new and powerful their PC's are, but I'm kind of the opposite. I think it's cool to run the wheels off, get all the use you can, people can be surprised at how much you can do with so little. If you can make cool stuff using a computer that shipped during the Bush administration, that's impressive. If you did have the latest zillion-core DDR5 rocket sled, that would be nice, but there'd be nothing remarkable about making music with it. I've been like a low rent Jim Roseberry recently. I rebuilt a couple of systems for friends to use, a couple of systems that originally shipped with Vista installed. One is a Core 2 Quad with 8G RAM that I received years ago as a hand-me-down. It was my main DAW computer for a few years and then my #2 for several more. My friend had no computer and needed one for some online exams, so now it's his. He's also a musician and Cakewalk on that computer is overkill for his stuff that usually maxes out at 3 or 4 tracks. If I were somehow forced to use only that computer on a daily basis to do my web browsing and TV watching and music creating on, I would definitely miss the newer systems that have replaced it, but I would not be dead in the water. I'd just have to be more clever with freezing synth tracks and such. It would be more work, but it would still happen. The second was an old Dell laptop that another friend of mine found at the bottom of a drawer at his house. He took it to the IT guy at his former employer and they said "toss it," so he brought it to me to see if there was a webcam I could salvage from it or something. Of course, telling me that the IT guy at work said to put it in the dumpster is a very good way to pique my curiosity. I don't remember what it had under the hood, probably a Core 2 Duo. I couldn't get past the Windows Vista password, even with my cracking tools, so I wiped it and put on Windows 10. Came right up, running on 3 Gigs of RAM(!). I dug up a 2G RAM stick and bumped it up to 4 and it runs fine as a web/YouTube/Netflix box. So of course I had to try it....and damned if Cakewalk didn't chug right along on just fine on it. Since he was expecting me to tell him that it was toast, I couldn't resist plugging a MIDI controller into it and jamming on the Cakewalk Studio Instruments for him, of course to his utter astonishment. Another guy who would do just fine recording his 1 guitar 1 voice demos on it if he bothers to try it. I found him a replacement charger on CL for $10 and now he has a portable Windows 10 system that works fine. As for the issues you're seeing, after a certain number of releases, I start to be concerned about "template rot." Cakewalk is wonderful about maintaining backward compatibility with files created in long-dead versions of the software, but how long should I challenge it by using such files as templates for new projects? 😁 Maybe at the 5 year point, I rebuild my template just to be sure. The 5 year point for my time with Cakewalk is coming up in April. When the time comes that you do go to get a newer computer, I think refurbished Dells are a really good value. There are many Dells from the corporate world that got early retirements and probably have a decade left of decent computing to do.

I have multiple monitoring devices and I don't use sends. I use a dedicated "Output" bus. Everything up to and including the Master bus is probably as anyone else would do it, but then I have the output of the Master set to my Output bus. Depending on which hardware out I wish to listen to (headphones for instance), I just set the destination of the Output bus to it. The reason for doing it this way rather than just routing the Master right to it is that it allows me to use that Output bus as a volume control without disturbing anything on the Master bus. Other people might just use the faders on the hardware outs, but I don't like disturbing those either once I have them all set how I want (roughly equal to each other in volume). Perhaps it's not a one-click switchover, but I don't have a need to switch outputs that quickly.

Digital wolf tones. 😢 An exported WAV would be a product of offline rendering, though, which I'm positing could be different from playback in the same DAW. People try the null test; I tried the null test with Cakewalk and Mixcraft (they didn't null completely, but they weren't off by that much, either). But the null test is done on rendered files, not the output of the DAW's playback. There's nothing requiring the programmers of a DAW to use the exact same algorithms at playback time (when resources are more scarce) as they do at render time. If they were completely equivalent, why doesn't it take exactly the same time to render a track as it does to play it back? If you leave Task Manager running, you see CPU usage is way higher during render than during playback. Is it possible that something might be handled differently for the sake of less chance of dropouts during playback? I listen at a slightly lower fidelity while mixing, by my own choice. I use plug-in oversampling, but only turn it on for rendering. 20 years ago you did NOT want to let anything convert your tracks' rates up or down. The trip from 44.1 to 48 would mess things up (phase shifting, aliasing). Then at some point the algorithms got good enough at it that nobody's concerned about it any more. I've done enough testing with Resource Monitor of both Mixcraft and Cakewalk to know that on similar projects, Cakewalk does a lot more disk reads than Mixcraft during playback. As far as I could tell, Mixcraft was loading the audio files completely into memory (which would help explain their bullet-resistant playback engine) while Cakewalk was streaming them from the disk (supposedly not an expensive operation in terms of I/O).

Curious, Craig: what do you think of my hunch that while that's true for recording and rendering, it may not be true for playback? For sure about the I/O,and not just the analog components. I was gobsmacked by how much better my Presonus Studio 2|4 sounded than my Presonus Firepod, and I had to learn why. How could it be possible that two interfaces from the same company sounded so different when their published specs were so similar? I did some research and found out about how jitter degrades the listening experience. According to that paper, even a mathematically small amount of jitter can be perceptible. The Firepod was made before prosumer companies like Presonus started using DAC's with JetPLL, a technology that drastically reduced jitter. So once I learned this, it made me wonder what other less commonly understood or cited phenomena might affect the listening experience. The marketing hype around the introduction of the compact disc said that it was like the end of hi fi history, that digital audio was now a "perfect" representation. It's kinda funny how many improvements have been made to "perfection," even fairly recently. I can name three DAW's, Samplitude, Mixcraft and Ableton Live, all of which advertised that they had "improved" the sound quality of their audio engines within the past 3 or so revisions. This raised a question for me: if their engines already did the same thing as every other DAW's audio engines, how was it possible for them to "improve?" 🤨

Not one that I know of; this is supposed to "just work." Is this in every project or just one or in some of them. Whatever the case, the devs would probably like to see a project that exhibits this behavior. As simple as possible. Then they can study it and see what's going wrong. Have you tried a simple reinstall or "clean" reinstall?

Good shootin'. Documentation errors are getting hard to find. @Morten Saether is the person to alert about documentation/Ref. Guide issues.

It occurs to me that no wheels need be reinvented here. How does it work in other, similar, audio/video editing software? If most of them work a certain way and Cakewalk doesn't, that suggests a change might be due. We're talking "standards" here, but in addition to Windows/Microsoft standards, there are also standard behaviors among similar apps, which should probably be paid attention to. I know that developers dislike the argument that since a given feature works so handily in a competitor's product, their product should also do it the same way, but I think there's no call for it to be needlessly idiosyncratic either. Compliance/use of the Windows Clipboard can be as robust as even working between two different apps that share the same datatype (pixels, text, etc.). In your example, if it's confined to being within Cakewalk, let's posit that the user copies a section of audio or MIDI data to Cakewalk's clipboard, and then subsequently they perform half a dozen operations on the original timeline clip, then invoke Paste again. It sounds fraught with troubles, but keep in mind that assuming they made the changes to the original data using Cakewalk, Cakewalk should have no trouble handling that. After all, Cakewalk remembers what it does, doesn't it? Bets are off if the user alters an underlying audio file with Explorer or another program, but that's true for other operations as well. We must be careful when doing anything to our audio data that isn't started from inside Cakewalk itself. So let's say I select a section of a clip, Copy it, then delete the entire track. My expectation, unless I have explicitly copied to the clipboard again since the original copy, is that I will be able to continue to Paste that same section as many times as I want to into new tracks, old tracks, other simultaneously open Cakewalk projects, etc. Whether I use the Move or Split or Draw or Delete tools in between those operations shouldn't clear the clipboard. (It doesn't 100% obey that now, but it's still how I'd expect it to work) When I'm working in a pixel editor that has a Move function, I can select an area of the picture, Copy it, then select the same or another area of the picture and use the Move or Delete (or whatever) tool, and that doesn't clear the original selection from the clipboard. There's a lot of pixel editing workflow that would go right up the creek for me if that were the case. Copy some pixels, then add a layer, switch back to the first layer and delete a bunch of stuff, move some stuff using the move tool (not Cut/Paste) change the hue, then Paste the pixels I copied earlier on top of the new layer. I do that kind of thing all the time. It sounds like how Cakewalk is different is that it's treating its Move tool operations as a Cut/Paste macro, which IMO, may be the way that it is, but if so, it ain't standard. Use of the Move or Cut or Split or Draw tools should not change the contents of the clipboard. If I'm reading it correctly, it's not as if the clipboard then gets filled with the clip the user just dragged so it's not even a full Cut/Paste.

This space intentionally made blank....

I didn't know that. Please tell me some software products that have "public roadmaps" because I am really interested to see what one looks like. I've never seen a "roadmap" for a commercial software product and am very curious to add to my knowledge. These are even more things that I didn't know. Is Cakewalk behind every other DAW in features or just some of them? And in the number of users, does Cakewalk have the fewest users of all DAW's? If not, which DAW's have more and which have less? You seem to have access to so much information that I don't, and I want to learn too.

And so would the developers of every other DAW. Even though the license for Cakewalk is free, the DAW is competing with all the others. Revealing plans to the competition is uncommon in the technology field. Every new release of Cakewalk comes with lovely surprises. I'm sure the next one will be the same.

This. Also, the Skylight (Cakewalk's term for the system of various expandable and dockable panels and views) interface is a feature that rewards spending time to maximize its potential. As Noel said, the stock Advanced workspace throws it all up there, and in an opened state no less. This isn't how experienced users run it. Start with the Control Bar. I guarantee that there are modules on display that you don't need (maybe ACT and Sync, unless you're working with control surfaces and timecode). They can also be resized into larger or more compact form, and rearranged horizontally. The Browser (the long panel on the right side) and Inspector are easily closed and opened as need be ("B" key and "I" key). The Multidock (which is the panel where the Console and Piano Roll views open by default) can be opened and closed with the "D" key. If you're on a multiple monitor system, you can put the Multidock on a separate monitor, and even drag the panels from it to float on their own. Cakewalk is flexible, but with great flexibility comes many "OMG, I didn't know I could do that" moments. When @David Baay suggested I try holding shift when using the "D" key....yikes. Working on my laptop became much easier. Lastly, try some custom themes (see my sig). @Brian Walton is fond of modding his to omit what he sees as labels that experienced users don't need (maybe not great for a new user). My "Flat Dark" ones have flat Ableton/Studio One style transport buttons. An issue with custom themes for new users is that the button images and colors won't precisely match what the documentation shows.

Caveats: although I really liked the demo song, this is a standalone rather than a VSTi, and unless you donate, it pops a beg screen every 3 minutes.

If your plan is to record a handful of simultaneous audio tracks on the laptop and then bring the project back to the main (presumably tower/desktop) DAW computer, a Core 2 Quad and 8G RAM and a 7200RPM spinner from the time of the W. administration would serve the purpose of the recording laptop. Recording audio data to disk is not a computationally "expensive" task. As for I/O, whatever Focusrite or Presonus has the number of inputs you need, you can't go wrong these days. Mixing is another story. It's plug-ins that burden a DAW system. But even my 2017 i7-7600U Dell business laptop with its whopping two cores can handle some pretty complex plug-in loads without needing to freeze tracks. If you are curious about single screen vs. 2 or 3 monitor real estate management, that's where the Skylight interface really comes into its own. It scales down as well as it scales up. The D key (and shift-D) to quickly open and close the Multidock is golden.

Even then....there are so many loss-leader ROMplers. Kontakt Start, Sampletank CS, Sine Player, LABS, Soundpaint, Analog Lab V. Now that I consider it, nothing I've seen about HALion suggests it would do much for me but clutter my system further.