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
The Save Button Has A Math Problem
14 posts
• Page 1 of 2 • 1, 2
The Save Button Has A Math Problem
In Flowstone, math for the save button works like this:
221KB + 460KB = 5,536KB
Can somebody explain that crap ?
Here are the files.
[Moderator Comment: Links and downloads removed]
221KB + 460KB = 5,536KB
Can somebody explain that crap ?
Here are the files.
[Moderator Comment: Links and downloads removed]
Download plugins here:
https://mega.nz/folder/nhVCkQRA#UWgU06K1o9gRFI0WqnBw_w
https://mega.nz/folder/nhVCkQRA#UWgU06K1o9gRFI0WqnBw_w
- DSP-Robotron
- Posts: 58
- Joined: Tue Aug 18, 2020 3:39 am
Re: The Save Button Has A Math Problem
Almost certainly, your sample data is stored multiple times within the schematic. This is something you have to watch with any bulk data - waves, bitmaps, large arrays, etc.
Almost all "green" and Ruby FlowStone components store their current values within the schematic file whenever you save it (the same for VST or EXE exports too). This makes startup very fast, as no data needs to be recalculated or moved between components, but as you see, it can take a shed-load of memory, as a "value" can be an entire sample or bitmap (or its equivalent in some other internal format). The likely culprits are any "green" Float Arrays or RubyEdits which have working copies of the data for generating displays, "normalised" versions of sample data, etc. It's not helped by the fact that some data formats can't be shared (a wave contains essentially integer data, internal audio "mems" use native float arrays, and Ruby uses "objects" - each format change implies a copy, and the copy may be stored in the file).
The usual workaround is to save the schematic (or export) with empty wave data (or bitmaps, whatever) and restore it at startup using an "after load" primitive. Whether you want to do that depends on your objectives, of course - sometimes you really do want to "embed" the data to avoid having "sidecar" files. There are similar "after load" tricks you can use if you need to clear only certain internal copies (the "last switch" primitive is your friend here).
NB) There is a built-in optimisation for bitmaps - a single set of data is shared for any bitmap accessed by "yellow" GUI primitives (but RubyEdits will each store their own copy if they use it!!!)
PS) I must say, I'm very impressed at how quickly you are exposing some of FlowStone's most annoying "gotchas"!
Almost all "green" and Ruby FlowStone components store their current values within the schematic file whenever you save it (the same for VST or EXE exports too). This makes startup very fast, as no data needs to be recalculated or moved between components, but as you see, it can take a shed-load of memory, as a "value" can be an entire sample or bitmap (or its equivalent in some other internal format). The likely culprits are any "green" Float Arrays or RubyEdits which have working copies of the data for generating displays, "normalised" versions of sample data, etc. It's not helped by the fact that some data formats can't be shared (a wave contains essentially integer data, internal audio "mems" use native float arrays, and Ruby uses "objects" - each format change implies a copy, and the copy may be stored in the file).
The usual workaround is to save the schematic (or export) with empty wave data (or bitmaps, whatever) and restore it at startup using an "after load" primitive. Whether you want to do that depends on your objectives, of course - sometimes you really do want to "embed" the data to avoid having "sidecar" files. There are similar "after load" tricks you can use if you need to clear only certain internal copies (the "last switch" primitive is your friend here).
NB) There is a built-in optimisation for bitmaps - a single set of data is shared for any bitmap accessed by "yellow" GUI primitives (but RubyEdits will each store their own copy if they use it!!!)
PS) I must say, I'm very impressed at how quickly you are exposing some of FlowStone's most annoying "gotchas"!
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
Don't stagnate, mutate to create!
-
trogluddite - Posts: 1730
- Joined: Fri Oct 22, 2010 12:46 am
- Location: Yorkshire, UK
Re: The Save Button Has A Math Problem
I think FS should make use of instances and reuse everything without wasting resources or at least compress everything that gets stored on disk. Basically, I have to store the samples outside of the schematic because if they are stored in the schematic it's increasing the file size by 7.92 times.
The only difference between those 2 files is that one has no samples stored in the schematic while the other one has the samples loaded in. The one with the samples stored inside is 7.92 times bigger than what is supposed to be. Which still doesn't make any sense at all.
Basically, FS was coded by complete amateurs and doesn't know how to use multiple cores and threads and bigger cache sizes and instances and whatever else is included in Windows 10 64bit combined with a AMD Ryzen 7 3700X 8-Core. That's very very very very bad FS. Very bad. Very bad DSP Robotics and Robotron robots with flow charts and schematics set in the stone age. That's very very bad...
The only difference between those 2 files is that one has no samples stored in the schematic while the other one has the samples loaded in. The one with the samples stored inside is 7.92 times bigger than what is supposed to be. Which still doesn't make any sense at all.
Basically, FS was coded by complete amateurs and doesn't know how to use multiple cores and threads and bigger cache sizes and instances and whatever else is included in Windows 10 64bit combined with a AMD Ryzen 7 3700X 8-Core. That's very very very very bad FS. Very bad. Very bad DSP Robotics and Robotron robots with flow charts and schematics set in the stone age. That's very very bad...
Last edited by DSP-Robotron on Sat Aug 22, 2020 1:00 pm, edited 2 times in total.
Download plugins here:
https://mega.nz/folder/nhVCkQRA#UWgU06K1o9gRFI0WqnBw_w
https://mega.nz/folder/nhVCkQRA#UWgU06K1o9gRFI0WqnBw_w
- DSP-Robotron
- Posts: 58
- Joined: Tue Aug 18, 2020 3:39 am
Re: The Save Button Has A Math Problem
trogluddite wrote:Almost certainly, your sample data is stored multiple times within the schematic.
OK. Here is the deal. Since you know more about how this super buggy toy works, you have 30 days to prototype this synth right here and make it work more kick ass than the Korg Wavestate synth. Right now the sample switching is noisy as crap and it makes all kinds of nasty clicks and pops, which means, some cross-fading needs to be engineered in the components somewhere. The ADSR envelopes are also complete crap, which means, we need something better. Maybe multistage graphical envelopes with splines and scaling options ? Try that.
Here is a sample image of the front panel.
https://drive.google.com/file/d/116w2Yv ... sp=sharing
Download plugins here:
https://mega.nz/folder/nhVCkQRA#UWgU06K1o9gRFI0WqnBw_w
https://mega.nz/folder/nhVCkQRA#UWgU06K1o9gRFI0WqnBw_w
- DSP-Robotron
- Posts: 58
- Joined: Tue Aug 18, 2020 3:39 am
Re: The Save Button Has A Math Problem
Since all the components are buggy and slow as crap, we also need a button that says:
Convert Ruby script to super optimized assembly script that is fully editable by retards and other ridiculous Robotrons.
That way this thing could run properly for once without killing the CPU and it would also take full advantage of 16 virtual cores and 64bit and whatever else is available on my PC.
True/False ?
Convert Ruby script to super optimized assembly script that is fully editable by retards and other ridiculous Robotrons.
That way this thing could run properly for once without killing the CPU and it would also take full advantage of 16 virtual cores and 64bit and whatever else is available on my PC.
True/False ?
Download plugins here:
https://mega.nz/folder/nhVCkQRA#UWgU06K1o9gRFI0WqnBw_w
https://mega.nz/folder/nhVCkQRA#UWgU06K1o9gRFI0WqnBw_w
- DSP-Robotron
- Posts: 58
- Joined: Tue Aug 18, 2020 3:39 am
Re: The Save Button Has A Math Problem
Here is my most advanced sampler so far with automatic panner and such but it still sucks because there are clicks and pops every time is switching sounds and performance is not very great either. So, yeah. Thanks Flowstone for ruining my precious Wavestate prototype. LOL
You can see it in action here but it's still killing the CPU about 3 to 6 times more than normal.
That's why we need Ruby-2-Assembler and Ruby-2-DSP script converters/translators. And also back to Ruby/Python/C/C++ or whatever else.
[Moderator Comment: Links and downloads removed]
You can see it in action here but it's still killing the CPU about 3 to 6 times more than normal.
That's why we need Ruby-2-Assembler and Ruby-2-DSP script converters/translators. And also back to Ruby/Python/C/C++ or whatever else.
[Moderator Comment: Links and downloads removed]
Download plugins here:
https://mega.nz/folder/nhVCkQRA#UWgU06K1o9gRFI0WqnBw_w
https://mega.nz/folder/nhVCkQRA#UWgU06K1o9gRFI0WqnBw_w
- DSP-Robotron
- Posts: 58
- Joined: Tue Aug 18, 2020 3:39 am
Re: The Save Button Has A Math Problem
DSP_Robotron wrote:you have 30 days to prototype this synth right here
And you have the rest of your life to remain banned from the forum, though I doubt even that will be long enough for you to learn to behave like an adult.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
Don't stagnate, mutate to create!
-
trogluddite - Posts: 1730
- Joined: Fri Oct 22, 2010 12:46 am
- Location: Yorkshire, UK
Re: The Save Button Has A Math Problem
This forum really needs a "Like" button...trogluddite wrote:And you have the rest of your life to remain banned from the forum, though I doubt even that will be long enough for you to learn to behave like an adult.
I keep a pair of oven mitts next to my computer so I don't get a concussion from slapping my forehead while I'm reading the responses to my questions.
- deraudrl
- Posts: 239
- Joined: Thu Nov 28, 2019 9:12 pm
- Location: SoCal
Re: The Save Button Has A Math Problem
Here you go...
-
Spogg - Posts: 3358
- Joined: Thu Nov 20, 2014 4:24 pm
- Location: Birmingham, England
Re: The Save Button Has A Math Problem
I don't think my buttonholes are big enough for that.
Website for the plugins : http://kbrownsynthplugins.weebly.com/
- k brown
- Posts: 1198
- Joined: Tue Aug 16, 2016 7:10 pm
- Location: San Francisco, CA USA
14 posts
• Page 1 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 26 guests