[PD] Pd-list Digest, Vol 120, Issue 88

[Jonathan Wilkes]

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 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:
>>
>> 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 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...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150329/33d82781/attachment.html>