DSP Robotics Support

No, you're missing my point tzarls.. Tester.. I don't know WTF you are talking about..

Anyways, Tzarls...
The point is not about whether the link happens statically or dynamically, the point is about the fact that the older version of FS copied a DLL out of itself and then, dynamically linked to it. I have no problem with it dynamically linking, I have a problem with the process by which it got to the file. The file should either already exist on the system as in ruby being properly installed, or it should be statically linked. Everyone wants their plugins to be simply copied to the VSTPLUGINS folder and have them run. So, the only real and "proper" option was to statically link because you do NOT create executable files from your own executable.

So its a problem when your users accuse you of secretly installing executable files. Its a problem if, for whatever reason a virus scanner sends off a false positive on you, its a problem when you have two plugs, one made with an earlier build of FS and one with a newer and your plug crashes because of improper Ruby version. There is many, many reasons why this is not a proper technique.

Now though, it does not matter, its probably fixed, but, I'm still concerned about what happens when two different plugs are running with different Ruby versions statically linked in them because AFAIK they share memory space in some way. That needs to be answered and I have no way of testing for that, so I'm going to drop Malc an email and ask him...

My guess is that if it does not run from the word go, then we're going to have stay with one statically linked version of Ruby forever. That's totally ok with me, but lets make sure we understand the ramifications thereof. If that's the case then if the statically linked version of ruby was to ever be upgraded in FS, and two different ruby versions cannot coexist, then plugs will crash...

So is 64 bit happening or not?



I'm using a demo of FS now, and I really like it! But, if they're not going catch up with the times and make it happen I'm sure not gonna drop $150 plus update cash on it. Shouldn't there be a thread or a developer's log where they can show the community what progress they've made/are making? We're sitting here in the dark, no information, no estimate, no deadline, no nothing. That's a serious let-down, and in this day & age, that's a serious business failure.

Say no more

http://www.steinberg.net/en/newsandeven ... -2504.html

tor wrote:Say no more

http://www.steinberg.net/en/newsandeven ... -2504.html

brand new info! thanks tor, thats very interesting and important, so steinberg forces all developers to switch to vst3, lets see how long they will support vst 2 on cubase, nuendo... follow the leader!

Well ... how much could really change in v2 without breaking it or compatiability issues.

V3 Dev tools will still export to V2 to keep all platforms. Maybe I'm missing the point.

Leader? Rather a bad dictator.

Also fruity loops is going to 64 bit, and mac osx too.

The fact is: or we move to 64 bit or this software will no more useful for us.

Flowstone has great potentialities, don't let them stagnate!
Ruby fixed? jump up and made a 64bit version of FS, to be distribuited on both flavours (32&64)...

After passing from SM to FS, i buyed the full pack license + 1 year update. I seen nothing, nothing of what promised.
For sure i will never get the upgrade if this is not planned.

And... Reply sometimes to your community.


I see the new synthedit alpha... That's will be my future software without any doubt.

What about 64-bit precision of greens and streams at reasonable performance?

Read what link says more:

Steinberg's host applications, such as Cubase, Nuendo and WaveLab, will continue to support VST 2, but the SDK for VST 2 will be made unavailable by the end of this year.

*** means no hurry for FS needed, because VST 2 is still supported

The VST 3 development kit not only generates VST 3 plug-ins, but also is capable of rendering to VST 2 and AU formats.


*** But this is interesting, AU format, so then maybe FS catch 2 flies in one go, VST 3 and AU export.

On the Steinberg page is nothing said about 64 bit only, or an end to 32-bit

jjs wrote:Read what link says more:

Steinberg's host applications, such as Cubase, Nuendo and WaveLab, will continue to support VST 2, but the SDK for VST 2 will be made unavailable by the end of this year.

*** means no hurry for FS needed, because VST 2 is still supported

The VST 3 development kit not only generates VST 3 plug-ins, but also is capable of rendering to VST 2 and AU formats.


*** But this is interesting, AU format, so then maybe FS catch 2 flies in one go, VST 3 and AU export.

On the Steinberg page is nothing said about 64 bit only, or an end to 32-bit

Flowstone couldn't export AU first because it use GDI, and in a wrapped way that does not fit VST GUI classes.
They should change the "core" of Flowstone, forgot this link to the windows libraries that will never allow any porting.

BTW, 64bit and VST3 may be possible for windows still using GDI+.