[PD-dev] "modular" compositions of object classes

Jakob Leben jakob.leben at gmail.com
Thu Sep 17 02:03:40 CEST 2009


On Sun, Sep 13, 2009 at 9:01 PM, mescalinum at gmail.com
<mescalinum at gmail.com>wrote:

> if I were writing an external that is somewhat an interface to arrays
> (read/write), I have some design choices:
>
> 1) copy/paste the code of array (g_array.c) (or eventually only copy
> [tabread]/[tabwrite])
>    pros: resulting external is tight & tidy
>    cons: code duplication, possible breakage in future releases
>
> 2) provide appropriate inlets and outlets, and require the user to patch
> the external among [tabread]/[tabwrite] objects
>    pros: modular. is independent from the array implementation.
>    cons: tricky to use, the user can patch it incorrectly and won't work.
>
> 3) is possible to patch the required objects without phisically put them
> in the canvas [?]
>    pros: all pros mentioned in 1) and 2)
>    cons: [?]
>
> obviously, 1) and 2) are ugly under some point of view; what I am
> interested in is 3), hence asking here if possible, and directions on
> how to proceed.
>

I would suggest the following two options. Everything used in the examples
is declared in the "m_pd.h" header that you have to include in your external
anyway. Basically, I will explain the techniques used by the pd objects that
operate on arrays and the delay objects, so this is stuff that will most
probably not be broken for numerous future releases, or a very large part of
pd should drastically change.

1.
You can get a direct pointer to data stored in a g_array with the following
code:

t_symbol *array_name = gensym( "array-named-foo");
t_pd *the_array = *pd_findbyclass*(  array_name, garray_class );
int size;
t_float *data;
*garray_getfloatarray*( (t_garray) the_array, &size, &data );

You have to pass the name of the array as it was set in the pd patch as the
"s" argument of pd_findbyclass function. Therefore you can easily let the
user choose the array you will operate on via an argument to your external.

2.
You can associate your pd external with a symbol using the function

void *pd_bind*(t_pd *x, t_symbol *s)

...where you pass the struct of your external as the "x" argument (you can
easily cast it to t_pd). What this means in effect is that you can get a
pointer to that structure from another external with the already introduced
*pd_findbyclass* function, by passing it as arguments the registered symbol
and the *t_class* of the registered external.
Again, it is a good idea to let the user choose the registered symbol via an
argument of the external.

This effectively means that you can separate the functionality you want to
achieve into many externals, so that one allocates memory for some data in
its struct and the others will be able to operate on that memory by accesing
the struct of the registered external, while the "invisible connections" are
made via the symbols that the user gives as arguments to the externals (we
can say, by the names that the user assigns to the instances of the
externals).


If you have further questions, please ask!

Best regards,
Jakob Leben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20090917/ef8eed6d/attachment.htm>


More information about the Pd-dev mailing list