[PD] Pd-list Digest, Vol 120, Issue 88
danomatika at gmail.com
Sun Mar 29 17:04:46 CEST 2015
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
On Mar 29, 2015, at 10:54 AM, Jonathan Wilkes <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:
> 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
>>> On Mar 27, 2015, at 7:00 AM, 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