Hans-Christoph Steiner a écrit :
having a complex abstraction to replace this :
If there is good code out there, I want to use it, not reinvent it.
is overkill. it add complexity to a simple patch.
you use mapping in Pd-extended, you never need to know anything about
what's happening inside, it just works.
if you don't use pd extended, it just don't work.
i already explain why i don't use pd-extended, and will not change my mind soon.
With a little bit of effort,
Pd-vanilla users can also acheive this. That's why I am fixing up
libdir.c and these libraries in SVN.
i just don't want to add complexity to a simple thing, just because you think
These libraries were a place for me to experiment with ways of handling
libraries in Pd easier.
for me it was something for everyday use!
and i basically can't use it the way i want, and the way i made it.
Some of the experiments failed, but I think
right now its in a pretty good place. So try it out the way it is now
and tell me what doesn't work.
to have mapping/reverse in the object break the way i work with pd for the last
to use [float_argument] that is outside the mapping folder cause problem to.
(remember the pm mapping presentation @ hangar?)
at least, it could be copy / linked on the mapping directory. the best would be
of course to replace it with a more simpler code based on 3 simple object.
(well, to revert the change you made to my objects)
this are the biggest problem i've got.
Pdemail@example.com mailing list
UNSUBSCRIBE and account-management ->