On 06/11/2018 07:11 PM, Henri Augusto Bisognini wrote: > zexy/0x3d0x3d0x7e
äh? you really don't want to autocomplete *that*. > The only thing it can't do is to read inside those sys dependent files to > know what objects are there inside monolithic libraries, like zexy. For that > reason it reads a .txt file that the user can set that contains that > information. Something like: > > [...] > zexy/atoi > zexy/demultiplex > zexy/demux > these examples puzzle me a bit, as they are quite the reverse of what i consider "monolithic libraries". when loading zexy as a multi-object library (aka "monolithic library"), then there will be *no* [zexy/demultiplex] object, just [demultiplex]. so: are we really talking about the same thing here? > It would definitely be better to communicate with pd directly to query those > objects. Is that possible for a GUI plugin? not for a gui-plugin alone. however, you can write "mixed-mode plugins" that consist of a both a gui-plugin and an external (https://git.iem.at/pd-gui/punish/ uses this quite a lot; it's basically a gui-plugin that tells Pd-core to load an external to add the necessary C-parts). > About it running on slow computers like Raspberry Pis. What exactly would be > the the problem? Processing or memory? not sure whether this is directed at me (i don't remember saying anything about performance) > Right know the plugin only increases 424kb in RAM usage on my windows > computer and i have a reasonable amounts of externals. however, i think that the number of autocompletable objects will only have very little impact on the total RAM used by Pd(gui). i wouldn't worry about the memory foot-print at all :-) gfmdsar IOhannes
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
