I'm new to Pure Data and i wonder about the utility of the [struct] machinery. I guess that it is a matter of taste and that there is no definitive answer but i would like to know if it is used always, often or never by users in the community.

@Guest et all...... This thread seems to have gone "off topic" a bit, but anyway........ If you have enough ram and a multicore processor then why don't you run multiple VM's?
Surely that would keep it simple?
David.

Well I would be very sad if struct was removed, I mess around with it quite a lot.
Here's a way to make a coloured wave display showing only the peaks
Cheers Balwyn
waveform.pd

Anyway it appears that the Tcl/Tk is horribly much more imbricated than i thought and thus the struct family is far in the problem stack.

@Guest: the [struct] object and scalars have nearly no graphical properties by default. If you define a [struct foo] and create a scalar from it, that scalar only computes a single pixel bounding box that you can "grab" with the mouse. But that is less than what a normal object has (visible rectangle, text, and possibly inlets and outlets).

There are use cases for [struct] with no visual properties-- for example, data structure arrays can be very powerful (if clunky to use).

Of course, there are draw commands like [filledpolygon] which do associate data structures with visual elements. But even there, it's not necessary to actually have gui code like tcl strings in the C code. You can just send messages to the GUI saying that some data was changed, and let the GUI figure out how to change the visual appearance accordingly. You can even just figure out what visual attributes need to be changed and
target those in the GUI message without being too inefficient.

The only time it starts to become a problem is when you try to compute visual properties-- like bounding
boxes, for example-- in Pd. So if you have a data structure visualized with, say, 20 polygons, Pd needs to
recalculate the bounding box every time the mouse is moved over the patch. That's one of the reasons why
they are so inefficient. (But that goes the same for a canvas filled with lots of object boxes.)

I tried to mitigate this somewhat in Pd-l2ork by caching the bbox. But this stuff gets a lot easier if you just do all the GUI manipulation in the GUI. Data structures don't make that separation harder, but they do get easier to manage with a more sensible design.

I've kind of "doubled down" on data structures in the GUI port of Pd-l2ork-- you can now group drawings together, perform affine transformations, change opacity, and even draw sprites. I also added some classes to receive events and change variables without having to use pointers, which makes it much easier to use.

Thanks for reply. As i said in previous post, more i go in the rewrite process, more i'm afraid by how the GUI is managed. It is true that the [struct] objects are not really more complex for GUI that rest of the code. So I decided to keep them. I guess that any forked version of Pd should be compatible at least with vanilla. I cleaned half of the Tcl/Tk code for now, but the C core is a much more biggest chunk. Certainly that to reduce the flow between Tk and the Pd executable adopting a kind of MVC approach will be the first job i would do in such case. Your changes are interesting, but IMHO the Pd code is seriously messy and a big clean must be done first.

@guest (pink color): what rewrite process are you referring to?

The only time it starts to become a problem is when you try to compute visual properties-- like bounding
boxes, for example-- in Pd. So if you have a data structure visualized with, say, 20 polygons, Pd needs to
recalculate the bounding box every time the mouse is moved over the patch. That's one of the reasons why
they are so inefficient. (But that goes the same for a canvas filled with lots of object boxes.)

@jancsika Could you elaborate on this problem? How does it affect regular patching (without the use of data structures)? Are the bounding boxes you mention the same as a GOP area?

@jancsika My own (private) rewrite process (yellow == pink).

@LiamG

Pd computes bounding boxes for every graphical object, including message boxes, object boxes, and iemguis. It needs to know the top-left and bottom-right corners of the box so that it can tell when you click inside or mouse over the object. The algorithm just walks the list of all the objects in the canvas until it finds one that includes the current mouse position, then calls that object's event handler.

For a patch with 10 objects in it, it's usually not a big deal-- at worst you compute 10 bboxes. But if there are 1000 objects and you mouse over an empty area of the patch, Pd iterates over all 1000 before deciding you didn't move the mouse over anything interesting. Open Pd with the "-d 3" flag (for debugging) and see how many "motion" messages get sent to Pd from the GUI. Each one triggers a walk across the list of objects (or some portion of it). That's bad.

I haven't changed this yet in the GUI port because I'm doing things incrementally. But doing that "hit box" computation in the GUI instead of in Pd will definitely be an improvement. (And besides, gui toolkits have all kinds of tricks for doing calculations like that efficiently.)

@jancsika Thanks for the detailed reply. I have been pondering this problem for a long time with regards to custom made click GUI objects using mouse data from iemguts/sendcanvas, which I have indulged in quite a lot. The more you replicate them, the more obsolete data you have. But I didn't know that this happened with every GUI object. In a way it makes me feel better, because at least the custom buttons don't create any more mess than the factory ones! But it still does make me feel uneasy, and I know the day will come when I create enough copies of the abstraction that performance starts to suffer.

@LiamG: Not sure what you mean about obsolete data. A patch with 1000 objects will have the correct coordinate data for the objects-- it's just that it becomes computationally expensive and causes dropouts in the audio.

But yeah, even iemguis suffer the same fate.