You know, those could be added to libpd …
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://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.
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 http://danomatika.com robotcowboy.com http://robotcowboy.com
On Mar 27, 2015, at 7:00 AM, pd-list-request@lists.iem.at mailto: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.
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.
On 03/29/2015 11:04 AM, Dan Wilcox wrote:
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?
gui_vmess just leverages sys_vgui to do the actual sending over the socket. There's a lot going on in s_inter.c, but my approach is that gui_vmess will replace all sys_vgui/sys_gui calls everywhere else.
For convenience, I also made an incremental wrapper that suits things like garray data points and data structures. It looks like this:
gui_start_vmess("array_coords", "ss", canvas_tag, array_tag); gui_start_array(); for (i = 0; i < array_length; i++) gui_f(array_coord[i]); gui_end_array(); gui_end_vmess();
I don't technically need it to be an array-- the interface could instead send flat FUDI messages with the array coords tacked on to the end. But I found that it's really nice to have the data arrive to the GUI in a form that cordons off the array data. I stopped short of just having it be JSON because that seemed like overkill for the majority of cases where you're just sending a few positional args.
Anyhow, I've thought of that interface mainly as a stop-gap used to make the garray and data-structure widgetbehavior intelligible. It also helps with iemgui and other properties windows, where you can have name/value pairs in an array of attributes rather than sending a long list of positional args.
-Jonathan
enohp ym morf tnes
Dan Wilcox danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
On Mar 29, 2015, at 10:54 AM, Jonathan Wilkes <jancsika@yahoo.com mailto: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 http://danomatika.com robotcowboy.com http://robotcowboy.com
On Mar 27, 2015, at 7:00 AM, pd-list-request@lists.iem.at mailto: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.
-
Dan Wilcox -
Jonathan Wilkes