2010/4/20 IOhannes m zmoelnig zmoelnig@iem.at

On 2010-04-19 19:09, Vilson Vieira wrote:

...

Guys,

is there any object (or any way to create an external object) to get informations about other objects on the patch at the moment (for example, the number of inlets/outlets of one object, it's state (number, symbol,

...)

...

and other things)?

yes. it's in iemguts.

Thanks IOhannes, I've used iemguts, it's so interesting! But being an external, can I get information about things like: how many objects are on my current patch? how inlets/outlets they have? I think you've implemented iemguts to that porpouse: there isn't a way to do that using just the m_pd.h interfaces. Am I right?

I'm trying to get information about the objects on a patch to make it easy to reflect the state of PD to other languages like Python [1]. Yes, I've seen your presentation about reflection on PD and it's awesome!

Is there a roadmap to make the facilities of iemguts a default feature at PD soon? I would like to contribute on it.

Thanks a lot!

[1] http://github.com/automata/topd/

2010/4/21 IOhannes m zmoelnig zmoelnig@iem.at

well, what iemguts can do, you can do in any other language (if you are willing to use the private interfaces in s_stuff.h, m_imp.h, g_canvas.h,...)

now I got it.

...

Is there a roadmap to make the facilities of iemguts a default feature

at PD

...

soon? I would like to contribute on it.

i haven't planned that. for me, iemguts is something highly experimental (e.g. not something most people would use in their everyday life; but of course it's up to the people to chose what they use in their everyday life). more important, what i want to do can be mainly done as an external (even though using private interfaces), and so there is no real need to internalize these objects (it's not something like a loader-mechanism, which is virtually impossible to implement without touching Pd-core)

I understand. iemguts is really a good way to get what I want.

anyhow, i'm happy to include contributions in iemguts (if they meet my random criteria :-))

I will be glad to contribute, even with documentation. And I imagine that, because it's dealing with PD guts, you need to watch its close every new release of PD, right? I wish to help.

Thanks again!

On 2010-04-22 12:16, João Pais wrote:

you often say that iemguts is very experimental and can be broken in the

it's probably a disclaimer, just as Pd seems to be not reaching a release "1".

next day (due to developments in pd gui or something?). there are some very interesting things there, like the externals dealing with parent patches. Using these with abstractions would make it much easier to depend on $0-variables and still use independently programmed abstractions (I myself use as many $0 as I can, but sometimes can't use abstractions as well, because they have a different $0).

obviously, this stuff has been one of the design principles of iemguts.

Are these externals going to stay there, should we be using them? or is it just a temporary thing, until you get better things to do?

there are 2 parts, why i need the disclaimer: #1 iemguts use private headers of Pd; a change in these headers might/will break iemguts. such break can and will happen with other externals as well (e.g. a lot of gui objects will just plainly crash when used with a Pd-version they have not been compiled against)

#2 iemguts are mainly research driven. the only userbase that counts for me, is currently(?) myself. this is unlike other to libraries i provide, like zexy or Gem, where there is an acknowledged userbase, which i feel a responsibility for (e.g. even after major changes of an object's API, i will at least provide a wrapper that keeps backwards compatibility)

in a way you can think of it in similar terms as "dynamic patching". whenever you use dynamic patching (and iemguts allows you to do some more complex dynamic patching), there is no guarantee whatsoever from Pd (or rather: from Miller), that this will still work with the next release of Pd. people still do it. and chances are not so high, that things will actually change. but still...

so go on, use it.

mfgasdr IOhannes

On Thu, 22 Apr 2010, IOhannes m zmoelnig wrote:

On 2010-04-22 12:16, João Pais wrote: there are 2 parts, why i need the disclaimer: #1 iemguts use private headers of Pd; a change in these headers might/will break iemguts.

Everybody and their dog are using private headers in Pd, and everybody else and their dog are relying on externals that rely on private headers in Pd.

such break can and will happen with other externals as well (e.g. a lot of gui objects will just plainly crash when used with a Pd-version they have not been compiled against)

which externals ? which versions of pd ?

#2 iemguts are mainly research driven. the only userbase that counts for me, is currently(?) myself. this is unlike other to libraries i provide, like zexy or Gem, where there is an acknowledged userbase, which i feel a responsibility for

So, in that case, wouldn't you prefer iemguts to be kept out of pd-extended ?

there is no guarantee whatsoever from Pd (or rather: from Miller), that this will still work with the next release of Pd.

Thus *none* of the GUI externals are guaranteed to work with the next release of Pd, yet they all have worked since 2002 or before... at least at the source level. Who believes that the API would change ?

people still do it. and chances are not so high, that things will actually change. but still...

but still what ?

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801