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

yes please

@th8a Here's a quick hack:

responsive-demo.pd

The hack is that I currently don't have an easy way to do clipping, so I'm using grouping and opacity to work around that.

The logic for the keyboard is: when the scaling factor is large enough AND the proportions of the box are wide enough, the piano appears. Otherwise it hides itself. You could define other size/position changes for each widget based on the size of the container.

As hacky as this is, I think it's still easier to comprehend than GOP's behavior.

Also notice that there are only two fields to the struct: x and y. That means if you copy and paste the widget, the only data saved with the scalar are the x/y coordinates. If you wanted to be able to have multiple collections of widgets operating independently you would need an additional field in the struct for each piece of data. For example, adding xSize and ySize would allow you to save the dimensions of each scalar. (You'd also have to change the guts of the drawing routine to fetch and set those values.)

Hwell son'bitch! I finally got back from my folks place today and had a chance to check this out. I took your patch and made it a gop, scaled it accordingly and it woked without crashing. This method seems like a more sensible way to go for scalable scalars. Having to anticipate the number of instances by changing the struct's variables would defeat my idea to make an easily accessible abstraction to bottle and give away to the next guy, or reuse in multiple projects though... Since $0 naming is out, can you think of any other way to take this concept and make it easily called on as an independent abstraction?

@th8a Would you be shipping a scalable square-circle-triangle-piano, or do you want to ship a library that allows users to make arbitrary combinations of squares, circles, triangles, and pianos?

I suppose it would be the latter, though what i am trying to do is make a graphical abstraction, like this button here for instance... Save it as an abstraction and then use it like an object or external. I could call it multiple times in a patch and each instance would operate independantly, remembering it's size and placement. I could put the patch up on this forum, and anyone could easily use it in their patches, etc. I suppose I would want it to operate like a graphical array, in that it is a UI element that can be used allover and easily sized and customized. If I can figure out how to get that to work, then I plan a whole library of nice looking UI objects, like knobs, faders, buttons... maybe even some MAX object clones like [live.grid] etc. All easily called on and able to customize like changing size, colors, placement etc.

That's certainly possible. I'll show a demo when I get a chance.

The only thing missing atm is the possibility to define a "drag" event in editmode for scaling the scalar. That's why I put it in runmode on the other demo.

@jancsika That'll work. I'd start with that, and then it sounds like you plan to add the drag functionality in edit mode at some point, which could make it that much better, but still cool til then