Starship Krupa

That is really odd and messed up. I've been thinking about creating projects that will allow me to change synth patches within the song, but it seems like this was made much more difficult. I also have so many soft synths that it would be nice to make "patch browser" projects that quickly step through the available sounds as a preview. This will be tougher to do as well. What are the workarounds?

The headquarters of both companies is in a tiny town just outside one of the entrances to Yosemite National Park here in California. Having participated in their beta program enough to get my name in the credits for the Mixcraft 7 release, something I can tell you about Acoustica is that they are one of the most quality-minded software manufacturers that I've ever dealt with. So please report your experience and findings about this performance issue to them. They will likely want to know about it and work with you and the BandLab Cakewalk engineers to fix whatever is. Good question, and one that I can't really answer. Without being able to read the minds of the folks at Steinberg, there's only speculation. It could be that there were starting to be too many extensions to the VST spec that weren't controlled by Steinberg, and they feared losing their grip on it. Maybe they thought that being able to announce a shiny new technology that their own DAW's would be the first to support would be good for marketing. Maybe the Cubase/Nuendo developers were having a hard time working out sidechaining support in their apps and wanted to force that work onto plug-in developers. Whatever drove the move, as far as I can see it backfired. Other manufacturers (correctly, IMO) saw little advantage to supporting the new format. Rather, it only increased their coding and testing burden. Adoption was slow. When they finally applied their legal muscle to force new developers to adopt the format by refusing to issue more licenses to develop VST2, it served as an alert to participating vendors that Steinberg had too much of the wrong kind of control and that a more open and flexible spec might serve the industry better. So now there is CLAP, a competing plug-in format. As for CLAP, as long as Steinberg continues to play nice, I don't think it will become the dominant format. But I'm glad it exists, because it serves to show Steinberg that if they do try any more funny business, the industry has other options My suspicion is that if you ask anyone in the business of developing plug-ins or hosts for them about VST3, they'll tell you that the canonical DLL location is the only thing that they benefit from. I'm sure it eliminated a LOT of easily resolved support issues. However, I was so used to using custom locations for my VST2 plug-ins that I initially tried doing the same with VST3's, which of course didn't work too well.... Is it that VST3 doesn't support it or is it that plug-in and/or host manufacturers stopped supporting it? Communication between host and plug-in regarding presets in general seems to have gotten lost along the way. Where it seemed like most VST2's relied on the host for preset management, and reported their own presets to hosts' preset managers, in the VST3 era, this isn't the case. Now it's unusual for a plug-in to use that part of the spec to report their presets, and every plug-in has its own proprietary preset manager. Which can be hard to find and quirky to navigate, depending on the developer. The VST3 spec does call for a canonical location for .vstpreset files, but few plug-in companies use it and Cakewalk's support for it is clunky. That's a drag, because I like using the host's preset manager more than the ones within the plug-ins, which have to be learned for each different manufacturer.

I'm probably the deflator of VST3 hype that John is thinking of. To recap my usual points: VST2 plug-ins that support sidechaining do so just fine on every DAW except Steinberg's. The "VST3=sidechaining" stuff is only true for Cubase and Nuendo. PreSonus came up with a widely-used extension to the VST2 spec (so widely used that it was incorporated into the VST3 spec and hyped as being new) that allowed for plug-in UI resizing. The "plug-in goes to sleep when no audio is being passed" is a nice idea in theory. In practice, it's not that big a deal because just like any processing, plug-ins usually only eat resources when they're actually processing something other than silence. Also, implementing that part of the VST3 spec is not mandatory. No part of the VST3 spec is mandatory; it's a spec, not a law. There is no authority enforcing compliance. Of my VAST plug-in collection (Cakewalk has it at almost 500 FX), there is only one manufacturer I have seen implement silence=sleep, and that manufacturer, MeldaProduction, also implemented the feature in the VST2 versions of its products. Think about it: how many projects have you ever done that would benefit much from turning off a couple of plug-ins when they were idling? Due to slow uptake of VST3, most plug-in manufacturers still provide VST2 versions of their products. Since they are less likely to want to code two separate versions, that results in their VST3's being restricted to a VST2 feature set. The one single big advantage of the VST3 spec that I perceive is that it has a canonical location for the DLL's. But even that isn't without issues, as anyone with a 256GB SSD for their C drive and a large plug-in collection can tell you. Yes, you can circumvent this with sym links, but relatively few people have the knowledge and skills to implement that. Regarding Cherry Audio's products not working so well in VST3 form, this, unfortunately, is less of a surprise than it should be. Cherry Audio shares staff and management with Acoustica, makers of Mixcraft. When Mixcraft first started supporting VST3, the otherwise rock solid Mixcraft was so crashy and buggy with VST3's that I gave up on VST3's for over a year waiting for the next version of Mixcraft, which worked fine with VST3's. It appears that even now, they may not have cozied up to the VST3 spec? It's been a long time since I've run into VST3/VST2 issues, but one notable exception is Acustica (not to be confused with the DAW manufacturer) Multiply, the excellent freeware chorus. From its initial release, the VST3 version of Multiply will not work in CbB.

Well, I guess there's little to win, but nothing to lose....

Who, indeed, cares what games we choose?

I can't find in the documentation where it says this, but if it does, the documentation is in error, not the program.

I snagged Loop Engine during its not-that-long-ago intro sale and I do like it. As idea jump-starters go, it's my favorite of the ones I've tried. The Note Editor "piano roll" thing by itself seems to be worth the upgrade tenner, so I'll snag this. That they're keeping Chords, Chords Pro, Chords Pro+Notes and Loop Engine 1.1 all as active products is asinine. It's not a deep enough product to support 5 different feature levels and this just adds to the confusion I ran into when I was trying to figure out which one to get. Their ad copy isn't explicit enough in stating that each product contains all of the features of the next one down. Fortunately none of that affects my enjoyment of the product I bought. Still, though....considering that they're under the same corporate roof as FL Studio and MeldaProduction, one might think they'd get their upgrade policy act together.

My favorite de-collision tool, Wavesfactory Trackspacer, is currently on sale for $39 at Plugin Boutique. So easy to use and effective that it feels like cheating. As for ScalerEQ, I haven't looked into it enough to understand what it has going for it beyond presets. Cakewalk's QuadCurve EQ includes a piano keyboard graphic as a visual aid for figuring out where you're emphasizing and de-emphasizing frequencies. All of the MeldaProduction EQ's include similar visual helpers. So if I wanted to do some in key EQ'ing, it would be easy enough to start there. This assumes of course that one knows what the song's key looks like on the piano keyboard....

Bapcoin!

The goal isn't to have more users, it's to sell more licenses. Think of the two companies who initially worked together on it, PreSonus and Bitwig. I have never worked with Bitwig, but I read that it has some really interesting and unique features for MIDI composition. As a relatively new product that is oriented toward ITB composition, I suspect that when it comes to mixing that it's not a powerhouse. And if you need to generate staff music as a deliverable, I doubt that you can print it from Bitwig. So a Bitwig user can either sit around praying that the features that they have requested (maybe something like external inserts, if Bitwig doesn't have them, or maybe a staff view) will appear in the next release, or they can buy a license for Studio One (or now REAPER) and have the best of both worlds. To go back to the MIDI comparison, think of all of the specialized MIDI controllers there are now, 40 years on. If MIDI had never happened, in order to use one of these controllers, someone would be stuck in the ecosystem of whatever synth manufacturer produced them. Wow, great, if you want to use a Yamaha wind controller, you're stuck with having to use Yamaha synths. Roland guitar controller? Welcome to Roland World. With an interoperability standard, someone can have a great idea for a MIDI controller and just start making it. The user can buy it with the confidence that it will work with any synth or software that accepts MIDI input, which is ALL of them. This could free programmers from having to do a ton of coding and UI design work that they might not be good at or want to become good at. Thereby bringing the license price down and allowing them to focus on what they do best. There could be a whole new market for DAW's whose purpose is mainly composition. With the idea that when the project gets to heavy lifting mixing and routing tasks, the user will export the project to be finished in a general purpose or mixing-centric DAW. And of course they'll need to have licenses for both of them. What if someone were to come up with a DAW that tried to be the perfect compositional tool for orchestration and scoring? The designers know how they want it to work, with a killer staff view, sample library management, sound design features, video editing, etc. But due to time constraints, personal knowledge and understanding, whatever, it only has basic routing and mixing features. With DAWProject, no worries. Get the project together in the scoring DAW, then export it to your favorite general purpose DAW that supports DAWProject import. At this point, that could be Studio One or REAPER. Wouldn't it be nice if Sonar were on that list? How it sells more licenses is by giving potential users confidence that if they invest in the general purpose DAW, if something else (like the theoretical scoring powerhouse DAW I mentioned) comes along, time and money invested in the general purpose DAW won't be wasted. The GP DAW will still do what it does best and they can also get the specialized one if it interests them. For those of us who like shiny things, along with hundreds of licenses for plug-ins we seldom use, we could add a few licenses for specialized DAW's we seldom use. Right now, I have 4 full-featured DAW's on my system, all licensed. Cakewalk, Mixcraft Pro Studio 10, Studio One Artist 6.5, and Waveform Free. I like to play around with things. If more DAW's under $100 existed, especially if they did things no other DAW can do, that list might be longer.

If you're looking for peculiar cymbal sounds in general, not necessarily sampled real stuff, Applied Acoustic Systems' synths and soundpacks have a TON of such sounds. You can check it out for free using Swatches, which has over 600 of their synths' sounds.

It's because REAPER is different. Cakewalk could be different too, but making Cakewalk different is a feature request. I've seen other programs that do or do not allow setting buffer size for WASAPI Shared. I imagine that the companies that make it fixed do so with the idea that the fixed number of buffers that they use is a good compromise between playback latency and leaving enough resources available to other programs that are playing sound at the same time.

Since I make music to please myself and I like to listen on both loudspeakers as well as headphones, I try to make it sound good for both. People also listen to music on loudspeakers at clubs and when they watch TV and movies. For long haul multiple hour mixing sessions, I can go either way. I have multiple sets of monitors that I like and multiple sets of headphones that I like.

Why does this discussion continue after this point? You got it to work. Now you're claiming that there's a bug in Cakewalk and someone else is suggesting that your onboard hardware CODEC may be "garbage." WTF? Cakewalk and Exoverb Micro work together when you configure Cakewalk to use WASAPI Exclusive, which is the preferred driver mode for onboard sound. What is there to say beyond that point?

They don't. These are always free. Also great for anyone who uses Hybrid 3. I was hoping they'd drop the Multivation bundle for XPand!2 down to $9.99, but see that it's $14.99....still not bad for 3 expansions.

The preferred term is "hobbyists," thankyouverymuch. 🤨

You don't say how "large" you mean. I bought one of these a few weeks ago for $72.00: 2TB Silicon Power 2.5" SATA III. Silicon Power are my favorite brand of SSD and RAM. Their reviews are as good as WD, Hitachi, SanDisk, Crucial, Kingston, Samsung, etc, but their prices tend to be a few dollars lower.

Forum search function, missing or just invisible? BPB are I can't speak to the part about Waveform, but Cakewalk, as a free program, is being discontinued. It will be replaced in BandLab's portfolio by Cakewalk Sonar (mixed case), which will be a paid product. So the only thing incorrect about BPB's article is the punctuation of Sonar. People who are looking for free DAW software because they don't have the budget for it should stay away from Cakewalk by BandLab for that reason. I'd consider CbB at this stage to be a free demo for Sonar. We don't yet know what the license fees will be for Sonar.

Did you look at the pages I linked to? The motivation isn't collaboration: The target use isn't collaborators who prefer different DAW's and want to go back and forth. It's for "I like composing in Bitwig due to the MIDI tools specific to Bitwig, but when the project gets closer to completion I prefer Studio One's console and the ability to sync to video." The ability for person A at facility 1 to start their project in one DAW and sending it off to person B at facility 2 for completion is less likely and not even mentioned by the sources I linked to. The target use is a single user or organization that wants to be able to start a project in one DAW and then continue working on it in a different DAW. Not incidentally, a situation where licenses for any plug-ins involved will be owned by the person(s) doing the migrating. I'd like to pronounce that straw man beaten to death, but since people seem to leap to the conclusion that it's about enable multiple creators who prefer different DAW's to collaborate that I'm sure he'll rise again.... And for the record, it's not a feature that I personally would make use of at this point. My DAW of choice is Cakewalk, and if that were to change, migration would take place via the traditional audio and MIDI files. I'm advocating for it because I think that it would benefit Cakewalk Sonar (and users other than me) to support it. Practically and symbolically. If Sonar were to be an early supporter, it would get the name out there and being discussed by people who need to know that such a program even exists. Here's a joke I thought of that illustrates my attitude toward interoperability standards. Q: Remember the synthesizer companies that decided not to support MIDI? A: Yeah, me neither.

The closer one stays to an ecosystem the greater the chances of compatibility I'd think. My guess is that S1<>REAPER via DAWProject might stand a better chance of arriving with PreSonus Plug-in Extension API-specific information intact due to REAPER being a host that also makes use of the PreSonus Extensions API. We may be focusing on and making a bigger deal about what happens with FX plug-ins than the expected use of the format warrants. To the extent that I use plug-ins during the tracking phase of an audio project, they're typically not in the critical path (comfort reverb, maybe some compression on backing tracks for easy monitoring). Mixing and mastering is when the plug-ins go on. An amp sim might be an important element while tracking but not much else I can think of at the moment. I'm with you all the way on DAWProject being for one-way trip workflows. I can think of why some people might want to try going back and forth, but it seems like asking for trouble.

My favorite (maybe little-known) way to quickly switch to another tool and immediately come back to whichever one I was using is as follows: Assuming that you're using the Smart Tool and you want to momentarily switch to the Move Tool, press and hold F7*. While holding F7, do whatever moving tasks you wish, then release F7. The tool will switch back to the Smart Tool. It also of course works for any other pair of tools; for a track with phrasing issues you might want to start with the Split Tool then quick swap to Move, repeat until you have it sounding in time with the rest of the music. It may feel a little stiff the first half dozen times you do it, but once you get the muscle memory, you'll probably be able to fly. (*this assumes standard SONAR/CbB bindings, so unless you're really attached to your custom ones, maybe re-import the SONAR bindings from the Keyboard Shortcut prefs. or set up some new ones for the tools) As @David Baay said, the Smart Tool can do different things depending on where you click, so it could also be an opportunity to print out the page of the manual that has the diagram for that and get to learnin' it.

I did some digging and PreSonus and Bitwig have DAWProject on GitHub. @azslow3, you may find it interesting. I'd love to hear what you have to say about it if you take a look under the hood. PreSonus have a page that points to developer resources for ARA and other extensions to the VST spec that they are involved with. I'm especially intrigued by the PreSonus Plug-In Extensions. Among many other things, it seems to allow VSTi's to report to the DAW what articulations they have available. I'm impressed by how cozy Studio One seems to be with certain manufacturers' plug-ins (specifically brainworx/Plugin Alliance), and now I know what's behind that. Kudos to them for putting the extensions out into the wild for everyone to use. Cakewalk has a proud history of embracing stuff like this (ARA, Groove Clips), and I'd love to see that continue with Cakewalk Sonar.

You've come to the right place....

I wish that it hadn't gotten less interesting lately. Custom theming was one of my favorite features of Cakewalk. Here's hoping that Cakewalk Sonar brings it back.

Just guessing, this is probably where the process is running into trouble. Either that or the switch in time signature.