If you have a problem or need to report a bug please email : support@dsprobotics.com
There are 3 sections to this support area:
DOWNLOADS: access to product manuals, support files and drivers
HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects
USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here
NEW REGISTRATIONS - please contact us if you wish to register on the forum
Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright
So, when is 64bit VST3.5.x be released in FS?
Re: So, when is 64bit VST3.5.x be released in FS?
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...
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...
- VPDannyMan
- Posts: 118
- Joined: Mon Jan 04, 2010 4:50 am
Re: So, when is 64bit VST3.5.x be released in FS?
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.
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.
- Dugg Funnie
- Posts: 3
- Joined: Tue Sep 03, 2013 3:35 pm
Re: So, when is 64bit VST3.5.x be released in FS?
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!
-
Nubeat7 - Posts: 1347
- Joined: Sat Apr 14, 2012 9:59 am
- Location: Vienna
Re: So, when is 64bit VST3.5.x be released in FS?
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.
V3 Dev tools will still export to V2 to keep all platforms. Maybe I'm missing the point.
- RJHollins
- Posts: 1571
- Joined: Thu Mar 08, 2012 7:58 pm
Re: So, when is 64bit VST3.5.x be released in FS?
Leader? Rather a bad dictator.
Need to take a break? I have something right for you.
Feel free to donate. Thank you for your contribution.
Feel free to donate. Thank you for your contribution.
- tester
- Posts: 1786
- Joined: Wed Jan 18, 2012 10:52 pm
- Location: Poland, internet
Re: So, when is 64bit VST3.5.x be released in FS?
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.
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.
Need my support for app development, website or custom scripts?
PM me if you are interested.
Experienced Java, J2EE, PHP, Javascript, Angular, Cloud Solutions developer.
PM me if you are interested.
Experienced Java, J2EE, PHP, Javascript, Angular, Cloud Solutions developer.
-
CoreStylerz - Posts: 327
- Joined: Sun Jan 22, 2012 2:19 am
- Location: italy
Re: So, when is 64bit VST3.5.x be released in FS?
What about 64-bit precision of greens and streams at reasonable performance?
Need to take a break? I have something right for you.
Feel free to donate. Thank you for your contribution.
Feel free to donate. Thank you for your contribution.
- tester
- Posts: 1786
- Joined: Wed Jan 18, 2012 10:52 pm
- Location: Poland, internet
Re: So, when is 64bit VST3.5.x be released in FS?
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
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 - Posts: 142
- Joined: Thu Jun 09, 2011 12:15 pm
Re: So, when is 64bit VST3.5.x be released in FS?
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+.
Need my support for app development, website or custom scripts?
PM me if you are interested.
Experienced Java, J2EE, PHP, Javascript, Angular, Cloud Solutions developer.
PM me if you are interested.
Experienced Java, J2EE, PHP, Javascript, Angular, Cloud Solutions developer.
-
CoreStylerz - Posts: 327
- Joined: Sun Jan 22, 2012 2:19 am
- Location: italy
Who is online
Users browsing this forum: No registered users and 47 guests