EZ Math

[Nubeat7]

I hope you're suggesting there's more of an impact than that.

i don't think that it has more impact, but it is enough and too much for a well optimized schematic, if you don't mind about 10kb for one module more or less, at the end your schematic is hundrets of kb's bigger then it needs to be (like RJ mentioned already), it also results in longer loading times and it also needs the space on the RAM where vsts get loaded, so also the size of the schematic should be of interest, also when it has no direct influence on the performance (only add is used when selected and nothing else).

About purgeable, if something is set to purgeable it simply will be deleted on export, so you need to take care that the data which are coming out of purgeabled modules are save (use a float prim on the output for example, this will hold the last value). it can be really helpful for more complex module settings, for example if you have a closer look into the cablepatcher i did, you will find out that the ins and outs arrays, their positions and names can be set graphically inside a huge properties panel, the whole part (~250 lines of ruby code which is just unused ballast in the app itself ) is purgeabled and the data from it is used in the main module... but also for small modules (like my hex2col modules) viewtopic.php?f=2&t=2505
this makes sense and should be a common practice

you would wonder how much space you can save when searching every single module for parts which you can delete (and how clean everything looks after it)

[Perfect Human Interface]

Thanks Nubeat, I will definitely add the purge knowledge to my list of considerations in future work.

I can look into what may be purgeable in the EZ Math modules. However I have to respectfully disagree on the idea that a few KB's in a project is significant. Call it personal opinion, but if 64 of these modules is only a difference of 28 KB, I would never worry about using that in any remotely reasonable case. Even if it adds 300 KB to the final product (that's at something like 686 EZ Maths), I'm almost certain any difference in load time would be imperceptible with current hardware, and nobody is going to even run serious music software without at least 4GB on board so that's hardly a drop in the bucket in terms of RAM use. Even looking at internet distribution, 300KB takes 1 second to download on my slow American internet. It's just an exceedingly miniscule number in terms of practical impact and becoming more so every year.

"Wasting" more memory is always worse, in theory, but this is nearing the point of possibly not worth my time to even bother with. In fact, I can say I use Flowstone with the intention of wasting resources.

[tulamide]

"Wasting" more memory is always worse, in theory, but this is nearing the point of possibly not worth my time to even bother with. In fact, I can say I use Flowstone with the intention of wasting resources.

Are you serious? If yes, I would advise to not use your modules. You've put a lot of effort in it, but if they aren't optimized they are just error-prone, which should be avoided in larger or professional projects. Also, it's not just the wasted space, it's actual code behind the scenes, and every code will be loaded and initialized, which takes time. Best practice is to not have in the schematic what you don't need.

About purgeable, the easiest way is to think about it as a tool to mark everything that you only need during development. When the time comes to export, you don't have to scratch your head, but just export and Flowstone takes care that none of your marked developer tools will get exported.

[Perfect Human Interface]

Are you serious?

It's just diminishing returns my friend. If I spend 1 hour working and end up reducing an item's memory footprint by 1KB, a difference in practical measurement that could be accurately described as "none," then I've wasted that hour. That's just a hypothetical though; that doesn't mean I won't ever try to tidy up where I can.

If I weren't comfortable with the idea of using more resources than is absolutely necessary, I wouldn't be using Flowstone, simply.

About purgeable, the easiest way is to think about it as a tool to mark everything that you only need during development. When the time comes to export, you don't have to scratch your head, but just export and Flowstone takes care that none of your marked developer tools will get exported.

I like that, thanks.

[tulamide]

If I weren't comfortable with the idea of using more resources than is absolutely necessary, I wouldn't be using Flowstone, simply.

That's why I would advise others not to use your modules. Of course it's totally fine to work with Flowstone however you like. That's what it's for. But if sharing content, it should be optimized in any way, to make sure not to introduce issues to the project, where that content is being used. Everyone works different, even PCs may work different (let me just mention SSE), so when sharing you shouldn't assume that everything is the same as for you. Just because in your example you would save just 1 kB doesn't mean the project it is used in also just saves 1 kB. And once again, it is not just the wasted space, it's actual code. The more code you bring in, the more issues can occur. That all is meant for sharing content. For your own work, you can handle it as you prefer

[Perfect Human Interface]

That's why I would advise others not to use your modules.

That's a bit broad don't you think? Anyone can look inside the module to see what it's doing and if it's suitable to their needs or not, and make changes if they see fit to. I'll take concrete statements over questions of philosophy.

These modules were not designed with the intention of keeping resource footprint identical or better than simply using the prims. The purpose is not optimisation. The design goals were visual compactness and convenience. If I can use a tool to speed up or simplify development while also increasing resource use, as long as that use can be deemed either negligible or of low enough importance to the final outcome, I'm going to elect to use that tool. That's my personal preference, and I've shared my work here with the idea that others may share that preference (I don't think that's far-fetched). It's also in line with the philosophy of Flowstone itself. If you find issue with adding a fraction of a KB to your project per module used, then you can elect not to use it. I think people can make that choice for themselves.


That talk aside, I've gone into these EZ Math modules and set the GUI elements to purgeable, but unfortunately I don't think I can measure what impact this has. Exporting to a Fruity format plugin yields exactly the same size schematic with the items set to purgeable as with them not (down to the bytes). I can venture a guess that it only works for VST exports.

Non-purged versions do indeed take about 1/3 of a Kilobyte per module. Presumably the purged export would be significantly less. I'll update the schematic in the original post regardless, and maybe you can take a look if you have VST export options.

[tulamide]

That's a bit broad don't you think? Anyone can look inside the module to see what it's doing and if it's suitable to their needs or not, and make changes if they see fit to. I'll take concrete statements over questions of philosophy.

No, I don't. Again you are assuming what you shouldn't assume. If people can have a look inside the module and actually understand what it is doing, they won't be interested in it in the first place. Those who are interested will use it because they weren't able to do something similar. Those won't be able to fix issues that could arise from using the module. Also, I was very detailed in my statement and had particular arguments, not philosophing. I don't mean it harming, in fact I already said that you've put a lot of work into it. And with all that work, a little additional optimization doesn't hurt, I'd say

Non-purged versions do indeed take about 1/3 of a Kilobyte per module. Presumably the purged export would be significantly less. I'll update the schematic in the original post regardless, and maybe you can take a look if you have VST export options.

I did so. I created an instrument with nothing in it but 5 copies of EZ Math. Exported that purged and not purged. Savings were 8.4 kB. Good job!

[Perfect Human Interface]

I created an instrument with nothing in it but 5 copies of EZ Math. Exported that purged and not purged. Savings were 8.4 kB.

Well I find that bizarre after calculating that the modules without purging occupied 1/3 KB and now we're saving 8.4 KB with only 5 modules... but I guess I can't predict the differences between VST exports and "Fruity" exports (which are of course just the wrapped Flowstone app itself with the GUI disabled).

[tiffy]

deleted

[RJHollins]

very interesting/educational following this thread. Thanks to all.

I've just dL'd and had a look inside. There, one can really appreciate the work/thought that goes into something that seems so basic, yet offers many useful options/functions.

Did not yuet try exports ... but to notice one thing...

When stringing 2 EZMaths together, entering data in edit box, I thought the output would update after hitting ENTER], but doesn't .

Is this by design ??

Thanks