I support 64Bit development

[JB_AU]

Go into C:\Program Files (x86)\DSPRobotics\FlowStone and there is exe.dll & vst.dll.
If you rename exe.dll to exe.exe & run it, it is the windowed program that runs the schematic.
vst.dll is similar , but for vst. I never made a vst plugin, but if you could supply one, i could take a peek.

You schematics are injected into these modules.

It is highly possible to patch the resulting file regardless of size, as the wrappers do not change.

Now before some nay sayer gets on their soapbox about reverse engineering Flowstone, we are not, we are reverse engineering the end product. The license agreement for paid versions claim that executables/plugins are ours & can be used for commercial reasons.

[CoreStylerz]

Go into C:\Program Files (x86)\DSPRobotics\FlowStone and there is exe.dll & vst.dll.
If you rename exe.dll to exe.exe & run it, it is the windowed program that runs the schematic.
vst.dll is similar , but for vst. I never made a vst plugin, but if you could supply one, i could take a peek.

You schematics are injected into these modules.

It is highly possible to patch the resulting file regardless of size, as the wrappers do not change.

Now before some nay sayer gets on their soapbox about reverse engineering Flowstone, we are not, we are reverse engineering the end product. The license agreement for paid versions claim that executables/plugins are ours & can be used for commercial reasons.

Yes. the problem is that it will be hard maybe also having the source code for making the wrapper. How it's possible to do that without knowing how these things works?

If DSPR maybe release a kind of documentation or source code of these wrapper we may can accomplish the task.

[JB_AU]

You should ask them for their bank account numbers & passwords while your at it

Your essentially asking the programmer for all their secrets.

You will literally have to pay someone to do this, as it is a workaround (hack) for your current problem.
In order of magnitude we are talking 10's of Thousands if not 100's of lines of code.

[CoreStylerz]

You should ask them for their bank account numbers & passwords while your at it

Your essentially asking the programmer for all their secrets.

You will literally have to pay someone to do this, as it is a workaround (hack) for your current problem.
In order of magnitude we are talking 10's of Thousands if not 100's of lines of code.

Yes it seems a bit hard. Really don't know how the software embed the schematics into the exe, but i do not believe that (depending on how that task is accomplished) this reveal any secrets. (yes, maybe depending on how is made up).

But we going out of topic.
How much $$$ DSPR needs to make use able to export 64 bit (compatible or bridged) plugins?
This can be a solution for a long time (if stable) so there's no need for plenty 64 bit support.

[Tzarls]

I've never made a 64 bit vst but I've built some 32 bits ones using code (c++) so I know some things about this. In my opinion there's no need to get fs' source to make something like this. All you need to know is in the Steinberg's sdk. From the 32bit plugin's point of view the wrapper would look like plugin host. From the DAW's point of view the wrapper is a 64 bit plugin. The wrapper would then act as a mediator between the 64bit host and the 32bit plugin, passing messages between each other and taking care of converting what is needed. The 32 bit plugin will still be limited to the maximum amount of memory a 32bit app can address. At this point, apart of the possibility of telling your customer that your plugin runs in a 64 environment, what are the advantages of a 64bit plugin? RAM, of course but what else?

Now, there are some wrappers already in the market. Have you tried any of those?

EDIT: Now thag I think about it... With all the asm stuff inside fs, even if the plugin can be made to run as soon as the schematic does something funny and out of the convention lf a 64 bit environment it would crash... If that's the case then no wrapper in the world can help, because such things have to be addressed and fixed in the plugin itself.

[CoreStylerz]

I've never made a 64 bit vst but I've built some 32 bits ones using code (c++) so I know some things about this. In my opinion there's no need to get fs' source to make something like this. All you need to know is in the Steinberg's sdk. From the 32bit plugin's point of view the wrapper would look like plugin host. From the DAW's point of view the wrapper is a 64 bit plugin. The wrapper would then act as a mediator between the 64bit host and the 32bit plugin, passing messages between each other and taking care of converting what is needed. The 32 bit plugin will still be limited to the maximum amount of memory a 32bit app can address. At this point, apart of the possibility of telling your customer that your plugin runs in a 64 environment, what are the advantages of a 64bit plugin? RAM, of course but what else?

Now, there are some wrappers already in the market. Have you tried any of those?

EDIT: Now thag I think about it... With all the asm stuff inside fs, even if the plugin can be made to run as soon as the schematic does something funny and out of the convention lf a 64 bit environment it would crash... If that's the case then no wrapper in the world can help, because such things have to be addressed and fixed in the plugin itself.

Yes there's are plenty of bridges that run ok. Usually are in the host (like reaper) or other like jbdrige. The problem is that there's no way (due to licensing in the case of jbridge) to deploy your plugin already bridged or capable of being used in 64 bit hosts.

Ye probably not the best deal. Plugins will not became 64 bit native and there will be many problems related to stability.

The solution can only come from DSPR releasing a 64bit flowstone.
For many the solution may be use c++.

[tester]

Ask bridge developers under what conditions they are willing to support you.

[Exo]

I've never made a 64 bit vst but I've built some 32 bits ones using code (c++) so I know some things about this. In my opinion there's no need to get fs' source to make something like this. All you need to know is in the Steinberg's sdk. From the 32bit plugin's point of view the wrapper would look like plugin host. From the DAW's point of view the wrapper is a 64 bit plugin. The wrapper would then act as a mediator between the 64bit host and the 32bit plugin, passing messages between each other and taking care of converting what is needed. The 32 bit plugin will still be limited to the maximum amount of memory a 32bit app can address. At this point, apart of the possibility of telling your customer that your plugin runs in a 64 environment, what are the advantages of a 64bit plugin? RAM, of course but what else?

Now, there are some wrappers already in the market. Have you tried any of those?

EDIT: Now thag I think about it... With all the asm stuff inside fs, even if the plugin can be made to run as soon as the schematic does something funny and out of the convention lf a 64 bit environment it would crash... If that's the case then no wrapper in the world can help, because such things have to be addressed and fixed in the plugin itself.

Yes writing a wrapper would be relatively simple. On DSPRS side we could do with having doubles and quad words fully supported in ASM in ASM.
My free running oscillators would be a crash risk on 64bit because it relies on the address from the new mem to address component, this is an integer. So for that to work I would need quad words in green to and then pass it to the ASM to read from the mem.

[CoreStylerz]

You mean creating a new dll.dll and replace it for building new wrapped plugins exo, or you're talking about making a wrapper to include the output wrapped schematic .dll exo?

[Exo]

You mean creating a new dll.dll and replace it for building new wrapped plugins exo, or you're talking about making a wrapper to include the output wrapped schematic .dll exo?

I mean wrapping the dll.