RUBY: Droplist selector uses massive CPU when copied

[Spogg]

I know I’m probably going to end up being embarrassed by this, but I wonder if my Ruby friends could put me right on this and explain what I did wrong. Be gentle with me

The Ruby-based droplist selector, in the attached schematic, uses a massive amount of CPU when copied up to 3 times, but more copies don’t increase the CPU further.

So far I’ve been unable to figure out what part of the RubyEdit is causing the issue, but if I turn it off the CPU drops to zero. Deleting various sections of code doesn’t seem to help.

The details are inside the module, so if anyone can reproduce this and make me feel stupid I would be really grateful!

Cheers

Spogg

[Walter Sommerfeld]

Hi Spogg,

i think u have a loop in ur schematic:
have a look at the check input from the preset out...

def event i,v
if i == "check"
output 0, @check
output 2, @items[@check]
end
end

check it with a trigger counter...

[DaveyBoy]

On my machine I only have to select it and the CPU skyrockets, no need for me to copy/paste.

I reduced the module level and it's ok now.

I don't know the reason for this but I'm sure more knowledgeable people than I will chip in

The attachment SpoggBox.fsm is no longer available

Edit: Oops! forgot to include the preset module . . Sorry

Try This one:

SpoggBox.fsm

(1.71 KiB) Downloaded 960 times

[tulamide]

Can't really confirm the behaviour. On my PC, while copy-pasting it goes up to 5% but back to 0% right afterwards. However, you do have a serious problem. Maybe that's why others can confirm a heavy load:

I told time and time again, in any thread that even just remotely touches that topic, that you never do anything else in the draw method than drawing! I also pointed (not long ago, in our fb group, and you were one of the people that saw it, or at least gave a like ) to an old thread that describes a serious issue when using "output" from within the draw method. The result is a continuous loop, because output forces an internal redraw, which runs the draw method, which calls ouput, which forces an internal redraw, which runs the draw method, which calls output...you get the point.

But this doesn't look like something you have programmed. I hope you didn't grab it from some 5 year old schematic, because at that time people weren't aware of such issues, and I don't recommend using code from those times. But if I'm wrong and you ARE the original programmer, then I'm diasappointed that you didn't listen

[Spogg]

Thanks for looking into this you guys!

@Walter:
Yes I can see the loop. However if I disconnect the Check input and also delete the event code from the RubyEdit, I still get the high CPU with copying.

@DaveyBoy:
As presented, I can make copies without the CPU increasing noticeably. However, when I bring out the Index value, either from the Ruby pin or the Preset pin, and connect an Int prim external to the selector in order to display the selection, the copy issue returns!

So I still feel mystified.

Cheers

Spogg

[tulamide]

Bump, because we seem to have written parallel

[Spogg]

Can't really confirm the behaviour. On my PC, while copy-pasting it goes up to 5% but back to 0% right afterwards. However, you do have a serious problem.
...
But this doesn't look like something you have programmed. I hope you didn't grab it from some 5 year old schematic, because at that time people weren't aware of such issues, and I don't recommend using code from those times. But if I'm wrong and you ARE the original programmer, then I'm diasappointed that you didn't listen

Sorry tulamide, I made my last post while you were posting, so this is out of sequence.

Yes, I did simply adapt an old schematic, but that's no excuse for not noticing any issues. There's just SO much to remember and consider while trying to learn. I shall look into it again and see what I can come up with.

Cheers

Spogg

[tulamide]

I feel I should clarify that I am only referencing Ruby code from very old schematics. Prims are just fine, because if they had issues they were solved later on (mostly). But most Ruby issues are only touched now in the 64-bit development.

[nix]

0% cpu for 8 copies here
I have an ill computer though

[Spogg]

Thanks Nix.

I found that, on my PC anyway, it’s the connection to an Int or Float prim that starts the problem. So you have to copy the 2 modules together. Alternatively I can make 2 copies and then add the Int prim to the index and the cpu goes up to about 11% (Core i7). What I really don’t get is that more than 3 copies doesn’t increase the cpu load further. If you and tulamide didn’t get the same result and you both did copy the two connected modules then I also can’t explain that.

I’ve tried making changes to the RubyEdit, as per tulamide, and also tried trigger blocking and sample & hold on the output but no success yet.

I’ve eliminated the very high trigger count, due to the feedback loop by adding a Change prim, so the check value only gets passed from the preset index value when it actually changes. This has reduced the trigger count to 2 per operation, down from hundreds.

Also I’ve made a complete new copy of the RubyEdit and swapped it but no change, so I don’t think it’s a Ruby interpreter corruption of some sort.

In the scheme of things this really doesn’t matter since we have a perfectly good drop selector available. But I’ve become rather obsessed with the issue.

@tulamide: The output method is used in 2 situations: To give out the result when the droplist is closed and to give the output when the preset manager recalls and supplies a setting. Both situations write to the outputs, which is probably why I now get 2 triggers and not 1. I can’t really see that output is being used inside a draw method, so I think I haven’t really, truly, understood your point.

I’ve attached my latest variation with some notes inside.

Any further insights would be most welcome, and of course if I find a fix myself I’ll post it.

Cheers

Spogg