Forum rss-feed

Forum

General Discussion: ALL Tau players!

Most Recent

written by: carvingCode

Thanks, Ferdinand, for the thorough explanation.

written by: geert

Sat, 19 Nov 2011 09:15:57 +0000 GMT

Hi NothanNumber,

We put quite a bit of effort into reducing the memory footprint for the 1.4.8 release, I suggest you give it a try. I'd be interested to know how it fares for you and if you can more easily run Omnipshere. It's a shame that Spectrasonics didn't implement their memory server for Windows as they did for Mac, since Native Instruments didn't do it for Kontakt either I suspect there's something on Windows that prevents them from doing so. There's no fixed ETA yet for a 64 bit release of EigenD.

Take care,

Geert


written by: NothanUmber

Sat, 19 Nov 2011 11:49:38 +0000 GMT

Hi Geert,

yes, tried it with 1.4.8 - much better now - that's what I meant with "got more thrifty". With 1.4.7 Omnisphere crashed EigenD with all but the most simple presets, now all but the most complex multi layered presets work. (E.g. search for some in the > 250 MB area, those still lead to a crash because of memory issues). Fortunately Omnisphere is available as 64 bit plugin, so as soon as EigenD 64 bit is there we can switch to that - and there are other plugins available on the market with less insane requirements. (E.g. my goto patch uses ten instances of ACE - without the slightest problems)

Greetings,
NothanUmber


written by: NothanUmber

Sat, 19 Nov 2011 14:41:34 +0000 GMT

Just did a short test with Kontakt 4 and Gofriller Cello, one nki instance can be loaded and played, when trying to load additional cellos into Kontakt for per-key expressions it crashes when trying to load the third instance.
That is to be expected of course, you can simply do the math to come to the conclusion that this can't work with a reasonablly sized preload cache with a 32 bit host (that needs ~1 GB RAM by itself) on Windows.

So what I did with Kontakt (and probably also will do with Omnisphere and other too memory intensive plugins now) was to use midi out in EigenD to control the 64 bit standalone version of the sampler. That way you can even load 16 cellos without problems with 8 GB of RAM.
P.S.: Kontakt 4 requires < 500 MB of RAM with 16 cellos as it intelligently reuses samples that are loaded once, so it would even have worked with the 32 bit standalone host without problems.
P.P.S.: So all in all EigenD+Kontakt+16 cellos would be < 2GB - probably the problem is related to memory fragmentation then (no big enough continuous memory block can be acquired), in theory the virtual user space memory would be sufficient even on Windows.


written by: geert

Sat, 19 Nov 2011 15:07:55 +0000 GMT

It's a shame that neither Omnisphere nor Kontakt has a memory server on Windows. On the MacOSX versions a memory server is available that loads the samples in another process, hence stepping around the memory issues.


written by: NothanUmber

Sat, 19 Nov 2011 16:58:40 +0000 GMT

Found an interesting solution that could solve the problem for almost any plugin:
jBridge

A bridge that loads 32 and 64 bit plugins in 32 or 64 bit hosts, so you can use any combination of 32 and 64 bit or run 32 bit plugins in a dedicated process (so the plugin doesn't have to share user space with the host). If this is compatible with all plugins (that matter) that could be the solution (until 64 bit EigenD comes out)!

*edit* Unfortunately no luck - was neither able to get the plugin:32 bit host: 32 bit not the plugin:64 bit host: 32 bit variant to run with any of my plugins on Win 7 64 as long as the host is EigenD (seems to work with others, e.g. Bidule 32 bit can load both 32 and 64 bit plugins with jBridge). A pity, would have been an elegant solution :(
If 64 bit support is still in the more distant future perhaps it could be worthwhile to try to get jBridge support to run? (There is even an API to add native jBridge support to a host)


written by: NothanUmber

Sat, 19 Nov 2011 19:38:11 +0000 GMT

Intermediate solution to intermediate solution:
Got jBridge to work in EigenD when using Bidule as subhost. (You have to start EigenD with administrative rights, otherwise the GUI of the plugins will stay blank.) Tried it with both Omnisphere and Kontakt 64 bit - works flawlessly.
And it's more convenient than the standalone variant as there is only one program to start, all settings are stored in the EigenD setup, you don't need a MIDI routing solution like LoopBe and you can use automation.


written by: carvingCode

Wed, 23 Nov 2011 12:28:26 +0000 GMT

NothanUmber - I'm not familiar with Bidule or jBridge and will look into them. Could you provide a bit more detail in this setup? Is it necessary to load these in a certain order? When you mention that everything is saved in an EigenD setup, do you mean one of the preset setups? What exactly of these non-EigenD settings are saved?

Thanks,

Randy


written by: NothanUmber

Wed, 23 Nov 2011 19:10:07 +0000 GMT

Sure, try to explain it in more detail:

The problem with many operating systems is that you can't easily mix 32 bit and 64 bit code in the same process. As vst plugins are essentially dynamically loadable code fragments that will be executed in the context of the host process space it's normally not possible to host 64 bit plugins in 32 hosts and vice versa. Additionally each process has only a limited amount of memory
available, this "virtual address room" is 4 GB for 32 bit processes. For Windows those are further split, so your normal user application has only 2-3 GB at it's disposal. As host and plugin run in the same process they also share the same virtual address room, so if the host takes > 1 GB alone there are "only" 1-2 GB left for the plugin. (Due to various technical reasons often even less.)

jBridge tries to circumvent that by using a trick: It consists of two parts: a 32 or 64 bit vst plugin code that runs in the process context of your native 32/64 bit host and a separate 32 or 64 bit hosting process that can host a vst plugin itself. What jBridge does now is to forward data sent to the vst plugin to it's own hosting process and to send audio/midi output data from the vst inside this hosting process back to the plugin output running in the native host via shared memory. So you can run a 64 bit plugin together with a 32 bit host or use legacy 32 plugins in a 64 bit host. Additionally the plugin (now running in it's own process) has the full 2-3 GB user space memory at it's disposal (when it's a 32 bit plugin) or all remaining memory+swap space you might have in your system (for 64 bit plugins).

So in order to make this work you have two constraints:
1) the jBridge vst plugin is compatible with your host
2) the plugin you want to host inside jBridge has to be compatible to jBridge

Unfortunately the first point is not fulfilled with the EigenD 1.4.8 audio unit and jBridge 1.3.

That's where Bidule comes into play.

Bidule is (among other things) a vst/au host that is available as a stand alone version and a "sub host" version that can be run as vst/au plugin itself.
So each preset of the Bidule subhost can be a more or less complex setup of interconnected vst/au plugins, "building blocks" control logic (think "Max lite") etc.

As jBridge is not compatible with the EigenD audio unit but Bidule is, the following constellation is possible:

* Bidule is hosted in the EigenD audio unit (is compatible)
* jBridge is hosted in Bidule (is compatible)
* the 64 bit plugin is finally hosted in jBridge (is compatible for Kontakt 64 bit and Omnisphere 64 bit)
=> works

Regarding what is stored in the EigenD setup:
As with each plugin the current settings of the 64 bit plugin are stored as part of the vst chunk data by the subhost 1 (jBridge) which's settings are stored in the vst chunk data of subhost 2 (Bidule) which is forwarded to the native host (EigenD) when this requests all chunks for saving all vst parameters in the current "song" (in the case of EigenD: setup). (That's the way VST works so you usually find plugins in the state they were when reopening a saved project in a sequencer). So to cut a lengthy explanation short: All relevant data of Bidule, jBridge and the 64 bit plugin should be saved in the EigenD setup :)

Now all you have to do is to
* install jBridge
* install the plugin you finally want to host inside jBridge (e.g. Kontakt 64 bit, Omnisphere 64 bit etc.)
* register your plugins with jBridge via the registration "jBridger" tool that is part of the package. A tutorial can be found here: http://abtlog.wordpress.com/2009/11/05/deutsche-anleitung-fur-jbridge-unter-cubase-x64/ (the text is German but there are nice screenshots :) )
* install the 32 bit Bidule subhost vst and the standalone version (the demo does only work in standalone, so you need to buy the full version - it's very good price for value though)
* do a plugin scan inside Bidule standalone (under Preferences->VST). All jBridge wrapped 64 bit plugins should be recognized now.
* you can close Bidule standalone now, it was just necessary for registration
* start the "Plugin Scanner" inside EigenD and perform a scan. Bidule should be listed as a recognized plugin now
* load Bidule in one of the audio units (e.g. eigenbrowser hey audio unit 1 plugin browse)
* load the jBridged version of your desired 64 bit plugin inside Bidule
* configure the plugin as desired (load presets, change settings - whatever)
* configure the EigenD mapping as desired (e.g. parameter automation via yaw/pitch, breath pipe to midi cc 2 - what makes sense for the plugin)
* test whether it sounds and reacts as desired
* save the EigenD setup as a user setup
* close EigenD, restart it and reload your setup - everything should be in the state as you left it.

Have fun :)

Best,
Ferdinand


written by: carvingCode

Thu, 24 Nov 2011 14:57:13 +0000 GMT

Thanks, Ferdinand, for the thorough explanation.



Please log in to join the discussions