I'm not sure if you can make calls directly into Pd, but if so, you can do what Pd does to create a couple of invosoble canvases it leeds. Look in teh Pd source for garray_init() (g_array.c) to see how it's done.
Perhaps this would be a good thing for libpd to support directly at some point.
Also, I've been thinking for a long time about how patches could include their own abstractions for easier distribution... I haven't been able to figure out the best way to do this yet (fake a filesystem? Or include dependencies directly in the Pd file? dunno...)
cheers Miller
On Mon, May 04, 2020 at 04:46:05PM -0400, Andi McClure wrote:
Hi. I am embedding libpd into a video game. The video game targets Android and so will be shipped in a configuration where assets are bundled into a zip file (the APK) and decoded at runtime. Code does not access the filesystem directly.
Looking at the libpd C sample, and also the documentation, it appears the only way to get it to open a patch is `void *libpd_openfile(const char *name, const char *dir)`. This appears to take an on-disk path to the patch file directly and it appears sometimes it will open other files from disk too (I guess pd files can reference external sound files?). However, again, none of the files I will want it to open are on the disk so it will not find them.
Is there a way around this? For example is there a backdoor to give libpd a buffer in memory containing an already-loaded file? Or callbacks to replace libpd's open/read file functions?
If this is not possible, it looks like I might be able to alter libpd to add virtual filesystem abilities (for example, letting the library user provide a table of surrogate openFile, readFile, closeFile function pointers). It looks(?) like the filesystem access is pretty neatly contained in s_path.c and m_binbuf.c. If I do this, would there be interest in accepting the patch back upstream?
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...