Hi!
It's my first time here! I'm sharing with you a vanilla auto complete plugin.
https://github.com/HenriAugusto/PD-AutoComplete-Plugin
Right now it needs some testing but in the future i think it would be nice if it could be distributed with vanilla, like deken. That's why i'm starting this thread in the dev-list.
I've tested it extensively on my windows machine those last two days but couldn't test in OS X or Linux. Fill an issue on github if you find any bugs.
It was based on Yvan Volochine's work that was idle since 2013. I embraced the project and i'm willing to maintain it!
Cheers,
Henri.)
OMG, this HAS to be part of the vanilla distribution!
I'll definitely test it and check it out.
I don't know much about licenses, there wouldn't be a problem to include a GPL tcl code into Vanilla, right? Or would it help if it were BSD?
cheers
2018-06-09 16:25 GMT-03:00 Henri Augusto Bisognini msndohenri@hotmail.com:
Hi!
It's my first time here! I'm sharing with you a vanilla auto complete plugin.
https://github.com/HenriAugusto/PD-AutoComplete-Plugin
Right now it needs some testing but in the future i think it would be nice if it could be distributed with vanilla, like deken. That's why i'm starting this thread in the dev-list.
I've tested it extensively on my windows machine those last two days but couldn't test in OS X or Linux. Fill an issue on github if you find any bugs.
It was based on Yvan Volochine's work that was idle since 2013. I embraced the project and i'm willing to maintain it!
Cheers,
Henri.)
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
2018-06-09 22:07 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
OMG, this HAS to be part of the vanilla distribution!
I'll definitely test it and check it out.
Doesn't run in macOS :/
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.
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.
2018-06-11 14:11 GMT-03:00 Henri Augusto Bisognini msndohenri@hotmail.com:
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?
In Max I agree it's rather annoying, as all of Max's interface. But yeah, this is totally different as it's only activated with the tab key.
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.
if you're sharing patches, I can see it's a good practice, but personally, I just like to avoid namespaces. But I can see why it's best to have it include namespaces by default as
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.
currently, deken can use a list of objects to search for libraries when you give it an object name. I do provide these text files also as part of the library. If such a text file is provided, the plugin could automatically search that without having the users need to make lists of their own.
cheers
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
-
Alexandre Torres Porres -
Henri Augusto Bisognini -
IOhannes m zmoelnig -
IOhannes m zmölnig