So, when is 64bit VST3.5.x be released in FS?

[MyCo]

I wouldn't compare the GUI of SE 64bit with FS, it is nowhere near. Also it is so terrible slow... I don't know... I can't really use it on a 4GHz 8-Core. Looks like they redraw full screen so often that the CPU is just working for the GUI instead of working on Audio.

Please don't compare the amount of work for migrating SE to 64bit, with the amount of work that has to be done for FS. SE doesn't operate as low level as FS does!

[jjs]

OK. you are wrong

Thanks for sharing the info.
Then why is Jeff not advertising anything on his website?
He would like to sell i suppose?

[Sean]

OK. you are wrong

Thanks for sharing the info.
Then why is Jeff not advertising anything on his website?
He would like to sell i suppose?

Its a long way from an Alpha to a release......so not point going too public, but at least you know its not just 'talk', it is being worked on. It isn't really relevant as to which package is easier to covert to covert to 64 bit or at what level VPL's work at (SE at allows C++ modules...)- if your only interest is making 64bit VSTi with a GPL, SE will be of interest if they get it released. I mainly use MAX (with Live 9) and that went 64 bit a while ago now- they managed!

[kortezzzz]

I wouldn't compare the GUI of SE 64bit with FS, it is nowhere near. Also it is so terrible slow... I don't know... I can't really use it on a 4GHz 8-Core. Looks like they redraw full screen so often that the CPU is just working for the GUI instead of working on Audio.

Please don't compare the amount of work for migrating SE to 64bit, with the amount of work that has to be done for FS. SE doesn't operate as low level as FS does!

yes, SE isn't perfect. to say the truth, its far a way from perfection. but. we are talking here about value. and no,
simplicity, convenience or speed are not leading factors in this Comparison, as this market is still missing it's
"bread and butter", 64bit. its like comparing two watchdogs without teeth. no matter which one is better:
no teeth, no win. give the weaker dog 4 teeth, and game is over.

I now that working on FS 64 is away harder then SE 64, but the need for 64bit has been discussed few years a go.
that means FS knows what the community needs for a long time. and still, nothing. i think that they should
decide if they really want\need us or not, because i'm not going to pay an extra money for upgrading to another Toothless watchdog anymore.

[jjs]

I'm not after 64bit.
I'm after a sample player that plays wav correctly with all markers in it. I know SE is capable as far as i know.
I don't want to use sf2.
I want to be able to make a container with samples in it like Maize sampler or Kontakt.
Maize sampler plays all correct and saves all in a container but the possibilities are waaaaay to limited.

So for now i use kontakt. But then you're always have to use Kontakt or the player.

Maybe there are possibilities with Ruby, but i don't know yet. Don't have the time now to dive further in to it.

I compare 64bit as with a new tv. Now there is Ultra HD, but no cable-provider is supporting it yet. They have just completed to support HD. Now the HD tv concept with the old crt tubes (Philips) is allready from the '80 's and came way too soon for people. Think that Plasma is new? The first plasma tv was allready made in the '60's (but then only blue screen). Even the electric car is allready from 1900. But if not all people are ready or it is being holded by the "greater powers" aka stock holders. Then it is not gonna come soon.

[VPDannyMan]

Well.. Just my 2 cents on the matter..
First off, the Ruby implementation was a disaster, we all know that, and if you don't then you need to do some reading. Having said that, Malc has now fixed it and can move on to other pressing issues like 64 bit. I have a feeling that he was already starting to at least look at it before the Ruby problem took over his time.

Lets face it, that was no small feat on his part, So, well done Malc.. Great fix, and if we were soccer players I'd give yer ass a celebratory slap..

I mean talk about a square peg into a round hole..
Ruby...
Was designed for a completely different OS that is chock full of psycho developers who would like nothing more than to see Windows killed. Anyone who has ever worked on any type of development with these people know what I'm talking about.
Now you say you are going to take their new "premier" language, and place it in a Windows only software... What kind of support do you think there would be for that? Yep... there would be developers lined up ready to answer your questions...haha

So, first off, DSPR showed one hell of a set of bullocks just for adding Ruby in those circumstances, and second off, they deserve kudos for getting it to work.. I'm confident that they will attack the 64 Bit thing and when they do, I am equally confident that sales will increase. Especially when existing plugs are upgraded to 64 bit and they carry the "Made with Flowstone" moniker.. So, hats off Malc, go ahead and celebrate this success, but just not for too long... you still have work to do

[tester]

Although I don't use ruby, I don't think it was a disaster. It simply serves else things and it was designed for else things. Not everyone here is VST producer. Besides implementing new things (like ruby) always/usually means trouble period, and it needs time to figure out in practice which way is really better; It is not within words of complaints, it is within operational projects and their issues/limitations. I don't think SE can be compared with FS due to functionalities.

Following this and other threads, I suspect MyCo may know something positive about incoming future.

[VPDannyMan]

Here tester, read again...

First off, the Ruby implementation was a disaster, we all know that, and if you don't then you need to do some reading.

"if you don't then you need to do some reading."

There are plenty of places on the web that will tell you that adding an executable file at run time, only to call procedures/functions from it is not a proper practice in any way. That is the disaster I am speaking about, because it caused many problems. If you don't understand why that is, then please go do some reading on the subject matter.

It seems that you are saying that FS is being used by others, not just audio, and that makes it ok to do this...It has nothing to do with what you are creating and has everything to do with safe, and solid programming practice.

So, if you are creating a file that gets exported and then you are calling functions in it, why not just add the functions to your program instead of writing a file and then deleting it when the program has finished running. Its one thing to create data files, entirely another to create executable files. Either way, by Malc statically linking the Ruby DLL, the functions are now contained in the Plugin DLL. Note there is no more of the errors reported before...

All due respect afforded...

[tester]

...starting with operating system called Windows. Veeery good, safe, and solid programming practice. So you are suggesting, that other environments don't have their bad things? I think certain degree of issues seems to be simply "acceptable". It works that way not only in programming. Just look around in physics, biology, chemistry - and yet, the world did not broke apart. If what's in FS was so bad, then there would be no FS nor working operational business around it.

[Tzarls]

Here tester, read again...

First off, the Ruby implementation was a disaster, we all know that, and if you don't then you need to do some reading.

"if you don't then you need to do some reading."

There are plenty of places on the web that will tell you that adding an executable file at run time, only to call procedures/functions from it is not a proper practice in any way.

(...)

So, if you are creating a file that gets exported and then you are calling functions in it, why not just add the functions to your program instead of writing a file and then deleting it when the program has finished running. Its one thing to create data files, entirely another to create executable files. Either way, by Malc statically linking the Ruby DLL, the functions are now contained in the Plugin DLL. Note there is no more of the errors reported before...

Isn´t that the whole basis of a plugin architecture? I mean, based on what you say, loading a plugin would be a bad programming practice because one should actually include the whole plugin´s procedures in the DAW instead?

Also, in the Linux "world" the preferred method is to have libraries dynamically linked - I wouldn´t say that the Linux community is guilty of bad programing practices (at least not because of this). I too prefer static linking, but I think that the Ruby situation had nothing to do with how the library was being linked. I think it has more to do with not having taken the time to evaluate the tool and check if it fullfilled all the requirements, then having to patch it until it works. In other words, Ruby wasn´t made for what the FS´s developers wanted.

But of course it´s good that now the problem is solved.