Vst editor closed = more cpu!?

[tester]

Generally, you may need to focus on syncing ticked parts. So for example - gui ticks at 25, then data gathering also ticks at 25. But... You may try at lower rates, like tick5 to tick20. Slower tick = more regular ticking if a lot of greenery is happening. And - single "redraw" prim, to refresh the area. If you put "redraw" module into each item, then you don't refresh it at tick 25, but at 25xLeds. Basically "common autoredraw" will work for everything except editboxes in edit mode.

Another thing worth to consider is to use "change" module on comparators. If bool value isn't changing, then why should you pass a trigger? And since you have a network of comparators - it will save you some green cpu so to speak. There are situations in which too much greenery may even crash the schematic or just to slow it down.

While blue operations are limited to single core, greenery, yelowery and rubyery are treated by Windows, so it spikes on both cores.

[Nubeat7]

Try gui elements without ruby.
Get replacements from SM forum.

do you still believe the old mythos ?
something works slow - it must be ruby but usally its not..
can you confirm any of your mentioned bugs as extracted fsm? would be interesting..

anyway, i agree that the original led system to trigger each led individually and redraw each individually is no smart way to do it and uses lot of unneded triggers and redraws, you have a similar looking meter in the toolbox it also works with a 25 ticker wich is fast enough for the eye

[Father]

Generally, you may need to focus on syncing ticked parts...

hmm tricky

i agree that the original led system to trigger each led individually and redraw each individually is no smart way to do it and uses lot of unneded triggers and redraws, you have a similar looking meter in the toolbox it also works with a 25 ticker wich is fast enough for the eye

From what I've seen, you're absolutely right. Gotta do it in ruby like the meters in toolbox.
I tested the meters in toolbox. sometimes they don't responded, and have to reload the plugin. Is it just me? When i replace the "Ballistics" module with an envelope follower it works fine.

[tester]

Try gui elements without ruby.
Get replacements from SM forum.

do you still believe the old mythos ?
something works slow - it must be ruby but usally its not..
can you confirm any of your mentioned bugs as extracted fsm? would be interesting..

Well - I disagree. The thing is - SM old modules are predictable and basically well known, while ruby behaviors are still leaving some space of uncertainty. It leaves also some space of uncertainty because it is an open language so to speak.

I have experienced recently some instabilities related specifically to ruby modules in context of gui/visual elements (for example I could not use the ruby driven stock counters and had to switch into old SM ones). As for confirmation. There are already few ruby/gui things I experienced on my work machine. Some of these things will be checked on other PCs to confirm them, some were just replaced by other solutions (if something isn't working - I just don't use it, and replace with something else). But I'm not in hurry - nobody pays me for beta testing here and I need to finish few things before I can interact.

You may laugh. As you know - I use ruby (and with your help - thanks again), but I don't use it for everything. Trog suggested the same as you know, no need to replace everything. My guess is - folks less experienced in ordinary programming (like me) will experience more ruby related bugs, because we don't fit the programmer's routines nor care about it too much (we don't follow rules/order).

As for case above - I bet it's just too many duplicated redraws. Externalize redraw prim (make single one) and refresh on it (tick) instead of doing it in individual modules. And reduce comparator triggers by using "changed" prim.

[Father]

As for case above - I bet it's just too many duplicated redraws. Externalize redraw prim (make single one) and refresh on it (tick) instead of doing it in individual modules. And reduce comparator triggers by using "changed" prim.

I'll look into it. And then will compare it to the ruby version. should be interesting.
Using changed prim will prevent some redrawings for sure, but Is it really faster to use a global redraw instead of individual redraws?

[Nubeat7]

@ tester: telling somebody "eliminate all ruby stuff from your schematic" as first thing just supports "be aware of evil ruby" and nothing else.. its the same like i would say "eliminate all your assembler stuff because i don`t know about it and it leaves much space for bugs, better don`t touch it..." but i dont want to fire a ruby discussion here in fathers thread...

back to the theme,

From what I've seen, you're absolutely right. Gotta do it in ruby like the meters in toolbox.
I tested the meters in toolbox. sometimes they don't responded, and have to reload the plugin. Is it just me? When i replace the "Ballistics" module with an envelope follower it works fine

just tested the stock meter and seems to work fine here (using renoise)
the ballistic is in fact an envelopefollower they just didn`t normalize the input signal..(if i got it right)
i slightly modified the stock meter to use the 'ballistic in mono4 and used an envelopefollower with denorm prevention this should do the job pretty well..

i also added one which is drawnwith ruby, in fact its just a rectangle where the hight is related to the value..

[Father]

just tested the stock meter and seems to work fine here (using renoise)
the ballistic is in fact an envelope follower they just didn`t normalize the input signal..(if i got it right)
i slightly modified the stock meter to use the 'ballistic in mono4 and used an envelope follower with denorm prevention this should do the job pretty well..
i also added one which is drawnwith ruby, in fact its just a rectangle where the hight is related to the value..

Thanks a lot guys.
New ballistics working fine now. These are definitely faster than my original LEDs. they're both very similar in performance but the rectangle seems to be slightly better.
Unless tester could beat this without ruby I'm gonna stick with it!

[tester]

@ tester: telling somebody "eliminate all ruby stuff from your schematic" as first thing just supports "be aware of evil ruby" and nothing else.. its the same like i would say "eliminate all your assembler stuff because i don`t know about it and it leaves much space for bugs, better don`t touch it..." but i dont want to fire a ruby discussion here in fathers thread...

It's a matter of methodical approach, not "ruby specific".