KVR Audio

umd · Post by **umd** » Fri Mar 06, 2009 12:28 pm

Hi!

This is something I've been working on in the latest days. Some sort of 32bit to 64bit vst adapter, you can watch a short test here:

Credits for Brad from Topten software, who has been helping me a lot, and all the other folks around here who have helped me sorting out issues and clearing doubts.

More to come...

My current issue is the gui editor, some plugins don't like the gui part to run on a separate thread, so I'm looking for ideas on that... is there a "right" way of implementing the effeditopen/close/etc part in a host?

Thanks!

bradr · Post by **bradr** » Fri Mar 06, 2009 1:03 pm

Hi umd,

No problem, glad to help.

For those who are wondering about the performance of it, I've tried it (only on a high end quad-core machine) but for audio processing the overhead is very small. For a non-sounding VSTi, the load meter in Cantabile (which is a max time based calculation) went from 0% to maybe 1 or 2% on a 10ms buffer size. Can't complain about that.

Currently there's some issues with MIDI - where each MIDI event seems to cause a big spike. You can actually see this in the video - as each key is played watch the load% number in the status bar (just to the right of "Stopped"). It even hits 100% at one point. It is early day though and I believe umd is working on this.

Anyway, so far I've been well impressed... good job umd.

Brad

Chris Walton · Post by **Chris Walton** » Fri Mar 06, 2009 1:24 pm

Cool!

This is using shared memory and HEVENTs, right?

mn · Post by mn » Fri Mar 06, 2009 1:36 pm

x32 plug support for x64 hosts without their own support? Nice.

umd · Post by **umd** » Fri Mar 06, 2009 3:26 pm

Yes, it's using shared memory and semaphores.

The plugin is loaded by a 32-bit aux host that communicates with the main host.

It's also possible to run 64bit plugins in 32bit hosts this way ( although I don't know who'll want that ).

As for the midi events spikes problem, I'm afraid there's nothing I can do (at least for now), because after some testing I concluded that what causes the spikes is the processevents call in the plugin, not any ipc operation ( in fact, in the current implementation there isn't any direct ipc triggering for incoming midi events ).

Chris Walton · Post by **Chris Walton** » Fri Mar 06, 2009 5:00 pm

umd wrote:Yes, it's using shared memory and semaphores.

The plugin is loaded by a 32-bit aux host that communicates with the main host.

It's also possible to run 64bit plugins in 32bit hosts this way ( although I don't know who'll want that ).

As for the midi events spikes problem, I'm afraid there's nothing I can do (at least for now), because after some testing I concluded that what causes the spikes is the processevents call in the plugin, not any ipc operation ( in fact, in the current implementation there isn't any direct ipc triggering for incoming midi events ).

Cool. How much work did you put into this, approximately? Going to take a more detailed look tomorrow, when I have more time.

Elffin · Post by **Elffin** » Fri Mar 06, 2009 5:25 pm

This looks pretty useful - great idea

umd · Post by **umd** » Fri Mar 06, 2009 5:27 pm

Chris Walton wrote:
umd wrote:Yes, it's using shared memory and semaphores.

The plugin is loaded by a 32-bit aux host that communicates with the main host.

It's also possible to run 64bit plugins in 32bit hosts this way ( although I don't know who'll want that ).

As for the midi events spikes problem, I'm afraid there's nothing I can do (at least for now), because after some testing I concluded that what causes the spikes is the processevents call in the plugin, not any ipc operation ( in fact, in the current implementation there isn't any direct ipc triggering for incoming midi events ).
Cool. How much work did you put into this, approximately? Going to take a more detailed look tomorrow, when I have more time.

About 3/4h daily for the last days, sometimes at lunch break too.

umd · Post by **umd** » Mon Mar 09, 2009 1:57 am

I've uploaded another video with some more testing:

I should put something out for public testing in the next weeks, if all goes well.

SimSam · Post by **SimSam** » Tue Mar 10, 2009 12:56 pm

Worked fine on Cantabile solo (x64) with Kontakt 3. I didn't get as far as testing CPU spikes like Brad. But it loaded and played the instruments through the on board keyboard.

It does, at least on my Vista 64 system, crash Cubase 5 64-bit hard. In fact, I can't kill Cubase 5 as a process afterwards and have to reboot. I wonder if it's conflicting with Cubases VST bridge?

Anyhow, my hats off to you. This is great. I'll do more testing when I return home this evening after work.

Brian

umd · Post by **umd** » Tue Mar 10, 2009 2:30 pm

The cpu spikes issue seems to be resolved. I've gotta take a look at the cubase issue, is there any demo of it available?

ps: please post any future feedback here:
http://www.kvraudio.com/forum/viewtopic.php?t=244999

thanks.

TiUser · Post by **TiUser** » Thu Mar 26, 2009 9:06 pm

Hi.

I'm watching this development with interest... I want to go 64bit soon too and that adapter pushes things one step further, making Cantabile 64bit really more useful.

I guess this thing works under Vista 64bit too, does it?

Oh and I should not forget to repeat that I like Cantabile a lot too...

ocmtime · Post by **ocmtime** » Thu Sep 22, 2011 8:00 pm

umd wrote:I've uploaded another video with some more testing:

I should put something out for public testing in the next weeks, if all goes well.

Did the older versions lack the JBridge gui and settings button at the bottom of the bridged vst's native gui

umd · Post by **umd** » Thu Sep 22, 2011 8:05 pm

Hi.

Hum, it's not quite the same thing, at that stage it had no GUI in the main host, so this was like the separated GUI mode.

A 32bit to 64bit vst adapter/bridge