DSP Robotics Support

Great that the Ruby issue has been solved!

Now this is out of the way: let's address the 64 bit vst case!

CC

Good fix and stuff.
Le'ts go x64!

ccpurno wrote:Great that the Ruby issue has been solved!
CC

The ruby issue is not solved, you can't load any external libray now.
Are the only one that uses external libraries, for its vst?

I will post soon video showing that it is possible for each user to have his interpreter.
I hope that Malc read the previous post.

I asked the same question to devs earlier, so here is reply on that I received:

Thanks 'tester' for sharing the message. From the looks of it, I think I'll do the upgrade ... I guess If I had a problem I could revert back. Hopefully that wouldn't be needed.

Again, thanks 'tester' for the post ... I think you saved me from possible hassle

I have had one issue RJ-
I had contrived a 'preset string' alternative to 'preset parameter array',
this has broken with the update,
so far nothing else is playing up.
I could try and debug the string array thing,
I just switched it to prs param. array,
as my preset name workaround is no longer neccessary.
It was working fine, 'til the update

Tronic wrote:

ccpurno wrote:Great that the Ruby issue has been solved!
CC

The ruby issue is not solved, you can't load any external libray now.
Are the only one that uses external libraries, for its vst?

I will post soon video showing that it is possible for each user to have his interpreter.
I hope that Malc read the previous post.

i`m also happy about this, not need to be in fear that somes other fs plugin can crash the host anymore,this is much more important for me than to have the possibility for external dll, i think this was a really big problem to do public releases... shure its bad for for people like you who used this possibility already but all that stuff with saving things to different folders taking care for namespaces and classnames... not a clean and secure solution

hopefully there will be a way in some future releases to expand ruby with gems and dlls, but for me i really prefer this way like it is now because i dont need to be in fear that plugins of other fs devs crash my plugin..

Tronic - sorry that this change doesn't meet with your needs. We were trying to do the best for the vast majority and I think very few people will be using Ruby extensions for VSTs and even fewer will be compiling their own Ruby dll. Although we haven't tried it here yet, I'm sure your suggestion will probably work.

The thing is this would still require the ruby dll to be packaged with the plugin and extracted to a folder. This is something that wasn't very popular.

There could also be a possible compatibility issue if two separate plugins just happen to pick the same name for their ruby dll. I suppose this is unlikely and maybe we could get round this by generating the name for the Ruby dll internally to ensure it has a unique name.

We haven't drawn a line under this issue, there is still more thinking to be done on our side about how best to deal with it.

nix - I didn't think there had been changes made in that area. If you need to have it working then please do send us a schematic to show the issue and we'll look into it.

oh-- thank you Support
It's no problem, the float array preset works fine.
If you want to look further into it,
I will tinker and see if I can fix it,
before sending you the trouble schematic.
I'm not sure what happened,
I had done the preset string array thing because I could prefix all the values with zz,
allowing me to format the preset .txt in Excell.
The float array values get jumbled up,
impossible to manually parse.
IMO- something has changed in the last 2 updates.
Actually, I will look into it and get back to you in the next week,
could be handy to use the string format for something.

I'm fine with having the Ruby .dll extracted,
I just need no conflicts between instances.
Tronic- I hope they can do this so you can use the advanced features of Ruby--
Maybe even you and support could start a dialog allowing key gems/functions to be included?

Thanks support...look forward to installing it...
Have been having lots of issues with toolbox items(tags) dissappearing.
My maths folder has 3 items in it..same with "Element" and "Flow"...
I used to get a fix by re-installing...but it's not working anymore.
"User Created" folders are ok...just the others have issues..
Hope this new update will help somehow...

Thanks for the dll. fix....

support wrote: it allows for communications between instances which can be a useful feature!

"Communications"..??...wow...interesting stuff...so our VST's can "talk" to each other....
no idea on how it's done......would love to see some sort of tutorial breaking this whole process down....

support wrote:Tronic - sorry that this change doesn't meet with your needs. We were trying to do the best for the vast majority and I think very few people will be using Ruby extensions for VSTs and even fewer will be compiling their own Ruby dll. Although we haven't tried it here yet, I'm sure your suggestion will probably work.

The thing is this would still require the ruby dll to be packaged with the plugin and extracted to a folder. This is something that wasn't very popular.

There could also be a possible compatibility issue if two separate plugins just happen to pick the same name for their ruby dll. I suppose this is unlikely and maybe we could get round this by generating the name for the Ruby dll internally to ensure it has a unique name.

We haven't drawn a line under this issue, there is still more thinking to be done on our side about how best to deal with it.

nix - I didn't think there had been changes made in that area. If you need to have it working then please do send us a schematic to show the issue and we'll look into it.

I understand your vision of simplicity.
But I guess that is not always the simple things are the best,
because a user, even now to get the ruby ​​libraries, he must know a minimum of programming, and compile all from source.

But since, as described in the previous post works,
why not have both the possibilities?

just make two versions, type
vst_ruby_embedded.dll
exe_ruby_embedded.dll

vst_ruby_packed.dll
exe_ruby_packed.dll

and give the possibility of using one or the other system, in the creation phase.

to guarantee the uniqueness of the names of the dll, just add the name of a 4-digit id, such as the one for the ID for vst.
so if it conflicts that would conflict also vst. therefore should be changed

about extracting files,
half of the software that use extract when initializing many files.

however the files will be extracted only if not already existing in the specified folder, so as to make sure everything works and do not have the trouble of creating an installer.

If instead then there will be a way to call external libraries without passing by ruby, for me it would be even better.

My say wants to be constructive. Without any malice.

And I wonder, this not being the same for the exe, the ruby ​​interpreter is still shared? I have not really understood.

My solution here works very well, without any problems.

I hope you keep in mind the request.
Otherwise my projects will be for now unusable and can not be achieved in the future, with the new system ruby.

if you need to know the details of my solution, I am available.

if you can tell us, if you are inclined or not, to the request,
otherwise stopped my development now, before not being able to accomplish things.
Malc Thanks for your attention.