Noel Borthwick

Hello this was an installer problem. It has since been updated. If you are encountering this issue you can simply rollback and then reinstall the latest update again. This should fix the issue for you.

@HIBICan you send me your text file? It definitely worked with some Japanese text we tried. Are you running an English version of Windows with the language set or Japanese Windows?

@Percy Ferry that link isn't accessible. You should be able to zip the minidump and drop the size a bit. If you save from task manager for a hang the dump file will be big since its a memory snapshot.

Arrangement Preview will not be sample accurate - that's why its called preview. It will improve though if you run at low latency. Can you verify that it improves? Depending on project load seeking to far apart sections may cause small discontinuities. Crossfades won't solve all problems. In general arranger is a tool for editing, experimentation and composition but before getting ready for production you typically need to render it and do some clean up.

This issue should be fixed in the 2020.04 release that was posted earlier today. The issues below were related. Please verify that it is fixed and no longer occurs. Unexpected behavior with Instrument tracks when adding MIDI ports. Adding or removing MIDI devices can cause soft synths to be assigned to incorrect ports.

Just to clarify for this thread, the problem RBH was having has been resolved. He has a broken DirectX installation that causes even the Microsoft DirectX diagnostic tools (DXDiag) to crash. The new version of Cakewalk uses Direct2D for some drawing optimizations for the arranger UI and this is what triggers the problem on his PC. Normal Win7 systems are unaffected by this problem.

@Nicault what exactly is the problem you are having? If anyone on this thread is having a specific Win7 problem with the early access release please get in touch ASAP.

For the record Windows 7 is end of life and we do not have the resources to test or develop custom workarounds or hacks to keep CbB working on Win 7 anymore. Though we try to remain basically compatible, problems like this will continue to happen because nobody is testing it anymore. That said, if there is something fundamentally broken and we can find a cause we do try and address it when possible.

@Craig AndertonWhen you select entire mix, exports are captured from the hardware mains rather than the buses. There is no hardwired logic to favor the master bus - its all based on the signal flow. i.e. if your selection has tracks and buses that route to a specific set of mains by default they will be shown in the dialog. If there are multiple hardware mains selected when you export, then we internally create a bus to mix down all the mains selected and export that bus output.

@markrounds what specific issue are you referring to? I'm not aware of any Maschine problem that came my way. Do you have a case number for this?

No current plans to make Cakewalk itself cross platform. We're working on other cross platform apps and our efforts could ultimately help facilitate a full cross platform port but its very unlikely to happen in the near future. Staff view is a lower priority since it is one of the least used features. We try to make incremental updates to it but it was never intended to be a full blown score editor.

We just posted the 2020.04 early access release. Please post any comments or feedback directly in the linked thread. We're very excited to get this major update of Cakewalk out. We plan on releasing the final build next week which will include a few more tweaks.

I assure you it will be worth the wait

@HIBI this is fixed for next release.

Will look into it thanks for the heads up

Hi Folks, as mentioned in the prior release that model is considered "beta" since I still have to do more testing with it. The latency problem is due to a weird race condition leading to audio buffers being lost. I just havent had time to track it down yet but will get to it. For now don't use that model until further notice.

@Maxim Vasilyev the problem with track names displaying garbage has been fixed. As mentioned above its actually caused by the way the VST3 SDK reported this so technically could have been easily addressed from the plugin side (most other VST3 plugins handle it). However I have made a change to resolve it from our end. As far as VST2 goes there is no way for a host to report track names to the plugin via the standard VST protocol so this won't work with Relay in any host. You must use the VST3 version to get this functionality. Cakewalk has supported VST3 channel naming from the get go for many years now. With regard to track ordering in Neutron, this is a deficiency in the plugin since it it appears to be sorting the track names alphabetically and ignoring the host specified track order. There is a specific VST3 interface that can be used by the plugin to identify the order of tracks. If they use that the tracks will be sorted in the same way that they appear in the host. This is how it works with the Softube Console One. BTW the same track ordering problem can be observed in other VST3 hosts such as Reaper.

I've fixed this issue as well for the next release. It had to do with some peculiarities with how Relay requests the host to do resizing via VST3.

Oh well I managed to sort out the string garbage by fixing some code in the VST3 SDK . The SDK code was not copying over the null terminator for the string ? I'll submit my change to Steinberg as well since any app that uses that would be susceptible to the same problem.

@Matthew Sorrels I finally had a chance to look at this. The problem is not in the Cakewalk code. The channel names are provided by a standard VST3 interface called IAttributeList and provided via ChannelContext::IInfoListener. In this the string is properly null terminated but VST requires the user of the string to use the string size provided and properly null terminate their target. This is not being done by the Izotope plugin hence the garbage appears. I will pass on this information to Izotope.

I cant quite follow what the problem the user is having other than the fact that something doesn't work right with REAC. Since we no longer have a REAC system to test and it is no longer supported by Roland its going to be hard to troubleshoot. One suggestion is to turn on "StopEngineOnASIOPanelOpen" since some Roland devices don't like the audio engine running when the ASIO panel is opened.

A fix for this is now available in the hotfix we just released.

After several hours of troubleshooting and a tip from @Steve Katsikas I managed to reproduce the issue again. Its a bizarre preexisting problem that happens when you seek on the timeline to a late measure. In my testing the app would appear hang for about 5-10 seconds and then vanish silently. I was able to find the root cause and fix it last night. The engine was incorrectly responding to a seek on the timeline and computing a bogus delay compensation value. In Steve's case this could compute a delay of up to 3 hours ? This value would then be used to send a HUGE MIDI buffer the next time playback started causing an overflow and crash. While most users wouldn't necessarily see a crash (since its dependent on the amount of MIDI data) this issue results in way more MIDI data being processed when playback starts at a high measure number. I've sent Steve a build to verify the fix and if all is well we'll be releasing a hotfix with this and a few other issues soon. I'm happy that this issue is fixed since it could have been the cause of many unknown random crashes in the field over the years - the problem has been latent at least since 2006 Fortunately his project was reliably able to reproduce this and allow us to fix it. Thanks for working with us to repro the issue.

@Steve Katsikas its the strangest thing. I tried for 30 mins today to reproduce this issue and it is no longer happening. I went back to 2020.01 and even SONAR and the project plays fine at 48K and I even the your markers while playing extensively. Both myself and a colleague were able to reproduce it earlier but the issue seems to have gone away. Can you please retest this after updating windows since its not impossible that there was some external update that fixed itself. If you can still reproduce it please see if you can get a sequence of steps that makes it more likely to happen. @Bob4u I think your issue may be something else based on the crash. Please ensure that your VC redists are up to date by downloading and updating the latest 64 bit VC redist from microsoft.

Hi @Robert Bone @FJ Lamela and others who had this issue. Please try out this version of VST scanner. I've updated the logic so that it is more specific about the VST3 folder rather than just checking for VST3, It will now only look at the standard VST3 folders under Program files or Program Files (x86). Also it wont get tripped up by names like VST32. You will need to copy that file into C:\Program Files\Cakewalk\Shared Utilities and then scan again. Let me know if it fixes the issue.