Global Ruby variables are shared through all VST instances?!

[ortseam]

Hi!

Found one more unpleasant thing with VSTs using Ruby code. Seems that any global Ruby variable (the one that begins with '$' sign) is shared among ALL instances of VST plug that use it, which are loaded in DAW. So the same parameters of all instances become synchronized. If this can not be avoided, the use of the global Ruby vars becomes useless at all, IMHO (except some very special cases).

UPD: The User Manual confirms my observation: "...if you declare global
variables or classes in one schematic then they will be visible in the 'Ruby space' of the other
schematic" (So strange as to me )

[Nubeat7]

thats interesting, me i never use this "$" global variables but thats why they are called global or?

i normally make one module called globals and send them with wireless links so i can call them whereever i want in my app, maybe you also could do a ruby module and define your constants there, this should work per instance i would expect

if you only want to use the $ you should make a "unique" name like your "appname_varname" to minimize the chance of the same var name in other apps

[Nubeat7]

UPD: The User Manual confirms my observation: "...if you declare global
variables or classes in one schematic then they will be visible in the 'Ruby space' of the other
schematic" (So strange as to me )

but wasnt this fixed with vst plugins in the last update! it shouldnt be shared as vst because every instance of a vst plugin runs its own interpreter!

[ortseam]

i normally make one module called globals and send them with wireless links so i can call them whereever i want in my app,

Thanks for an idea but I'd like to have a possibility to easily synchronize different GUI parts realized in separate Ruby components (such as EQ parameter button and according interactive point at the graph). In this case there is no master-slave relationships which can be built using wireless connection. What is needed is namely synchronization (i move button - the point is moved, I move point - the button is moved). This could be easily realized by global vars and i see no obvious alternative way.

[Nubeat7]

should work without global vars, just set the values from one with the other
somethong like this:

sychronized knobs.fsm

(119.96 KiB) Downloaded 857 times

in general i think that global variables are mostly used as constants..

but anyways have you tested this behavior, because classes are not shared between different vsts so i think that also globals shouldn`t, or does more instances of one plug in share one interpreter? then it also would be logical that the global variable is global for all instances of the plugin

watch version history 3.03

http://www.dsprobotics.com/versions.html

[ortseam]

Thanks for the .fsm. Yes, this schematic does what I want. Maybe with the use of Ruby it could be done even more simple. But the solution still would be more complex then when using global vars, because in any case you must set inputs, outputs and wires which would result in rather entangled structure having tens of groups with more then 2 syncing objects in each.

does more instances of one plug in share one interpreter?

Seems like that. If I make the renamed copy of the same VST plug it works separately from the original one. But the instances of the same plug get synchronized ((

UPD: same problem with class variables (beginning with "@@")

[Nubeat7]

thanks for testing this out ortseam,

but does this mean that we cannot use classes? or do we have to be careful how to write classes?

i never wrote some class so i dont know a lot of it, do we need to take care of how to use private, public and protected variables and methodes?

[ortseam]

but does this mean that we cannot use classes? or do we have to be careful how to write classes?

Using classes generally shouldn't cause any problems. Several instances of the same VST plug will define the same class in the same way several times in their common "ruby space" that wouldn't change anything. But class variables (the ones that is dynamically shared among all instances of the same class) maybe shouldn't be used because they become common for all plugin instances.

[RJHollins]

somewhere .... there is discussion of this by TROG.

I don't recall the exact thread title, but I think it had to do with one of his early RUBY examples [a rather involved dissertation that glazed my eyes over

Although I tend to work at a novice level, it would be good to hear from the experts ... also, some search on 'Global variables' may hit info.

THANKS for what's been posted and tested already ...

[trogluddite]

First thing - thanks to ortseam for your observations about multiple instances of the SAME plugin - I hadn't notice that. Knowing the nature of the beast is the most important step of avoiding any problems.

So is this a problem? Depends what you want to do, I suppose, but global variables are generally treated as a last resort even in general Ruby programming - if the value you want to store really is "global" in nature then there should be few issues with scope.
However, with class variables, it could be more of a problem - they're very often used to keep a tally of the number of objects of the class (e.g. how many notes am I playing), or a store for "most recent" values - things that really need 'sand-boxing' between plugin instances.
In cases like this, the only real choice is to use internal links to route the "unique" objects around, and ensure their scope.
It can also be a problem where a class or module has only class methods and is effectively used to provide a "single instance" object.

but does this mean that we cannot use classes?

We sure can - more easily since the changes made with v3.0.3.
Apart from a few corner cases, most things can be written without the need for class variables - so most of the time we are using classes just to give us some nice object instances to play with.
The big problem before was that if ANY two plugin defined the same class, the first once would get all of its methods re-defined by the second - so if the two classes were defined differently, plugin one would instantly break.
Those days are thankfully gone, and in the case of two identical plugins, the classes would share the same definition, and redefining a class does not destroy any existing instances. That is assuming that no class variables have been used (unless sharing is your intention), and that the class does not "self-modify" its own code by dynamically re-defining methods.

do we have to be careful how to write classes?

Oh yes! But maybe not for the reasons that you think.
The two problems that IMHO are much more common are...

1 - Name Space
Say you make a new class called "MyObject" and use it tucked away inside one of your modules. You then take a fancy to something tasty from the forum - download it, put it in your schematic, and... BROKEN.
Without you knowing it, your new download has some Ruby in it - and the developer decided to use their own custom class called "MyObject" - which just wrote over your version. As many of us share the same obsessions with DSP, and use the same jargon, this is probably not as unlikely as we would like to think.
This is easily got around using name-spaces (though I often forget myself!). Simply define your class nested inside a 'module'

Code: Select all

module Trog
  class MyObject
   #CODE#
  end
end

To use the class now, it must be prefixed with the module name, separated by two colons...

Code: Select all

@myObject = Trog::MyObject.new

Of course, clashes can still happen, but by choosing what is hopefully a unique module name (our forum name maybe?), we can avoid treading on each others toes.

2 - Execution order
You can't use a class until it's been defined, obviously. The order of initialising modules has strict rules, but they can be hard to follow in practice - after a bit of editing it is very easy to lose track.
The safest way to deal with this is to remember that ALL "init" methods are parsed before any events can happen. Arranging the code so that custom classes don't need to be called during "init" or "loadState" ensures that they will definitely be available. If you do need to initialize a value, a quick and easy way to do it in the main code is...

Code: Select all

@newObject ||= Trog::MyObject

"||=" is a funny syntax, but in practice it means - IF this variables already has a value THEN keep it ELSE do the '=' assignment. So you get a new value the first time around, and then after that it does not get touched.
You still need to take care if there are dependencies between several classes (classA uses objects from classB) - to be sure, the easiest thing is to define them all in the same RubyEdit (an external code editor is useful for this - the FS one gets very slow after a few hundred lines).

...rather involved dissertation that glazed my eyes over

He he, sorry. done it again Just be thankful I don't live close enough to corner you in a bar and chew your ear off!