Comparing RUBY vs Primitives - code efficiency ?

[RJHollins]

Hi Everyone,

Just a general question/observation comparing RUBY vs Primitives related to graphics.

I've just started working with some of the RUBY graphic commands, and am noticing the so few amount of coding, along with only a few Primitives that are used to make, say, a background GUI panel.

I'm comparing to my SM modules ... when I look inside the SM modules, I see way more primitives inside.

I know this is a 'relative' comparison/observation ...

I guess my question would be ... efficiency. Not only 'speed-wise', but thinking about file size, memory usage, etc.

Maybe I should post a side by side example ... but I just converted a bit of GUI using RUBY. Even the RUBY version of the 'LABEL' module just seems light weight compared to the SM module.

So ... would it be a waste of time, nothing to gain, if I proceeded to convert things like this to RUBY from SM ??

I'm only looking at the 'obvious' code ... I've no insight if that would have any impact on the exported VST or EXE.

Again ... curious to hear from the 'Experts' on this.

Thanks!

[tester]

Plus - it is not certain what will happen (if terms of performance) if you will have many many many ruby instances (see my question few posts around).

[RJHollins]

Plus - it is not certain what will happen (if terms of performance) if you will have many many many ruby instances (see my question few posts around).

Hello Tester,

oh yes, I've been following your post with interest ! Just wish I could offer an experienced comment for you on any of the multitude of project you have going


As for many, many RUBY instances ... well, that is another aspect I have no experience on.

However, just my recent changing over parts of my schematic to RUBY has yielded identical results as the all primitive use ... but at a fraction of the parts!

One benefit I see ... the ease of reading through my schematic section. As I looked deeper into the SM modules, I see some heavily populated modules, with several wireless connects, all kinds of switching and calculations.

I think this could be the situation that some of the SM modules I used had many more options than I needed for a specific function. I would figure that this would all add up, particularly using many of these SM modules.

Again ... I'm just speculating as to the efficiency. Look forward to more replies!

Thanks

[TrojakEW]

I have tried to create complex preset randomization with only primitives. In the middle of work I just stop because it was too complex and slow. Then I start looking for another way and I started to make it using ruby. Generating even a large array of numbers within any given range is not just easier but also much faster. So if you are going to work with arrays then I definitely recommend ruby.

[VPDannyMan]

Agreed, Ruby is a million times better at arrays, and in general just better at everything else than the prims. Its just too bad with its implementation, I find it unacceptable to use. So I am stuck using SM still... I wish they would get that fixed because ruby makes things a million times easier..

[RJHollins]

Agreed, Ruby is a million times better at arrays, and in general just better at everything else than the prims. Its just too bad with its implementation, I find it unacceptable to use. So I am stuck using SM still... I wish they would get that fixed because ruby makes things a million times easier..

Hi VPDannyMan,

Thanks for reply, but I don't understand your 'implementation is unacceptable to use' ??

[VPDannyMan]

That thread explains it from start to finish and where the devs are at with it currently.
http://www.dsprobotics.com/support/viewtopic.php?f=2&t=941&start=40

[RJHollins]

Hi VPDanny ...

Well ... I really did read the thread you posted ... understanding the issues is quite another thing though

Coming from the land of 'Novice FS Programmer' [and I use the term Programmer in its' most generic form], reading the provided thread, I was quickly reminded of my 'Novice' status.

What I was able to glean were key words regarding multiple VST's and a potential RUBY conflict.

I may have this totally confused, but to the lay person, is there a problem for a user running multiple instances [VST] of the same plugin ???

Any clarification would be appreciated.

Sincerely

[VPDannyMan]

Not that I'm aware of..
What that thread says (among other things) is this..
If you decide that you (and most people will not do this), if you decide that you want to have a custom Ruby DLL that contains your own Ruby commands that are specific to your plugin, then there is no guarantee that your custom Ruby DLL will be available. So since the custom commands are not available, your plugin will crash. You can open the Ruby code and customize it any way you want, you can add or remove commands at will. As I say however, most people will not do that. That does not make it impossible though, and as such you can no longer guarantee your plugin will run.

So, here's the scenario.. This has been said before in that thread but I'll try and explain it better here..
You have two plugins. Plugin A has a custom Ruby DLL that has Ruby commands deleted and new Ruby Commands added, Plugin B uses the normal FS Ruby DLL.
The user loads plugin A in their recording software, The custom Ruby DLL is automatically copied out of Plugin A and placed in the App data(or whatever) folder. Remember now, Plugin A uses a custom ruby DLL file.

The user now loads Plugin B and it crashes! This is because Plugin A already copied the Ruby DLL and that copy has missing commands that Plugin B needs. Since the DLL is already open being used from Plugin A, windows locks it and will not allow the new copy to be made for Plugin B.

This "automatically copy a DLL to the App data Folder" is a highly irregular way of doing things. Sure applications make and copy data files all the time, but not DLL, or EXE files. Those are executable files and should be already installed and available before an application is run. (Windows development best practices, 1995 or so)

As I said earlier, I'm just not comfortable with this implementation of it. I think its a fantastic addition, but it needs to be implemented correctly, according to proper guidelines.

We have not even got into talking about the shared instance. That is a whole other set of potential problems that should be addressed. In a nutshell, the problem with this is that, say for example I have a variable called A, and you have a variable called X, in my plugin X should be equal to 5, but your plugin uses X as a counter so the value of X is always counting up. Now when my plugin needs to know the value of X it does not get the number it needed and crashes because your plugin changed the Value of X..

I don't know that statically linking Ruby will solve this issue either? Its a complex problem and will not be repaired overnight, that's for sure..

[Drnkhobo]

I suppose this wouldn't be an issue if you have multiple plugins with multiple Ruby instances that just do simple operations & not definition and usage of custom/stock classes, modules ect. . ?

What I mean is that if I have 6 plugins each using Ruby for simple handling of arrays (for example) then It wouldn't matter until you use a plugin which overwrites your Ruby DLL (and changes Array class or other dependent)

If we look at it, differently compiled Ruby DLL's SHOULD be alright if we adhere to good namespace (TROG TROG TROG) and intelligent deployment of these custom objects. - I say should be. . .

I still feel however, DSPR need to work on it & am happy to wait until its not really a problem anymore(shared instance). Ruby's power is just too sweet to let it go!