Ruby: Unexpected Behavior

[tulamide]

I'm not sure if it is only happening to me, so please download the schematic and do the following test:

1) After loading click and drag on the box to change the value in the range [0, 255]. Alternatively, doubleclick to enter a value.

2) With the value changed, click on 'P' to change to the properties view. If you now see the very same box with the newly entered value, try to change the value in the same way as described in 1).

3) If you can change the value, no matter which view you are on, you experience the same as I did. All others can stop now.

4) Go inside the module.

5) Go inside the module named "odd behavior"

6) Look at the code in the RubyEdit named "the ruby allpass" (name is just a joke, not its intended function) and read the yellow comment box.

7) Have a convincing explanation and report it here

Thanks!

p.s. Since Nubeat found out about the view issue, I wouldn't expect it to work at all. So that issue can't be the reason.

[KG_is_back]

Just tipe "watch @ins" somewhere in that module and everything becomes clear. View connectors are not handled via rubyedit input-output system. They also do not carry triggers - they carry redraws. When ruby component has an view output and the output is redrawed, it is simply drawn to all view connectors that are connected to it.

I think they should add a method "v.drawView(outputConnector)" which will draw specified view output to current input.

[tulamide]

Thanks, KG! That behavior doesn't make much sense, and is also inconsistent, but I understand your explanation. The thing is, green is also trigger-based, still the same thing done with the selector prim instead of Ruby works. That's why I say it's inconsistent.

Anyhow, now I see what is happening, and will look for another solution. Thanks again

[KG_is_back]

Be aware that selector does quite different things under the hood, depending on what is connected to it.

With green:
selector specifies which input will propagate its triggers (and value) forward.

With streams:
selector recompiles the stream part of the schematic, producing brand new machine code, with specified link. NOTE: When recompile happens, flowstone automatically thrashes the "dead ends" for optimisation, which effectively lets you bypass certain parts of stream schematic. Selector makes all unselected inputs to "dead end", creating on/off behaviour (this was possibly unintentional when it was introduced).

With views (based on this topic):
Switches which input can pass its redraw triggers (and a view instance) forward for drawing.


It is quite mysterious, why your ruby example does not work. It seems that green and ruby triggers are handled by "event" method and view redraws are handled by "draw" method. The view instances in the connectors do not end up in @ins array. If fact, if I recall correctly, every method that does anything with views (redraw(connectorIndex) or getViewSize(connectorIndex) ) always only requests connector reference, rather then the view instance directly. This all suggests that with view processing, there is something quite different happening under the hood and there is a reason why things are the way they are. Let's contact DSPR support to give us some info...

[MyCo]

Views cannot be handled like green or ruby connectors because they operate backwards. That means an input is actually an output and an output is actually an input. That's why you use multiplexers on views, rather than selectors.

[tulamide]

Views cannot be handled like green or ruby connectors because they operate backwards. That means an input is actually an output and an output is actually an input. That's why you use multiplexers on views, rather than selectors.

While your explanation about views are correct, it is not correct that they can't be handled like green (see Selector). That's why I insist of inconsistency. Either both should not work with views, or both should work with views.

Here's another little thing: In the attached schematic, connect the view with the view input on the RubyEdit. After that connect the trigger with the view input. They do carry triggers, and they do carry them forward.

[Exo]

Just tipe "watch @ins" somewhere in that module and everything becomes clear. View connectors are not handled via rubyedit input-output system. They also do not carry triggers - they carry redraws. When ruby component has an view output and the output is redrawed, it is simply drawn to all view connectors that are connected to it.

I think they should add a method "v.drawView(outputConnector)" which will draw specified view output to current input.

There is...

Code: Select all

def view( i, v)
      if(i==0)
       #draw stuff to this connector
       end

       if(i==1)
        #draw stuff to this one
       end

end

..if my memory serves me correctly.

[tulamide]

Code: Select all

def view( i, v)
      if(i==0)
       #draw stuff to this connector
       end

       if(i==1)
        #draw stuff to this one
       end

end

..if my memory serves me correctly.

Are you sure, you're not confusing this with draw(i, v) ?

[Exo]

Code: Select all

def view( i, v)
      if(i==0)
       #draw stuff to this connector
       end

       if(i==1)
        #draw stuff to this one
       end

end

..if my memory serves me correctly.

Are you sure, you're not confusing this with draw(i, v) ?

Ha ha, yes I meant to write draw....

[KG_is_back]

What I meant is, you can't specify that view-output 1. should be visible in view input 4. (and not in all others) etc.