On Mon, 26 Apr 2010, Claude Heiland-Allen wrote:
One way of fixing this once and for all would be to have a separate
[objectmaker] for each canvas (including abstractions, but not subpatches,
ie, those canvases that have a t_canvasenvironment attached to them - at
least that is how I understand that part of Pd's code).
Thanks for bringing back the topic. There was a thread about that on
pd-dev in september 2006, e.g. :
http://lists.puredata.info/pipermail/pd-dev/2006-09/007591.html
http://lists.puredata.info/pipermail/pd-dev/2006-09/007605.html
http://lists.puredata.info/pipermail/pd-dev/2006-09/007607.html
http://lists.puredata.info/pipermail/pd-dev/2006-09/007608.html
http://lists.puredata.info/pipermail/pd-dev/2006-09/007609.html
etc
I have a vague sketch of an implementation like this already, but it's quite
brutal to the core of Pd so I doubt the changes would be accepted by anyone
without me cleaning it up a lot and providing a clean .diff to a current
development version of Pd...
cleanliness is in the eye of the beholder... if you spend a lot of time
cleaning, you can realise that it doesn't look any cleaner to the people
you want to please, or else it can look dirtier.
apart from that, I think that you deserve good luck with this project and
I am happy to learn that you succeeded.
but how does «t_pd *pd_newest» work in that context ?
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
