msmcleod

I'm guessing it must be PC architecture, because apart from that they're very different. And now of course, Linux will run on almost anything.

Have you got "Fast Bounce" checked in the export audio dialog? If this is unchecked, it'll export in real time.

One more thing to try.... The MackieControl DLL was built over 5 years ago with a much older version of Visual Studio, whereas pretty early on in CbB's development they moved over to Visual Studio 2017. I wonder if it needs the earlier VC++ runtime installed... The 2015 runtime is here: https://www.microsoft.com/en-us/download/details.aspx?id=53587 The 2013 runtime is here: https://www.microsoft.com/en-us/download/details.aspx?id=40784 It might be worth giving it a go. [Edit] - Just to give some background to this... almost everyone I know on this forum who uses the Mackie Control has come from SONAR, which was built with VS 2015. This would have come with the VC 2015 runtime as part of its installation. So moving to CbB wouldn't have caused any issues. It's just a theory, but it won't do any harm to install these. I'd try the 2015 first, and if this doesn't help try the 2013. FWIW my version of the MackieControl.dll is compiled with VS 2015.

The Mackie control dll is called MackieControl.dll and lives in c:\program files\cakewalk\shared surfaces This DLL holds Mackie Control, Mackie Control XT and Mackie Control C4. If this isn't registered, they wouldn't appear in the list.

You'd be better off with a 02R. They go for around £300 ($400). They were closer to $10K when they came out. The technology is much the same throughout the range of those products. More or less the same IC's are used in the DS2416, 01V, 01V96, 03D, 02R, 01V, ProMix 01 and 01X. The 02R was "the" pro digital mixer at the time. It's easy to expand too, with MADI, ADAT cards etc. From what I hear though, practically no-one uses the EQ on these. It's neutral, but pretty uninspiring. On the upside, each of the 4 EQ's have the full range of frequencies. They're still perfectly usable though.

From what I remember, it wasn't a failure as such. They did get something working, but the cost of making it work properly was too high. Then of course they'd have the cost of ongoing maintenance of DAWs on two OS's. Cakewalk have already dropped 32 bit support so they can concentrate on only one OS. So yeah, don't expect one.

That's certainly true for some products - and especially computer products - but others seem to keep on going. The 01v96 came out in 2003. The 01v96i is essentially the same, but with some firmware upgrades and USB audio support, and it's still on the market. And you can't knock them for parts... you can still buy parts for the original DX7. To be honest though, I had a great run with my DS2416 cards. I bought my first one when it came out (1997 I think), and I only retired it 2 years ago. So 20 years of use, which isn't bad in anyone's books.

I can find any proprietary USB drivers for the MCU, so it must be designed to use the generic Windows MIDI USB driver. The ports disappearing doesn't make sense. It's almost as if it's refusing to open the ports, but then if that was the case, surely Cakewalk wouldn't list the device? You seem to be doing everything you should be as far as setting things up. I would give Cakewalk support a shout. Maybe they can work out what circumstances would cause the ports to be removed from the dialog, and take it from there.

I guess quite a few of us are still feeling burned by the events of Nov 2017. The Cakewalk development team is now far smaller than it was, and a lot of us are keen to see them focus on fixing some of the long overdue bugs, rather than work on what would be a quite large new feature. But I totally agree with your sentiments here. No one should be shot down for making a perfectly valid feature request.

Yeah, the SW1000XG uses the same audio recording drivers as my DS2416 cards. I used to check the ALSA site too, but I've given up hope. It would need input from Yamaha, and they will no doubt refuse to make the needed technical details available. I'm part of an 01X group on Facebook, and a similar thing happened there when trying to get info on re-writing the 01X drivers. Luckily one of the group members managed to hack the existing drivers to work with Win 10.

Do the MIDI devices disappear from the main list of MIDI devices as well? This might indicate a hardware or driver issue (bad USB cable maybe, or out of date motherboard drivers?) You've not said what OS you're using, but have you got all the latest upgrades/service packs? Other than that, I'd try contacting Cakewalk support: support@cakewalk.com

I'm not convinced Celemony will ever fix this. Celemony developed ARA 2, whilst leaving backwards compatibility with ARA 1. I suspect something in the 4.2 update has broken backwards compatibility in certain scenarios. However, Celemony won't want to continue to support ARA 1 compatibility, when they'd rather DAW developers use ARA 2. So I reckon it's probably going to be up to Cakewalk to support ARA 2, which is probably on their road map anyhow.

I've always been more than comfortable with Ubuntu both for server & desktop systems. In the past 15 years, I've gone from about 95% Windows development in my day job to 95% Linux development. Linux has pretty much won the server war. At home I can pretty much do everything on an Ubuntu desktop for free (an most of the apps do actually come pre-installed with the distribution). You don't need to be a techie to use Ubuntu either - up until she got her new laptop, my wife was quite happy using Ubuntu for 3-4 years without any need of assistance (well, apart from installing the printer drivers). The only thing I can't do well is audio production. The biggest problem with Linux is its lack of native audio drivers for pro audio interfaces. So whilst there's some good DAW's out there, like Rose Garden, Reaper, MixBus/Ardour, N-track etc., you're limited with the hardware that you can use with them. RME seems to a be a notable exception here, but I guess if you can afford RME gear, you're probably not that fussed about paying for an OS The other issue is compatibility of plugins. Actually, most will work under WINE (this is after all what MUSE Receptor does), but they will run slower than on a native OS, and proprietary anti-piracy protection can be a real issue here. It's a bit of a catch-22: people won't use Linux for audio because of lack of support, and hardware/plugin manufacturers won't support Linux because people aren't using it.

Ah, I wonder if it's your MIDI driver mode... make sure it's set to MME rather than UWP. I've had no end of issues with UWP mode, but MME has always been good for me. You'll need to make sure all projects are closed to change this:

Maybe the USB hub is the issue. I use the original MCU plus an XT and 2 x C4 in my main studio. The MIDI traffic is pretty high. The MIDI ports shouldn't disappear though. Are you certain nothing else is using those MIDI ports? Try using the MCU without the USB hub and see if its more stable.

ACT and the MackieControl control surface are different beasts. You can't use them at the same time. You need to make sure that the MackieControl plugin has exclusive control of the Mackie MIDI ports. ACT can't be using them at the same time. To setup, add it as the following (obviously with your own Mackie MIDI Input/Output ports): You should then see it here: Once applied, you should see it under the Utilities menu: Also make sure these options are selected on the Mackie Control dialog:

It's significantly faster at detection. Not sure if they've improved the accuracy of the detection or not, but it's still just as good. As long as you've created a Region FX, and selected an algorithm you won't get the crash. The template method I described earlier was a bit hit & miss. The common factor for failure seemed to be whether the Melodyne GUI had been active or not. If it was visible, and was focused at some point (i.e. you clicked on it), then it seemed to work.

A couple of things to check... 1. Make sure Analytics is unchecked in preferences: 2. Make sure you've not got background plugin scanning enabled. Set it to Manual:

I find drinking water when I get the munchies helps. Also forcing myself to go to bed earlier... but that's easier said than done. Too much to do, to little time.

I think I may have found a new workaround... Create a new project using your usual template (e.g. Basic) Create a new audio track, and record a very short silent audio clip Create a Melodyne FX Region using this clip Select the Algorithm within Melodyne Hide the track from both within the Track view & the Console view Close Melodyne within the MultiDock Save your project as a template (e.g. Basic_Melodyne.cwt) Now when you create a new project using this template, Melodyne is loaded & initialised using the algorithm you previously selected. The hidden track can be a bit annoying if you use an external controller however, so in this case just miss out the hiding the track part when creating your template, and delete the melodyne track as soon as you've created your new project. [EDIT] - Scratch that... it doesn't work every time

Have you tried JBridge rather than Cakewalk's BitBridge for 32 bit plugins? I use SampleLord as a SF2 player (it'll also play GIG, FXP, NKI, EXB, WAV, AIFF files too). It's not free (€40) but it is 32 bit. For something like my own sampled piano, I find using SampleLord via JBridge is a lot more CPU friendly (and perfectly stable) than something like Kontakt in native 64 bit. There's far more options in JBridge for dealing with any compatibility issues than BitBridge, which has no options at all.

Have you got any look-ahead plugins on the vocal track? Try bypassing FX and see it that solves it. If it does, then look at what plugins you're using. Also, when using Melodyne consider "Bounce to clip(s)" after editing. I've never been comfortable leaving a region fx open for any length of time.

Have you looked at Plogue Sforzando? https://www.plogue.com/products/sforzando.html

I take it you're using Melodyne as a Region FX (as opposed to putting it in the FX bin) ?

Changing the buffer size will force a change in AUD.INI, so although it isn't quite the same as deleting it (which would force Cakewalk to create a new one), it was obviously enough in your case. As you say though, having a mismatch between 44.1K & 48K would have caused issues too. Some drivers don't always change their sample rate / buffer size when Cakewalk tells them to, so it's best click the ASIO Panel button and check there too. I'm glad it's all sorted now