It would seem that trying to embed structs and scalars for graphical elements in GOP subpatches is glitching out something nasty. Draw commands work well until the GOP property is turned on, and then the canvas size gets huge and scrolling gets lost on something like an infinite scrollbar treadmill. Ive been super eager to start designing UI elements with scalars,, but the inability to nest structs and scalars in GOP subpatches is posing some real limitations/frustrations... is anyone else experiencing this? Am I doing something wrong, or is this a bug?

@th8a You can look at this thread to find some examples: https://forum.pdpatchrepo.info/topic/10858/data-structures-append-and-get-what-am-i-getting-wrong/7
Without your patch it is quite difficult to tell what is going wrong.

About the scaling: After creating the subpatch you usually don't need to open it ever again, so i would say you just don't have to worry about anything if it looks like you want it to on the parent...

that seems like sound advice. Here is where the patch is currently at. I want it to simply be a nicer looking bng button which is scalable and reusable as an abstraction. for now it's just an exercise to learn this aspect of purr-data. Eventually, I have a bunch of UI object abstractions I plan to give to the community once they are awesome. feel free to look around on it. If you do, let me know if your seeing the thing where the scalar is huge inside the subpatch window but normal on the parent. j-svbng-blu.pd

@th8a i use pd vanilla, so i don't have the [draw] object and can't help you with that.

But i made a button patch that should work: button.pd.

It would take some more effort to make a full fledged abstraction out of it where you can set the size.

Well, I tried my idea of dynamically making structs per instance by setting a loadbang to send the canvas a message to create a struct and scalar with the $0 number of that instance prepended. It works, but not without causing a full on crash.... back to the drawing board I suppose...

UPDATE: ok, I had to set a delay between the message which creates the struct object and the message that creates the scalar. Looks like my old nemesis, the bug that attempts to update elements before they are created is once again the culprit. With a little delay time it is stable and each abstraction functions independently. I can copy and paste multiple instances, but if I call the object from a text box, it will still crash. go figure... my best guess is something to do with pointers getting mixed up j-svbng-blu.pd

SyntaxError: missing ) after argument list
    at perfect_parser (/home/th8a/apps/purr-data/lib/pd-l2ork/bin/pdgui.js:1662:48)
    at Socket.<anonymous> (/home/th8a/apps/purr-data/lib/pd-l2ork/bin/pdgui.js:1680:9)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:191:7)
    at readableAddChunk (_stream_readable.js:178:18)
    at Socket.Readable.push (_stream_readable.js:136:10)
    at TCP.onread (net.js:560:20)
Segmentation fault (core dumped)
[5872:5872:0908/181830.239431:ERROR:extension_function_dispatcher.cc(601)] Permission denied for nw.App.quit

@th8a Very interesting. i opened your patch with Pd-L2ork and first thing i must say the graphics look very beautiful in Purr Data!

i still don't understand how you got the scalars into the patch without any [append] object?
Is it not possible to use [draw] onto a subpatch? It would solve the graphics all over the place issue to just put the scalars into a subpatch with gop on.

i put some comments to my button example from above that hopefully give a somewhat comprehensive overview of the basic concepts of data structures in pd and how to use [append] to add scalars:

button-data-structures-mini-tutorial.pd (updated)

i also added an example on how you can safely use dynamic patching with data structures without any crashes and without any delays.

i still don't understand how you got the scalars into the patch without any [append] object?

You can dynamically instantiate scalars with a "scalar" message to a canvas.

In Purr Data you can create a scalar by typing the name of the template into a box.

But I haven't looked at the patch yet so I'm not sure if that's how the author is doing it.

Is it not possible to use [draw] onto a subpatch? It would solve the graphics all over the place issue to just put the scalars into a subpatch with gop on.

[draw] can be used in the exact same way as [drawpolygon] and friends.

Clearly, I still have quite a bit to learn... lol. I'll check out this patch and see if I can understand. thanks fellas.

i still don't understand how you got the scalars into the patch without any [append] object?

Tbh, the way you showed how to do it in your tutorial patch is completely foreign to me! I am coming from being a heavy user of MAX and somewhat recently started learning pd, so I approached it like you would in MAX where the scalar and the logic are all part of one gop subpatch. It took some shots in the dark and trial and error to get the graphic to line up without the [append] objects and all of that. Now that I see that you are putting the scalar in it's own gop subpatch that contains nothing but the scalar, it all makes a lot more sense how you are approaching this and why my way is confusing. I will rework my button patch with some of these methods and see if I can't make it work without crashing etc.
Thanks again for the help. Much appreciated. I'll post the finished product here when it's ready.

So I am starting to get a hold of how the whole thing works. I realized that some of what is there in the tutorial patch doesn't apply while using the [draw] object, which I believe is unique to purr-data... But no matter what I do, it seems like working with dynamically created structs causes a lot of instability. I modified my patch to create scalars in a subpatch with gop on so that i can clear the scalars and drawing instructions before creating new ones to avoid crashing. What i am finding is that the entire system gets unstable. PD will crash randomly or when creating send objects or objects with $0 prefixes, saved patches will open up with some of the object's missing or malformed, freezes, even an entire system crash at times, requiring full reboot. My patch was otherwise working well, but all of the scalars and pointers being tossed around just makes everything too unstable to even work, so I finally tabled the project until I can find a better way to do it, or some solution to the instability of structs (which I remember being a problem in various versions of PD,) are solidified to run without causing constant and consistent crashing and instability. Sorry for the news of failure... What might be really cool in the of purr-data future would be if the graphical instructions weren't bounded to the TK/Tcl constructs, and were handled independently by something more modern. Since purr uses the web-browser engine for it's UI, I envision something like an HTML wysiwyg editor to handle svg graphics and animations, like Adobe Edge or Tumult hype. Those programs let me know that HTML5 and JS in conjunction can be extremely powerful for graphics, animation and interactive interfaces. A full length animated movie could be made just in HTML5, potentially... Just my two cents and wishful thinking... but it would be cool....

@th8a i gave the dynamic patching example, but i think you wouldn't need dynamic patching at all to make the button...

You are right that the button can be made without dynamic patching, however making it as a reusable abstraction which can have multiple instances on a patch would require at least the dynamic capability of structs with $0 prefixes, which I am finding to cause some instability. I suppose I can try one more time with no dynamic patching and from a fresh start to see if it can work and stay stable. Stay tuned...

@th8a as mentioned above [struct $0-structname] works fine in pd and Purr Data.

If you get "error: 1004-template: only one struct allowed per canvas." it means that only one struct is allowed within one subpatch.

From my experience, pd sometimes becomes unstable with data structures if you have a scalar in place and than change the struct object or the drawing instructions. Therefore the advice would be to always clear the subpatch containing the scalars first and than make changes to the struct object or drawing instructions and recreate the scalars afterwards. That way everything should be stable.

@ingox yea... so the best I could do was get it to be stable when the scalar is in a subpatch, however this does not allow the graphic to be scaled by dragging the gop square on parent, which to me is the biggest advantage of svg graphics in the first place. If no scaling can be easily done, may as well use pixels... You have to open the subpatch to scale it, or send a donecanvasdialog message, and then if you save it. it will scale all instances of the abstraction. $0-naming of structs and scalars works if the structs and scalars are in a subpatch of the abstraction, however for some reason it won't work if the scalar is on the top level. The only way to name a scalar on the top level with a $0 prefix is to dynamically patch it at load time, but then ofcourse this crashes and makes it unstable. So, either i can make the button but it won't be scalable from the top level, or I make it but it crashes every time you call it in a text box. Ive spent many hours now trying to work around it... but every path I take seems to lead to some glitch or dead end... Im sorta ready just to table this and wait for updates of pd to hopefully fix the problem.... Here's what i got so far though. You can call one instance and it will work (sometimes) and you can copy and paste multiple instances and that works also. If you call it more than once from a textbox, it loads, you see the button flash once, and then crash. j-svbng-blu.pd

@th8a I haven't looked closely at what you're doing, but as far as scaling goes:

[struct blah float x float y]

[nbx]
|
[* 0.01]
|
[transform scale $1(
|
[draw rect 10 10]

[blah]

That will scale a rectangle by the desired scaling factor.

See doc/4.data.structures/pd-l2ork/ds-tutorials for more features.

@th8a Thanks for the explanation. I wasn't aware of the drag-and-scale feature of gui objects in Purr Data. So unless there is some event message on scaling and a method to read the gop properties to adjust a subpatch containing the scalar, yes, the only method to get the scalars to scale would be to put them directly inside the main patch.

Still the reason for the crashes is that you have the scalar in the patch and then mess around with the struct object.

The way to prevent this is:

• Delete the scalar
• Create the object [struct $0-blinky float x float y]
• Add:
  [loadbang]
  |
  [scalar $0-blinky 0 0(
  |
  [s $0-blinky-cnv]

(Alternatively you can use the append method.)

This would mean that the scalar is created on load and also means that you would have to delete the scalar before saving the patch to avoid multiple scalars in the patch.

I would guess that with this you can get rid of all the delays as well.

If you can do without the drag-and-scale feature and be ok with just setting the size via creation argument or message, it is possible to do it the "clean" way with the scalar inside a subpatch.

Well, instead of using loadbang you can also:

• Delete the scalar
• Create the object [struct $0-blinky float x float y]
• Manually do:
  [scalar $0-blinky 0 0(
  |
  [s $0-blinky-cnv]
• Save the patch

This way you can get rid of dynamically creating the [struct] object.

Whenever you want to change the [struct] or [draw] objects, delete the scalar first and recreate it afterwards.

The first example is actually what is going on in the patch there. The second example would work, but for some reason naming $0 on the scalar won't work on the top level patch, hence dynamic patching to get the $0 number instead of $0 as a literal. There is no changing of draw instructions or anything. The only thing that is created at load time is the scalar itself... which actually even works unless you call it from a text box, where it will load and then crash. I honestly cannot figure out what makes it crash exactly, but it does - every time. As far as I can see, I've patched everything properly and it should work, but alas... so close yet so far... I appreciate all the input on this patch... the main reason I was making it was an experiment to see if UI objects could be made to scale on mouse drag of the GOP square instead of creation arguments or message. With that, I can make some external/abstractions for quick WYSIWYG style editing of interfaces, whereby you can type a UI object name, get something that looks reasonable sleek and modern that functions and is somewhat customizable, and then easily drag and drop it where you want it to go on your interface, scale it etc. Having started in MAX msp, there are some features like what I am saying here that I'm sure many would love to see brought to puredata in a more modern way than what has been done so far. To me, that's really the one and only thing PD is missing. Other than that I actually prefer PD to max now... So this was just an experiment to see if I could create my idea in this manner and make some nice UI objects to contribute. I'll just have to either find another angle or figure out why my current method is unstable....

@th8a Do you want to scale individual widgets-- the way Purr Data does with iemguis?

Or are you actually talking about a responsive design where the widgets scale and pad themselves accordingly as the viewport itself changes size (e.g., when the user drags the GOP box to scale things)?

The first option is certainly doable with the [draw] event callbacks. Getting an actual responsive design isn't currently possible with any of the public interfaces provided by Pd or Purr Data. (At least not in a way that you can ship the patch to someone else and have the responsive design work.)

As an experiment to see if it is possible, the latter. I actually came damn close to making it work too! if only it were stable...

I take that back-- you probably can do the responsive thing using [draw g].

I can give you a demo if you want.