Noel Borthwick

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.

@FJ Lamela Some questions: Are the 7 plugins removed when you scan from cakewalk the same plugins from c:/vst32/? Do any of those plug-ins reside within a folder that has the name VST3? Are the removed plugins VST2 plugins?

There have been no changes to Plug-in manager recently. All it does is utilize the VST scanner for scanning but as has been mentioned numerous times, all scanning should be done from Cakewalk not plugin manager. We don't maintain or test scanning from plug-in manager and the scan functionality from there will be removed soon. There are many other improvements to scanning such as sandbox scanning that are only available from the Cakewalk preferences dialog. We'll look into why this happened but please use the standard preferences page for scanning, which has been the preferred way to do it for many years.

Please send the dump file for analysis. Your issue may not be the same problem

@Steve KatsikasThere is something strange going on with that project leading to a MIDI buffer overflow. I'll have to spend some time debugging it on Monday. This happens in older versions of Cakewalk as well. I went back as far as September and also tried SONAR which hangs with that project.

This really looks like memory corruption. What plugins or synths are you using in the project? I see that TTS1 is loaded. Also there are a ton of different ASIO drivers on your system. If its basic can you share the project so we can try and repro? What happens if you remove TTS1 and instead use a different synth does it still crash? What sample rate are you running at?

@bvideoYou can read more about our patented plug-in load balancing here. A fundamental requirement of load balancing is for there to be 2 or more serial plugins that can be processed in parallel. Synths in the synth rack are SOURCES. The synth audio processing must take place individually for each synth before any further signal processing in the downstream circuit is performed. i.e. synths get fed MIDI data not audio and produce audio which is then sent to the tracks sourced by the synth. Its no different from recording audio or input monitoring in that regard. So load balancing doesn't apply here. Any parallel processing for synths has to be done within the synth itself by parallelizing the processing of its voices. This cannot be done by the host since it requires the plug-in vendor to do this. Its a double edged sword even for the plug-ins that attempt to do this however, since the threads in the plug-in start to compete with the DAW's threads and this can lead to other performance problems. I had a proposal many years ago to solve this problem but it requires cooperation with plug-in vendors to implement. For now the best way to do this if the synth doesnt support parallel processing internally is to have per channel instances of the synth and make one instrument track per channel. This way the DAW will manage the parallel processing since each synth voice will be farmed out to its own core. Of course this is a trade off between RAM and CPU performance because inserting multiple instances can take more memory depending on what samples are loaded etc. Hopefully the synth vendor internally optimizes this and shares samples between multiple instances of the synth. For TTS1 the extra memory would be negligible. TTS1 is pretty lightweight so I don't think it would be necessary to split into multiple instances typically.

@paulo There are some more WASAPI improvements in 2020.01 (esp for exclusive mode) so please try it there as well. What output device are you when using the mic in Cbb? This is important because both the output and input have to support the same sample rate and bit depth for it to work. The fix I am referring to has to do with how some devices deal with 16 bit audio. We had a case where a device would only work when the bit depth was set to 24 bit manually. This has been fixed in 2020.01 and such devices should now connect properly. Let me know if updating fixes this issue. If you are still having a problem PM me and we can do some more troubleshooting.

@Steve Moddelmog I looked at all (well several) of the dump files you sent. These are all 100% plugin crashes - the stacks are not even remotely in Cakewalk code so its not something I can analyze further. The crashes are all in a shared plugin dll that they are loading called Chromaphone 2 Shared.bin. I suggest that you get in touch with AAS and give them the same dump files. They should be able to analyze why the plugins are crashing since its within their shared plugin code. I know the AAS guys well so if they need any assistance from us ask them to contact me. Its likely some incompatibility or a bug in the plugin thats being exposed under some conditions on your system. I've included some relevant snippets from the dumps. One more thing suspicious in your dump files. I see that you are running outdated Microsoft runtimes for the VC redistributables. Here are the time stamps you have: mfc140u.dll *C:\Windows\System32\mfc140u.dll 14.16.27024.1 11/7/2018 1:49 PM VCRUNTIME140.dll *C:\Windows\System32\VCRUNTIME140.dll 14.16.27024.1 11/7/2018 1:35 PM The ones we redistribute are much later so I'm not sure why your system isn't up to date. Maybe you reverted the install somehow or another app put old files there. The versions from the Cakewalk installer are as below: mfc14u.dll 14.20.27508.1 3/8/2019 vcruntime.dll 14.20.27508.1 3/8/2019 Please do an install of the latest VC redists by following this link. After ensuring that you have more current versions of these files please redo the test and see if it crashes. I'm not sure if your crash issues are related but having old redist files can definitely cause crashes and other incompatibilities. 'Untitled_01312020_125802.dmp' (Minidump): Loaded '*\\?\C:\Users\User\AppData\Local\Temp\Chromaphone 2 Shared.bin 64\Chromaphone 2 Shared.bin'. Module was built without symbols. Unhandled exception at 0x0000000054EE4660 (Chromaphone 2 Shared.bin) in Untitled_01312020_125802.dmp: 0xC0000005: Access violation reading location 0x0000000066B15180. 'Untitled_01252020_092413.dmp' (Minidump): Loaded 'C:\Windows\System32\explorerframe.dll'. Unhandled exception at 0x00000000A8FF834C (Chromaphone 2 Shared.bin) in Untitled_01252020_092413.dmp: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF. ntitled_01262020_184418.dmp' (Minidump): Loaded '*c:\program files\common files\VST3\Chromaphone 2.vst3'. Module was built without symbols. 'Untitled_01262020_184418.dmp' (Minidump): Loaded '*\\?\C:\Users\User\AppData\Local\Temp\Chromaphone 2 Shared.bin 64\Chromaphone 2 Shared.bin'. Module was built without symbols. Unhandled exception at 0x00007FFE4A80A839 (KERNELBASE.dll) in Untitled_01262020_184418.dmp: 0x20474343 (parameters: 0x000000007D5DF370). Untitled_01262020_185903.dmp' (Minidump): Loaded '*c:\program files\common files\VST3\Chromaphone 2.vst3'. Module was built without symbols. 'Untitled_01262020_185903.dmp' (Minidump): Loaded '*\\?\C:\Users\User\AppData\Local\Temp\Chromaphone 2 Shared.bin 64\Chromaphone 2 Shared.bin'. Module was built without symbols. Unhandled exception at 0x0000000072754660 (Chromaphone 2 Shared.bin) in Untitled_01262020_185903.dmp: 0xC0000005: Access violation reading location 0x000000000078A180. 'Untitled_01262020_190505.dmp' (Minidump): Loaded '*c:\program files\common files\VST3\Chromaphone 2.vst3'. Module was built without symbols. 'Untitled_01262020_190505.dmp' (Minidump): Loaded '*\\?\C:\Users\User\AppData\Local\Temp\Chromaphone 2 Shared.bin 64\Chromaphone 2 Shared.bin'. Module was built without symbols. Unhandled exception at 0x0000000071784660 (Chromaphone 2 Shared.bin) in Untitled_01262020_190505.dmp: 0xC0000005: Access violation reading location 0x00000000722E8180. 'Untitled_01262020_195535.dmp' (Minidump): Loaded '*c:\program files\common files\VST3\Chromaphone 2.vst3'. Module was built without symbols. 'Untitled_01262020_195535.dmp' (Minidump): Loaded '*\\?\C:\Users\User\AppData\Local\Temp\Chromaphone 2 Shared.bin 64\Chromaphone 2 Shared.bin'. Module was built without symbols. 'Untitled_01262020_195535.dmp' (Minidump): Loaded '*c:\program files\common files\VST3\Ultra Analog VA-3.vst3'. Module was built without symbols. 'Untitled_01262020_195535.dmp' (Minidump): Loaded '*\\?\C:\Users\User\AppData\Local\Temp\Ultra Analog VA-3 Shared.bin 64\Ultra Analog VA-3 Shared.bin'. Module was built without symbols. Unhandled exception at 0x00007FFE7027A839 (KERNELBASE.dll) in Untitled_01262020_195535.dmp: 0x20474343 (parameters: 0x000000008AA21B50).

Another way to do this is to SOLO the MIDI track which will auto solo the synth audio track. Then bounce to track without a selection. The reason why it requires a selection of the MIDI track is the operation doesn't know which MIDI tracks you may want to include in the bounce. I think we can improve this by being smarter and auto selecting all associated MIDI tracks if nothing is selected, to avoid confusion like this.

This looks like a memory leak leading to this. Can you reproduce this by just creating a project and inserting Revo Pro?