[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