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