Out of memory error

[Phil Thalasso]

Hello fellow flowstone tribals.

While working on a project - and that has never happened before - flowstone hung itself up and I got the message that there isn't enough memory. There was nothing running in the background and I doubt that my computer was out of memory. I also didn't do anything out of the usual, however, I imported a module from Adam's wonderful synthmaker archive files. Could it be that legacy modules crash FS 3.06? The strange thing with that module is also that it cannot be added to the tool-box. Well, at least I can't. Any idea?

The thingy I write about is a display that can be found in

http://www.naiant.com/SM/SM%20Forum/Syn ... 081912.zip

for example in schematic 1123_ADSR display.osm which you can find in this post.
Why am I asking? There are plenty of very interesting things in that archive, but I just wonder how stable they are. I probably make mistakes enough as it is, so no need to bring in extra problems. Although I'd love to have that display in my tool-box.

Best Regards
Phil

[Spogg]

Ages ago, when I was building the SynthMaker Greatest Hits topic, I did find several old schematics that produced undesirable behaviour. I guess it was to be expected considering the huge version hike. In case you weren’t aware of it:

viewtopic.php?f=3&t=3809&hilit=synthmaker+greatest+hits

I tested all the OSMs I found and those shared in the topic all worked in FlowStone 3.08.1 which I was using at the time.

Sometimes I was able to rectify issues, and I mentioned what I changed in the posts I made.
Sometimes stuff just didn’t do anything, plus a few caused nasty crashes, so I rejected them.
In some cases I found many evolving versions, so I only shared the most recent working ones.
Sometimes I found projects that have better modern versions in FlowStone, so I didn’t see the point of sharing functionally superseded stuff.

Essentially, I did a lot of work so maybe you and others don’t need to duplicate my efforts, unless you want to!

I hope you find some interesting stuff there!

Cheers

Spogg

[Phil Thalasso]

Thank you Spogg!

As I very infrequently have time to enjoy flowstone, I tend to forget things. And so I forgot about your posts which you started in 2015. When I got flowstone some time in 2016, looking at all those posts greatly helped to get a basic understanding of what you can do with the program - not saying I can do it, up to this day. Thank you for reminding me.

Best Regards

Phil

[trogluddite]

Essentially, I did a lot of work so maybe you and others don’t need to duplicate my efforts, unless you want to!

I've just had my first trawl of the thread; you've done a grand job there! I lost myself for a good few hours, and it was a trip down memory lane to see so many names from so many years ago. I even found a couple of my own files that seem to have gone walkabout in the mean-time! It gives me great pleasure to see how much has been preserved of so many people's efforts. Bravo, and thankyou!

[Spogg]

Thank you Trog!

For 3 months I was mining for gold and finding diamonds, as well as fossilised crap

It was great fun and I learned a lot in the process.

Cheers

Spogg

[wlangfor@uoguelph.ca]

Reminds Me of Javascript. Speaking of which We need to stress to Flowstone dev's that the Visual GUI could be replaced with css3. It has next to no issues at all and can do anything.

Much faster as well. Limited to 100hz but what is'nt. Faster than ruby and the code to include it is almost non-existent. The trick would be the drivers to support it of course.

https://www.w3schools.com/Css/

it can practically do anything a programming language can do and safely without the risk of any code interfering.

[trogluddite]

Speaking of which We need to stress to Flowstone dev's that the Visual GUI could be replaced with css3

Except that the dependencies would be huge. To be able to use a CSS renderer, either VST plugin users would have to have the necessary libraries (.dll) files installed, or each plugin would have to statically link to the libraries (i.e. include their code within the plugin .dll, as is done currently for the Ruby interpreter.) For back compatibility, or for those users who don't want another coding language to learn, you would also need a CSS version of all of the GUI primitives and Ruby methods, and code to composite CSS from multiple module GUIs.

This is far from being the easy task that you seem to think it is, and since installation of dependencies is usually frowned upon by VST users, could lead to huge VST .dlls due to inclusion of the CSS renderer libraries. Although I'm not a fan of its CPU hogging, the GDI+ engine that's currently used is pretty much guaranteed to be available on all Windows installations, so doesn't have this dependency problem.

Much faster as well. Limited to 100hz but what is'nt

Whether CSS would be any better would depend on whether the chosen CSS renderer uses hardware acceleration - CSS itself is just a descriptive language, it's not inherently fast or slow, it all depends on how the chosen renderer implements it. There's already no inherent limit to how fast you can trigger redraws, the problem is that the current GDI+ renderer uses the main CPU for drawing, so it's the CPU load that becomes the limiting factor. A CSS renderer without hardware acceleration would have to work just as hard as the GDI+ renderer does, so wouldn't lead to any advantage in frame-rates. Using the power of the graphics hardware is the critical factor, not the language which is used to describe what should be drawn. Despite many years of people complaining about it, DSPr seem very reluctant to change from the current system.

[wlangfor@uoguelph.ca]

Speaking of which We need to stress to Flowstone dev's that the Visual GUI could be replaced with css3

Except that the dependencies would be huge. To be able to use a CSS renderer, either VST plugin users would have to have the necessary libraries (.dll) files installed, or each plugin would have to statically link to the libraries (i.e. include their code within the plugin .dll, as is done currently for the Ruby interpreter.) For back compatibility, or for those users who don't want another coding language to learn, you would also need a CSS version of all of the GUI primitives and Ruby methods, and code to composite CSS from multiple module GUIs.

This is far from being the easy task that you seem to think it is, and since installation of dependencies is usually frowned upon by VST users, could lead to huge VST .dlls due to inclusion of the CSS renderer libraries. Although I'm not a fan of its CPU hogging, the GDI+ engine that's currently used is pretty much guaranteed to be available on all Windows installations, so doesn't have this dependency problem.

Much faster as well. Limited to 100hz but what is'nt

Whether CSS would be any better would depend on whether the chosen CSS renderer uses hardware acceleration - CSS itself is just a descriptive language, it's not inherently fast or slow, it all depends on how the chosen renderer implements it. There's already no inherent limit to how fast you can trigger redraws, the problem is that the current GDI+ renderer uses the main CPU for drawing, so it's the CPU load that becomes the limiting factor. A CSS renderer without hardware acceleration would have to work just as hard as the GDI+ renderer does, so wouldn't lead to any advantage in frame-rates. Using the power of the graphics hardware is the critical factor, not the language which is used to describe what should be drawn. Despite many years of people complaining about it, DSPr seem very reluctant to change from the current system.

No I meant to literally replace the guts with css3. Then everything visual would be through an html interpreter. That would make c++ just a means to host the html engine which is a few kb's.

There's nothing visual that ruby can do that css3 can not. And there won't be the same problems.

[trogluddite]

And there won't be the same problems.

Which problems exactly? I can't see that you've suggested what they are besides the learning curve of the FS GUI system, and a preference for CSS because you're already fluent in it.

At the moment, when a primitive or Ruby wants to draw, say, a rectangle, the C++ of GDI+ is called directly to construct a system-level GUI object of some kind. You're suggesting replacing this with inserting 'green' parameters into CSS/HTML strings, composition of the HTML from multiple modules, which then gets parsed by an HTML parser, from which the system is finally called to do the drawing. Unless the drawing itself uses a vastly more efficient method (i.e. hardware acceleration), this is inherently less efficient than what we have now, and all those HTML strings will require lots of additional memory allocations.

I would be the first to suggest, as I have many times, that the GUI components should be enhanced with a more efficient engine, and a framework for easier formatting and more complex objects (e.g. tables, tree-views.) Some CSS/HTML capability would certainly be great as an extra feature, but I just don't see how it's a good fit for FlowStone's way of working - much as I love all of FS's various code boxes, graphical modular construction is its primary appeal even to me, and even more so for folks that don't have the "written coding" background that you or I might have. I think it notable that no-one else has expressed any enthusiasm for your suggestion.

[wlangfor@uoguelph.ca]

Ah, well I'd meant that everything would work the same way; merely be driven by html.
No learning curve as it is behind the scenes so to speak.

And I agree about enthusiasm, it's just it is very efficient.