[PD-dev] gem vs. mrpeach strings?
Martin Peach
martin.peach at sympatico.ca
Sun Nov 11 23:39:26 CET 2007
IOhannes m zmölnig wrote:
> Martin Peach wrote:
>
>> IOhannes m zmoelnig wrote:
>>
>>>
>>>
>> I suppose because the surgery required to add a type to pd is not easy,
>> and requires patching the source, so just adding a single 'unknown' type
>> that requires the external to do the type-checking is easier. If the
>>
>
> why?
>
> when patching the core is needed (which i agree that it is), then we
> could just go the whole length
>
>
Sure! I did the string/blob as a first attempt to see if it could be
done. I'd be quite happy to see it done better.
>> atoms were not restricted in size it would be easy to just add another
>> field to identify the type. The way things are it might be better to
>> modify the blob type
>> from:
>> typedef struct _blob /* pointer to a blob */
>> {
>> unsigned long s_length; /* length of blob in bytes */
>> unsigned char *s_data; /* pointer to 1st byte of blob */
>> } t_blob;
>>
>> to:
>> typedef struct _blob /* pointer to a blob */
>> {
>> t_symbol *blob_type;
>> void *blob; /* pointer to blob */
>> } t_blob;
>>
>
> still i don't understand why you would want a blob to have 2 types:
> A_BLOB and blob_type.
> iirc, atom.a_type is (int), which gives us a huge wealth of possible
> types and no need to add another type-system.
>
>
Well because A_BLOB is the type that can be anything, and blob_type is
the particular type. The pd core needs to be patched for every new
A_THING, but externals could handle the different blob_types without
passing through the core. The A_BLOB handler just calls the user-defined
function for its own blobs, or a default when there is none. Probably
it's unnecessary to have the blob_type registered in the core as long as
pd passes A_BLOB messages around properly. I was thinking that the
class_addmethod function needed the s_blob symbol but it probably would
work without it.
>
>> then after verifying that the blob_type is the right one, the blob could
>> be accessed according to its expected structure. In the case of string
>> blobs the blob type would be "string" and the blob itself would be a
>> struct consisting of the length and the pointer to the data. You still
>> have the problem of name conflicts, just as with the different "counter"
>> objects, but there is no way of avoiding that in every case, apart from
>> having a central repository of registered names or a dispenser of
>> "globally unique identifiers".
>>
>
> i think this could be solved if you don't insist on giving a symbolic
> name, and have a way to share a variable across your objects.
>
Whatever it is has to be 8 bytes long and contain a pointer to something
(4 bytes) as well as a way to know what kind of thing the data is. It
could be an int or a pointer to a symbol or something else.
> furthermore, even with names, the good news is, that you can chose an
> arbitrary name (which nobody but the C-programmer has to remember),
> which is a lot easier than with object-names.
> for instance, one could (by convention), use globally unique identifiers.
>
>
Maybe something like:
typedef struct _blob /* pointer to a blob */
{
int s_guid; /* unique identifier for this type of blob */
void *s_data; /* pointer to 1st byte of blob */
} t_blob;
Then an external would ignore blobs with guids it doesn't recognize. The s_data for a "string" would be defined inside the str external as:
typedef struct _string_blob /* pointer to a string blob */
{
unsigned long str_length; /* length of string in bytes */
unsigned char *str_data; /* pointer to 1st byte of string */
} string_blob;
and if you had a t_blob pointer b it would access the first byte of the string as ((string_blob *)(b->s_data))->str_data[0]
Martin
More information about the Pd-dev
mailing list