Very, very glad to hear it.
> but one thing i
> still miss is the 'max patch import' or better 'max patch draw' tool.
> can you please make the code public that you already built for this
> purpose! for sure there's a lot to learn from. especially how to
> create customized visual elements. this would be sooo helpful.
Ask and ye shall receive. Sheet attached.
1. you are correct that it's really a max patch draw tool rather than
a max patch import in any significant way. I hacked it together for
all of a screenshot.
2. but it doesn't take the path of least resistance — that would be no
fun — it maps max boxes to Field code boxes and injects drawing code
into those boxes.
3. it then uses callbacks to draw and maintain the connections between
these boxes so you can drag them around and they still look connected.
4. this doesn't actually give you much except for a window onto some
underdocumented things in Field. But it does try to spot Max boxes
that have valid "scripting names" and tell the Max plugin about them
(since the max plugin uses "scripting name" to identify potential
targets of Field / Max communication). Code you type in to those
boxes, or subelements of those boxes, ends up going to max.
5. there s a bug in Field 12's MergeGroup class that I have to work
around in the sheet that makes this code a shade more cryptic than it
ought to be. (But since I never got around to writing up MergeGroup
(it's a class that helps create and delete subelements on demand)
nobody could notice it until now.) This sheet will make a nice
addition to the set of things I test before calling a release a
All in all, it's cute, but I've never found a use for it.
Takeaway things, if you were looking to tutorialize this sheet to find
the things that are maybe under-documented in Field:
1. @overrideShouldSetFrame and friends are pretty useful (see
overrideShouldSetFrame isn't even mentioned on that page which is
silly — its the callback you want it you want some code to run when
any sub element changes frame
2. properties that start with decoration_ are interpreted as lists of
PLines by any box
is great for adding decorations to elements anywhere.
3. MergeGroup needs it's own tutorial (and test sheet) if people are
really going to get into dynamically creating boxes.
> You received this message because you are subscribed to the Google Groups "Field-development" group.
> To post to this group, send email to field-de...@googlegroups.com.
> To unsubscribe from this group, send email to field-developm...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/field-development?hl=en.
This is an embarrassing question. If I didn't know a prior that there was a page ExtendingFieldinField under http://openendedgroup.com/field/wiki/ how would I have know it was there? Is there a way to know what pages are linked to /wiki/?
Anyway, hope all is well.
And that's what I get for packaging stuff off of my development
machine. Previous sheet depends on bleeding edge Field stuff. Attached
is one that should open on everybody else's machines.
In this particular case that page is cross-linked from a bunch of
other pages. Additionally, like almost all pages that are added, it's
When it's added, and linked off of the main documentation page:
This one is also in a tutorial:
For those who want to follow along, all page edits to the wiki can be
Although by snooping around there you may catch pages that are being
written and passed around "internally" that refer to stuff that isn't
ready for prime-time yet (for example, work on new "FLine" cleaned up
version of PLines is going on there).
But all-in-all I completely agree. Right now I suspect that it's the
lack of reference documentation that's making you and others feel like
you need to be a little clairvoyant to know what Field has going on.
Write permission to anybody who wants to seriously contribute to the wiki...