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