I guess so. I was just thinking, since you're in the middle of working this out, that we/I could distill this wisdom into libpd. I might be maintaining libpd right now but I don't have a detailed understanding of the Pd source.
Are you mainly using gui_vmess? What else needs to be wrapped?
enohp ym morf tnes
Dan Wilcox danomatika.com robotcowboy.com
On Mar 29, 2015, at 10:54 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
On 03/27/2015 02:55 PM, Dan Wilcox wrote:
You know, those could be added to libpd …
Do you mean as they currently exist in Pd-Vanilla? Unless you're hooking them to tcl/tk I think that'd be of limited value.
My replacement API probably needs a few passes, though. Right now it looks like this:
gui_vmess("some_javascript_function_name", "sfiis", "c-string", 98.6, 42, 42, "etc.");
Looking at it now, it seems wrong. Maybe the format string should come first, and that function name should just be the next string arg after that. An alternative would be for the first arg to be a pointer to a Pd. (But then you'd have to send a 0 or dummy object for messages to the running Pd instance.)
One caveat is "s" here is a c-string and not a t_symbol* as it is in pd_vmess. Also, I'd like to add a char to the format string for hex strings that representing objects, but I'm not sure if that should be "x" or "p".
-Jonathan
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Mar 27, 2015, at 7:00 AM, pd-list-request@lists.iem.at wrote:
Unfortunately, no. That's the simple answer, as evidenced by the lack of hooks in libpd for all the functionality inside g_*.c.