DSP Robotics Support

Completely beyond me but it sounds very impressive and I wish you well.
Keep us up to date on how the project progresses...

Cheers

Spogg

ScullEd1981 wrote:Hello All,

In recent email form Malc:

"
And that brings us to 64 bit - of course we’d love to do that but it’s not easy. It’s been on out radar for a long time and we are going to be looking at the issues again over the next few weeks. If this is vitally important to you then maybe it’s best to wait and buy in if it eventually comes.

"

I recall they said loooong time ago that the biggest obstacle going x64 was the DSP/ASM module because new Visual Studio doesn't support using pure sse assembler anymore.

My question is. Do you really need that so desperately?
The performance has never been the main selling point in SM/FS. Even less so now that computers are quicker.
Maybe there's even some way to use "intrinsic sse code" in its place? Or just external .dll files compiled separately..
I dont know.. I dont care.. It's just a shame if this product dies just because there's no room for compromises.

matti wrote:The performance has never been the main selling point in SM/FS.

you think so? i don't know how much vsts you are using in an audioproject. me. a lot. and for me in audio production performance is still one of the most important things!
i always optimise the whole streampart with asm, thats 20 - 30% better cpu performance, and then i get results which are "ok" and in an acceptable range when you compare it with similar good quality plugins on the market... without the asm optimisation they would be far away ...

+1
Besides, the codebox is rather limited compared to asm. For instance FFT would not be possible in stream code. To sacrifice asm for 64bit would be a bad compromise.

Nubeat7 wrote:without the asm optimisation they would be far away ...

Yes that is the case inside FS. But try to think outside the box for a moment. From my experience i can get up to 10x quicker dsp code by doing it with C++ and vst sdk. And it's really just like the stuff that gets written down to the "code" module. You can almost copy paste it.

And the point was not that speed doesn't matter. It was that if you are specifically looking to find the most cpu efficient platform.. you are not even looking at FS's direction.

matti wrote:

Nubeat7 wrote:without the asm optimisation they would be far away ...

Yes that is the case inside FS. But try to think outside the box for a moment. From my experience i can get up to 10x quicker dsp code by doing it with C++ and vst sdk. And it's really just like the stuff that gets written down to the "code" module. You can almost copy paste it.

And the point was not that speed doesn't matter. It was that if you are specifically looking to find the most cpu efficient platform.. you are not even looking at FS's direction.

sure, but then its useless to argue here in flowstone, just use juce instead....

i think the only way to get more into c++ with flowstone would be the support of audiostream for the external dll feature, like this you could program complex modules with c++.

i remember how disappointed i was when the dll component was introduced and i saw that it just support green and ruby connections but no Stream connection..

Nubeat7 wrote:i remember how disappointed i was when the dll component was introduced and i saw that it just support green and ruby connections but no Stream connection..

that's not true, the DLL component supports audio using ruby frames... there is no other way to do it as every call into a DLL has a function overhead so you need frames and can't call into a DLL for every sample.

Unfortunately, with FS 3.09 beta 2, the DLLExamplesV1.osm example from the Flowstone Guru site seems to 'randomly' crash due to the streaming/frames part (after I remove just that part from the schematic and perform a 'save as', then the other functions are just fine). This happens on both my Win7 i5 and Win10 i7 system (the dll itself compiles just fine with Netbeans IDE 8.2 and MinGW C++ compiler). Any hints?

Ref.
http://flowstone.guru/blog/the-dll-component-getting-started-part-3-the-flowstone-schematic/

I'm helping to test the new alphas. You can ask MyCo if you want to join in.
Anyways, I'm testing pre-made schematics and I had a dll component issue and he said the dll component is a bit broken at the moment.
So I would wait a bit...

Cheers

Spogg

Will the next version be 64 bit or is that off the table for good ?