Got it! I'll try to get this tested out tomorrow.
 
Thanks again for all the work on this!

For those who may come looking for answers later...
 
Colin has a base project for both the vanilla and MFC sample MFX projects that works under VS 2010 Professional, so long as you follow the registration method described in the included read-me file. We're thinking about how this might be improved for now, and one of us will be sure to make a web page with a final version when it's done, so that developers can start working right away.
 
One thing to steer clear of is VS Express 2012. It will barf on you and totally not work! We're not yet sure if VS 2010 Express will work: at the very least it requires a patch to let it target x64 builds, plus some other headache-inducing steps to install (see: http://stackoverflow.com/questions/8044385/64-bit-build-on-microsoft-visual-c-express-2010). Also note that MFC isn't included with Express versions. I eventually gave up on trying to get this to work, and opted for the trial version of 2010 Pro!
 
More news later.
 
Cheers,
- m

I'm glad to see everything's working out.
 
I guess our lesson learned is that regsrv32 should be run in elevated mode, something to think about when when creating .bat files or install scripts.

Yeah, we'll have to figure out a way to make that easy for the average user. It's just odd that it returns a 'success' without entirely completing the task at hand. Quite misleading!
 
- m

>> It's just odd that it returns a 'success' without entirely completing the task at hand. Quite misleading!
I should probably fix that too. Considering code for completing the registration actually reports on success, it would be straight forward to propogate that back to regsvr32

>> It's just odd that it returns a 'success' without entirely completing the task at hand. Quite misleading!
I should probably fix that too. Considering code for completing the registration actually reports on success, it would be straight forward to propogate that back to regsvr32

Hi Markleford, Colin, etc,
 
I'm sorry that you guys had to figure this out all on your own. Its not due to indifference on our part. Normally development help requests get sent to me from tech support and when I have bandwidth I try and respond.  If you had opened a case with support it would have been routed to me. Anyway if you need to reach me you can get to me via NoelBorthwick at cakewalk dot com. I'm normally quite responsive with 3'rd party developers :)
 
The reason the SDK is old and unupdated is because the MFX SDK development was deprecated many years ago primarily due to lack of industry interest. Since our primary business is in building DAW's we figured it was not worth the investment to enhance the SDK since. As you may have noticed we don't build new MFX/DXi plugins. SONAR however fully supports MFX/DXi and we have no plans to remove support for it.
 
Regarding 64 bit, most of our existing 64 bit DXi/MFX plugins were ported to 64 bit manually. As you have found out there is no special sauce required from the sdk really. The main thing when porting to 64 bit is to make sure all the data types and pointers are 64 bit internally and there are no assumptions made about bit depth. In many cases it is trivial to port a 32 bit Mfx/Dxi plugin to 64 bit.
To change the SDK itself to use a newer compiler like VS2012 is a bigger task because it uses the old Wizard to generate code from templates. I'm not even sure how that is done in newer compilers or if its even supported by Microsoft. If one of you have the bandwidth to check it out and port the wizard to VS2012 we would be happy to host your updated version of the SDK (and credit you of course). Generally speaking however i think its sufficient to have a boilerplate sample solution with both 32/64 bit configurations that so that users can copy and modify into their own plugin. While the old wizard is nice its icing really.
 
On a different note, we are interested in open sourcing our control surface SDK including the newer interfaces and source code for the V-Studio 700 and Mackie surfaces. We are willing to host all the code on Github but need someone to help moderate and support it since there is a lot of code there. If anyone is interested in helping with that project please contact me.
 
thanks,
Noel
 
 

Noel, thanks for replying. It's good to finally have an official word on this!
 
After having figured it out for ourselves (well, Colin did the heavy lifting, and Frank provided the sanity check!), there are only a few bits of very simple fixes that needed to be addressed, but they were elusive. As you say, it's fairly trivial after you know that.
 
I suppose most of our frustration come from the fact that both Colin and I *had* opened a case with support (several times over, in fact), but never achieved resolution... or even a contact point to help work through the issues. Somewhere in your communication chain things had broken down. There are all sorts of problems on the DevXchange area of the site, with links that go nowhere and forms that produce errors. A little investigation by the web team could help reduce these annoyances, and a word or two about the state of DXi/MFX in 2013 would allow devs a little more confidence that these technologies are still hostable (i.e. it's nice to know, explicitly, that there's no secret sauce!).
 
The remaining frustration, then, would be that if MFX is no longer being fostered internally, shouldn't something else replace it? Will SONAR get support for VST MIDI Modules and better MIDI busing in the future?
 
All the same, thanks again for the reply. I'll contact you later with progress on our working out a new boilerplate template.
 
Cheers,
- m
 
 

Hi Noel, Thank you very much for joining the thread. We can definitely provide you with an update for the MFX project. Right now I have it running under VS2010, but I'll see what I can do about VS2012. I know Markleford was hoping to find a viable way to get it running under the express edition, but that doesn't presently seem feasible.
With regards to the wizards and DXi, I can take a look at them. However, my only motivation for exploring the SDK in the first place was to create a couple destructive MIDI plugins for my own use (and to share if they seemed like they might be helpful to others). So, we'll see.
Take care,
CJ