I'm using [import] on an abstraction (as discussed earlier); this abstraction does some automatic object instantiation (via [polypoly]) and each of the generated objects has an [import ...] in it. This leads to a barrage of console output, like:
[import] loaded library: 'cyclone' libdir_loader: added 'cyclone' to the canvas-local objectclass path libdir_loader: added 'cyclone' to the canvas-local objectclass path [import] loaded library: 'cyclone' libdir_loader: added 'cyclone' to the canvas-local objectclass path libdir_loader: added 'cyclone' to the canvas-local objectclass path . . . (repeat for number of voices created by [polypoly].
A great enhancement for [import] would be a verbosity control! :-)
Phil Stone
Here I go following myself up again...maybe *I* need a verbosity switch! Anyway, multiple copies of cyclone (for instance, as below) are not really getting loaded are they? Pardon my ignorance of the mechanics of [import].
Phil
Phil Stone wrote:
I'm using [import] on an abstraction (as discussed earlier); this abstraction does some automatic object instantiation (via [polypoly]) and each of the generated objects has an [import ...] in it. This leads to a barrage of console output, like:
[import] loaded library: 'cyclone' libdir_loader: added 'cyclone' to the canvas-local objectclass path libdir_loader: added 'cyclone' to the canvas-local objectclass path [import] loaded library: 'cyclone' libdir_loader: added 'cyclone' to the canvas-local objectclass path libdir_loader: added 'cyclone' to the canvas-local objectclass path . . . (repeat for number of voices created by [polypoly].
A great enhancement for [import] would be a verbosity control! :-)
Phil Stone
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list