[PD] Pd-list Digest, Vol 120, Issue 88
jancsika at yahoo.com
Sun Mar 29 20:54:51 CEST 2015
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);
for (i = 0; i < array_length; i++)
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.
> 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 at yahoo.com
> <mailto:jancsika at 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:
>> 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".
>>> Dan Wilcox
>>> danomatika.com <http://danomatika.com>
>>> robotcowboy.com <http://robotcowboy.com>
>>>> On Mar 27, 2015, at 7:00 AM, pd-list-request at lists.iem.at
>>>> <mailto:pd-list-request at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list