On Thu, Mar 28, 2013 at 12:42 PM, SourceForge.net
<noreply(a)sourceforge.net>wrote:
> Patches item #3609350, was opened at 2013-03-28 04:42
> Message generated for change (Tracker Item Submitted) made by zmoelnig
> You can respond by visiting:
>
> https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3609350&group_…
>
> Please note that this message will contain a full copy of the comment
> thread,
> including the initial issue submission, for this request,
> not just the latest update.
> Category: puredata
> Group: bugfix
> Status: Open
> Resolution: None
> Priority: 5
> Private: No
> Submitted By: IOhannes m zmölnig (zmoelnig)
> Assigned to: Miller Puckette (millerpuckette)
> Summary: prevent recursive loading of gui-plugins
>
> Initial Comment:
> if a gui-plugin loads other plugin, we might easily encounter a recursion
> (where the plugin tries to load itself).
> while the current gui-plugin loader mechanism tries to prevent re-loading
> of the "same" plugin (based on the filename of the plugin), it doesn't
> catch recursive loading.
> the attached patch fixes this, by adding the to-be-loaded plugin to the
> "::loaded_plugins" list, then tries to load it and removes it from the list
> if the loading fails
> (rather than adding the plugin to the list after the loading succeeded)
>
>
Some minor comments from the perspective of the current plugins-plugin
which you may or may not want to consider:
- the plugin creates a ::plugins_loaded list which is almost the same as
::loaded_plugins with the difference that "-plugin.tcl" is stripped and,
more importantly, brackets in the name are stripped too because they can
cause weird things when handling the strings in tcl.
- for the sake of tidiness, the plugin introduces a ::plugins namespace
where all the functions go.
- what about splitting the whole plugin stuff out into a new pd_plugins.tcl
so that we don't have to worry too much about bloating pd-gui.tcl?
FYI: current plugins-plugin is cca. 200 lines, of which obligatory protocol
is 20 lines, switching mechanism is 40 lines, meta extraction is 60 lines
and building the dialog box is 70 lines - thought this may assist the
decision about what to maintain inside pd and what to leave in a plugin.
My 2 cents are that the moving-the-file way of managing is ugly and a list
of enabled plugins shall be maintained in the preferences. Pd-gui could
load everything (or nothing) by default, letting a plugin modify the list.
So it would at the end take only a few extra lines in core pd gui.
András
Patches item #3609351, was opened at 2013-03-28 04:52
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3609351&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: conditional auto-loading of all gui-plugins
Initial Comment:
currently Pd-GUI tries to load all gui-plugins it can find in any of the search-paths.
this can be rather annoying as it allows neither to select which plugins should (not) be loaded nor in which order the plugins should be loaded (a problem if the two plugins modify the same property).
a single solution proposed on the pd-list [1], is to define a specially named plugin, that - if present - is the only plugin loaded (if the plugin is not there, the original behaviour of loading all plugins is kept)
this specially named plugin can then implement a "plugin manager", that allows to selectively load plugins (potentially in a defined order).
the attached patch does just this: it searches for a file named "autoloaded-plugin.tcl" in the gui-plugins search path and loads it if possible, instead of loading ALL plugins.
[1] http://lists.puredata.info/pipermail/pd-dev/2013-03/019346.html
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2013-03-28 13:40
Message:
This is an interesting idea, but I'm not sure if its the best approach. I
still think just ignoring folders called 'DISABLED' in any search path is
more true to how the GUI plugins work because the mechanism for managing
plugins will be the same whether its thru a GUI plugin or via file
management, as it currently works.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2013-03-28 05:20
Message:
since this patch has a light dependency on #3609350 ("prevent recursive
loading of gui-plugins") the latter is added here as well.
reason: we only want to stop loading ALL patches if the
autoloaded-plugin.tcl actually succeeds in loading. this is checked through
the return value of load_plugin_script (introduced in #3609350).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3609351&group_…
Patches item #3609350, was opened at 2013-03-28 04:42
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3609350&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: prevent recursive loading of gui-plugins
Initial Comment:
if a gui-plugin loads other plugin, we might easily encounter a recursion (where the plugin tries to load itself).
while the current gui-plugin loader mechanism tries to prevent re-loading of the "same" plugin (based on the filename of the plugin), it doesn't catch recursive loading.
the attached patch fixes this, by adding the to-be-loaded plugin to the "::loaded_plugins" list, then tries to load it and removes it from the list if the loading fails
(rather than adding the plugin to the list after the loading succeeded)
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2013-03-28 13:34
Message:
I haven't tested this, but the rationale and the patch make sense to me.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2013-03-28 05:15
Message:
forgot: the patch also makes "load_plugin_script" return '1' if the plugin
script has been successfully loaded, or '0' otherwise.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3609350&group_…
Patches item #3609351, was opened at 2013-03-28 04:52
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3609351&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: conditional auto-loading of all gui-plugins
Initial Comment:
currently Pd-GUI tries to load all gui-plugins it can find in any of the search-paths.
this can be rather annoying as it allows neither to select which plugins should (not) be loaded nor in which order the plugins should be loaded (a problem if the two plugins modify the same property).
a single solution proposed on the pd-list [1], is to define a specially named plugin, that - if present - is the only plugin loaded (if the plugin is not there, the original behaviour of loading all plugins is kept)
this specially named plugin can then implement a "plugin manager", that allows to selectively load plugins (potentially in a defined order).
the attached patch does just this: it searches for a file named "autoloaded-plugin.tcl" in the gui-plugins search path and loads it if possible, instead of loading ALL plugins.
[1] http://lists.puredata.info/pipermail/pd-dev/2013-03/019346.html
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2013-03-28 05:20
Message:
since this patch has a light dependency on #3609350 ("prevent recursive
loading of gui-plugins") the latter is added here as well.
reason: we only want to stop loading ALL patches if the
autoloaded-plugin.tcl actually succeeds in loading. this is checked through
the return value of load_plugin_script (introduced in #3609350).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3609351&group_…
Patches item #3609350, was opened at 2013-03-28 04:42
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3609350&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: prevent recursive loading of gui-plugins
Initial Comment:
if a gui-plugin loads other plugin, we might easily encounter a recursion (where the plugin tries to load itself).
while the current gui-plugin loader mechanism tries to prevent re-loading of the "same" plugin (based on the filename of the plugin), it doesn't catch recursive loading.
the attached patch fixes this, by adding the to-be-loaded plugin to the "::loaded_plugins" list, then tries to load it and removes it from the list if the loading fails
(rather than adding the plugin to the list after the loading succeeded)
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2013-03-28 05:15
Message:
forgot: the patch also makes "load_plugin_script" return '1' if the plugin
script has been successfully loaded, or '0' otherwise.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3609350&group_…
Patches item #3609351, was opened at 2013-03-28 04:52
Message generated for change (Tracker Item Submitted) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3609351&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: conditional auto-loading of all gui-plugins
Initial Comment:
currently Pd-GUI tries to load all gui-plugins it can find in any of the search-paths.
this can be rather annoying as it allows neither to select which plugins should (not) be loaded nor in which order the plugins should be loaded (a problem if the two plugins modify the same property).
a single solution proposed on the pd-list [1], is to define a specially named plugin, that - if present - is the only plugin loaded (if the plugin is not there, the original behaviour of loading all plugins is kept)
this specially named plugin can then implement a "plugin manager", that allows to selectively load plugins (potentially in a defined order).
the attached patch does just this: it searches for a file named "autoloaded-plugin.tcl" in the gui-plugins search path and loads it if possible, instead of loading ALL plugins.
[1] http://lists.puredata.info/pipermail/pd-dev/2013-03/019346.html
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3609351&group_…
Patches item #3609350, was opened at 2013-03-28 04:42
Message generated for change (Tracker Item Submitted) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3609350&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: prevent recursive loading of gui-plugins
Initial Comment:
if a gui-plugin loads other plugin, we might easily encounter a recursion (where the plugin tries to load itself).
while the current gui-plugin loader mechanism tries to prevent re-loading of the "same" plugin (based on the filename of the plugin), it doesn't catch recursive loading.
the attached patch fixes this, by adding the to-be-loaded plugin to the "::loaded_plugins" list, then tries to load it and removes it from the list if the loading fails
(rather than adding the plugin to the list after the loading succeeded)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3609350&group_…
Patches item #3051663, was opened at 2010-08-23 09:45
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3051663&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: bugfix
Status: Closed
Resolution: Accepted
Priority: 6
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Martin Peach (mrpeach)
Summary: make slipdec reassemble arbitrary packages
Initial Comment:
current slipdec doesn't work if the SLIP encoded package is not presented as a single list
(which kind of defeats the idea of SLIP, which is to paketize a _stream_ of data)
with the attached patch, [slipdec] is able to decode a stream even if it was [1, 192 2, 3 4, 5 192, 6, 192(
before applying and committing the patch, please have a close look at it.
for now, i just disabled the "valid" output (because it doesn't make so much sense anyhow, a SLIP stream is almost always valid)
i know think that the flag could indicate whether there is still data waiting in the queue (and is updated after each message received)
----------------------------------------------------------------------
Comment By: SourceForge Robot (sf-robot)
Date: 2010-09-29 12:30
Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: Martin Peach (mrpeach)
Date: 2010-08-26 13:34
Message:
Maybe it should output the size of the queue, so zero would mean a complete
packet.
Valid was supposed to mean that all the input was equivalent to bytes, i.e.
no floating point, symbols, etc.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3051663&group_…
Patches item #3051663, was opened at 2010-08-23 09:45
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3051663&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: bugfix
Status: Closed
Resolution: Accepted
Priority: 6
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Martin Peach (mrpeach)
Summary: make slipdec reassemble arbitrary packages
Initial Comment:
current slipdec doesn't work if the SLIP encoded package is not presented as a single list
(which kind of defeats the idea of SLIP, which is to paketize a _stream_ of data)
with the attached patch, [slipdec] is able to decode a stream even if it was [1, 192 2, 3 4, 5 192, 6, 192(
before applying and committing the patch, please have a close look at it.
for now, i just disabled the "valid" output (because it doesn't make so much sense anyhow, a SLIP stream is almost always valid)
i know think that the flag could indicate whether there is still data waiting in the queue (and is updated after each message received)
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2013-03-27 19:37
Message:
I think this is one of the most important info for me. And i am glad
reading your article. But should remark on some general things, The web
site style is wonderful, the articles is really nice : D. Good job, cheers
Burberry Bags http://burberrybags118.cabanova.com
----------------------------------------------------------------------
Comment By: SourceForge Robot (sf-robot)
Date: 2010-09-29 12:30
Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: Martin Peach (mrpeach)
Date: 2010-08-26 13:34
Message:
Maybe it should output the size of the queue, so zero would mean a complete
packet.
Valid was supposed to mean that all the input was equivalent to bytes, i.e.
no floating point, symbols, etc.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3051663&group_…
hi pd-dev list,
my name is matthias kronlachner, master student of electrical
engineering-audio engineering at iem graz (austria), but currently
living in vilnius, lithuania.
i am teaching computer music (with support of pd) at the music and
theatre academy vilnius (lmta), writing my master thesis and working on
various projects.
i would like to apply for svn commit access.
since about 5 years i'm using pd to generate audio and video for
performances and installations.
i was lucky to learn a lot from the staff of iem (IOhannes, ritsch,
musil), especially about pd.
my interests are in performing electronic music, spatial audio, human
machine interfaces, computer vision, streaming audio and video,
algorithmic composition...
some of my projects can be found on my website:
http://www.matthiaskronlachner.com
i developed several pd and gem externals, especially for the kinect sensor.
currently my pd externals reside at github: https://github.com/kronihias
i'd like to contribute to the repo with my pd externals and fix issues
with existing ones, if investigated.
i just ported a dbap (directional based amplitude panning) external from
max to pd, and i guess it would be good to have that at the main repository.
my sourceforge name: mkronlachner
hope to be able to contribute further to this great project.
kind regards,
matthias