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.

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?