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