Okay, so I rewrote 'obj2.c' in the directory so that it had int a=3; outside of the various classes etc. I added it to one of the numbers being sent out an outlet, put in a line 'a= a + 1; and that augments the result every time I send my mutant obj2 a number via the right inlet, fine.

If I make that a 'static int a = 3;' then I can make a pair of obj2's and it's the same 'a' ; every time I tickle the right inlet of either one the result increases by one and when I switch to the other 'obj2' this continues to work.

Now when I also write obj6.c (which was identical except for having 6 replacing 2 throughout, I can compile this and make obj6's.

Two of these will also share the same 'a' and augment it with a tweak to either one's inlet... but this has (of course! -- right?) no effect on the 'a' shared between two obj2's on the same patch. They keep on augmenting their 'a' but it's a different number.

How to add a truly global variable to a pd external? (outside of lua extensions, where it seems to be a simple matter of leaving out the 'self.'s )

?

[Oops -- wrong button, sorry!]

Anyway, no, I just declared 'static int a' in the body of the file, outside of any function. Particular functions were quite able to use it.

Sorry abt being such an idiot re this -- but I'm drowning in an ocean of documentation & not doing so well at understanding how it relates to making use of all these definitions.

If I get an example I can play with it -- & when I get an error I can sort of see why it's an error. But the sheer weight of abstraction, not so good!

ah, it seems the hack-ish solution is to declare them extern http://publications.gbdirect.co.uk/c_book/chapter8/declarations_and_definitions.html (I'm still learning c myself). maybe put it in a .h file with the definition and #include that file in both of your files.

Yeah, I used to do Fortran & assembly language, can use C sort of like a blunt object -- have to laboriously work out which end of pointer to stab sabertooth with, which end to hold. Classes, objects, libraries -- If it doesn't have main{} in it somewhere I start wondering When does anything happen here? [Thanks for link, & maybe I'll even grok what's a t_object some day...!]

Okay, your link has it:

"A declaration outside a function (file scope) which contains the static storage class specifier results in internal linkage for that name. (The Standard requires that function declarations which contain static must be at file scope, outside any block)."

So when I'd put 'static int a;' inside the definition of an obj2 (right after the '#include' stuff) that applied to every function of every obj2 I'd construct from it. But that was a different file from the one used to make obj6's. So, if I've got this right -- An 'extern' declaration in the obj6 file should get the linker looking for 'a' to be defined eventually... If there are already obj2's defined & in used, then it would find their 'a' (if it didn't find somebody else's 'a' as well, a reason for choosing global variable names very carefully & not often...)

This is helping, thanks!

Ummm, a 'header file' lets me declare a variable, ie say what type it's going to be and what it will be called.

But (unless I'm missing something) that variable has to be 'defined' ie 'actually allocated storage' someplace or I just get an error.

It looks like your x_connective stuff provides an indirect way of doing the same thing, ie associate a variable name with some storage, put a value in and take a value out --

but if I just wanted to directly declare a variable and have it available to any of my own objects -- Is there a place to do that? (Hmmm, is that something that writing 'a library' is for?)

Okay, oops, you're right!

I wrote myh.h

which consists of the single line:

static int a;

and put:
#include "myh.h"
into the obj2.c file.

At first I couldn't put it anyplace the compiler could find it -- but when I copied it into ..../6.externals I was able to compile it; & yep, 'a' is at work in there.

Next -- to do the same thing with obj6.c

If you don't have me back kvetching soon you can assume that this -- though hardly something I'd do to anyone else's installation -- works.

No again!

The header file just compiled each object as if it had its own static int a

What worked was to put both classes into the same file, so that obj6 was also defined and provided with a construction method in the file that defines obj2.

Which would be, after all, what a library basically does(?)

from, looking at that [value] code, this looks like the important bit to me:

/* get a pointer to a named floating-point variable. The variable
belongs to a "vcommon" object, which is created if necessary. */
t_float *value_get(t_symbol *s)
{
t_vcommon *c = (t_vcommon *)pd_findbyclass(s, vcommon_class);
if (!c)
{
c = (t_vcommon *)pd_new(vcommon_class);
c->c_f = 0;
c->c_refcount = 0;
pd_bind(&c->c_pd, s);
}
c->c_refcount++;
return (&c->c_f);
}

so, you actually create an object OUTSIDE of your current object, which will be shared by all your similar objects. It also says "created if necessary", and so it looks to me like pd_findbyclass(s, vcommon_class) is checking to see if the object exists?

sorry, just making guesses here...

It looks to me like the x.connect stuff would create a variable outside my own objects, giving it a name that other objects should be able to access by that name. Which is essentially what I'd wanted (but the syntax confuses me.)

Thanks! (& I hope this will be useful for some of what pd alone finds difficult.)