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.

"... talks about deleting it ..."

I seriously consider that also (and thus my question).

Examples in "The Theory and Technique of Electronic Music" don't use that stuff. Is there other audio examples that do it somewhere else?

@cacafade Yes, that is true,, but Pd doesn't only do computer audio. It is far more flexible. [struct] is more useful in other areas, but it appears in unexpected places...........

The canvas is the basic "workspace" in Pd, and [struct] is used to help explain canvases here........ pd\doc\5.reference\5.all_about_canvas_properties.pd..........???

Read chapter 2.9 to understand how it is relevant to audio/music/composition (in Miller's opinion, and "The Theory and Technique of Electronic Music" is his treatise after all!).

Any large audio project in Pd is likely to need data structures in the end......... to choose/co-ordinate streams, pick samples, import data sets as presets etc. Or just to visualise a composition in a dataflow program (Pd) that has no "Sibelius" add-in...... The gui in Pd is "poor" and [struct] can improve it greatly. It's just a bit hard to understand. Some people have managed to use it very effectively, and if you delete that one small file you will not be able to enjoy their work.

If you keep it you will eventually forget about it and everything should normally work. If you delete it then every now and then something will not work.
David.

I honestly don't get what one would get by deleting it,.

@gsagostinho

That was just a thought in order to make easier to split the Tk GUI from the Pd core. For now, i didn't know well the sources of Pd, but i suspect this feature to force Tk and C to be very intricated and it could be a problem for me.

@cacafade How do you want to split them? The gui talks to the application through the localhost. By starting the application with the -nogui flag you can connect them on different machines and even on different platforms......... and over a network............ or run the application headless.
You should probably start reading here....... https://puredata.info/community/pdwiki/PdInternalMessages and you will find what you need on that site.
David.

I am interested by the original question here, which is how many people use data structures. I took a look into them a few months ago and decided that they were way too complicated for what they offered, and so decided just to forget about them. I usually find that canvases ([cnv]) are sufficient for whatever I'm doing, and of course they're very easy to control. The only limitation here is that you're limited to rectangles, which aren't always elegant, but honestly they're all I've ever found I needed. Conversely, I believe that data structures are also limited to polygons--instead of creating a circle you have to create an n-gon (am I wrong about this?), and even this seemed like a hell of a task when I looked into it.

but I am willing to be convinced otherwise. David, could you maybe point to some examples of where data structures have been used effectively?

@LiamG Here is a very simple example. If you have used [plot] then you have used scalars and therefore [struct]..........
It can be effective and simple to use.... simple struct usage.zip
In this case for an "audio editor" style display......... Thanks to Toxonic.
And you can draw more interesting shapes than just triangles and lines... have a look at [pd plot-help-data] within pd\doc\5.reference\plot-help.
And for a reasonably understandable tutorial.........http://www.pd-tutorial.com/english/ch05s02.html
David.

TBH my opinion is biased. I'm a long-time user of Max/MSP and a newcomer to Pure Data mainly to embed it with libpd. I follow that software since i use Max/MSP and so i'm aware of limitations (e.g. it is not possible to run several instances of Pd and much more) as soon as it comes to wrap it (for instance with JUCE) and thus my investigations. Of course reasonable approach is to keep things backward compatible and to give it a chance before to judge a feature. But at first glance introducing GUI in data flow programming is something for me very bad and that almost lead to messy inefficient results. The example above does not convince me that "GUI in Pd" paradigm is better than a "Pd core with a largest collection of UI plug-ins" paradigm.

My 2 cents.

@cacafade I agree, but as long as it is there and being used and nobody is providing better tools..... we are stuck with what we have.
David.

@whale-av

You are right. Accept, grumble or DIY. I start with the last option. Of course it will probably take so long time that it will never finish (but forking is a rather common hobby in the Pd ecosystem). Anyway thanks for replies.

For anybody who might read this thread later, I started looking into data structures more seriously today, and found a good tutorial:

https://puredata.info/community/projects/convention04/lectures/tk-barknecht/tut.tgz

It's well written and all done in pd, so you get to play with the files as you go.

Hello Guest
why and how is it not possible to run several instances? I do that when i need to deal with video and audio. I might not like that solution but it works.
take care,
johnny

@Johnny-Mauser But it is a kind of a pain to manage two complete separated instance (communication from netsend/netreceive or in my case I am using shmem). Also using [pd~] is helping, but the dsp is linked to the main patch, so not possible to separate completely the 2 process (Gem + [pd~] not working (glitches)).

Cheers~

"Why and how is it not possible to run several instances?"

I don't know. I repeat what i have read elsewhere. Ah Ah. But i guess that if you want to embed Pd core in another software anything static could be a problem (if you don't want to spawn a process each time).

@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.