Suppose I wish to generate stripes with random widths.

I can, right now, manually create a series of [translateXYZ] --> [rectangle] objects and, with the right numbers, I do get stripes.

But maybe sometimes I need 3 really fat stripes and other times, 20 narrow ones. Or I want to fill up a total distance of 1.5 with randomly-sized stripes and random distances between them, so that the total number of stripes is not known in advance.

If every stripe must be an individual [rectangle], then I'm afraid I don't see how to do it.

High-level jiujitsu trickery is welcome

hjh

@whale-av "Try this..... https://curiousart.org/digital_proj/pd_eBook.pdf"

Excellent, that's downloaded nicely. Thanks!

And here's the trick I had been asking about... 19-0928-gem-iteration-3b.pd Oh... requires zexy.

hjh

@ddw_music Lists are the stuff of Pd. You can get around any message problem with just vanilla tools.
[repeat 5] can be replaced like this.......

and probably by other methods as well.

There was an interesting doc for iteration in Gem 0.43 for extended.......
Specifically on re-entry when using recursion.
this.zip
David.

I was an avid Gem user and I'm switching to Ofelia because it’s more flexible. Gem is a great tool and is very well documented, which is perfect for students, but you have to stick to its objects and the way they are designed. If you want to do things in a different way you can either write your external (IMHO not easy at all) or find a way around it, if possible.

Ofelia requires dealing with undocumented and confusing stuff but once you get your hands dirty you can basically do everything you do in Gem with much more control and flexibility.

Ofelia seems to require explicitly addressing the individual vertices of a mesh

@ddw_music Actually it's quite easy to texture an image on 3D primitives with Ofelia, but I agree that doing the same by connecting [gem_head] →[pix_image]→[pix_texture] →[cube] is much more exciting and less distracting for students working on a multimedia project for the first time.

-- Define my cube with height, width, depth
local cube = ofBoxPrimitive()
cube:set(100, 100, 100)

-- Load an image
local image = ofImage()
image:load(“image.jpg”)

-- Bind texture to the cube
image:getTexture():bind()
cube:draw()
image:getTexture():unbind()

@dom1817 I agree that Pd is the best starter course. It's flow chart simplicity and excellent documentation promotes understanding and the use of logic whilst enabling a progressive learning of digital audio and the rendering of graphics.
Seeing ones mistakes happen in real time with data flow programming accelerates the learning curve.
I know that many with good experience will recommend staying up-to-date and starting with Vanilla, but I still believe that Extended is the best place to start.
In Extended the tools are all in place, including GEM.
The libraries of objects allow a student to achieve just about anything without having to delve initially into the underlying messages.
And Extended includes the "magic glass" that lets them "look" into the messaging as they grope to understand more.

Many problems posted on this forum are from students trying to patch one of the many tutorials published on the Web that were built with extended...... while using vanilla.

Of course mandatory 64-bit compatibility will put a full stop to Extended, and as more libraries are recompiled for Deken it will fade away anyway.
I will always miss the "Magic Glass" and [rawprint] though.

Vanilla and Ofelia are superb once a student has advanced enough to understand what is happening "behind the scenes" and delve into code.

But of course assembly code is still the best....!
David.

I started with Pd Extended myself, it was very fun to play with but got too messy for me. Sharing patches with Vanilla users was too difficult, there were too many redundant libraries and, as you say, the release of Deken together with the 64bit compatibility issue made it obsolete.

I think that Pd Vanilla is becoming better and better but I miss a well designed repository with all the «add-ons» available today. Many other programming frameworks share the same problem: someone develop a library in his spare time then move on to something else and abandon the project with the library eventually becoming obsolete. There is no official guideline on libraries or documentation.

TBH I think this lack of a clear communication strategy is true for Pd in general. There are way too many isolated communities: mailing lists, irc channels, discord, international and local pd forums, generic and library-specific facebook groups, reddit threads. It would be great to see all this energy channelled into a collective effort instead of seeing people reinventing the wheel everytime (me included).

@dom1817 Agreed. It would be good to see a "Vanilla Extended" for beginners that still need to rely on the web examples of Dr. Rafael Hernandez... 2009 but still unrivalled.
MrPeach is a library that should really be included in vanilla as standard.

Having to check every shared patch against plain Vanilla to identify missing externals is also a real pita.
David.

@dom1817 "Actually it's quite easy to texture an image on 3D primitives with Ofelia"... oh wow, I spent quite a lot of time searching for "open frameworks texture mapping" and all I could find was a quite advanced tutorial about creating your own mesh and setting the vertex properties based on the image. I should have figured there was an easier way, but the web let me down.

@dom1817 "I was an avid Gem user and I'm switching to Ofelia because it’s more flexible" -- Oh yes, I agree. I could actually say the same about Pd/Max vs SuperCollider It seems to be still the case, after 30+ years of dataflows, that boxes and wires can't beat code for iteration, structured data and parallel operations. E.g., this:

vs Array.series(n, 0, 1) (core function in SC, no add-ons), I guess about 5-10 seconds to type. There's no way you can put all those objects together in 10 seconds... so you spend a lot of time on mouse mechanics rather than creating stuff. (Sorry, I know this is a Pd hangout...) So then you get, as mentioned, user extensions in various states of (dis)repair to fill the gaps, and compatibility problems etc. (FWIW, SC faces exactly the same problems with user extensions.)

So yeah, I'd love to get the kids to code. The trouble is that it's a big mental leap for them to visualize state (I've tried...), but some of them can understand how a number comes out of a slider into [mtof] etc. So if this is the gateway that works for them, so be it. (The courses are "audio synthesis theory" and "interactive multimedia," not "programming for digital arts" so the programming methodology is secondary.)

I'm tempted to try Ofelia with them -- and it's very nice how you can integrate Of scripting with Pd's control layer -- but I've had experiences in the past where their eyes just glaze over the second I bring any code into it. Some kind of mental block, like "we can maybe do the visual stuff but code??? Nope, we won't even try."

hjh

PS Oh, and IMO cyclone and zexy are indispensable.

@ddw_music said:

Ofelia

What a GREAT link! Thank you!!!

@whale-av I'm trying your [repeat] substitution but it seems not to work with gemlists.

[gemglxwindow]: Direct Rendering enabled!
translateXYZ: no method for 'symbol'
translateXYZ: no method for 'symbol'
translateXYZ: no method for 'symbol'
translateXYZ: no method for 'symbol'
translateXYZ: no method for 'symbol'
translateXYZ: no method for 'symbol'
translateXYZ: no method for 'symbol'
translateXYZ: no method for 'symbol'
consistency check failed: gpointer_copy
consistency check failed: gpointer_copy
inlet: expected 'float' but got 'pointer'
inlet: expected 'float' but got 'pointer'
translateXYZ: no method for 'symbol'
consistency check failed: gpointer_copy
inlet: expected 'float' but got 'pointer'
inlet: expected 'float' but got 'pointer'
translateXYZ: no method for 'symbol'
consistency check failed: gpointer_copy
inlet: expected 'float' but got 'pointer'
inlet: expected 'float' but got 'pointer'
translateXYZ: no method for 'symbol'

etc.

Am I doing it wrong? Or are gemlists "special" somehow?

hjh

@ddw_music It is probably because the output is tagged as a list. I tried adding [list trim] and strangely the list tag remained.
Adding [f] after [list] will retag the repeated float as a float and then it should work for Gem (I hope).
David.

@whale-av

Alas:

consistency check failed: gpointer_copy
inlet: expected 'float' but got 'pointer'
Couldn't convert gem_state to float.

It's funny... seems like this "should" work.

hjh

@ddw_music i think the error message makes sense, because you send the gem pointer to the second inlet of [translateXYZ] which expects a float.

@Jona "because you send the gem pointer to the second inlet of [translateXYZ] which expects a float."

I don't think so:

The [f] box is whale-av's suggestion above, to deal with a different error.

hjh

@ddw_music alright, i was refering to your last screenshot, now it looks different... sorry, i do not have a solution.

@ddw_music So [list] creates "gpointer_copy" errors from the Pd binary (use log debug mode to see).
And an abstraction will not accept gem_state messages travelling back up the chain as an external can do.
The gem_state will need to be looped like this........ iteration.zip
It's simple and I think it's safe.
David.

@whale-av I see, recursion is the only way, then. zexy is probably easier to explain to the students.

Thanks!

hjh