Pilot Pulgins

[Lynn Davis]

Hey Guy,

I was curious if anyone has successfully used this plugin by Mixed in Key? It crashes Cakewalk every time I try to insert it into an Instrument track. I've contacted Mixed in Key, but they haven't found a solution yet. 

Thanks!

Lynn

[Devilone12]

The same happened to me

[Glenn Stanton]

did you share the dmp file with the folks at Mixed in Key? 

[Lynn Davis]

Yes, I sent the dump file to Andy at Mixed In Key. Reply below.

Lynn

Hi Lynn 

 

Good to hear from you.

 

Our developers have looked at the issue but unfortunately there is an issue with Cakewalk which is preventing us from being able to apply a fix. 

 

I won't go into deep technical jargon, but it's an issue relating to a config file within the DAW which is throwing an error in C# - which is the coding language we use. Since we don't support Cakewalk, unfortunately, for the time being at least, we won't be able to fix this issue.  

 

[Lord Tim]

Get this dump file off to the devs at Cakewalk as well - I'm sure if this is a problem on Cakewalk's end, they'd want it sorted out.

[Simon Barker]

I am having the same issue on all the pilot plugins - reported to Mixed in Key and Cakewalk by bandlab - not what I was hoping for on my Birthday :(. I note in the install it installs 32bit and 64 bit - not sure if I can change to a different version

[Simon Barker]

19 minutes ago, Simon Barker said:

I am having the same issue on all the pilot plugins - reported to Mixed in Key and Cakewalk by bandlab - not what I was hoping for on my Birthday :(. I note in the install it installs 32bit and 64 bit - not sure if I can change to a different version

I got this back from Mixed in Key:
 

Currently Pilot Plugins is officially supported by Logic Pro X, Ableton Live, Cubase, Studio One and FL Studio. We aim to have support for all major DAWs, however we cannot currently offer an ETA.

 

Some non-supported DAWs like Cakewalk will work with Pilot Plugins, although there may be bugs or partial incompatibility. 

 

[Simon Barker]

1 hour ago, Simon Barker said:

I got this back from Mixed in Key:
 

Currently Pilot Plugins is officially supported by Logic Pro X, Ableton Live, Cubase, Studio One and FL Studio. We aim to have support for all major DAWs, however we cannot currently offer an ETA.

 

Some non-supported DAWs like Cakewalk will work with Pilot Plugins, although there may be bugs or partial incompatibility. 

 

And here is the response from Cakewalk

Thanks for reaching out to us. The dmp file does point out the Pilot Plugin. Although we support plugins that run under the VST, VST3 format, like the support staff at Mixed in Key said, there will be compatibilities issues that we will need them to test with Cakewalk by BandLab exclusively.
 
I would recommend taking up the refund as there is a considerable risk of crashes occurring with Cakewalk should you wish to continue using their plugins.
 
Nevertheless, we do hope their plugins will work with Cakewalk by BandLab in the near future, as we looking into updating our program further to minimize crashes or compatibility issues.

[John Vere]

3 hours ago, Simon Barker said:I note in the install it installs 32bit and 64 bit - not sure if I can change to a different version

If the plug in uses an installer the common generic system will allow you to uncheck unwanted versions. And you can select the pathway for each type.  
If not then  I would point that out to the developers as who on earth still uses 32 bit anyway?  
32 bit plug ins usually get put in the Program 86 folder and I keep that one out of Cakewalks plug in scan. 
So even if you can control the installer the 32 bit plug ins are easily ignored by the scanner.  
I only have 2 32 bit VST’s lurking and those I moved the the 64 bit folder. 

[bitflipper]

On 3/14/2023 at 7:36 AM, Lynn Davis said:

I won't go into deep technical jargon, but it's an issue relating to a config file within the DAW which is throwing an error in C#

Please beg Andy to "go into deep technical jargon". Inquiring minds want to know. What Cakewalk config file would a plugin be reading? And how could reading a text file cause .net to blow up anyway? 

[Glenn Stanton]

11 hours ago, bitflipper said:

 And how could reading a text file cause .net to blow up anyway? 

well you could create a while loop which reads in the file content into an array until the app or device crashes...

 

of course, it's more likely that reading the file means getting a file handle which could (without proper care) try to lock the file and in a folder requiring admin permission to lock it, doesn't get the exception properly caught, or worse eaten, and then nulls etc fun for all and so on. that it works on the developer desktop is meaningless. if i had a dollar every time i heard that i wouldn't have to work for a living making sure developers don't do things like that...

Edited March 24, 2023 by Glenn Stanton

[Simon Barker]

10 hours ago, bitflipper said:

Please beg Andy to "go into deep technical jargon". Inquiring minds want to know. What Cakewalk config file would a plugin be reading? And how could reading a text file cause .net to blow up anyway? 

The bit I do not understand is why the other Mixed in Key plugins are all working as expected - the instrument (Pilot Plugin bass as an example) can be added to a track - it fails when I try to load the actual module interface - I would have though Mixed in Key plugins would all act the same up to this point - ie validate License key etc.

[bitflipper]

2 hours ago, Glenn Stanton said:

well you could create a while loop which reads in the file content into an array until the app or device crashes...

True, you never want to underestimate the creativity of coders when it comes to finding ways to crash a program!

In this case, though, it's unlikely to be a matter of some junior dev copying sample code from an online post and calling it a day. The error code shown in the dialog is a generic code, a broad "something went wrong" kind of code from the CLR, the common runtime that underpins C# and its .net siblings. It could be anything. My guess would be that some data is being passed to a CLR function that it chokes on.

And that's partly why I'm curious: Cakewalk's config files are plain text. But I also can't imagine why a plugin would be reading those files in the first place. All of a plugin's communication with its host should happen exclusively via the VST interface. 

Which is not to say there haven't been issues with some plugins in the past. Most recently, there was an issue with Spectrasonics instruments causing Cakewalk to crash, and although the problem was Spectrasonics' doing, Noel & company managed to write a workaround to avoid that crash. 

 

[abacab]

22 minutes ago, bitflipper said:

And that's partly why I'm curious: Cakewalk's config files are plain text. But I also can't imagine why a plugin would be reading those files in the first place. All of a plugin's communication with its host should happen exclusively via the VST interface. 

I think plain text config files are just one of the places that Cakewalk keeps it's settings. Seriously doubt that a third party plugin is coded to read a DAW config file.

I would take that response with a grain of salt.

[bitflipper]

Well, there's also the registry of course. But I've never heard of the registry being referred to as a "config file", even if it technically is. I don't know of any other repositories used by Cakewalk that aren't plain text. That's why I assumed it wasn't actually a problem reading a config file, but rather an issue of passing data to the CLR.

Grain of salt, yes. I suspect that Andy is not the programmer, and may have just misspoke trying to relay a more complicated answer given to him by the coder. 

 

[Variorum]

Don't mean to sound snooty, but I wish developers would take the time to write plug-ins in the native language of DAWs (C/C++) rather than taking the easy way and coding in C# and hoping everything bridges correctly...

[Lord Tim]

I think it's more so the really loose VST3 spec that's catching everyone out, rather than the language. Steinberg really dropped the ball on this one, IMO.

[Simon Barker]

You will be pleased to here that Cakewalk by Bandlab are talking to Mixed in Key and a copy of the plugin is going to Cakewalk to investigate.

[Starship Krupa]

On 3/25/2023 at 1:03 PM, Variorum said:

I wish developers would take the time to write plug-ins in the native language of DAWs (C/C++) rather than taking the easy way and coding in C# and hoping everything bridges correctly

Can you explain more about this? I'm not a programmer, and I'm curious how the developers' choice of languages could affect interfacing a plug-in with its host.

[Variorum]

Well... That's a complex subject, but in a nutshell, C# is a managed language as opposed C++ which is a native language.
It's compiled to an intermediate bytecode that's run by an interpreter called the CLR (Common Runtime Language). Java is similar in that it compiles to bytecode that run by the Java Language Runtime. This makes both languages much safer because memory allocation and other low level functions are managed by the interpreters, so it's a lot harder to crash the OS because of some bungled code. Of course, this layer of protection adds a bit of overhead to the code so it's kind of a trade-off between faster code and safer code.

C# is a great language, especially when GUI's are involved... much easier to code than native C++. The problem is that it can be difficult to interact with a native C++ program (like a DAW) because you have to jump through some hoops to communicate with the API in both directions and depend on the CLR to correctly translate the data being passed back and forth. The VST API is heavily dependent on pointers to memory locations for audio, Midi buffers, etc. and there's technically no such thing as native memory pointer in C#, so you need code to translate/convert those pointers.

C# likes to keep to itself and manage it's own... everything (by design), so forcing it to interact with wild hippie native code can be difficult and occasionally problematic.
So, although it's more difficult to code a plug-in and its GUI in native C++, as long as your code is well written and thoroughly tested, there are fewer unknowns to deal with, and you'll almost always get better performance in the end.

Just my opinion.