JnTuneTech

Your mileage may vary - or actually will vary depending on what sound interface, drivers, and settings you use, to answer the general question topic posed here. CbB converts things within a project to match - as per your choices. -Then - for your specific end scenario, upsampling from CbB on an export is also quite easy. Or, you can do that with other software after the fact, before sending it to your mastering engineer. Everyone finds their own favorite workflow there. FWIW - In my recent CbB & SONAR project cleanups & consolidation efforts, I have found that CbB seems to primarily base the stated overall project bit-depth, determined, in my experiments anyway, by the highest bit-rate audio clip in the project - mostly. -So, for instance, when I actually want to change the overall CbB project bit-depth, I use that as a guidepost. In my system, sometimes I seem to get better performance, -but not always audio quality (but it's very hard to tell), by matching the overall project bit depth to my audio interface recording capability (which for me is currently 24-bit). And if I have a 32-bit or higher audio source I want to use, I back it up (just in case, in practice CbB doesn't resample destructively anyway), and then have the import dialog convert it for me, -most of the time. -Then viola, the project rate changes to whatever I wanted. But that's only what I choose to do, -there are many good choices. I find that CbB does a great job of using mixed bit-level files, at almost any sample rate, with my systems over the years. But the actual sound quality of the overall output, and exports to be sure, changes individually depending on settings used, and the hardware interface & driver performance combined. -You should experiment to find the combination of project settings, file bit-levels, and then of course sample rate base, and dithering that you find works & sounds best with your system. That part varies widely. But otherwise, mixing audio file bit-rates within a project, and exporting at another has never been a problem within CbB for me. And with plugins, internally I suppose that's a whole other story, but again, Cakewalk seems to handle it all "under the hood" quite well so far for me.

I guess many of us have been at it long enough now (maybe not always continuously - for me either) to see the catch-22 that this modern software-based audio production technology presents, you know? I had never thought about it that way originally, I was just so jazzed to find that I might not have to buy every pedal and rack unit out there to do each effect I had always really wanted to use on my old cover tunes, and that I could have access to keyboards, even entire orchestras, -provided I could afford it and keep the computer in good enough shape to use them practically-, that I mostly stopped buying hardware for recording & production at all, when I got back into it about 15 years ago. Then, I paused again about the time Cakewalk was about to get dumped by Gibson, and didn't delve into CbB until about the 2021 release period. -And like you, I also upgraded a lot of my old plugins, and had the same problems you are describing. -Even a few of my older NI libraries had been reorganized by then, which would screw up loading projects with them in it until I re-ran a library search, resaved the project, etc. -All the while however, I still had a few rack units around, and any time I wanted to use a compressor, or a reverb for instance, those units would fire right up, and still do the very same thing I remembered, every time, no updates, no reinstalls, no relicensing... Sometimes you just can't win! Just last week - I opened an older SONAR project, which used a few Dimension patches (oops - programs!) - but ones that had been created and saved using the old 32-bit Cakewalk Sound Center plugin. -And, I had even saved the programs in the project folder, and "upgraded" them to running in 64-bit VST3 Rapture Pro. However, when I played the project, only 1 out 3 tracks using those programs played back the MIDI. -I scratched my head a bit, then looked closer at the names I had given the program files - and saw the non-working ones were referencing a "CWSC mod". I realized then, I had recently removed all the 32-bit plugins in CbB that I could, including CWSC. -So, I went to my backups, and found that originally, the 32-bit CWSC implementations used an entirely separate copy of the Dimension & Rapture multisamples, -instead of the eventually common shared folders that things became and was used until SONAR was dumped... Luckily, I had backups, but backpedal, backpedal, to finally open just a simple older project properly. Jeez. Anyway, I thought I had done so well "upgrading" and backing up my settings as well, but even that sometimes gets trounced by the changes in the technology we just casually use, and then you have to backpedal & gyrate just to open a project you thought was so simple! -Then of course, there's the snags due to licensing and corporate ownership issues, that we find out as time goes on, on top of that. Sigh. -But well, as you say, most of it at least still keeps working (after some backpedaling anyway)!

(OK, I just had my cup of Peets...) I am one of the folks fairly OK with subscriptions (yes, I know...), and I was all in with the lifetime thing with SONAR, but like you, I knew better than to expect that literally - from any company or product. -I was still hoping to get an unlock key for the version I had last paid for, but again, I know what to expect from corporate dealings, so I have never complained about that. -I did notice, within the terms of my iZotope subscription, that supposedly when I cancel, I will still have use of the software to open & run, but not edit or modify iZotope projects, and I think that maybe applies to plugins too (?) - at the last version level I paid for. -That's about all I hope for these days, -being able to just use the software as it is - at least until my system dies or is updated too far ahead to use the old stuff. There sadly is a lot of stuff that doesn't work that way. -I keep heading towards making nearly immediate stems of all my projects that are using Native Instruments libraries... just in case. Part of the modern workflow is planned obsolescence. -Ah well, more coffee, so far "my" blend is actually still on sale here in Alaska today... 😅

Web site security is such a thankless job - seriously, thanks to the mods here, I think I've noticed so much less trouble overall here than in many other virtual platforms over the years. -And things like that lately seem to be on an upswing, and AI automation in general is going to help it get worse. Still, so far it's still down to human caused foibles - isn't it? -I once had the unfortunate experience to be in contact with one of the earliest spammers, briefly, back in ancient times (!). She started sending unsolicited self-marketing mass messages on Usenet, if I recall correctly. -In conversations with her, she basically stated that since the Internet itself was a product of tax-supported infrastructure, as a taxpayer she should be able to do with it as she saw fit. -I even have old friends who feel that if something is "free to all", they should be free to use it in any way they deem appropriate. -Of course, the logic never holds when someone uses that type of methodology, and it hurts them personally. Always a moving line between what we "can" do and what we should do - isn't it? Painful to think about that story, as that person even went on to make money off of a book, explaining her "marketing techniques", when she gained some notoriety for her actions. -I hope she has would up in some place that endlessly repeats cheap TV ads over and over, in a locked room, with no remote control or something. -Sigh.

If you read the setup instructions on any major amp sim plugin, one of the first things they will state is that you have to find a proper input signal setting for your instrument input on your sound interface - to actually drive the simulations reliably. And many higher-end sims will point out that properly designed electrical inputs for guitar pickups & the like are not always the same. -Setting that all up prior to having a pass at tweaking the virtual gain in the DAW, will probably be more important to your virtual amp performance than anything else. -And for me, finding that setting that works consistently, across several types of instruments (guitar, bass, etc.) is tough, since, as you probably already know, there are so many styles of instrument pickups, it's nearly impossible to achieve in a DAW without having an individual audio interface gain (and possibly impedance) setup for each instrument, which is a real pain. I have long since found that using factory presets, or other user's presets, in amp sims, never really works exactly as designed (or what the name of the preset seems to impart in my mind anyway), and that is because I am not using the same sound interface, the same input level, -much less the same guitar (or talent for that matter!)and even the same strings, etc. - before it even gets into the DAW & plugin. -That being said - yes, you will notice all kinds of differences in amp sim performance, starting simply by changing the gain in your sound interface, and up to and including the gain staging in the DAW channel and plugins. -You just have to find what works for you, and if you really think you've found a great sound - definitely print it - before you lose it! -Or, at least try to document all your settings in achieving that sound. -Not that it's any easier really in the real world when using various amps, cabs, pedal chains, and so forth, -but it is a whole different set of variables to learn in a DAW. -It can be fun, and frustrating - often all at the same time! -From my experience anyway, FWIW.

I keep seeing discussions that go on about this, but the biggest difference here is that we are not using a physical channel strip and amplification hardware inside of the DAW. -The place where hardware gain staging works in a typical DAW is in the audio interface - which has the real controls for gain and headroom (plus impedance, routing, and so on). -Before it even gets to the DAW. And some audio interfaces even include pre-DAW input processing options, so using the old analog methods inside the DAW will be useless if the hardware I/O mixing is not right in the first place. I see so many posts in these forums, regarding issues with audio interfaces, starting with the drivers, & connecting to CbB tracking, And it seems to me that audio interface setup and configuration is one of the biggest wildcards in using a DAW, versus something like an old integrated mixer & recording deck. (Plugins are then the next biggest departures and wildcard issues). -Gain staging inside the DAW is certainly necessary and important, and for things like chaining plugins can be very important to understand, but again if you really don't learn how the hardware I/O controls & driver options work, you won't ever get the kind of scenario that you are talking about above with using analog mixing and gain control, except by luck if all your mics & line levels somehow magically set themselves up in your sound interface, -which again, comes way before the channel strip & virtual gain inside the DAW.

FWIW - I found that using Offset Mode worked for me - if I also saved a project backup before engaging it. -I know that can be confusing, and more work, but as others have mentioned, it seems to be best using a project in one mode or the other - not switching back & forth. -I think "accidental changes" are meant to refer to the odd caveats that happen when switching back to non-offset mode and assuming that your project will still have the same mix. There's even a warning in the documentation regarding offset mode. I had several mixes, years ago, during which I accidentally pressed a keyswitch that turned offset mode on - before I even knew what it was - and then saved the project. After that point, I couldn't ever get back my original non-offset mode mix from those projects. -It seems to me like maybe it's intended to use either for temporary playback - comparisons, and bypassing envelopes in live mixing, etc., or for those who wish to use it full time, -and don't get me wrong - it does have good uses. -But be careful, -back up your mix(es) - once you start playing with it, for sure.

I'm glad you found & copied your old instrument definitions - those take a lot of work to set up! -I have been copying mine to backups for years now, and when changing PCs they can be invaluable. I have a suspicion that the reason the saves don't work normally, is that under Windows 10 - the Home Studio app needs to have Windows - compatibility settings configuration (in the Windows app shortcut run options - try XP compatibility) and maybe even run with admin permissions, to enable things like that. Especially since it is a 32-bit legacy version. - I hesitate to advise you on how best to enable that, as it depends on your system & security preferences, and also changing that can make you have to reset things in Sonar - depending on how you enable running it as Administrator. -But keep at it, you are on the right track, if you really want to keep that old version. -As others have noted, the current CbB is designed to run almost any older version project - probably much more efficiently as well, so you may want to just work towards that. -CbB can use your old Master.ins just fine as well, BTW.

Well, as long as the Skipper doesn't start out calling you "little buddy" right off the start, you should probably be alright. At least in those waters. 😬 P.S. - My subs have plenty of "condensation rings" on the top... After a while it just becomes normal. I even caused several of them myself!

The reason this was asked about, is that Windows programming defaults were changed for some of those type of things when Windows 64-bit OS became available, and eventually the standard. File permission to add/modify things in certain system directories has changed as well. I don't know how 32-bit Home Studio 4.01 was originally meant to reference its preference files. In 64-bit versions, some of that now gets set and modified in the normally-hidden "AppData" subfolders under the logged in user name folder. The running version of Master.ins for (64-bit) CbB typically resides there, and other copies can exist but are only reference copies. If the running version of Sonar you are using does actually try to write to a Master.ins in the directory you have listed, it may not have proper permissions to change or save that file. That might be causing what you describe, unless there is some other issue saving an update to a system file like that.

And I will also repeat that what the OP has found in practice is that there is some difference in performance, on their system & projects, between exports using virtual bus outputs, and the ones that have problems for them are the ones that are identified as hardware output related. I don't doubt that any of you are correct in your reporting & analysis, but since I don't write or know how to analyze the actual code involved, again I am looking forward to testing and seeing if I get the same results as @Max Arwood has posted. And again, I feel that programmatically there may simply be more involved in the coding for each output scenario, logically. -In the end of course, if it works better, regardless of whether my suspicions or reasoning is correct, I will be happy to have error-free exports on large projects. All of this is good to know, thanks all.

I am just guessing, but in my mind having the DAW export to a hardware-defined output, versus a software defined one (such as a bus), will always have the limitations and circumstances imposed by the hardware driver, in most cases. -If I am right, the problems the OP experienced could possibly be due to various inconsistencies in the export type, and maybe even plugin data conversions, what have you, to accommodate the output destination - hardware/driver requirements. Perhaps I can test this as well when I come upon a larger or problematic mix export. It may very well be that mixing and exporting straight from software defined paths is easier technically. -Say for instance, if you are mixing in 32 or 64 bit, and your hardware driver is only rated at 24 bit - wouldn't something like that be an added complication? To me, it seems like exporting to a hardware output is not a great goal, since a hardware output is not really the destination for a file - it's really just an output to an amplifier circuit, in essence.

Indeed. -That one was mentioned as a possibility in the article listed at the beginning. -Well, for now, looks like there won't be the awkward conjunctions from the other affiliations that could have happened! -Still, though I wish them all the best, these once individually-defined companies all seem to be fading into obscurity under the guise of "managed acquisitions", and one always has to wonder how that will wind up for the folks like us who just need to use the tools on a regular, reliable basis. Not that these things are always bad, and our continuing here with Cakewalk can easily be an example of that, of course. But so many of the original companies and brands I grew up and went to work, and play with, seem to have watered down and all but disappeared, and acquisitions like this are usually the beginning of that. -Investment groups don't just do it for fun, a price will be extracted for the shareholders above all else. -Ah well, I guess I should have worked to be a musical stock broker or something like that maybe? -Perhaps in another life.

Just adding to the other recent posts about the companies we used to think of as "solid" businesses in their own right... https://musictech.com/news/industry/native-instruments-investor-bids-to-acquire-avid/ Hmm... So, which app will we soon need to download & license it all... Native Access, AVID Master Account, iZotope whatever... ? -I'm not sure I even want to know!

RME TotalMix settings are up to you to save as a file (there are many options, so read the documentation), but in general, I have never had a driver update or reinstall delete the last saved TotalMix configuration. You may have to reset your driver configuration preferences -But again, saving the mix yourself is safest, and then if backed up properly you can have the settings even if you should have to reinstall the OS, etc.

The process for me has been: A: If I was happy with the mix, I would do the recommendation that @57Gregy laid out (often I would record just the full wet reverb output in a separate track), and B: After removing the plugin from Cakewalk, then yes, update any projects that had used it. -At least those projects would open reliably, and my system was more stable overall, so it was worth the effort. -For me anyway. And don't get me wrong, it was tough, I had a lot of old projects with PerfectSpace in them. A few other things to note: I also turned to mapping and using some of the same IRs in other convo reverbs, but I noticed a few things right away. First, PerfectSpace by default used an auto-leveling algorithm for the IRs on loading, and for me it really smoothed out testing various choices side-by-side. When using other reverbs, that didn't happen, and very often my original IRs seemed to take a lot of "fixing up" to find the sound I had been used to with them. -Also, PerfectSpace had an internal latency setting that had to be adjusted to match the sound interface settings, and when that didn't work, some very bad timing & CPU usage would ensue. -That function alone was maddening enough to warrant removal, again, -for me. So, it has been tough, there is no easy fix, but I also feel moving to a more modern plugin is worth the work, in the long run especially. -Or, yes, you can just cross your fingers and hope it keeps on working, reboot every time things get buggy... it's your choice!! Keep backups, and maybe an old 32-bit system? I know some folks do it that way, and if it works...

My first thought would be that in one instance, the track is set for stereo interleave, and in another it is set for mono interleave. -I am also assuming the driver naming ":S" is when using the stereo interleave, and ":L" is when using the mono interleave. "S" being stereo, "L" being left mono.

Several things seem a bit unclear in your post, so it's hard to answer exactly. But as far as the wet/dry issue, it really sounds like you may need to revisit the routings you have set up, as it sounds like more of a misunderstanding in use of sends & levels. If the plugin is set to full wet output, then you should have no problem adjusting the relative mix, normally. In my experiences over the years with PerfectSpace - I found that it was great in the 32-bit era, but I had to pull it off my system for modern usage, because when it got used in conjunction with BitBridge & the like in a 64-bit SONAR setup, it became way too unreliable and a resource hog. -It didn't necessarily stop my projects from opening per se - however, when opening & closing several projects that used it in a session, invariably things would get buggy, lots of transport errors, and several times I had to completely log out of Windows, or forcibly quit the BitBridge server process that would often hang even without SONAR running. And it did sometimes crash a project on opening, but a full reboot would "fix" that, and the project was not harmed. -Not worth the hassle though! -That's my experience anyway.

I still use a few analog tools with analog patching - when bringing in XLR balanced to a mic-level input that may not be very adjustable, there are adapters for that. Especially if you are worried about some kind of input mismatch on the level that might overload something. In the picture is one of a pair I have used for years (together with an XLR gender change adapter), on and off stage, mostly just to extend unbalanced cable runs with less RF interference, but also just to match the levels without so much input switching involved. -Since this one is passive, it does roll off the high frequencies a bit, sometimes a DI box with adjustable response can sound better. Lots of choices.

I tend to agree (on several points..) - mainly that treatment, including a good FX chain can be the part that gives life to samples, but is best when adjustable. -Simple things like SI Drums - you can't change the flat samples, noisy ones are noisy already, so that's tough. -Even with TTS-1 - if you forget that the default for patches is to have reverb send at 40 (and that reverb is rather "canny" to me), then without adjusting things, you will think it all sounds cheesy. -Start with drier sounds, add FX, play with stereo in the mix, and many basic sample sets will work better than you might think.

Yeah. Something about the "..Watched a ton of youtube videos and read forum posts.." part left me thinking it was a bot-created post, probably to get hits going from the Amazon product link. -Certainly didn't seem to have read the other zillion posts about ASIO4ALL. -And when I bring up the OP - I could swear I hear dogs barking somewhere (blatant Terminator reference) - but maybe that's just me... Anyway, I think your first post answer was as helpful as can be, for all that it's worth now!

Yes, I think the drift here is to use a smaller device for external VST control already. (I have the BCR2000 as well, but it's a bit clunky, and not small though 🤓) I think a lot of folks already do this as well, and there are many modern products out there, and more every day. Some are super expensive (SSL, etc. - yikes!), and some are cheap plastic built for failure... but I digress! - Both the OP and I have the X-Touch Mini. That one has the same type of 8-knob - button layout as the older Behringer BC series (so as to easily map the MCP options), but with only 1 row of rotaries & "VPOTs", as well as 2 rows of buttons, 1 fader, and a layer switch to assign things to 1 more alternate set of parameters. Besides the issue of getting either ACT or something like the AZ Controller set up for each individual's system and tastes, I am still always hoping to find some logical way of addressing things starting with some sort of logical "common" set of parameters (yes, I know azslow...), so that I can switch between similar plugins without so much setup disparity. -And, I am still learning these options myself, as most of it is buried in reams of text documentation and setup screens, so it's a learning in progress, to be quite clear. One of my experiments, with either (or both) the Cakewalk ACT customization or the AZ Controller plugin, will be to take similar use plugins, starting with several "typical" (I know, I know...) EQ VSTs, and see if I can define a list of most common functions (EQ band, Q, level, - master i/o level, what have you), that I most always will start from, so that I can always assign those to the same rotaries on each VST template. The goal of course, to be able to minimally control several similar plugins with the same layout on the controller, leaving extra & plugin-specific controls for the mouse. -I know this concept is nothing new at all, but I have a lot of things to learn, and I want to concentrate on achieving it within Cakewalk first as much as may be possible currently. One other consideration - the current small-factor controllers have little or no labeling capability on the device itself, and for me that increases the multi-mapping learn curve. -I have to admit, I can only even type text still using a lot of hunt-and-peck, so that is my particular curve limitation. -I guess on the X-Touch Mini, there seems to be some room between rotaries & buttons that might be something I could apply a custom label strip to, but I'm not sure yet. But anyway, @Glenn Stanton -yes, getting the right type of controller is probably first, and then for me anyway, almost more important is trying to find some common programming setup(s) easily enough that I don't give up!

-I apologize, and I can only say that when I was answering the OP, I was stating my own knowledge and experience. -This entire thread is one I am currently bookmarking, in fact, as between the info herein from you & msmcleod, much of which is new to me, I have a lot to learn by trying some of this out. -I in fact have both the X-Touch (full) and the Mini, and as yet have not had full experience with using your AZ Controller, nor even the customization of the built-in ACT in Cakewalk lately. -Again I apologize, and @Bassfaceus I do hope you re-read through this as well, as it does look indeed like there are many good options to try here. I know I will be trying some of it out soon on my own system. And certainly, @azslow3 - I would not wish for you to stop responding with your valuable information & assistance (i.e. don't "shut up" !) 😬

Not specifically something I know of. Perhaps someone else reading this may offer some other perspective, some kind of MIDI CC to keyboard input mapping app perhaps? I wish I could help more.

In that scenario, you may also want to check: If you use a bus in Cakewalk - whether or not the gain is changed there (or anywhere else in the path). On the RME side - whether or not the gain is changed there by FX if you have enabled "EQ + D" in the Fireface USB driver preferences, as well as the above mentioned hardware mix monitoring levels - does the level of "Software Playback" to your choice of monitoring output match your "Hardware Input" monitoring level? -Most of this you can use your ear for, of course, but also remember that the metering at the hardware level (TotalMix or the front panel) may be the most useful for troubleshooting the actual levels coming out at the end. If this were for studio calibration or something more serious, I would suggest trying the old fashioned method - putting a test tone through the chain, and using the metering options to validate the gain staging. I used to have a console with a built-in tone generator, just for that purpose. -In this case though, you could probably just find a synth or similar sound source, to create a steady pitched output with no modulation, and input that on one of the hardware input channels, and follow the levels through to the end, to check for parity mismatch. -Again though, in this case, maybe you are just curious - but it's up to you, experimenting can be fun, and lead to other creative discoveries, again... IMHO.