This is funny, I used a workaround in PixelTANGO to get around this, striping the file path so that the abstractions can be created properly from the directory listing.
Of course I'd have to update my patches after this change, but I guess it would also be needed if I decided to search for my abstractions in multiple directories.
.b..
IOhannes m zmoelnig wrote:
is this of any use to anybody?
if so i would like it very much in the upcoming release... (it shouldn't break anything, but you never know)
mfg.asd.f IOhannes
SourceForge.net wrote:
Initial Comment: each abstraction-canvas is bound to a receive-symbol, based on the abstraction name, which enables you to send special messages to the canvas (like "vis 1") e.g. [foo] will be bound to "pd-foo.pd";
however, when the abstraction is created with a path-name, this is not reflected. e.g. [foo/bar] will be bound to "pd-bar.pd"
this is unfortunate if you are using multiple abstractions of the same name within different directories, like [foo/bar] and [task/bar] (both will listen to "pd-bar.pd")
the attached patch will modify g_canvas.c and m_class.c to additionally bind the abstraction's canvas to the full classname of the abstraction, with "pd-" prepended in the given example this means, that [foo/bar] will be bound to "pd-foo/bar" and [task/bar] will be bound to "pd-task/bar"
caveat: no ".pd" is suffixed, since the full classname does not hold any file-suffixes. i do not consider this too bad, but who knows.
what for?: i need this for a general framework where people can write their own modules that will be saved within a directory; the entry-point to each module is an abstraction with the same name.
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1403917...
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev