DSP Robotics Support

Another thing I'm doing so often as I can (as a part of strategy) - is the "externalization" of unique modules/parts, so that I can play with what is left inside. Some settings are just sent via wireless connectors from "collector module", so the only modification I do - is the manual renaming of nodes. Advanced visuals are separated from tech data through modularization. Sometimes I fill all modules with the same possibilities (easier to synchronize), and activate only selected parts.

My largest project has about 700 000 prims/modules, and around that much connections (including wireless), over 2000 parameters to save. Loads slow, loads presets slow, but works within expectations. Sure - it has limitations (multiple instances, running-at-once performance), but these were predicted in early stages of development. More important is - the app is stable when it runs, and offers auto/manual backup of what I do. Instead of trying to do "whatever impossible" - I just put in technical guide an information on what the limitatins are, and refer them to possible environment limitations with a short note "we are working on it". Thus - you have a year or two to figure it out, doing meanwhile all other minor updates.

One thing worth to mention. When I decide to use some sort of parts many many times (like oscillators, sliders, gui elements, randomizers, and so on) - one of first checkups I do - is to see how a test design behaves when I put inside 200-500 copies. Like you did with ruby windows; I just do it on the beginning, before I start promising anything. I remember the early stages in SM and stock sliders. I had to redesign the idea in order to make it work; because it did not wanted to work with so many sliders inside. Sure, later I also modified these sliders (and moved into vector based ideology instead of using bitmaps; with some effort - you can do pretty cool tiny things).

But each next large modification of my projects - was always faster to achieve than I thought it would be. So just play with the idea, and find out how to simplify things. This (i.e. planning and strategy) will take most of your time. Modifications - not so much.

Ok for comparison fast prototyped version of plugin statistic:
prims: 162 160
modules: 16 616
total: 178 776
links: 202 529
wireless: 16 183
ruby:0
even it is prototype a have tried minimize number of modules as much as I can so it may look like small project.

After test everything works as expected so I started optimizing and adding additional features (not audio related user interface changes, randomizing, subpresets and so on things that help user - better and simplified controls, better global overview - schematic view for example)
actual almost finished version statistic:
prims: 17 928
modules: 2 126
total: 20 054
links: 20 618
wireless: 3333
ruby:935

Everything is faster, plugin is 60% smaller, 70% faster with more features but?! Well you know.

But there is one little matter.

1) Seeing optimization in terms of amount of modules is tricky. Inside FS - modules are like pieces of code you write in ruby. So you may consider a ruby window with instructions in it - as a set of primitives, not one primitive. It's just a different visual representation. Some time ago I played with streamy codes, seeing if something will change if I reduce the amount of them. So instead of having multiple DSP codes, I tried to put what I could into just few ones, and guess what happened. Nothing. All instructions must be processed so or else.

2) Okay, you have "70% faster plugin, but". Can it be just 30-40% faster without "but"? I had similar issues with custom arrays and presets. I wanted to make the preset manager faster, so I switched all I could into few large arrays. It did not worked that way. While preset part was faster (from 40 seconds into less than 1), the greenery made the app hang, like in your ruby case, no response. Trigger handling. But - I figured out, that I need to convert into arrays only switches, and I should do more little arrays. If an array contains 2 elements, then 2000/2 = 1000 pieces. If an array contains 10 elements (and this is enough), then 2000/10 = 200 pieces. Having between 200 and 1000 pieces is fine.

3) Smaller size. Is it so important? 2TB disk drives and 2GB of ram can handle it? I'm not sure whether we speak of physical plugin size or about assigned memory size. For example, my plugins, without bitmaps inside (all vectors) - are around 8MB per file. 400-500MB of RAM in use, when using exe apps.

4) Actually how many instances of such plugin are needed to load at once? From my sound engineering practice, there are plugins that are used only as singular multi-purpose instances that do everything, including washing your teeth and plugins that deal with simple operations, like filtering, compressions and so on. Manage balance between these two directions. Sure, you can create a thing like Camel Audio Alchemy, but I don't think that FS is designed to cover such extensive setups.

So in general, I guess it is a playing around performance, usability, expansion, and so on.

1. Well looks like it is not true. This ruby bug is the proof. Even empty ruby modules can make slowdown without single code.

2.Even 70% btter performance is still not enough. It still use too much CPU. Trying to get even better performance. Not everyone has money for i7.

3. Ram usage is almost same about 100mb but I still prefer smaller files. For me this is also important aspect. Only because we have disks with large space doesnt mean we have to unnecessarily waste any byte. Again not everyone have money for bigger disk. It's business move or rather "tacit agreement" between the developer and manufacturer of hardware forcing user to buy new equipment in order to use new software even if it is possible to make it run smooth on older computer. Why make it faster? Why make it smaller? Just buy new hardware and it will be faster. I hate this!

4. As many as needed. Sometimes one is enough and sometimes you need more. Depend on project.

TrojakEW wrote:1. Well looks like it is not true. This ruby bug is the proof. Even empty ruby modules can make slowdown without single code.

2.Even 70% btter performance is still not enough. It still use too much CPU. Trying to get even better performance. Not everyone has money for i7.

3. Ram usage is almost same about 100mb but I still prefer smaller files. For me this is also important aspect. Only because we have disks with large space doesnt mean we have to unnecessarily waste any byte. Again not everyone have money for bigger disk. It's business move or rather "tacit agreement" between the developer and manufacturer of hardware forcing user to buy new equipment in order to use new software even if it is possible to make it run smooth on older computer. Why make it faster? Why make it smaller? Just buy new hardware and it will be faster. I hate this!

4. As many as needed. Sometimes one is enough and sometimes you need more. Depend on project.

a.d.1) Without any code - ruby is a primitive, that creates slowdown. With a code - it's like a set of primitives, among which is the slowdown routine. That's why I said it is tricky. 100 green prims can be seen as unoptimized bunch of elements, or like a few lines of code, there is no big difference. Sure, the difference is in the way how it is executed (on example of arrays and greenery vs ruby), but what I mean - is the perception shift - between lines of code, and pieces called "prims" and "modules". Optimization lies rather within relationship behind both - prims and lines of written code.

a.d.2.) I agree. But on my journey, I ended up with a question: "is it enough to do something useful?" And I made all I could, to make it enough on "threshold configuration". I have an old C2D here, only 2GHz.

I'm not able to do more on FS, but I'm not ready to learn something else in order to do more. I prefer to use in practice, what I am able to create.

a.d.3.) Sure, but is there a difference between 5 and 10MB in comparison to regular harddrives now? I remember well the times, when large HDD was something around 450MB... Let say that typical, old or used machine - has a 40-80GB hard drive. At such size - where things start to make noticable difference? Worth to keep in mind, that folks who produce music - must know that they need space, for export for example. 5-10MB. Is it equivalent of 1-2 mp3 files, that you can get rid of?

a.d.4.) There is something I call project management and task list optimization. During production process - you learn it, and you adjust the resources, all you have under your hand. Software, plugins, space needed, and so on. A simple relationship from practice. Software needs space, I need to create a product using that particular software. Conclusion - I do what I can, to get some space.

*

I'm not telling you, that you should abandon your path. I'm just indicating, that there are other aspects to consider, before getting into frustration, and before blaming something, that just is as it is, and it is as it was from the beginning. Most of what is going on in Flowstone vs ruby - was easy to predict, even for non-programmer like me.

What changes over time - is the optimization and understanding of ideas and flow of concepts you decide to integrate.

Just my few cents.

I'm not frustrated. This just small obstacle I need to overcome. Oh and I already started. Trying to combine as much ruby modules as it will be possible. Lots of work but what now. Too late to abandon. But it is good warning for others: Do not to use too much ruby modules on your project!

Oh and thanks to all for your comments and suggestions in this matter.

Thanks for warning on ruby.

TrojakEW wrote:billv your x11 has not been fixed. Since you have almost twice as many ruby components as I just use only 3 instances of your plugin in daw. This cause daw not to respond for about 30 sec after closing project.

The fix i was refering too was "crash on close".
This is fixed at my end, as i can't repeat it.

The delay in daw close...is something else....

on my slow cpu...
X11 is....
1 instance = 10 seconds
2 instance = 25 seconds
3 instance = 1 minute 26 seconds..

billv thats still a bug for me. Oh and you are one of few that has slower computer than me which is really extraordinarily since my has about 12 years or so (maybe more it is too old to renember How old it is) But I feed it with vitamins so it can live 12 more

TrojakEW wrote:billv thats still a bug for me

Yeh mate...the delay seems like a bug to me too...
but way beyond my understanding....ruby guru stuff...