I'm trying to hack plugin~ to accept a "bind foo" message that causes it to listen for messages sent to "foo-gain", "foo-drive", etc., as determined by the list of parameters the plugin accepts. Right now, every time I want to try out a new plugin, I have to do a bunch of wiring to receive a message, scale it appropriately (since I keep all my adjustable parameters in the range 0-127), and convert it to something like "control drive $1". My goal is to eliminate most of those steps with some help from plugin~ itself, which should be able to enumerate all the inputs, get their range, and listen for messages appropriately.
The problem I'm running into is that if I have made multiple pd_bind calls in the same object, to receive based on more than one symbol, I can't tell which symbol the incoming messages came from. For example, if I do: pd_bind(&x->x_obj.ob_pd, gensym("a")); pd_bind(&x->x_obj.ob_pd, gensym("b"));
and create corresponding [s a] and [s b] objects, I will receive messages sent via those objects -- but there is no indication which came from which.
The complicated workaround is to create a new object for each symbol I want to receive on. But before I pursue that (tedious and difficult) route, is there a more straightforward way to accomplish this?
Thanks,
Jacob Lee artdent@gmail.com
Jacob Lee wrote:
For example, if I do: pd_bind(&x->x_obj.ob_pd, gensym("a")); pd_bind(&x->x_obj.ob_pd, gensym("b"));
and create corresponding [s a] and [s b] objects, I will receive messages sent via those objects -- but there is no indication which came from which.
Proxies! pdlua has an implementation that seems to work for me, there might be a better way to implement it for a C-based external though.
svn co https://code.goto10.org/svn/maximus/pdlua pdlua
The complicated workaround is to create a new object for each symbol I want to receive on. But before I pursue that (tedious and difficult) route, is there a more straightforward way to accomplish this?
Yeah, it's not ideal, but this proxy solution isn't so tedious if you make it generic enough, which isn't too hard.
Maybe there should be a libpdutils for such common tasks, pending inclusion into pd?
Thanks,
Claude
On Sat, Sep 13, 2008 at 4:59 PM, Thomas Grill gr@grrrr.org wrote:
Maybe there should be a libpdutils for such common tasks, pending inclusion into pd?
There's flext, but no chance for inclusion... gr~~~
I actually looked at flext, since I knew that pyext had solved this problem. But plugin~ is relatively lightweight, so I didn't want to introduce a dependency on flext. (Plus, frankly, the flext build system is really scary. Have you thought about switching to autotools or scons?)
Am 14.09.2008 um 03:54 schrieb Jacob Lee:
On Sat, Sep 13, 2008 at 4:59 PM, Thomas Grill gr@grrrr.org wrote:
Maybe there should be a libpdutils for such common tasks, pending inclusion into pd?
There's flext, but no chance for inclusion... gr~~~
I actually looked at flext, since I knew that pyext had solved this problem. But plugin~ is relatively lightweight, so I didn't want to introduce a dependency on flext. (Plus, frankly, the flext build system is really scary. Have you thought about switching to autotools or scons?)
There are both skeletons of build systems for autotools and scons but
since i personally don't need it and obviously noone wants to help me
with it, it will probably not be finished shortly. I don't find the
flext build system scary, it's just different. Compared to how many
workarounds i have to invent to support autotools under all platforms
it's actually a pleasure to work with.
gr~~~
On Sun, Sep 14, 2008 at 10:32 AM, Thomas Grill gr@grrrr.org wrote:
There are both skeletons of build systems for autotools and scons but since i personally don't need it and obviously noone wants to help me with it, it will probably not be finished shortly. I don't find the flext build system scary, it's just different. Compared to how many workarounds i have to invent to support autotools under all platforms it's actually a pleasure to work with. gr~~~
If you post your SConstruct files into subversion, I'll try to see if I can help. Theoretically, all that needs to be asked of the user is:
- where to install to (perhaps with a default of /usr/local/lib/pd)
- where the pd source is located -- and this only if a program needs
more than m_pd.h (or if m_pd.h is not in one of the standard locations)
I realize, of course, that this is far easier to state than to do :-). And having to support myriad platforms only makes it harder. But I think it's extremely worthwhile to reduce as much as possible the number of questions asked of the user (e.g. where is sndobj.h? I dunno, it's wherever the debian package puts it, and it's always nice when configure scripts can find it unprompted.)
Hi Jacob,
it seems i got rid of the scons part of flext because it was too
badly maintained (i don't even remember when....)
Anyway, the autoconf stuff seems to be more promising, although i
really hate it.
gr~~~
Am 16.09.2008 um 04:49 schrieb Jacob Lee:
On Sun, Sep 14, 2008 at 10:32 AM, Thomas Grill gr@grrrr.org wrote:
There are both skeletons of build systems for autotools and scons
but since i personally don't need it and obviously noone wants to help me
with it, it will probably not be finished shortly. I don't find the flext
build system scary, it's just different. Compared to how many workarounds i
have to invent to support autotools under all platforms it's actually a
pleasure to work with. gr~~~If you post your SConstruct files into subversion, I'll try to see if I can help. Theoretically, all that needs to be asked of the user is:
- where to install to (perhaps with a default of /usr/local/lib/pd)
- where the pd source is located -- and this only if a program needs
more than m_pd.h (or if m_pd.h is not in one of the standard locations)
I realize, of course, that this is far easier to state than to do :-). And having to support myriad platforms only makes it harder. But I think it's extremely worthwhile to reduce as much as possible the number of questions asked of the user (e.g. where is sndobj.h? I dunno, it's wherever the debian package puts it, and it's always nice when configure scripts can find it unprompted.)
-- Jacob Lee artdent@gmail.com
On Sat, Sep 13, 2008 at 3:47 PM, Claude Heiland-Allen claudiusmaximus@goto10.org wrote:
Jacob Lee wrote:
For example, if I do: pd_bind(&x->x_obj.ob_pd, gensym("a")); pd_bind(&x->x_obj.ob_pd, gensym("b"));
and create corresponding [s a] and [s b] objects, I will receive messages sent via those objects -- but there is no indication which came from which.
Proxies! pdlua has an implementation that seems to work for me, there might be a better way to implement it for a C-based external though.
svn co https://code.goto10.org/svn/maximus/pdlua pdlua
Ah ha! That's exactly what I'm looking for. And not quite as complicated as I had feared.
The complicated workaround is to create a new object for each symbol I want to receive on. But before I pursue that (tedious and difficult) route, is there a more straightforward way to accomplish this?
Yeah, it's not ideal, but this proxy solution isn't so tedious if you make it generic enough, which isn't too hard.
Maybe there should be a libpdutils for such common tasks, pending inclusion into pd?
+1. Though it's really hard to say what's a common task.
At any rate, if what I end up writing looks generally useful, I'll extract the proxy bits and post it somewhere.
-
Claude Heiland-Allen -
Jacob Lee -
Thomas Grill