request Add 'PD_FLAVOR' = VANILLA to m_pd.h

[porres]

Hi, I gave this idea to Purr Data to add it's flavor to its m_pd.h file and I'm also suggresting other forks to do the same, see --> https://github.com/agraef/purr-data/blob/pd-else/pd/src/m_pd.h#L23

This way I easily can know in my code if I am loading an external in Vanilla or some other flavor and the whole thing may be standardized.

[Spacechild1]

I think for your use case you would need to get the "flavor" at runtime - which would require an API function, e.g. const char * pd_getflavor(void).

The macro PD_FLAVOR can only be used when you build against that particular header, so it's not particularly useful.

[porres]

that should be better indeed. should I try and give it a shot?

[porres]

this would be just like 'sys_getversion' right?

[Spacechild1]

this would be just like 'sys_getversion' right?

Yes!

---

I am wondering, what exactly could you do with the "flavor" information? In other words: can you give an example of an else object that would behave differently in Purr Data, and if yes, how so?

[Spacechild1]

What I would find more useful: a function like t_method pd_getextension(const char *name). Fictional usage example:

t_method fn = pd_getextension("PurrData_some_cool_function");
if (fn) {
    // cast to correct signature and use it
} else {
    // do something else
}

A similar technique is used by VST plugins resp. VST hosts to add their own (optional) extensions.

[porres]

I don't have a great example, best I have is warn people what objects have been ported yet :)

[porres]

actually this idea first came up with abstractions that don't show up correctly in Purr Data so you use this information to correct the offset for iemguis, not a great example either.

not great examples aside, seems like a cool thing to have

I already have proposed [pdcontrol] to output PD version, could be nice if it could give us the flavor too :)

[umlaeute]

1. but wouldn't in general that be a feature to be implemented by the various forks, rather than by Pd-vanilla?

   the reasoning would follow the logic: "if it is neither Purr Data, nor Pd-next nor Desire Data nor any other flavour we know of (or care about), then we should assume that it is Pd".

2. in addition to what @Spacechild1 said about sys_getflavor: a string-macro is often of limited use, as it doesn't allow you to use macro conditionals.
   E.g. you can't do

   #if PD_FLAVOR == "Purr Data"
   /* Purr-specific code */
   #elif PD_FLAVOR == "Plug Data"
   /* Plug-specific code */
   #else
   /* ... */
   #endif

   however: you can currently do this already:

   #ifdef PURR_DATA
   /* Purr-specific code */
   #ifdef PD2LORK
   /* l2ork-code
   #else
   /* .. */
   #endif

   but anyhow, @Spacechild1 's suggestion makes much more sense.

3. finally, "Pd-vanilla" is a term that is not much used by "Pure Data" internally. a better name would probably just be no name at all ("")