Ruby Class help

[tulamide]

But whatever "course" I started it always ended with not connecting the dots.

When I think back to first learning OOP, I'm always reminded of the old joke: (Visitor) "Excuse me, could you tell me the way into town?" - (Local Person) "Oooh; if I was going there, I wouldn't start from here!". The familiar-looking syntax made it hard for me to see that OOP is a different way even to think about code in the abstract sense. I made it hard for Ruby to be my friend because I wanted to be the same control-freak micro-manager that ASM had taught me to be!

Haha! I remember when a mysterious thing called "Python 0.9b" was passed around mailboxes, and everyone thought "wth?" I couldn't create even the tiniest working code, not because of that obscure language, but because of my lack of understanding!
Without reference to the joke, I think as a guy who started his journey with "10 PRINT 'HALLO' 20 GOTO 10" and getting used to commands like PEEK and POKE, I've come a long, long way.

[RJHollins]

But whatever "course" I started it always ended with not connecting the dots.

When I think back to first learning OOP, I'm always reminded of the old joke: (Visitor) "Excuse me, could you tell me the way into town?" - (Local Person) "Oooh; if I was going there, I wouldn't start from here!". The familiar-looking syntax made it hard for me to see that OOP is a different way even to think about code in the abstract sense. I made it hard for Ruby to be my friend because I wanted to be the same control-freak micro-manager that ASM had taught me to be!

Haha! I remember when a mysterious thing called "Python 0.9b" was passed around mailboxes, and everyone thought "wth?" I couldn't create even the tiniest working code, not because of that obscure language, but because of my lack of understanding!
Without reference to the joke, I think as a guy who started his journey with "10 PRINT 'HALLO' 20 GOTO 10" and getting used to commands like PEEK and POKE, I've come a long, long way.

But ya know ... it kinda made me happy to hear you say this.

Or should I say .... it encourages me to hear you say that.

[and I do remember that time playing with my Commadore SX-64, and then later with GFA-Basic on the Atari-ST].

Those were the daze I could put the time in [as a self taught hobbyist] --- no Internet ... just magazines, books.

Was never really great at it, but wow, did it pull me in deep ... and I actually made useful Programs.

Like most here, I do hope for the day FlowStone evolves to the next version.

Just hope you Guys are still here !!!

Wish these Special Tutorials, Instruction, Learning session could be placed in some form of Sticky that would be easily available and expand over time.

You Guys are invaluable to this Forum. !!

[adamszabo]

So I have been experimenting, and what I would like to achieve is to have the ability to change a variable inside a class from the outside, which then sends that to multiple RubyEdits. The only way I found is to use global variables but that is quite dangerous, is there a more elegant way? Is there a "self" method or something? I havent found any answers online

Thank you!

[tulamide]

So I have been experimenting, and what I would like to achieve is to have the ability to change a variable inside a class from the outside, which then sends that to multiple RubyEdits. The only way I found is to use global variables but that is quite dangerous, is there a more elegant way? Is there a "self" method or something? I havent found any answers online

Thank you!

A class definition exists for all RubyEdits. A class instance however, only exists for the specific RubyEdit. You want all instances of a class to react to one change to a class definition? Or to a change in an instance (like setting the name "john" in one instance in RubyEdit A, and all instances in RubyEdit A and all instances in RubyEdit B update their name to "john"? Can you lay out a use case for what you try?

What you used there is not a global variable. You used a class variable. (@var = class instance variable, @@var = class variable). In this case a class variable that belongs to the RubyEdit class (not instance). That's only dangerous if you are not taking care of proper naming.

[adamszabo]

Ah I see, what I meant was the @@ is a class variable. The problem with that is if I change that value, it will be seen all across the ruby, so if I open multiple VST plugins in a host for example, then all the instanced will change. Thats is not really what I am after. What I would like is your first example. So I will have this RubyEdit in multiple locations copied:

Code: Select all

man = Person.new
man.name

Sure, I could connect a string input for each of them and send "John" to all, but since they will anyway get the same name, it would be more elegant to change it "inside" the class Person itself, however for that RubyEdit, I would like to get that name from an outside string like in the picture.

[tulamide]

Since you didn't provide us with a use case example, it is difficult to answer. I'm honestly thinking that you are possibly on a wrong path. There could be a simpler way, depending on the use case. Just to emphasize my confusion: I don't quite see, why you would use several instances, when they all keep the same value. Therefore, just one instance is needed, "sent" to a RubyValue output, accessible for all. It wouldn't even create all the copies, as RubyValue would just reference the original instance.

With more information on what you're trying to achieve, it would be easier to give you a satisfying answer.

[adamszabo]

You are right, I shall be more specific. Here is a very basic example. I have a Square class in a RubyEdit which draws a rectangle.

Then I have other RubyEdits which call that class and draw the actual rectangle. Lets imagine that I will have many of these RubyEdits all over the schematic. I would like to change the color of them to the same color at the same time. Instead of sending the color individually to all of them, it would be neat to change it once in the class itself and all the square colors change. So basically I want to bring a value into the main RubyEdit class from the outside being able to change it any time (I connected a red color to it how I imagine it to work). I could write the color value directly in the class, but then I cant change it dynamically.

Is this possible somehow?

[tulamide]

Is this possible somehow?

Not as you are trying to do it. Not withhout affecting all other plugin instances.

The reason it wouldn't work is that you try to use a class in a way, it is not intended to be used. The first step when working with classes is to internalize its function and behavior.

Code: Select all

class Square
end

A class definition is not a class, as you understand that term. It's a definition. It defines the elements of which the class will be constructed. It serves as a template, if I may bring this comparison up. A template is not made for dynamic changes, on the contrary, it is made to have a set of fixed elements, that you intend to use over and over again, with differing content.

Code: Select all

@square = Square.new

A class instantiation is the copying of a template into its own place, ready for you to fill the fixed elements with your own content. Just like in Word, where you start from a template, fill the frames with text, and NEED to save it as a new document, not as the template you started from. A class instance is the dynamic part of a class. Whatever you want to change at runtime, has to be done in this instance. (We leave out singletons and other methods of directly accessing a class definition, as that is not helpful for any of your tasks, and leads to possibly compromised code. In short, don't, if not absolutely needed)

Your example is like I imagined. I asked you two times, which means I see it as given, that this example is really what you try to achieve. My example is built on this premise, so please don't answer with something like "well, actually it's a little bit different than I explained, because..." My head will explode then

In my example you can clearly see that you only need one instance. You see how it is defined, instantiated and used. But, I kept it at the minimum. For use in a plugin, you should also send a "redraw" event, which here isn't needed, because Flowstone's environment updates the whole visible area, which includes all 3 views.

[adamszabo]

Thanks Tom for the explanation and example, that is an interesting solution!

Ok, next question, I am a bit still confused about how classes use some info. Here is another basic example. I have two Arc classes, but one of them gets and uses the pen from an existing RubyEdit, the other one has the pen inside the Arc class but only gets the color for each instance. Which is more efficient/better? The way I understand it is, in the first example I create a pen and ruby stores it in the memory. Then I create two arcs and they each only reference the pen. In the second example when the arcs are created ruby creates new pens for them since they are in the class, using twice the memory. Is this correct or it works a totally different way?

[tulamide]

Unfortunately they are both not the best solution.

The colour prim is connected to a RubyEdit, which means that it creates a color class instance, whenever you change the color in the prim (and when you first connect it to the input)

With Arc1 you create a new color class instance and a new pen class instance, whenever the color is changed.
With Arc2 you create a new color class instance whenever the color is changed and you create a new pen class instance everytime the view needs to be drawn.

From those two, the better option is Arc1.

But the most efficient version (in this specific case) is Arc3

Code: Select all

class Arc3
  def initialize
    @pen = Pen.new(0, 1.0175)
  end
 
  def draw_arc(view, col)
    ##let's re-use @pen, instead of creating a new one each time the draw method is called##
    @pen.setColor(col)
    view.drawArc(@pen, [3,3,5,5], 135, 270)
  end
end

Given that you connect a view and a colour prim to the RubyEdit, this will create a new pen class instance only when you create a new Arc3 class instance and a new color class instance whenever the color is changed.

This is more efficient not because it saves memory (there's loads of memory in modern PCs), but because it relieves the GC. The garbage collector has to free memory from unused instances. When you create a new one in the draw method, you might create like 30 instances per second, which all are immediately garbage after just one use. At one point the GC has to kick in, and that takes some time (up to half a second). The less instances are marked for the GC, the easier it is to free their memory at times, where nothing much happens, instead of while you're moving your knob, for example. Arc1 was on the right path, but Arc3 also saves the creation of a pen instance on every color change.