[PD] Purr Data rc4

Lucas Cordiviola lucarda27 at hotmail.com
Sat Jan 28 06:32:25 CET 2017

>> "ds-slider.pd" is cool, also it can easly be shaped to a circle instead of square, and so on, the new [draw] is cool, but:

>> how do you send values to [ds-slider]?

>Where are the values coming from?

Some saved presets in a list, [text], [coll] ...,  eventually if not possible is ok anyway for other purpose.

>> I never been into "pointers" & "data structures".

>> Don't forget that we are trying to connect web-things to Pd, cuz Purr-Data uses

>> NW.js

>> Let me know your thoughts on some [htmlcanvas] or those <iframes> that I mentioned.

>It's certainly possible to add a web page using an iframe. It could be added as html-- either about or below the svg that holds all of the patch.  It could also be added as a "foreignObject" inside the svg itself, in which case it could (theoretically) have a z-order among the inner svg elements that represent the patch objects.

Good, an option.

> However, I don't think there is browser consensus on how the latter should actually behave.  I've tried to steer clear of behavior that isn't
well-documented and broadly implemented by all the important browser vendors (as in the latter case).

Yes, this could change. We all share the same vendor in Purr-Data right?

>Personally, I think it'd be more useful to have a patch contained/displayed
within an html file.  That's actually how patches are rendered in Purr Data
anyway.  (There just doesn't happen to be much content in the html other than the svg itself.)  So adding the ability to specify a different html "template" than the generic one I'm using would be a way to do that.

This has a lot of benefits. Can you elaborate the specification for doing such thing?.

>Still, keep in mind I didn't design the GUI to be able to do any of this.  It's been an incremental port using the tcl/tk code as a stand-in for a spec.  So even adding the ability to display arbitrary html content in a patch window would probably require some careful consideration and refactoring.

Yes, as of "refactoring" I propose starting with the simpler straigth forward option that you can devise.
As of "careful consideration" I think first there must be a starting point.

>Also-- to the extent possible I'd like to keep the "Pd-land" syntax distinct from "Web-land".  For example, I use a small subset of the svg specification to extend data structure drawing in Purr Data.  But I do it with simple Pd atoms/messages, not with XML.

Probably your right, I`ve read Iohannes saying something like "XML is rather difficult not only to Pd" iirc.



Mensaje telepatico asistido por maquinas.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170128/49bdf434/attachment.html>

More information about the Pd-list mailing list