If I have an Ofelia script like below -- shouldn't the "setup" listener cause the M.setup function to run?

(The window is being created in a different [ofelia] object.)

Very confusing -- I'd assumed the listener meant "if the window isn't set up, then this will run when it's created; if it's already created, it will run it immediately." Otherwise why bother with a listener? You'd just ask something else for the window status.

hjh

if type(window) ~= "userdata" then;
  window = ofWindow();
end;
;
local canvas = ofCanvas(this);
local outlet = ofOutlet(this);
local pix = ofPixels();
local path;
M.shader = ofShader();
M.image = ofFbo();
M.useFbo = 1;
ofDisableArbTex();
;
-- initialize;
function M.new();
ofWindow.addListener("setup", this);
... some stuff that's not relevant...
end;
function M.setup();
print("trying to load shader", path);
M.shader:load(path);
end;
... more stuff...

@ddw_music you always need a reference to the main ofelia object, something like:

local a = require("$0-gameOfLife3d");

see ofelia-object-help.pd -> variables.

and do not use M as a reference, because it is the same as ofelia...

I think the setup listener is only triggered once the gl window is created, So, I do it this way (which might not be the best):

@60hz that is true, too.

you always need a reference to the main ofelia object...

Patches in the Fast Prototyping system look like this:

... containing five [ofelia] objects ([of.window] contains two).

"Keeping a reference to the main ofelia object" implies that there is a main object. But if the functionality is distributed among multiple ofelia objects, then you can no longer make that assumption.

and do not use M as a reference, because it is the same as ofelia

In my reading of the ofelia help patch and examples, using M. module variables seems to be entirely idiomatic.

The explicit intention here is to create multiple modules, each of which is responsible for part of the rendering chain. Since each M. is its own namespace, then this is the cleanest, simplest way to avoid name collisions between objects.

60hz:

I think the setup listener is only triggered once the gl window is created"

OK, I see. It strikes me as a bit awkward to have to call the init function explicitly and wait for a signal, but it wouldn't be the only awkward thing in Open Frameworks...

I'm moderately puzzled that calling methods in Lua is normally : but for the listener, it's ofWindow.addListener... oh well, don't overthink, just copy the example.

In any case, I finally worked it out... the problem was that my [of.shader] abstraction was crashing when loading the shader. My first guess was that I shouldn't load the shader until the window exists and the rendering chain is active, which sent me down this rabbit hole.

It turns out the real problem was a mistaken variable-name change in the fragment shader file. Once I corrected that, it went back to normal.

So it's OK now.

hjh

@ddw_music said:

I'm moderately puzzled that calling methods in Lua is normally : but for the listener, it's ofWindow.addListener... oh well, don't overthink, just copy the example.

Yes, it's always a source of mistake, I suggest you to take a look at this page with useful informations about class instances and more https://github.com/danomatika/ofxLua

@ddw_music my mistake. i was not thinking in the fast prototyping way...
maybe was irritated by:

if type(window) ~= "userdata" then;
  window = ofWindow();
end;
;

do you still need that if you have an [of.window] object?

and:

"It turns out the real problem was a mistaken variable-name change in the fragment shader file. Once I corrected that, it went back to normal."

i feel you, that is one of my most common errors...

@Jona said:

@ddw_music my mistake. i was not thinking in the fast prototyping way...
maybe was irritated by:

if type(window) ~= "userdata" then;
  window = ofWindow();
end;
;

do you still need that if you have an [of.window] object?

No -- good catch -- that was flailing around, trying to see if that was necessary for setup to run. I already removed it.

Also my mistake to post an isolated test script without being clear about the full context.

The M. variables have proven to be quite nice for passing image data down the chain -- every image source (image, multiimage, movie, videoin, fbo) stores its image in M.image, and then downstream objects receive the Pd ID for the ofelia object, require it, and access the image member (e.g. https://github.com/jamshark70/Ofelia-Fast-Prototyping/blob/topic/shader-support/abs/scripts/of-plane.lua#L41). If they're local image then they'd be inaccessible; if they're simply image then global collisions would break it.

hjh

@Jona said:

@ddw_music my mistake. i was not thinking in the fast prototyping way...
maybe was irritated by:

if type(window) ~= "userdata" then;
  window = ofWindow();
end;
;

do you still need that if you have an [of.window] object?

Modularity imply a new set of problems to solves since many duplicated object can be created, and this might result in a mess sometimes.
I did this to simply avoid to create many instances of of.window.
I think it should do something like "If no of.window instance exist yet, then create one."
I did the same for the camera.

I don't know if it's the best way to do, but it works as far as I can tell.