Callbacks in Ruby?

[RJHollins]

how I wish I could understand everything you Guys are talking about

But the mention of GLOBAL variable in RUBY has surfaced before, and there were cautions expressed ...

A simple question [from one understanding 'simple' ... me ] ... ? What happens if this GLOBAL concept is used in a VST plugin .... and you end up using more than one instance ??

I understand that the possiblity of 2 separate programmers naming identical GLOBAL variable is not totally impossible [prevented through careful naming] ...

I've other questions ... but I prefer to limit them right now to mask my ignorance/newbie status

[Exo]

I like your last implementation tulamide very simple and to the point, only problem I have is the use of a global variable, this of course can be problematic.

Why? You are the only one maintaining the code, so I don't see a problem. Also, you can make sure it is not used elsewhere by giving it a proper name. Also (yeah I'm totally jealous ), Tronic makes use of quite a few global ones. Besides Flowstone's intern_this global, the class variables (starting with @@) are also semi-global, as they are not protected in any way and inherit above in the hierarchy.

Well obviously in this context it is appropriate. But I believe global variables should be avoided and only used as a last resort because of possible name conflicts.

I have to think about this because I will be sharing my work. I know that yours was a quick example but $instance is a very bad name for a global variable. Most programmers name things the same or very similar so with global variables we have to take extra care to ensure nobody else will ever come up with the same name.

By the way global variables don't even exist in Java. In Java everything has to live inside a class and the class has to be inside a "package" which is basically a namespace. When we do have a name clash the can easily be resolved by selecting the correct package.

I like Tronics example because even though it uses the $intern_this global variable it doesn't declare any new ones.

Yes @@ is kind of global but it only exists within the scope of the class, which makes name clashes less likely. This is how globals are done in Java where we use the keyword "static" instead of @@.


So (this is mostly aimed at newbies reading this) global variables should be avoided unless there is clearly no other way to achieve what you want.
When they are used I think a best practise is to prepend the variable with a descriptive and unique name such as..... $callback_instance or even safer could be $exo_callback_instance.

Also I would advice newbies against using this callback system in place of wireless links, only uses it in extreme cases where the benefits are out weighting the costs of your schematic being harder to understand. This method of callbacks has the potential to produce serious spaghetti code! So only use it where absolutely necessary.

[tulamide]

But I believe global variables should be avoided and only used as a last resort because of possible name conflicts.

I agree with you on this one. Also, I know where you're heading to, and I support newbies to lead to hassle free oop. It's just that one thing I can't agree with - that it's ok if someone else declares globals that you then make use of, but not ok if you declare them yourself. Malc is a very seasoned programmer - still he makes use of globals... (and through the nature of Ruby, there are several places where globals just can't be avoided. Even Tronics more general solution wouldn't work without globals.)

But I repeat, especially for newbies, your sentence: "global variables should be avoided and only used as a last resort because of possible name conflicts."

[tulamide]

how I wish I could understand everything you Guys are talking about

But the mention of GLOBAL variable in RUBY has surfaced before, and there were cautions expressed ...

A simple question [from one understanding 'simple' ... me ] ... ? What happens if this GLOBAL concept is used in a VST plugin .... and you end up using more than one instance ??

I understand that the possiblity of 2 separate programmers naming identical GLOBAL variable is not totally impossible [prevented through careful naming] ...

I've other questions ... but I prefer to limit them right now to mask my ignorance/newbie status

You should follow Exo's advice and avoid globals as much as possible. But to your question: VST's are encapsulated executables, each one lives on its own. There is no sharing of variables or constants between them.

[MyCo]

Just in case there are not enough already working versions

[MyCo]

VST's are encapsulated executables, each one lives on its own. There is no sharing of variables or constants between them.

This is actually not true. They share the same code in memory (unless you use a VST-Wrapper). Til now there is only one Ruby interpreter running in the VST host for all FS-VSTs. You can share data between plugins by using Ruby, I've used that for some freaky global settings exchanges.
I've attached a simple test schematic, just create the VST from it, and load it multiple times in the host, and turn the knob in one of them.

[tulamide]

You optimized that version, MyCo! Perfect. That's how I'd use it now!

This is actually not true. They share the same code in memory (unless you use a VST-Wrapper). Til now there is only one Ruby interpreter running in the VST host for all FS-VSTs. You can share data between plugins by using Ruby, I've used that for some freaky global settings exchanges.
I've attached a simple test schematic, just create the VST from it, and load it multiple times in the host, and turn the knob in one of them.

OMG, I wasn't aware of that. In that case, all people reading this thread, ignore my passionate globals pleas! Under that circumstance they should indeed only be used if you are experienced and know exactly what you do! My bad!

[MyCo]

I'm a bit concerned though... When I remember correctly, classes are shared between the plugins as well

See Attachment

[tulamide]

I'm a bit concerned though... When I remember correctly, classes are shared between the plugins as well

I'm afraid you're right. I knew about just one ruby instance (note: ruby instance, not ruby edit instance) from the manual, but I really thought it meant Flowstone's edittime. But, since globals are shared, there is only one ruby instance at runtime, too! That means, we have to be very, very careful and probably avoid class variables also.

EDIT: Just tried the example, which additionly proves me right. We need to avoid class variables when sharing ruby code modules here. (Luckily the sprite class doesn't use them )

[Exo]

Just in case there are not enough already working versions

Thanks MyCo, I will check this out later.