JnTuneTech

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.

Yes. As mentioned in the beginning. -Unfortunately though, there is no "fine" control that way, as you have found. I have no idea if that is possible.

With the RME interfaces, you have a lot of fine tuning options, that are up to you to set before it gets to Cakewalk. Not the least of which is how the input/output routing & respective volumes are setup in TotalMix - the RME hardware mix controls. -So, for instance, if your TotalMIx direct output signal path is set to a lower volume than say, the DAW channel output(s) you use to send Cakewalk playback to your speakers/headphones, of course Cakewalk will sound louder, because it was set that way. - And that is just one example of settings that can affect the relative volume of outputs you describe. This subject can in fact be confusing for anyone, at the outset, since it's sometimes hard to remember that the hardware outputs of most sound devices have their own mixer, which takes understanding, before connecting it to a DAW. I suggest familiarizing yourself with the RME mixing & setup functions (you would need to anyway to set initial microphone levels, headphone impedance matching, etc.), and then you may understand better the relative volume levels of the audio paths you set - it will really help you to do all that before you assume just connecting something in Cakewalk will just automatically be balanced or preset. And, you can try experiments to figure out how to get what you want , save mix settings, and so on - the RME documentation is all there (though I admit some of it is a bit dry!), and eventually when you get comfortable with the options, you may even find some great creative audio routing and even processing options with the RME audio hardware & Cakewalk together, Give it a try!

Yes, and you have explained it quite well. Also, from what I have seen, your work on controller mapping software has been very helpful, thanks for that. To what I said earlier - there are ways to establish and use basic standards. Otherwise, we wouldn't have a long list of manufacturers and instruments in Cakewalk who participated in the MIDI 1.0 GM & variations of initial standards, and things like MIDI CC1, 7, usage etc. would not have been (and still are) widely adopted as standards. And although I don't know the entire story, obviously Mackie (or the company they once were) managed to push a hardware & MIDI mapping standard set that still exists today. From what I have read of the development of MIDI 2.0 specifications, that is something that the newer guidelines are hoping to give more possibilities for developers to create and build out with modern capabilities. And I for one, am also hoping so. @Bassfaceus - I definitely understand what you mean. And even though the X-Touch seems to be a fairly decent piece of hardware, and I even happen to be fine with drilling into the manuals, or downloading configuration apps & all that entails, I too just wish some of these devices had an easier way to use what I consider basics - at least baseline control definition sets, with plugins, because I too prefer to twiddle knobs more than dragging a mouse... And by now, MCP is so behind modern system & software designs, but sadly, none of the other frameworks for that kind of stuff has come out on top. -Definitely frustrating, and it can't be helpful to DAW developers either!