Need testers for my x86 to x64 vst adapter

[benchase]

I also request VST3 wrapping.

I'm actually really surprised it doesnt yet, since that is the kind of thing jbridge does. I have a few new plugins from the BF sales, eg Novum, where there is only a VST3 version available. I need to run VST3 in VePro7 and it doesnt support them

[umd]

Please note that the VST2 API hasn't changed since 2006 ( and it is backward compatible with the VST1 API ), the VST3 API still seems to be changing ( as of 2022 ) and for some reason it was not made to be backward compatible with VST2.

That means that technically, making a VST3 to VST2 adapter will be much more difficult ( and the incompatibilities will be much more ), and it is presently "unsteady ground".

But, I would suggest trying to load the VST3 plugin in a VST2 plugin that can load VST3 plugins inside it as a workaround.

[qraqatit]

With version 1.74 under Cubase Pro 12, when using TbT 32bit jBridged plugins (https://web.archive.org/web/20080802013 ... rchive.htm) and change plugin fx slot position (that is grab it in its actual fx slot and move to some other fx slot position), any try to edit any value causes all plugin values to reset (or, in fact, going to some sort of previous parameters values I made some time before - very strange indeed to me + what's even stranger: it not happen everytime, more like 2x out of 7 or so, bah), very troubling, unfortunately - and this happens to all TbT plugins jBridged!

This does not happen when just editing plugin values in the slot initial inserted into.

Maybe I need to adjust some specific jBridge settings values for each jBridged plugin, but which one?

[umd]

Hi!

Does using the "separate GUI mode" or using the "legacy integrated mode" option makes any difference with those plugins regarding that problem?

[qraqatit]

Hi!

Does using the "separate GUI mode" or using the "legacy integrated mode" option makes any difference with those plugins regarding that problem?

No, it does not...BUT!

I guess (I am basically sure now after few tests) I GOT THE ANSWER: one have to DISABLE the last option in plugin's jBridge options which is enabled by default, it is called "Use legacy integrated mode (v1.2)" - once I did this (and I had to go thru all the options being there, mind you!), no problem of this sort whatsoever, so great so far.

To further pinpoint the problem: when you insert any TbT old jBridged plugin into Cubase Pro 12 FX slot, make some parameters adjustment, close the GUI and change its FX position JUST ONCE, all is good when you open its GUI, but if you change the FX position at least 2x in immediate succession with the GUI still closed (like grab the plugin in actual FX slot position and move it to another slot, right after that grab it once again and change the FX slot position one more time), it will reset all the parameters once you open the plugin GUI. Once you disable that last option in the plugins jBridge parameters I mentioned above (restart of the plugin required = remove the plugin, then insert it back once again), all works as expected.

I hope my solution will help others having this kind of problem...cheers!

And, BTW, I have all the jBridge options for the TbT plugins being unticked, that is none is enabled.

UPDATE (09:45)
Well, it seems like I was too quick in my opinion: unfortunately, there is probably also something else in play jBridge-wise (as this does not happen in their native 32bit version AFAIK), cos now as I have several of TbT plugins (actually just one specific plugin - TLs-3127-LEA) and I try to adjust some parameter in one of them, all parameters of this specific instance reset, but the other jBridged instances of it are OK even when I edit their parameters...mindboggling indeed this is!!!

[umd]

Could you also try enabling the "run in existing auxhost" option and let me know if that makes any difference? ( note: you need to re-start the DAW after that ).

[qraqatit]

Could you also try enabling the "run in existing auxhost" option and let me know if that makes any difference? ( note: you need to re-start the DAW after that ).

Unfortunately no - it does not help...

I was just thinking (OK, I know and understand you have better things to do in your free time, anyway just saying, maybe): could you download it from the link I posted and test it if it would do the same in your DAW when jBridged? What I mean is if it would stay unaffected then we could assume it is something in Cubase Pro 12.

But I have to also add that I noticed this behavior also with their other great plugin TLs Saturator (all freely downloadable from my link).

For instance, now what it does is that when I close the project/DAW and reopen, as soon as I open its GUI and try to edit any parameter, all its parameters reset immediately.

[umd]

Of course, I can give it a try!

This problem has been reported with some plugins, but this is definitely the most flagrant case so far.

But I am not sure about what causes it, seems to happen with certain plugin/host combinations.

One thing I forgot to ask too... If you also use the "sluggish GUI hack" option, does the problem remain?

[qraqatit]

thing I forgot to ask too... If you also use the "sluggish GUI hack" option, does the problem remain?

YES - this was the actual culprit (or better said: the right solution) of this problem, so thank you so much for solving this (so maybe we even do not need to disable the last option of "Use legacy integrated mode (v1.2)" which is enabled by default and what I initially thought was the problem, I do not know as I did not test it with that last option being enabled)!

So, after going thru some huge testing this morning (like trying all the options we discussed by at least 3x completely closing the DAW after each try, then changing the values and once again at least 3x in succession tested with closing of the DAW after every single test...huge amount of time required), I can say that all it needs to be ticked/enabled in jBridge options for all the TbT plugins are:

• Sluggish GUI hack - this is the needed solution: after enabling it and restarting of the whole DAW none of those problems described in my previous posts above occurred anymore, so great so far!

• Run in existing auxhost - this is needed cos from time to time, after closing the DAW, error windows appear saying "The specific semaphore already exists"/"Auxhost exclusive lock failed!": after enabling this option it does not happened a single time since!

Thus, finally, this is how every TbT jBridged plugin settings should look like to avoid any of the troubles mentioned in previous posts of mine:


Lastly, there is one other "problem" of sorts: one of the TbT plugins (TLs Matsering Maximizer) literally resizing itself downwards after clicking one of its options making such jBridged instance becoming completely white unless one closes its GUI and reopen it - isn't there some option for resolving this issue in jBridge settings for the plugin?

Another thing I would like to ask, just out of pure curiosity: I am retired JAVA programmer myself, so when I look at the C++ syntax (as I think C++ is the environment, where VST dlls are done/assembled/compiled, right?) I can tell it is very similar to JAVA, but definitely not the same, of course. So I would like to ask you - as you being the author of the great jBridge app - if I do understand these things correctly:

• Is it true (I guess I read it somewhere), that all one C++ programmer needs to do to make his VST dll being x64 is to assemble/compile the source code on x64 OS without anything being added to the code itself, just pure assembly/compilation in the desired OS environment (I assume that most probably in Microsoft Visual or something like that)??? Cos if so, I really basically do not understand the reason why there is no x64 versions FOR EVERY VST DLL OUT THERE, if that is all it needs (tho, once again, the fact that it is simply not the case tell me, that I may be wrong again here)?

• regarding your great jBridge: do I understand it right, that what it does - regarding previous point being correct - is, that it somehow grab all the dll's internal methods and functions (tho I heard it is not normally possible to do that - that is one cannot see the content code-wise of a dll, right?) and assembly/compile it once again in the x64 OS thus making it x64 version - am I right? Although I noticed you are still referencing the original 32bit plugin's path inside txt file created for every jBridged plugin which would be not the case (not necessary/not needed anymore) if you're just re-assembling/re-compiling it somehow to 64bit, so this is most probably incorrect, I guess now...

• ...or: what your app does is, that it creates some sort of "sandbox" around the original x32 dll and runs it inside it while being active inside a DAW redirecting all its native 32bit calls to their respective x64 equivalents sending them to the OS???

[umd]

Hi!

Glad that worked.

Regarding the TLs Maximizer plugin, does the "separated GUI mode" option prevents that behavior, despite not being so "elegant"?

Regarding your programming questions, what I will say is just my personal opinion, in fact I am not really a programmer, I just started trying to learn this stuff because I needed it for myself... So please take this from an amateur's perspective.

- I do some stuff in JAVA, and it is a great programming language for some purposes, but the hardest thing for me is keeping up with the constant IDE/library changes. On the other hand, you don't have to deal with some boring lower level stuff. But I get more concerned when I have to update my JAVA IDE than when I have to update my C/C++ IDE.

- You should not assume that you can simply take a piece of C/C++ code and compile it for a x64 binary or whatever architecture it comes up ahead. If it needs OS-specific libraries, and those are changed/deprecated somewhere ahead, well... Apple is a great example.

- jBridge does not "convert" anything, if that's what you mean, the OS needs to support 32bit binaries with that architecture, all that jBridge does is load a "dummy" DLL in the host that then communicates through inter process communication with the plugin which is loaded in a 32bit process . The OS needs to support the plugin's native architecture for that to work.

( But, I am "no stranger to pain", I did some stuff in assembly too before )

[qraqatit]

Regarding the TLs Maximizer plugin, does the "separated GUI mode" option prevents that behavior, despite not being so "elegant"?

No, unfortunately, and what's more, it even completely freeze my DAW (Cubase Pro 12) as soon as I reload the plugin (restart the plugin)!

Regarding your programming questions, what I will say is just my personal opinion, in fact I am not really a programmer, I just started trying to learn this stuff because I needed it for myself... So please take this from an amateur's perspective.

Huh, similarly, I did exactly for the same reason learning JAVA - I was (still am???) into CGI rendering stuff and there were things I thought can be done (cos previously I was ActionScript2 programmer, actually Adobe Flash scripting language - hey, former webdesigner here!) yet every JAVA programmer out there were telling me "nah, no way man, forget it!". So I said to my self "What in the world?!" Thus I learned it myself alone and I prove them being wrong coming up firstly with my own script for one of the JAVA CGI renderers out there (specifically virtual LEGO bricks renderer) and later on even creating my own complete separate JAVA CGI renderer, so yea, I understand you very well.

You should not assume that you can simply take a piece of C/C++ code and compile it for a x64 binary or whatever architecture it comes up ahead. If it needs OS-specific libraries, and those are changed/deprecated somewhere ahead, well... Apple is a great example.

So, if I got you right, you are saying what I was thinking source-code-wise: there is nothing to be added to the src when one wants to make 64bit version, only to have it environment files updated for the specific bit files (x32/x64), like having required specific x64 VisualMS dlls in place, but as of the actual src, C++ programmer is adding nothing to it, the code is exactly the same - right?

jBridge does not "convert" anything, if that's what you mean, the OS needs to support 32bit binaries with that architecture, all that jBridge does is load a "dummy" DLL in the host that then communicates through inter process communication with the plugin which is loaded in a 32bit process . The OS needs to support the plugin's native architecture for that to work.

Well, I am no wiser at all from this description, cos to me what you are saying here is "Hey, I just literally run x32 bit plugin in your x64 bit only DAW host" which is exactly the thing why x32 VSTs cannot run normally inside x64 DAW host...anyway, thank you for the effort - maybe it is just me too C++-wise dumbo.

[umd]

No, unfortunately, and what's more, it even completely freeze my DAW (Cubase Pro 12) as soon as I reload the plugin (restart the plugin)!

Oh, ok, let me give that a try and see if I can find anything... could you PM me with your email address so that I can send you a test build if I can come up with something to address that?

Huh, similarly, I did exactly for the same reason learning JAVA - I was (still am???) into CGI rendering stuff and there were things I thought can be done (cos previously I was ActionScript2 programmer, actually Adobe Flash scripting language - hey, former webdesigner here!) yet every JAVA programmer out there were telling me "nah, no way man, forget it!". So I said to my self "What in the world?!" Thus I learned it myself alone and I prove them being wrong coming up firstly with my own script for one of the JAVA CGI renderers out there (specifically virtual LEGO bricks renderer) and later on even creating my own complete separate JAVA CGI renderer, so yea, I understand you very well.

Nice! I imagine that took a LOT of work...

So, if I got you right, you are saying what I was thinking source-code-wise: there is nothing to be added to the src when one wants to make 64bit version, only to have it environment files updated for the specific bit files (x32/x64), like having required specific x64 VisualMS dlls in place, but as of the actual src, C++ programmer is adding nothing to it, the code is exactly the same - right?

May not be in every case... If some specific API is deprecated for example, you may not have it available in the new architecture you're compiling it for...

jBridge does not "convert" anything, if that's what you mean, the OS needs to support 32bit binaries with that architecture, all that jBridge does is load a "dummy" DLL in the host that then communicates through inter process communication with the plugin which is loaded in a 32bit process . The OS needs to support the plugin's native architecture for that to work.

Well, I am no wiser at all from this description, cos to me what you are saying here is "Hey, I just literally run x32 bit plugin in your x64 bit only DAW host" which is exactly the thing why x32 VSTs cannot run normally inside x64 DAW host...anyway, thank you for the effort - maybe it is just me too C++-wise dumbo.
[/quote]

It is very simple actually, you just load the plugin in a separate 32bit process ( that the OS can run ), and then make the DAW communicate with it, just passing the audio/midi/data between them. Think of it as two or more different processes communicating with each other.

[qraqatit]

Could you PM me with your email address so that I can send you a test build if I can come up with something to address that?

Yea, sure - just did that, thus moving our communication to PM so to not flooding this topic...