DSP Robotics Support

Is there any way for a module to access its own name or (probably more useful) the name of its parent module?

I don’t believe there’s any official way to do it.
I think it would involve a software hack of considerable proportions, if it were possible at all.

Just out of interest…why?

Cheers

Spogg

Hi!

There is something (I hope i got you correct)
It is a quite old post so i needed some time to find it:
viewtopic.php?f=3&t=602

Ruby Code:

Code: Select all

self.parent.caption

Example attached in this post.
But: I found no way to get the parent's parent module name so that you could make a module to get the including module name...

Maybe there is a solution?...

Regards!

The Ruby that chackl mentioned is as much access to the schematic "tree" that we have, unfortunately, besides the "root node" of the schematic (it's file/folder location); and it is strictly Ruby-only. The 'parent' method has always struck me as odd; it does rather look as if access to the whole tree might have been intended at one time, but it goes back no further than the module directly enclosing the calling RubyEdit.

Aside from that, the only other 'reflection' that I've discovered is:
- If a RubyEdit is within a toolbox module (the thumbnails are all "live" mini-schematics), the 'time' method returns nil.
- For a quick way to check whether a RubyEdit is in an export or the FlowStone application, you can use "defined?(CodeRay)" (CodeRay is a Ruby module which handles the code syntax-colouring, so isn't needed in exports).

As Hetty would say, "Bugger."

I kind of hoped there was something in Ruby that could walk back up the line, and that might be useful for what I have in mind. (Haven't thought the whole thing through yet, just checking feasibility.)

Of course, best case would be full access to the underlying FS object model, similar to the way VBA/JS/whatever has access to the entire document tree in COM-enabled apps like Excel or CorelDraw. In those apps, user-written macros can walk the entire document hierarchy, manipulating individual components. Hey, I can dream, right?

deraudrl wrote:Hey, I can dream, right?

Oh, yes - you're not the only one who dreams about such things. My first taste of Ruby was writing plugins for the SketchUp 3D-modeller back when it was still a Google thing, where besides every last node of the models, you could modify and add your own menus, toolbars, file export formatters, etc. to the application itself. And as I found just recently, having just acquired a new PC, I can barely use Notepad++ any more without installing a folder full of dozens of scripts and macro/menu/key-binding definitions; I forget which stuff came built in and which I've bolted on over the years!

trogluddite wrote:My first taste of Ruby was writing plugins for the SketchUp 3D-modeller...

I knew I'd encountered Ruby before, just couldn't remember where.

I built a CNC router back in 2012...looked at SketchUp briefly and bounced hard off it. The Vectric apps I ended up using had Lua as their macro language, and I think I've had Ruby and Lua confused ever since.

ahh ... SketchUp.

Got my introduction when beginning the design/layout phase for my Mastering Control Room.

To this day, I still play around with some Architectural designs/ideas every so often. One of the latest was for
a proposed outdoor deck that helped visualize the project. Probably to be built early this Spring

Also have the VRAY renderer

My younger brother is a Contractor, and a few times He's asked for a visualization for a Client. Kinda fun doing these
things ... a nice little diversion from my Audio work.

Spogg wrote:Just out of interest…why?

Side effect of my previous query about separating GUI and processing, which got some added incentive from BobF's thread about GUI's. Mostly I was looking for a cleaner way to handle the baroque intertwining of the stock control widgets, presets, and MIDI CC, which gives me a headache whenever I drill down into what looks to be a simple knob or slider.

A related question involves exactly what things propagate when one of a set of synced modules gets modified: does the syncing only reflect the components/connections or does it include names/properties/values etc? E.g. if I rename or change the value of a string primitive inside one of a set of synced modules, does it change in all of them? The manual, as is its wont, is ambiguous in this area.

(I suppose I could just embrace the suck and stop looking under the hood of things that are known to work properly, but my mind doesn't work that way.)

I don’t have the definitive answer but I do know that anything tagged as a Property (for viewing in the P view) will NOT be synchronised. Also the parent view size for any synced module won’t copy to the others. The synced modules name can also be changed for each module. So you could have Osc 1, Osc 2 etc but all still synced.

I think pretty much everything else will be synced, based on my experience.

Cheers

Spogg