Ruby component bug

[tester]

Did you reported this to devs?

[TrojakEW]

Well not yet. Hard to explain with my poor english.

[tester]

Your english is fine. My native language is totally different than english, and even I can still understand you.

If you have isolated the problem, then you should be able to describe it step by step, using simple words, simple steps and simple examples.

I would ask a question then, whether this is a bug, or performance limitation when using multiple ruby windows.

Because each separate ruby window - despite the fact they are using only one shared interpreter - is wired with separate greeneology inputs/outputs, and depends on them and their triggerology performance.

One thing worth to mention, and repeat. If it works better without ruby - then use it without ruby. Or add ruby only where it's needed, reduce amount of triggers and see what happens then. Ruby, like anything else in FS - has it's advantages and disadvantages.

Another thing to mention is the same issue, that I will deal in my own projects. While right now I'm using multiple sliders, just cloning the interface for what many instances I need within the app - maybe it is worth to use singular interface parts, and switching parameters within preset arrays, like here: viewtopic.php?f=3&t=1802 Then instead of switching slider, you switch a parameter that it is assigned to. Also - sliders can be moved all around the gui via multiplexers, because you can define location and size of areas.

p.s.: on my C2D 2GHz there is that lag too.

[Tronic]

I think it's normal behavior, when the ruby write in memory, after it uses a garbage collector to release it.
It may be noted that when some modules are triggered too often,
every now and then you have a nice spike in CPU,
it just happens when the GC is in action to free up memory no longer used.
This explains why sometimes you get unexpected spikes cpu or longer time to close the application.

[tester]

Behavior might be normal, but the question is - can it be optimized somehow on the compiler level.

256 ruby windows is much and not so much on the other hand (diversity of modules). Did you measured the threshold when it starts to cause problems? Or - is there a threshold, or this is "linear"? I ask, because it looks somewht similar to preset manager behavior, when it comes to deal with around 2000 parameters to store.

[Tronic]

With regard to the Ruby,
this is the magical part of the garbage collector and the bad part of it, because it is poorly performing , when you run many iterations.
works so as to release the memory occupied , in an automatic way ,
you could manage with controls

Code: Select all

GC.enable   # Enable the garbage collector
GC.start    # garbage collector on request
Gc.disable  # disable the garbage collector
GC.count    # count each time you run a garbage collector

if you run these commands look at the task manager,
you'll see how the memory is taken and released by GC , and you'll notice that every time it is run, you will have a stingy on CPU usage .

But disabling it , it will always write in memory but not releasing anything,
with the risk of not taking up a lot of ram and would optimize anything.

So the answer would seem no, the Ruby has these features that make it perform poorly when used for very demanding task . For this they have adopted a system based on Java , the JRuby , where he has a system of memory management more efficient.

The green lack managment of memory is a old story

[TrojakEW]

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.

Well if this is normal behavior than it is not good information for me. Don't know what to do now. Well its not a really bug but it is quite annoying. Explaining to users that is just a normal and they just have to wait? They send me to hell with this excuse! Replacing ruby parts with green will take months, not to mention that there is a deadline.

[tester]

That's why it is good to work with templates. If things repeat - they are easer to replace.

Besides - nobody listened to me, when I expressed my worries about ruby.

First-shot project in new/expanded environment - usually means a lot of testing and creating strategy. Took me almost 2 years to develop my first (and very large) project in SM/FS. It probably will take me only 1-2 weeks (or maybe few days?) to redesign and reoptimize it to new specs.

[TrojakEW]

Well I ave used synchronized modules as much as I can to avoid making changes to each module, but most components are unique even if they looks same. What I mean is even I use same slider control there are uniqe setting because some of features I have implemented like randomizing, subpreset saving and loading and so on. It is impossible to make it same beacuase of limitation in flowstone. If I have acces to all data in preset manager module and change data inside this module it will be different story. Look like flowstone for now is usable only for small projects .

[Nubeat7]

Look like flowstone for now is usable only for small projects .

i think thats a question of programming skills..

http://www.youtube.com/watch?v=U5fP8_c68js
http://www.youtube.com/watch?v=7F1K8EJoWC4