Hi, it's certainly possible to load Pd patches entirely from memory with a binbuf. In fact, Pd itself does this for its private hidden canvases. Checkout the patch "garray_arraytemplatefile" in g_array.c and garray_init() for how to read it.
Christof
On 04.05.2020 22:46, 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://lists.puredata.info/listinfo/pd-dev