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

[mescalinum at gmail.com]

Hans-Christoph Steiner wrote:
>
> On Sep 21, 2009, at 5:10 PM, mescalinum at gmail.com wrote:
>
>> Jakob Leben wrote:
>>> On Sun, Sep 13, 2009 at 9:01 PM, mescalinum at gmail.com
>>> <mailto:mescalinum at gmail.com> <mescalinum at gmail.com
>>> <mailto: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!
>>
>> hi Jakob,
>> I appreciate your contribution, but what I'm looking for is a general
>> purpose, so probably I want to do exactly what I ask.
>>
>> for sure, if I'll need to interface with arrays I'll use your proposed
>> solution number 2, but here I'm developing a meta-external (tclpd, a
>> toolkit for writing externals in Tcl language) so it has to be general
>> purpose.
>
>
> What Jakob outlines are the two methods of getting array data when
> writing an external in C.  If you are talking about creating a Tcl API
> to Pd arrays, I think there should be a Tcl equivalent of those two
> options.  If that's not what you mean, then perhaps you could
> illustrate the idea more?

I don't need specifically to access arrays (tclpd already support what
Jakob proposed, using pd_bind).

question was: "is it possible -in the context of writing a pd external
class- to invisibly patch some other object and attach to it/bind it?"

and that's what I want to support in tclpd, to avoid code duplication or
tricky patching of objects or using abstractions with their reduced
functionality (in respect to externals).

if it's not possible, I already have fallback solutions.

-- 
Federico Ferri

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20090922/a54fea61/attachment.pgp>