On 2018-06-11 05:21, IOhannes wrote:
ithink it is one of max's most cumbersome "inventions", and actively hinders patching.
I've never been a Max user. I've only experimented with it twice at a studio but nothing more.
Why it is cumbersome and hinders patching?
Anyway this plugin only activates if you say so because you must trigger the auto completion with the Tab key :)
On 2018-06-11 05:21, IOhannes wrote:
otoh, it is of course a nice way for beginners to get an overview over existing objects.
It also allows for really fast typing and automatically types the library names for you. You can very quickly type long stuff like
list-abs/list-unitvec zexy/0x3d0x3d0x7e list-abs/list-geometric-mean mrpeach/packOSCstream
thus encouraging use of "namespaces", which facilitates good patching practices because it avoids name collisions and also allows for easy finding missing dependencies. Such "namespace" use is not something i see everyday even in some experienced user's code.
On 2018-06-11 05:21, IOhannes wrote:
but anyhow, a very brief glance at the code shows, that the plugin draws its knowlege about auto-completion from hardcoded lists. i think it this is plainly the wrong approach, instead that knowledge should be gathered on-the-fly from the list of currently available classes.
It only reads a hard-coded list for vanilla objects, which is faster and very easy to maintain (and its only a 2kb increase in file size)
For all other externals it reads the $::sys_staticpath and $::sys_searchpath variables to get the PD paths
and then intelligently scans .pd files (skipping -help.pd ones) and system dependent files (.dll, pd_linux, pd_darwin) for each path.
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
[...] hoa/hoa.2d.decoder~ hoa/hoa.2d.encoder~ [...]
You can find them separately using a special "monolithic search mode" that displays the library name on the completions list but only auto completes the object name (since you can't use namespaces with those).
It would definitely be better to communicate with pd directly to query those objects. Is that possible for a GUI plugin?
About it running on slow computers like Raspberry Pis. What exactly would be the the problem? Processing or memory?
Right know the plugin only increases 424kb in RAM usage on my windows computer and i have a reasonable amounts of externals.
About processing power: on startup it scan the externals. Afterwards it will only act if the user press the Tab key to trigger the auto completion.
Cheers,
Henri.
________________________________ De: Pd-dev pd-dev-bounces@lists.iem.at em nome de IOhannes m zmoelnig zmoelnig@iem.at Enviado: segunda-feira, 11 de junho de 2018 05:21 Para: pd-dev@lists.iem.at Assunto: Re: [PD-dev] PD AutoComplete Plugin
congrats to the re-surrection of the plugin.
On 2018-06-10 03:07, Alexandre Torres Porres wrote:
OMG, this HAS to be part of the vanilla distribution!
however: personally, i am not very sure about this. ithink it is one of max's most cumbersome "inventions", and actively hinders patching.
otoh, it is of course a nice way for beginners to get an overview over existing objects.
so i'm not trying to say that the plugin is a bad-idea in the first place, but rather rejecting the notion of "OMG, MUST".
but anyhow, a very brief glance at the code shows, that the plugin draws its knowlege about auto-completion from hardcoded lists. i think it this is plainly the wrong approach, instead that knowledge should be gathered on-the-fly from the list of currently available classes.
but of course, i haven't even tested the plugin, so this might already be happening (and the hardcoded lists might be either left-overs or additional hints).
fgmasdrt IOhannes
PS: and my understanding of the legalese is pretty close to dan's.