I'm starting to look at ofelia (excited about this, actually ).

But I find myself confused about what images and variables.

I managed to make my own patch doing:

• [ofSetup] -> [load ...( -> ofImage name
• [ofDraw] -> [ofImage name ...]

... and it draws the picture properly.

But I saw other examples using the images within an [ofelia f] object -- for example, the pointillism example loads the image into [ofImage $0-img] and then has [ofDraw] -> [ofRequire $0-img] -> ... -> [ofelia f; local img, m = a[1].image, a[2]; ...].

So I made [ofDraw] -> [ofRequire name] -> [ofelia f; ...] and now I don't know what to do.

name:draw(...) just throws a lot of nil reference errors into the console window... but clearly example files are able to use images within [ofelia f]...? If I have "require"d name, then I suppose "name" should be available somehow?

What is the relationship between the [ofRequire] objects and the implicit a argument?

Apologies if this is supposed to be obvious. I went looking for a tutorial series and I didn't find anything, so I'm attempting to infer first principles from examples. That can take you only so far.

Thanks,
hjh

[ofRequire] loads the «M» variable from an [ofelia] object.

Let' say you have this [ofelia function] with name $0-script:
ofelia function $0-script;
M.x = 10;

You could use [ofRequire $0-script] to get the «M» variable defined in the [ofelia] object with name $0-script.

If you do this:
[ofRequire $0-script]
↓
ofelia function $0-another-script;
print(a.x);

This will print «10». What could be confusing is that I now use the «a» variable to access the «M» variable. That's because every float, symbol, pointer is received in the [ofelia function] with the name «a». Like:

[100(
↓
ofelia function $0-another-script;
print(a);

This will print the number «100». Now, since [ofImage] is actually an [ofelia define] object which cointains the variable M.image, if you require this script you will be able to access the image in an [ofelia function] using a.image, like this:

[...]
↓
[ofImage $0-nice-image]

and then:

[ofRequire $0-nice-image]
↓
ofelia function;
print(a.image:getWidth())

This will print the width of the image.
Hope this helps!

@dom1817 Much appreciate the help. This won't make much sense until I play with it myself -- unfortunately I am extremely busy in the next few days and Friday will be my first opportunity to do anything with it. But I think I can piece it together based on this.

Thanks!
hjh

BTW I had a little time between a meeting and a concert yesterday, and I did get that working.

Next question is -- where to get more information about...

• [of***] objects, and
• of***() functions available for use within scripts.

That is... if I open the help patch for [ofImage], it takes me to ofelia-object-help.pd... which doesn't explain that [ofImage] is an [ofelia define] (how should I know that it isn't [ofelia function]?) or that it establishes M.image rather than some other name.

For the scripting functions, the pd help browser takes me to classesAndGlobalFunctions.txt, with a flat list of function names without arguments or any description of behavior. OK, I finally found https://github.com/openframeworks/openFrameworks/wiki/Tutorials,-Examples-and-Documentation (but I'm having problems accessing it at the moment).

So it's an interesting challenge... but I should also admit that my own SuperCollider extensions are rather badly documented, so I understand

hjh

Yes, I totally get what you mean. There are a lot of layers (Pd, Lua, OpenFrameworks) that are not very well documented and require a bit of guess work.

Actually until the previous version of Ofelia each [of] object had its own Lua code accessible, but now they are all embedded as objects (that's why you can't see the script but only the generic help file).

That said, when working with more complex stuff I find much easier to just write my own scripts in a code editor and load them using an [ofelia define] object. This way you have full control on what is happening and you just need to check the OpenFrameworks documentation to see the methods and properties of each object.

Then it probably depends on how comfortable you are with traditional coding

@dom1817 "Then it probably depends on how comfortable you are with traditional coding"

I am very comfortable with it -- more comfortable than I am with dataflows. (I'll stop short of issuing my standard rant on the subject. I'm sure you've all heard it all before anyway.)

Students at my college, not so much. I've got a few months to figure out the right balance between dataflow objects and code blocks...

hjh