The unofficial MFX to VST wrapper thread. Please participate

[cold c]

For info: I received an email from polac that says "planning a small update in the near future" in reference to the MFX wrapper.

I tried the MFX wrapper with Musiclab Slicydrummer in eXT 2 and it doesn't work.

Did anyone have any success with slicydrummer via the MFX wrapper (in energyXT 2 or any other VST host)?

Thanks

Slicy Drummer works great with FXPansion DR800, A killer combo.
Which rises the question: Why dont more VST plug devs work iy out the way FXPansion did?

Yes it worked/works nicely with DR-008.

In an ideal world it would work just as seamlessly in a host environment (so different lines in Slicy could be routed to different instruments/samplers/synths/etc in the host).

However, as you probably know, the Fxpansion DR008 drum-deploy modules were essentially a proprietry type of MIDI plugin (not the standard MFX or VST etc) allowing the extra 'note name' data to exist in the plugin, thus greatly aiding usability.

In practice, the same data containing 'note names' is not available in any other MIDI plugin format (AFAICT), so it will result in a less usable MIDI plugin, even if a working wrapper is available.

It simply does not make sense for each instrument to have its own plugin format (that is why no-one copied the DR-008 method).

I have asked on the Cubase forum numerous times for the VST SDK to be updated to allow 'note names' from VSTi to host (to be displayed in piano roll, drum editor etc) AND host to MIDI plugin.

I do not think they care or understand the significance of this. The VST3 SDK is about to be released to 3rd party developers and I haven't heard anything about this type of functionality.

There are countless devices the 'modern studio' that cannot operate 'seamlessly' because they don't use a well thought out and robust standard, just think about the world of hardware control surfaces (functioning on a mish-mash of a clogged-up 1980s protocol, 'over USB'). This is why there are so many shitty, barely usable control surfaces being created today, because they have such poor/irrelevant standards to work with/build upon. (Yes I have heard of OSC, but I wonder if any hardware/software manufacturers have, and I am not saying it is 'the answer'.)

There is now the bizzare situation in the music software & plugin world that is mirroring the mess of studio hardware 'connectivity'. Plugins in multiple incomplete formats, needing to be wrapped to function in other hosts. Even worse: MIDI control surfaces that claim to be 'universal' that work by hacking together their own wrapper plugin or 'hosting' the instrument/target plugin, thus breaking the standard host-plugin parameter automation relationship, portability of projects, etc. Lame, nasty, crappy and shitty. This is before the poor build quality or the cheap, plasticy 'feel' of the devices has even been taken in to account.

In the case of MIDI plugins connecting to hosts, it makes no sense when the data exists entirely inside the software. You can see the name of the drum sound in your drum sampler, but not in your VST host's drum grid or key editor, and not in any MIDI plugin that you want to use to generate MIDI data for the drum sampler (even though they are all capable of sharing data with the host app). That makes so much sense Charlie...

I have to wonder if engineers from any music equipment manufacturers have ever met to discuss anything relevant to 'interoperability' of devices (hardware or software) in the past 20 years. Not the marketting twats, I mean actual engineers who painfully hack their devices up into a shiftable product. Do they ever stop to think, "rather than hack this for each host application, maybe we should all get together and come up with a set of hardware and software protocols that will serve today's and tomorrow's studio equipment needs" ?

[stag]

You got me confused with the tech talk. After reading it about three times, I must compliment you for your post and efforts.

It would be nice Battery or Additive Drums to support Slicy Drummer doe.

Musiclab released its own wrapper for Slicy\Fillin Drummer, PD Drum Tools, it needs a lot tweaking IMO before being recommended but one manages doe.

I'm a Remote SL user, the issues you have disclosed so accurately had crossed my mind more than once.

Awareness is indeed a gift.

[maiki]

I don't quite get how to use this.

My new computer is Windows 8 Pro 64 bit, so I installed 64 bit Sonar (8.5.3).

A lot of my old MFXs don't work now, not listed in Sonar.

I tried the mfxshell thing. It worked, in that now I see the 32 bit mfxs as VSTIs.

But how does that function. I take a MIDI track on which I wanted to use an MFX. I can insert the new VSTI created from an MFX as a softsynth, and route the MIDI track to that VSTI. But that MFX-VSTI is not really a softsynth, won't make any sound, and I cannot route it out to an actual softsynth.

How to use this?

[Markleford]

My new computer is Windows 8 Pro 64 bit, so I installed 64 bit Sonar (8.5.3).

A lot of my old MFXs don't work now, not listed in Sonar.

Cakewalk has stopped caring about MFX, and never properly supported VST MIDI modules. Myself and other developers have attempted to reach out to them to get an update to their decade old SDK so that we have the way forward to port to 64-bit, but they do not respond.

MFX will eventually go the way of CAL, I'm afraid: still there, but not supported.

I tried the mfxshell thing. It worked, in that now I see the 32 bit mfxs as VSTIs.

SONAR never properly used VST MIDI modules, and I don't think they intend to start now. I think the best they ever did was there was a way to fiddle with .ini settings to get a VSTi with MIDI output to loopback data to another track, but that's disappeared for all I know. And you could *never* insert them into the MFX bin as part of a chain.

That said, if you use the 32-bit version of SONAR, you can still use the old MFX. This is allowed under even under 64-bit OS, and you can run the 32 and 64-bit versions of SONAR side by side when needed.

- m

[maiki]

Thanks for the info, Markleford. And thanks for your great MIDI plugins--Ten Crazy!

That really is unfortunate, that Cakewalk doesn't provide info to update MFX to 64 bit. I have been a Cakewalk user since the early DOS versions, and they used to be a company that I think was quite responsive to user requests and suggestions, Now being part of Roland, perhaps they don't care any more. Sad.

Are you saying there is no problem with installing both the 32 bit and 64 bit versions of Sonar (same version number) on the same computer?

Thanks again.

MFX will eventually go the way of CAL, I'm afraid: still there, but not supported.

SONAR never properly used VST MIDI modules, and I don't think they intend to start now. I think the best they ever did was there was a way to fiddle with .ini settings to get a VSTi with MIDI output to loopback data to another track, but that's disappeared for all I know. And you could *never* insert them into the MFX bin as part of a chain.

That said, if you use the 32-bit version of SONAR, you can still use the old MFX. This is allowed under even under 64-bit OS, and you can run the 32 and 64-bit versions of SONAR side by side when needed.

- m

[lfm]

Only one I found was Frank's midi FX plugins as x64 native:
http://www.midi-plugins.de

Maybe some of those fit your needs. Not free, but cheap if you need it.

Cakewalk seems to be stuck in their old DX-land. A pity if they not by now in X2 support VST midi plugins.

But why blaim Cakewalk for not making x64 MFX?
Frank did it.

[Markleford]

But why blaim Cakewalk for not making x64 MFX?

For the record, they *did* make x64 MFX. They just haven't shared any information about how, and they never made a bit-bridge for them.

So I blame them because Cakewalk does not respond to developer communications via mail/web-form/forum, and their DXi2/MFX SDK is literally 10 years old (2003).

While I'm happy to give away my work for free, I don't have the time to dedicate myself to reconciling library and compiler incompatibilities. All I had time to do was attempt to contact them, and I kept trying that far longer than was reasonable.

If Cakewalk wants MFX to thrive, then they should improve their developer support, but I suspect they'll let it die like they did with CAL.

Frank did it.

Good for Frank, then. He's obviously smarter than me and other devs who haven't figured it out on our own. Then again, he charges money for his MFX plugins, so it was probably worth his investment to figure out.

Who knows, perhaps he'd be willing to share how he did it, maybe even for free. I've just had enough frustration for now to let it go for a while. But it is disappointing to tell people who mail me that Cakewalk has been no help at all.

Cakewalk seems to be stuck in their old DX-land. A pity if they not by now in X2 support VST midi plugins.

Oddly, many of their bundled plugins are now VST/VSTi (probably due to the influence of Rene@RGC), but they still don't handle MIDI processing, and still have only primitive MIDI bus routing.

- m

[Markleford]

I have been a Cakewalk user since the early DOS versions, and they used to be a company that I think was quite responsive to user requests and suggestions, Now being part of Roland, perhaps they don't care any more. Sad.

Yes, I first used 'Cakewalk for Windows' on floppy disk! Not quite as long as you...

Given their lifespan, they've had a lot of good people leave over all those years. When Ron Kuper was working there, I had a direct line to their dev process (funny, I interviewed with him years later at Sonos). I used to also get some input via the Beta program, but I was forced to drop out due to lack of time.

But perhaps part of it is that Roland gave them a different focus. And you can't really say that MFX was really popular to begin with, so they probably don't think that it's worth the effort to update their documentation. I think its heyday was probably around Project5 with their arpeggio, which eventually made its way to SONAR.

Are you saying there is no problem with installing both the 32 bit and 64 bit versions of Sonar (same version number) on the same computer?

Yes. Just make sure that the shared plugins directories are named differently. I believe it should be okay by default, abiding by the separate Program Files directories, and since they append _x64 to many of their bundled plugin names anyway.

- m

[lfm]

Oddly, many of their bundled plugins are now VST/VSTi (probably due to the influence of Rene@RGC), but they still don't handle MIDI processing, and still have only primitive MIDI bus routing.

- m

As I understand from someone in another thread they now allow at least midi out also on plugins - which they did not in my days with Sonar.

In that respect it's strange they don't fix VST midi plugin support if they can handle both in and out.

It was also something with always delay processing midi one sample late - and that might be tougher to solve.

But X2 should have a facelift and reworked audio engine, no?

Isn't all DX really Microsoft's format - why would it be dependent on Cakewalk solely?

I wonder if Frank just looked at Microsoft site somehow?
Can't imagine he did it without a x64 DirectX SDK.

Problem with Microsoft in later years has been that things that were reasonably small SDK's now are embedded in larger and larger packages that is undoable to download unless having 50-100MBit/s or so.

[Markleford]

As I understand from someone in another thread they now allow at least midi out also on plugins - which they did not in my days with Sonar.

Well, there were times back in my day that they allowed you to edit an .ini to at least get MIDI loopback from plugins. But my last version of SONAR is 8.5, so I am unaware of what they've done in X1 and X2.

But X2 should have a facelift and reworked audio engine, no?

Audio engine, yes. But not so much with the MIDI bus, I hear. Reaper is much better in this regard: its routing is extremely flexible!

Isn't all DX really Microsoft's format - why would it be dependent on Cakewalk solely?

I think that Cakewalk was very much a primary collaborator in specifically making the DX*i* format, not just DX. Sonic Foundry also supported DX very well, but I'm not so sure now that Sony bought them.

I really have to admit that that I don't follow this scene much anymore: I used to develop plugins as part of my music, but these days I work in primarily audio production (see: http://thejamesrocket.bandcamp.com/). Keeping up with the technology simply got in the way of creating music! It was okay as a solo artist, but producing someone else's songs has a different focus.

I wonder if Frank just looked at Microsoft site somehow?
Can't imagine he did it without a x64 DirectX SDK.

That's very true to say. I'm not doubting that he is very clever, but I don't have those skills unless someone gives me instructions! I can create the algorithms I need, but getting compilers to bend to my will takes far more effort... yet so little effort for those that *know* the key. It's such a fine margin that would allow me to provide 64x plugins for users.

- m