@tulamideYes, you're right; my bad!
I was forgetting about the change to the Ruby interpreter linking for plugins, which does indeed disable the ability to use C++ Ruby extensions in plugins (though plain Ruby code will still "require" OK.)
Spogg wrote:This is presumably because the Ruby sample & hold is interpreted whereas the green prim is hard coded in something fast…?
In part, yes; though the Ruby interpreter does translate the code text into "byte-codes" so that the code doesn't need to be parsed every time it's used. Ruby also deals only with "objects", which is a very different way to store values than green uses. For example, a green float is just a 32/64-bit region of memory, which can simply be overwritten when a value changes. OTOH, in Ruby, a new Float object has to be created for each new value, and whenever Ruby starts to run out of space for new objects, the garbage collector has to scan the objects to see which ones can be thrown away to make space. So there can be quite a bit of overhead for all of this copying/converting between green values and Ruby objects, especially for "containers" such as long Strings or Arrays. Green and Ruby also run in different threads AFAIK, so there's likely some overhead for synchronising the threads, too.
Ruby "Value" links can help to some extent - they pass just a reference to an existing object rather than creating a copy. However, this has to be used with care, as any change to the object will be visible everywhere else that it's used, even in places "earlier" in the chain of links.
OTOH, the many, many built-in methods which Ruby objects have are all coded in C++ behind the scenes. So complex operations on "containers" of data can be very efficient if you can use the built-in methods to do what you need. And, of course, Ruby has all sorts of goodies that would be extremely difficult to emulate in green!