the source code can be downloaded either via svn (https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals/plug...) or as a tarball from: http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/plugin...
the build-system is scons based ("apt-get install scons"; and then run "scons" in the directory)
I downloaded the src from the svn installed scons (thanks for mentioning this!) and compiled the plugin~ external with no errors
some cursory observations using test patches I built yesterday -->
- the [print] message does not print control parameters to the pd window:
error: plugin~: no method for 'print'
- the [reset] message returns this error message in the pd window:
plugin~: Warning: Plug-in defines activate() method but no deactivate() method
- sending the [info] and [listplugins] messages to [plugin~] make PdX
crash immediately
On 2010-06-08 21:23, Kim Cascone wrote:
the source code can be downloaded either via svn (https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals/plug...)
or as a tarball from: http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/plugin...
the build-system is scons based ("apt-get install scons"; and then run "scons" in the directory)
I downloaded the src from the svn installed scons (thanks for mentioning this!) and compiled the plugin~ external with no errors
some cursory observations using test patches I built yesterday -->
- the [print] message does not print control parameters to the pd window:
error: plugin~: no method for 'print'
in the code i had for fixing, there is indeed no "print" message (though it is in the help-patch)
- the [reset] message returns this error message in the pd window:
plugin~: Warning: Plug-in defines activate() method but no deactivate() method
well, it seems the plugin you loaded defines an activate() method but no deactivate() method :-)
i strongly believe, that both of the above were already in the original [plugin~] (that is: i haven't changed anything here)
- sending the [info] and [listplugins] messages to [plugin~] make PdX
crash immediately
i'll look into that.
fgamsdr IOhannes
On 2010-06-09 09:27, IOhannes m zmoelnig wrote:
- sending the [info] and [listplugins] messages to [plugin~] make PdX
crash immediately
i'll look into that.
i couldn't reproduce this as described. indeed i found a bug that would crash Pd, when a previously loaded plugin was "used" after calling [listplugins( (e.g. instantiate [plugin~ stereo_amp], call [listplugins( and then call [info] -> kaboom!)
i have fixed this, get the source from the same place as before.
fgamsdr IOhannes
fgamsdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
IOhannes m zmoelnig wrote:
On 2010-06-09 09:27, IOhannes m zmoelnig wrote:
- sending the [info] and [listplugins] messages to [plugin~] make PdX
crash immediately
i'll look into that.
i couldn't reproduce this as described. indeed i found a bug that would crash Pd, when a previously loaded plugin was "used" after calling [listplugins( (e.g. instantiate [plugin~ stereo_amp], call [listplugins( and then call [info] -> kaboom!)
IOhannes I just built the latest src for plugin~ I get the exact same behavior when sending down a [info] message
instantiate [plugin~ amp], connect [noise~] to it, turn on dsp, send [info] to [plugin~], pdx crashes
also, which version of PdX are you using? I'm using Pd version 0.41-4extended
can someone else test this as well with the new plugin~ src?
i have fixed this, get the source from the same place as before.
fgamsdr IOhannes
fgamsdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2010-06-09 18:23, Kim Cascone wrote:
IOhannes m zmoelnig wrote:
On 2010-06-09 09:27, IOhannes m zmoelnig wrote:
- sending the [info] and [listplugins] messages to [plugin~] make PdX
crash immediately
i'll look into that.
i couldn't reproduce this as described. indeed i found a bug that would crash Pd, when a previously loaded plugin was "used" after calling [listplugins( (e.g. instantiate [plugin~ stereo_amp], call [listplugins( and then call [info] -> kaboom!)
IOhannes I just built the latest src for plugin~ I get the exact same behavior when sending down a [info] message
instantiate [plugin~ amp], connect [noise~] to it, turn on dsp, send [info] to [plugin~], pdx crashes
hmm, could you provide a test-patch? are you sure you are using the updated version of plugin~? (it now prints the name of the plugin when it loads).
try running it with from the console with "-stderr", and see what it prints before dying. try increasing the verbosity with "-verbose -verbose" (2 times)
also, which version of PdX are you using?
i'm using Pd-vanilla 0.42-5
I'm using Pd version 0.41-4extended
i have now tested it with PdX-0.42-5extended-rc1 and it works ok as well.
fgamksdr IOhannes
IOhannes m zmoelnig wrote:
On 2010-06-09 18:23, Kim Cascone wrote:
IOhannes m zmoelnig wrote:
On 2010-06-09 09:27, IOhannes m zmoelnig wrote:
- sending the [info] and [listplugins] messages to [plugin~] make PdX
crash immediately
i'll look into that.
i couldn't reproduce this as described. indeed i found a bug that would crash Pd, when a previously loaded plugin was "used" after calling [listplugins( (e.g. instantiate [plugin~ stereo_amp], call [listplugins( and then call [info] -> kaboom!)
IOhannes I just built the latest src for plugin~ I get the exact same behavior when sending down a [info] message
instantiate [plugin~ amp], connect [noise~] to it, turn on dsp, send [info] to [plugin~], pdx crashes
hmm, could you provide a test-patch?
attached here
are you sure you are using the updated version of plugin~? (it now prints the name of the plugin when it loads).
yes - I get a printout of the plug name for example when I instantiate a amp.so LADSPA I get plugin~: found plugin "amp" in library "/usr/lib/ladspa/amp_1181.so" plugin~: open_plugin (x, "amp", "/usr/lib/ladspa/amp_1181.so", 44100); plugin~: constructed plugin "Simple amplifier" successfully plugin~: plugin ports: audio 1/1 ctrl 1/0 plugin~: plugin active
try running it with from the console with "-stderr", and see what it prints before dying. try increasing the verbosity with "-verbose -verbose" (2 times)
I'll try this and report back later :)
also, which version of PdX are you using?
i'm using Pd-vanilla 0.42-5
I'm using Pd version 0.41-4extended
i have now tested it with PdX-0.42-5extended-rc1 and it works ok as well.
fgamksdr IOhannes
On 2010-06-09 19:28, Kim Cascone wrote:
IOhannes m zmoelnig wrote:
attached here
are you sure you are using the updated version of plugin~? (it now prints the name of the plugin when it loads).
yes - I get a printout of the plug name for example when I instantiate a amp.so LADSPA I get plugin~: found plugin "amp" in library "/usr/lib/ladspa/amp_1181.so" plugin~: open_plugin (x, "amp", "/usr/lib/ladspa/amp_1181.so", 44100); plugin~: constructed plugin "Simple amplifier" successfully plugin~: plugin ports: audio 1/1 ctrl 1/0 plugin~: plugin active
this basically indicates that you are _not_ using the newest version.
in normal mode, when i construct a [plugin~ amp], i get _only_:
plugin~: "Simple amplifier"
when running with "-verbose -verbose", i get:
verbose( 2):plugin~: close_plugin (x) verbose( 1):plugin~: destructed plugin successfully verbose( 1):plugin~: found plugin "amp" in library
"/usr/lib/ladspa/amp_1181.so"
verbose( 2):plugin~: open_plugin (x, "amp",
"/usr/lib/ladspa/amp_1181.so", 44100);
verbose( 1):plugin~: constructed plugin "Simple amplifier" successfully verbose( 1):plugin~: plugin ports: audio 1/1 ctrl 1/0 verbose( 1):plugin~: plugin active plugin~: "Simple amplifier"
mfgasdr IOhannes
IOhannes m zmoelnig wrote:
On 2010-06-09 19:28, Kim Cascone wrote:
IOhannes m zmoelnig wrote:
attached here
are you sure you are using the updated version of plugin~? (it now prints the name of the plugin when it loads).
yes - I get a printout of the plug name for example when I instantiate a amp.so LADSPA I get plugin~: found plugin "amp" in library "/usr/lib/ladspa/amp_1181.so" plugin~: open_plugin (x, "amp", "/usr/lib/ladspa/amp_1181.so", 44100); plugin~: constructed plugin "Simple amplifier" successfully plugin~: plugin ports: audio 1/1 ctrl 1/0 plugin~: plugin active
this basically indicates that you are _not_ using the newest version.
ah OK is this NOT the url for the src?
the source code can be downloaded either via svn
(https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals/plug...)
or as a tarball from: http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/plugin...
the build-system is scons based ("apt-get install scons"; and then run "scons" in the directory)
in normal mode, when i construct a [plugin~ amp], i get _only_:
plugin~: "Simple amplifier"
when running with "-verbose -verbose", i get:
verbose( 2):plugin~: close_plugin (x) verbose( 1):plugin~: destructed plugin successfully verbose( 1):plugin~: found plugin "amp" in library
"/usr/lib/ladspa/amp_1181.so"
verbose( 2):plugin~: open_plugin (x, "amp",
"/usr/lib/ladspa/amp_1181.so", 44100);
verbose( 1):plugin~: constructed plugin "Simple amplifier" successfully verbose( 1):plugin~: plugin ports: audio 1/1 ctrl 1/0 verbose( 1):plugin~: plugin active plugin~: "Simple amplifier"
mfgasdr IOhannes
On Jun 9, 2010, at 4:15 PM, Kim Cascone wrote:
IOhannes m zmoelnig wrote:
On 2010-06-09 19:28, Kim Cascone wrote:
IOhannes m zmoelnig wrote:
attached here
are you sure you are using the updated version of plugin~? (it now prints the name of the plugin when it loads).
yes - I get a printout of the plug name for example when I instantiate a amp.so LADSPA I get plugin~: found plugin "amp" in library "/usr/lib/ladspa/amp_1181.so" plugin~: open_plugin (x, "amp", "/usr/lib/ladspa/amp_1181.so",
44100); plugin~: constructed plugin "Simple amplifier" successfully plugin~: plugin ports: audio 1/1 ctrl 1/0 plugin~: plugin activethis basically indicates that you are _not_ using the newest version.
ah OK is this NOT the url for the src?
Perhaps Pd is finding a plugin~ binary elsewhere first. YOu can see
which binary Pd loaded by turning on 'verbose' mode in the prefs or
from the cmd line.
.hc
the source code can be downloaded either via svn
(https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals/plug...
~)
or as a tarball from: http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/plugin
~.tar.gz?view=tar
the build-system is scons based ("apt-get install scons"; and
then run
"scons" in the directory)
in normal mode, when i construct a [plugin~ amp], i get _only_:
plugin~: "Simple amplifier"
when running with "-verbose -verbose", i get:
verbose( 2):plugin~: close_plugin (x) verbose( 1):plugin~: destructed plugin successfully verbose( 1):plugin~: found plugin "amp" in library
"/usr/lib/ladspa/amp_1181.so"
verbose( 2):plugin~: open_plugin (x, "amp",
"/usr/lib/ladspa/amp_1181.so", 44100);
verbose( 1):plugin~: constructed plugin "Simple amplifier"
successfully verbose( 1):plugin~: plugin ports: audio 1/1 ctrl 1/0 verbose( 1):plugin~: plugin active plugin~: "Simple amplifier"mfgasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
Hans-Christoph Steiner wrote:
On Jun 9, 2010, at 4:15 PM, Kim Cascone wrote:
IOhannes m zmoelnig wrote:
On 2010-06-09 19:28, Kim Cascone wrote:
IOhannes m zmoelnig wrote:
attached here
are you sure you are using the updated version of plugin~? (it now prints the name of the plugin when it loads).
yes - I get a printout of the plug name for example when I instantiate a amp.so LADSPA I get plugin~: found plugin "amp" in library "/usr/lib/ladspa/amp_1181.so" plugin~: open_plugin (x, "amp", "/usr/lib/ladspa/amp_1181.so", 44100); plugin~: constructed plugin "Simple amplifier" successfully plugin~: plugin ports: audio 1/1 ctrl 1/0 plugin~: plugin active
this basically indicates that you are _not_ using the newest version.
ah OK is this NOT the url for the src?
Perhaps Pd is finding a plugin~ binary elsewhere first. YOu can see which binary Pd loaded by turning on 'verbose' mode in the prefs or from the cmd line.
yeah that is what was happening it keeps loading the old one here instead of seeing the new one in my pd-externals dir:
so I replaced the old plugin~ in /flatspace/ with todays build deleted the old paths to the /plugin~ dir I created
launched PdX and console message was: tried /usr/lib/pd/extra/flatspace/plugin~.pd_linux and succeeded
I opened my test patch: 'plugin~June9.pd'
tried /usr/lib/pd/extra/flatspace/plugin~.pd_linux and succeeded verbose( 1):plugin~: found plugin "amp" in library "/usr/lib/ladspa/amp_1181.so" verbose( 1):plugin~: constructed plugin "Simple amplifier" successfully verbose( 1):plugin~: plugin ports: audio 1/1 ctrl 1/0 verbose( 1):plugin~: plugin active plugin~: "Simple amplifier"
then I sent down both [listplugins] and [info] but they still make PdX crash
I launched pd -stderr
and got the following:
kim@kim-laptop:~$ pd -stderr couldn't open MIDI input device 0 couldn't open MIDI output device 0 opened 0 MIDI input device(s) and 0 MIDI output device(s). tk scaling is 1.33202228777 tried but couldn't sync A/D/A libdir loader $Revision: 1.8 $ compiled on Jun 4 2009 at 14:32:58 compiled against Pd version 0.41.4.extended GEM: Graphics Environment for Multimedia GEM: ver: 0.91.3 'tigital' GEM: compiled: Jun 4 2009 GEM: maintained by IOhannes m zmoelnig GEM: Authors : Mark Danks (original version) GEM: Chris Clepper GEM: James Tittle GEM: IOhannes m zmoelnig GEM: with help by Guenter Geiger, Daniel Heckenberg, Cyrille Henry, et al. GEM: found a bug? miss a feature? please report it: GEM: homepage http://gem.iem.at/ GEM: bug-tracker http://sourceforge.net/projects/pd-gem/ GEM: mailing-list http://lists.puredata.info/listinfo/gem-dev/ GEM: compiled for SIMD architecture: MMX GEM: using MMX optimization libdir_loader: added 'ggee' to the global objectclass path libdir_loader: added 'memento' to the global objectclass path GridFlow 9.9, Copyright (c) 2001-2010 Mathieu Bouchard GridFlow was compiled on May 5 2010, 15:37:51 GF: setting stack size to -1 libdir_loader: added 'zexy' to the global objectclass path libdir_loader: added 'oscx' to the global objectclass path libdir_loader: added 'mapping' to the global objectclass path libdir_loader: added 'cyclone' to the global objectclass path libdir_loader: added 'flib' to the global objectclass path libdir_loader: added 'pddp' to the global objectclass path libdir_loader: added 'ext13' to the global objectclass path libdir_loader: added 'list-abs' to the global objectclass path libdir_loader: added 'motex' to the global objectclass path libdir_loader: added 'maxlib' to the global objectclass path libdir_loader: added 'pdogg' to the global objectclass path libdir_loader: added 'iemlib' to the global objectclass path libdir_loader: added 'pixeltango' to the global objectclass path libdir_loader: added 'flatspace' to the global objectclass path libdir_loader: added 'markex' to the global objectclass path libdir_loader: added 'mjlib' to the global objectclass path libdir_loader: added 'smlib' to the global objectclass path libdir_loader: added 'rradical' to the global objectclass path libdir_loader: added 'freeverb' to the global objectclass path libdir_loader: added 'toxy' to the global objectclass path libdir_loader: added 'unauthorized' to the global objectclass path libdir_loader: added 'jmmmp' to the global objectclass path libdir_loader: added 'pan' to the global objectclass path libdir_loader: added 'hcs' to the global objectclass path libdir_loader: added 'cxc' to the global objectclass path libdir_loader: added 'sigpack' to the global objectclass path libdir_loader: added 'creb' to the global objectclass path libdir_loader: added 'ekext' to the global objectclass path PDP: pure data packet version 0.12.5-darcs PiDiP : additional video processing objects for PDP version 0.12.23 ( ydegoyon@free.fr ) pdp_colorgrid: version 0.4 by Yves Degoyon (ydegoyon@free.fr) & Lluis Gomez i Bigorda (lluis@artefacte.org) pdp_ieee1394 : linux dv interface by Lluis Gomez i Bigorda (lluisgomez@hangar.org) extra: can't load library plugin~: "Simple amplifier" pd_gui: pd process exited Segmentation fault
not sure what else to try...
***another question I have is: if I get verbose( 1):plugin~: plugin ports: audio 1/1 ctrl 1/0
in the console when a plugin instantiates then what is the correct nomenclature to use when using this external in a patch?
KIM
.hc
the source code can be downloaded either via svn
(https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals/plug...)
or as a tarball from:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/plugin...
the build-system is scons based ("apt-get install scons"; and
then run
"scons" in the directory)
in normal mode, when i construct a [plugin~ amp], i get _only_:
plugin~: "Simple amplifier"
when running with "-verbose -verbose", i get:
verbose( 2):plugin~: close_plugin (x) verbose( 1):plugin~: destructed plugin successfully verbose( 1):plugin~: found plugin "amp" in library
"/usr/lib/ladspa/amp_1181.so"
verbose( 2):plugin~: open_plugin (x, "amp",
"/usr/lib/ladspa/amp_1181.so", 44100);
verbose( 1):plugin~: constructed plugin "Simple amplifier" successfully verbose( 1):plugin~: plugin ports: audio 1/1 ctrl 1/0 verbose( 1):plugin~: plugin active plugin~: "Simple amplifier"
mfgasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/10/2010 04:05 AM, Kim Cascone wrote:
yeah that is what was happening it keeps loading the old one here instead of seeing the new one in my pd-externals dir:
allright. Pd-extended often makes it a bit difficult to isolate things like that.
this is how i do it (and it's probably a good idea :-)
- go to plugin-sources
- compile with scons
- run Pd with the "-noprefs" flag
- open your plugin~-testpatch
so the trick is to use "-noprefs", which will make Pd(X) ignore the .pdsettings/.pdrc, so no libraries are loaded by default nor any paths are added but the "standard" ones ("extra/")
so I replaced the old plugin~ in /flatspace/ with todays build deleted the old paths to the /plugin~ dir I created
launched PdX and console message was: tried /usr/lib/pd/extra/flatspace/plugin~.pd_linux and succeeded
I opened my test patch: 'plugin~June9.pd'
tried /usr/lib/pd/extra/flatspace/plugin~.pd_linux and succeeded verbose( 1):plugin~: found plugin "amp" in library "/usr/lib/ladspa/amp_1181.so" verbose( 1):plugin~: constructed plugin "Simple amplifier" successfully verbose( 1):plugin~: plugin ports: audio 1/1 ctrl 1/0 verbose( 1):plugin~: plugin active plugin~: "Simple amplifier"
good.
then I sent down both [listplugins] and [info] but they still make PdX crash
bad.
when does it crash? when sending "listplugins" or when sending "info", or still with both?
I launched pd -stderr
unfortunately this gives loads of uninteresting info, and no interesting info.
better would be: $ cd path/to/plugin~ $ pd -noprefs -stderr -verbose -verbose plugin~-June08.pd
and see if something more interesting comes out of it.
also; would it be possible to run it within gdb?
and/or send me the test-patch and your /usr/lib/ladspa/amp_1181.so
mfgasdr IOhannes
On Jun 10, 2010, at 9:21 AM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/10/2010 04:05 AM, Kim Cascone wrote:
yeah that is what was happening it keeps loading the old one here instead of seeing the new one in my pd-externals dir:
allright. Pd-extended often makes it a bit difficult to isolate things like
that.this is how i do it (and it's probably a good idea :-)
- go to plugin-sources
- compile with scons
- run Pd with the "-noprefs" flag
- open your plugin~-testpatch
so the trick is to use "-noprefs", which will make Pd(X) ignore the .pdsettings/.pdrc, so no libraries are loaded by default nor any paths are added but the "standard" ones ("extra/")
so I replaced the old plugin~ in /flatspace/ with todays build deleted the old paths to the /plugin~ dir I created
launched PdX and console message was: tried /usr/lib/pd/extra/flatspace/plugin~.pd_linux and succeeded
I opened my test patch: 'plugin~June9.pd'
tried /usr/lib/pd/extra/flatspace/plugin~.pd_linux and succeeded verbose( 1):plugin~: found plugin "amp" in library "/usr/lib/ladspa/amp_1181.so" verbose( 1):plugin~: constructed plugin "Simple amplifier"
successfully verbose( 1):plugin~: plugin ports: audio 1/1 ctrl 1/0 verbose( 1):plugin~: plugin active plugin~: "Simple amplifier"good.
then I sent down both [listplugins] and [info] but they still make PdX crash
bad.
when does it crash? when sending "listplugins" or when sending "info", or still with both?
I launched pd -stderr
unfortunately this gives loads of uninteresting info, and no
interesting info.better would be: $ cd path/to/plugin~ $ pd -noprefs -stderr -verbose -verbose plugin~-June08.pd
and see if something more interesting comes out of it.
also; would it be possible to run it within gdb?
and/or send me the test-patch and your /usr/lib/ladspa/amp_1181.so
I did get random crashes on Mac OS X, but now I can 't reproduce
them. Its working for me. I improved the help file in the process of
testing.
.hc
mfgasdr IOhannes
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwQ5usACgkQkX2Xpv6ydvQGXQCgxWUlZhIHWMFwr1gINxujijxB ul8AoMr6Ophao4U5TSXMOD3L3DacTsG0 =snCy -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"[T]he greatest purveyor of violence in the world today [is] my own
government." - Martin Luther King, Jr.
Hans-Christoph Steiner wrote:
On Jun 10, 2010, at 9:21 AM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/10/2010 04:05 AM, Kim Cascone wrote:
yeah that is what was happening it keeps loading the old one here instead of seeing the new one in my pd-externals dir:
allright. Pd-extended often makes it a bit difficult to isolate things like that.
this is how i do it (and it's probably a good idea :-)
- go to plugin-sources
- compile with scons
- run Pd with the "-noprefs" flag
- open your plugin~-testpatch
so the trick is to use "-noprefs", which will make Pd(X) ignore the .pdsettings/.pdrc, so no libraries are loaded by default nor any paths are added but the "standard" ones ("extra/")
very useful trick! thanks!! and this did work so obviously there must be a library loading that affects [plugin~] ability to gather info
so I replaced the old plugin~ in /flatspace/ with todays build deleted the old paths to the /plugin~ dir I created
launched PdX and console message was: tried /usr/lib/pd/extra/flatspace/plugin~.pd_linux and succeeded
I opened my test patch: 'plugin~June9.pd'
tried /usr/lib/pd/extra/flatspace/plugin~.pd_linux and succeeded verbose( 1):plugin~: found plugin "amp" in library "/usr/lib/ladspa/amp_1181.so" verbose( 1):plugin~: constructed plugin "Simple amplifier" successfully verbose( 1):plugin~: plugin ports: audio 1/1 ctrl 1/0 verbose( 1):plugin~: plugin active plugin~: "Simple amplifier"
good.
then I sent down both [listplugins] and [info] but they still make PdX crash
bad.
when does it crash? when sending "listplugins" or when sending "info", or still with both?
it was both but now running with the -noprefs flag neither message crashes it
I launched pd -stderr
unfortunately this gives loads of uninteresting info, and no interesting info.
better would be: $ cd path/to/plugin~ $ pd -noprefs -stderr -verbose -verbose plugin~-June08.pd
and see if something more interesting comes out of it.
also; would it be possible to run it within gdb?
I have gdb loaded but not sure how to use it
and/or send me the test-patch and your /usr/lib/ladspa/amp_1181.so
I'm using the amp.so that comes with the LADSPA-sdk my patch and amp.so are zipped and attached
I am editing the 'hosting plugins' page on the PdX FOSS manuals and still need to know how to translate the info dumped by the plugin~ external into something a person can use it seems that the number of controls = #1 - #n ??? if this is the case it is unclear and confusing and needs to be clarified somewhere for other users coming to PdX from Max/MSP or other audio programming platforms
**I thank you both very much for taking the time to help me figure all this out :)
I think that being able to easily host a LADSPA, LV2, DSSI, or VST plug in PdX is a critically important part of building audio tools and should not be an issue in 2010 we're getting there! :) KIM
I did get random crashes on Mac OS X, but now I can 't reproduce them. Its working for me. I improved the help file in the process of testing.
.hc
mfgasdr IOhannes
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwQ5usACgkQkX2Xpv6ydvQGXQCgxWUlZhIHWMFwr1gINxujijxB ul8AoMr6Ophao4U5TSXMOD3L3DacTsG0 =snCy -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
IOhannes m zmölnig wrote:
allright. Pd-extended often makes it a bit difficult to isolate things like that.
this is how i do it (and it's probably a good idea :-)
- go to plugin-sources
- compile with scons
- run Pd with the "-noprefs" flag
- open your plugin~-testpatch
is there a way on the command line to load only certain libs? this way I don't have to delete them and retype them in on the 'libraries to load on startup' panel or is the simplest way to delete them from this list and put them back in one by one?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/10/2010 06:59 PM, Kim Cascone wrote:
is there a way on the command line to load only certain libs? this way I don't have to delete them and retype them in on the 'libraries to load on startup' panel or is the simplest way to delete them from this list and put them back in one by one?
the "paths" panel is mainly merely a graphical wrapper around the "-path" flag. e.g. "-path /path/to/lib1:/path2/lib2:/bla/blu"
the "startup" panel is mainly merely a graphical wrapper around the "-lib" flag. e.g. "-lib Gem:zexy:iemguts"
fgmasdr IOhannes
On Jun 10, 2010, at 2:02 PM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/10/2010 06:59 PM, Kim Cascone wrote:
is there a way on the command line to load only certain libs? this way I don't have to delete them and retype them in on the 'libraries to load on startup' panel or is the simplest way to delete them from this list and put them
back in one by one?the "paths" panel is mainly merely a graphical wrapper around the "-path" flag. e.g. "-path /path/to/lib1:/path2/lib2:/bla/blu"
the "startup" panel is mainly merely a graphical wrapper around the "-lib" flag. e.g. "-lib Gem:zexy:iemguts"
You could also create your own .pdextended file to make it not load
any libraries by default. That's the direction we are going with Pd-
extended anyway. Check out /usr/lib/pdextended/default.pdextended to
see the one that's loaded by default.
.hc
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
Hans-Christoph Steiner wrote:
You could also create your own .pdextended file to make it not load any libraries by default. That's the direction we are going with Pd-extended anyway. Check out /usr/lib/pdextended/default.pdextended to see the one that's loaded by default.
ah ha! good tip! thanks! I'll just comment out the libs and add them one by one this way much easier :)
Hans-Christoph Steiner wrote:
You could also create your own .pdextended file to make it not load any libraries by default. That's the direction we are going with Pd-extended anyway. Check out /usr/lib/pdextended/default.pdextended to see the one that's loaded by default.
can't seem to comment lines out of the pdextended file using '#' at the beginning of a line is there a different way to do this?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/11/2010 12:07 AM, Kim Cascone wrote:
can't seem to comment lines out of the pdextended file using '#' at the beginning of a line is there a different way to do this?
backup your .pdsettings file then edit the .pdsettings: remove the offending libs and set the libcount accordingly.
fgsdmf IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/10/2010 06:59 PM, Kim Cascone wrote:
is there a way on the command line to load only certain libs? this way I don't have to delete them and retype them in on the 'libraries to load on startup' panel or is the simplest way to delete them from this list and put them back in one by one?
the "paths" panel is mainly merely a graphical wrapper around the "-path" flag. e.g. "-path /path/to/lib1:/path2/lib2:/bla/blu"
true but doing this from a terminal will only add paths on a per session basis unless you open the 'paths' panel and click on Apply is there a way to make this persistent from the console?
the "startup" panel is mainly merely a graphical wrapper around the "-lib" flag. e.g. "-lib Gem:zexy:iemguts"
ok thanks - will try adding one at a time and seeing which one causes the [plugin~] crash more later
On Jun 10, 2010, at 3:09 PM, Kim Cascone wrote:
IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/10/2010 06:59 PM, Kim Cascone wrote:
is there a way on the command line to load only certain libs? this way I don't have to delete them and retype them in on the 'libraries to load on startup' panel or is the simplest way to delete them from this list and put them
back in one by one?the "paths" panel is mainly merely a graphical wrapper around the "-path" flag. e.g. "-path /path/to/lib1:/path2/lib2:/bla/blu"
true but doing this from a terminal will only add paths on a per
session basis unless you open the 'paths' panel and click on Apply is there a way to make this persistent from the console?the "startup" panel is mainly merely a graphical wrapper around the "-lib" flag. e.g. "-lib Gem:zexy:iemguts"
ok thanks - will try adding one at a time and seeing which one
causes the [plugin~] crash more later
The one that causes plugin~ to crash is likely 'flatspace' since it
includes the old, buggy version of plugin~. If you put the
plugin~.pd_linux into your project folder, it will be loaded first.
.hc
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
Hans-Christoph Steiner wrote:
On Jun 10, 2010, at 3:09 PM, Kim Cascone wrote:
IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/10/2010 06:59 PM, Kim Cascone wrote:
is there a way on the command line to load only certain libs? this way I don't have to delete them and retype them in on the 'libraries to load on startup' panel or is the simplest way to delete them from this list and put them back in one by one?
the "paths" panel is mainly merely a graphical wrapper around the "-path" flag. e.g. "-path /path/to/lib1:/path2/lib2:/bla/blu"
true but doing this from a terminal will only add paths on a per session basis unless you open the 'paths' panel and click on Apply is there a way to make this persistent from the console?
the "startup" panel is mainly merely a graphical wrapper around the "-lib" flag. e.g. "-lib Gem:zexy:iemguts"
ok thanks - will try adding one at a time and seeing which one causes the [plugin~] crash more later
The one that causes plugin~ to crash is likely 'flatspace' since it includes the old, buggy version of plugin~.
yeah I already compiled the new [plugin~] and replaced the old one in the /flatspace lib so there is something else either in /flatspace or another lib causing [plugin~] to crash when getting a [info] or [listplugins] message but I'll isolate the new [plugin~] from the rest of the /flatspace and see if that is true
If you put the plugin~.pd_linux into your project folder, it will be loaded first.
by 'project folder' do you mean the '~/pd-externals' directory?
On Jun 10, 2010, at 3:51 PM, Kim Cascone wrote:
Hans-Christoph Steiner wrote:
On Jun 10, 2010, at 3:09 PM, Kim Cascone wrote:
IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/10/2010 06:59 PM, Kim Cascone wrote:
is there a way on the command line to load only certain libs? this way I don't have to delete them and retype them in on the 'libraries to load on startup' panel or is the simplest way to delete them from this list and put
them back in one by one?the "paths" panel is mainly merely a graphical wrapper around the "-path" flag. e.g. "-path /path/to/lib1:/path2/lib2:/bla/blu"
true but doing this from a terminal will only add paths on a per
session basis unless you open the 'paths' panel and click on Apply is there a way to make this persistent from the console?the "startup" panel is mainly merely a graphical wrapper around the "-lib" flag. e.g. "-lib Gem:zexy:iemguts"
ok thanks - will try adding one at a time and seeing which one
causes the [plugin~] crash more laterThe one that causes plugin~ to crash is likely 'flatspace' since it
includes the old, buggy version of plugin~.yeah I already compiled the new [plugin~] and replaced the old one
in the /flatspace lib so there is something else either in /flatspace or another lib
causing [plugin~] to crash when getting a [info] or [listplugins]
message but I'll isolate the new [plugin~] from the rest of the /flatspace
and see if that is trueIf you put the plugin~.pd_linux into your project folder, it will
be loaded first.by 'project folder' do you mean the '~/pd-externals' directory?
No, say you have a Pd project, all the patches are in a folder called /
home/hans/Documents/myproject, then you'd put the plugin~.pd_linux
there. You can put it into ~/pd-externals too, that's a bit lower in
the totem pole of loading.
.hc
Access to computers should be unlimited and total. - the hacker ethic
Hans-Christoph Steiner wrote:
If you put the plugin~.pd_linux into your project folder, it will be loaded first.
by 'project folder' do you mean the '~/pd-externals' directory?
No, say you have a Pd project, all the patches are in a folder called /home/hans/Documents/myproject, then you'd put the plugin~.pd_linux there.
ah I see - so similar to Max where it looks in the same dir as the patch first - and patches with special externals can be more portable by putting everything in one dir got it thanks!
You can put it into ~/pd-externals too, that's a bit lower in the totem pole of loading.
OK good to know
.hc
Access to computers should be unlimited and total. - the hacker ethic
I did some testing with the libs to see which one was making PdX crash when sending [info] and [listplugins] to the [plugin~] external
I moved all libs out of 'usr/lib/pd/extras/' directory and moved them back in one at a time while launching PdX in between each addition
I found the Gem lib was causing the crash so I did the same testing with the Gem directory and found that
Gem.pd_linux
was the file in the Gem lib that is making PdX crash when sending down [info] and [listplugins] to [plugin~]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/10/2010 08:51 PM, Kim Cascone wrote:
The one that causes plugin~ to crash is likely 'flatspace' since it includes the old, buggy version of plugin~.
well, true and false. "flatspace" is likely to pull in the wrong version of plugin~. however, if you are loading the correct version of "plugin~" than floatspace is most likely not the culprit, but some other library (real library - a file with .pd_linux, not a "libdir")
fgdmas IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/10/2010 08:09 PM, Kim Cascone wrote:
IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/10/2010 06:59 PM, Kim Cascone wrote:
is there a way on the command line to load only certain libs? this way I don't have to delete them and retype them in on the 'libraries to load on startup' panel or is the simplest way to delete them from this list and put them back in one by one?
the "paths" panel is mainly merely a graphical wrapper around the "-path" flag. e.g. "-path /path/to/lib1:/path2/lib2:/bla/blu"
true but doing this from a terminal will only add paths on a per session basis
i thought this is what you were asking for with "is there a way on the command line to load only certain libs?"
we are talking about isolating a bug, aren't we?
unless you open the 'paths' panel and click on Apply is there a way to make this persistent from the console?
use a shell-script.
msas IOhannes
IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/10/2010 08:09 PM, Kim Cascone wrote:
IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/10/2010 06:59 PM, Kim Cascone wrote:
is there a way on the command line to load only certain libs? this way I don't have to delete them and retype them in on the 'libraries to load on startup' panel or is the simplest way to delete them from this list and put them back in one by one?
the "paths" panel is mainly merely a graphical wrapper around the "-path" flag. e.g. "-path /path/to/lib1:/path2/lib2:/bla/blu"
true but doing this from a terminal will only add paths on a per session basis
i thought this is what you were asking for with "is there a way on the command line to load only certain libs?"
yes, but I'm trying to understand your statement: 'the panel merely being a wrapper around the -path flag'
unless I'm not understanding something making these changes from the panel in Pd these settings are persistent making them from the command line they are not
libs loaded gets written to the 'default.pdsettings' file and is easier to make changes there except PdX doesn't recognize '# comments'
but I found going root and physically moving them back in in nautilus was easier
we are talking about isolating a bug, aren't we?
unless you open the 'paths' panel and click on Apply is there a way to make this persistent from the console?
use a shell-script.
a shell script would only work on a per session basis as well - no?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/11/2010 01:49 AM, Kim Cascone wrote:
i thought this is what you were asking for with "is there a way on the command line to load only certain libs?"
yes, but I'm trying to understand your statement: 'the panel merely being a wrapper around the -path flag'
ah in understand. i was referring to the path-entry box, and not to the "apply/save" buttons in the panels.
both the cmd-line flags and the .pdsettings are a way to configure your Pd sessions; none of them are a way to script Pd (which it seems is what you were expecting: being able to script Pd from the cmdline to store it's preferences to a file) [1]
unless I'm not understanding something making these changes from the panel in Pd these settings are persistent making them from the command line they are not
the question is, why would you want to make the settings persistens from the console? and how is this .pdsettings more persistent than cmdline flags or a shell-scripts.
is there a way to make this persistent from the console?
use a shell-script.
a shell script would only work on a per session basis as well - no?
all settings are "per session"; whenever you run the shell-script with the same-flags, you will have the same behaviour of Pd. .pdsettings are just a more user friendly way to provide Pd-settings (for users that are afraid of the cli; e.g. i regularily delete my .pdsettings, because i don't need it and it only interferes with what i'm doing)
anyhow, since Pd is cool and despite of what i said above, it even allows you to save your preferences with shell-flags.
[1] pd -lib blu -send "pd save-preferences ;"
fgmasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/11/2010 08:30 AM, IOhannes m zmölnig wrote:
a shell script would only work on a per session basis as well - no?
all settings are "per session"; whenever you run the shell-script with the same-flags, you will have the same behaviour of Pd.
to avoid confusion, this should have read "[...] run the same shell-script (which obviously has the same flags stored within at each call) [...]"
.pdsettings are just a more user friendly way to provide Pd-settings (for users that are afraid of the cli; e.g. i regularily delete my .pdsettings, because i don't need it and it only interferes with what i'm doing)
of course, my deletion is not so regulary, as i usually don't have a .pdsettings, sometimes i do generate one (e.g. just now to test the "scripted pref-saving"), and only then do i delete them.
gfsfdg IOhannes
IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/11/2010 01:49 AM, Kim Cascone wrote:
i thought this is what you were asking for with "is there a way on the command line to load only certain libs?"
yes, but I'm trying to understand your statement: 'the panel merely being a wrapper around the -path flag'
ah in understand. i was referring to the path-entry box, and not to the "apply/save" buttons in the panels.
OK so I grok that the panel is just a gui for the command line and that if you do not hit the Apply button all the paths are also 'per session'
I guess I've been hitting the Apply button automatically and never checked what happens if I didn't hit Apply
in Max/MSP you can simply enter a path into the 'file prefs' panel and it will be there after relaunching - so this is the behavior I expected to see only because I've used Max/MSP for 10+ years
both the cmd-line flags and the .pdsettings are a way to configure your Pd sessions; none of them are a way to script Pd (which it seems is what you were expecting:
actually, it seems that the .pdsettings are loaded on start up -- no? so wouldn't that make them a sort of script too - in a sense? i.e. changes made to this file are 'persistent' across program startups so long as the .pdsettings file is unchanged
being able to script Pd from the cmdline to store it's preferences to a file) [1]
yes, I was only interested in creating a workflow that would make testing plugin~ smoother no big deal about not being able to set -flags persistently
unless I'm not understanding something making these changes from the panel in Pd these settings are persistent making them from the command line they are not
the question is, why would you want to make the settings persistens from the console? and how is this .pdsettings more persistent than cmdline flags or a shell-scripts.
.pdsettings gets loaded on startup - no? so, if I make changes directly to this file in gedit won't those changes be loaded as well? sorry, I'm just trying to understand all this better :)
is there a way to make this persistent from the console?
use a shell-script.
a shell script would only work on a per session basis as well - no?
all settings are "per session"; whenever you run the shell-script with the same-flags, you will have the same behaviour of Pd. .pdsettings are just a more user friendly way to provide Pd-settings (for users that are afraid of the cli; e.g. i regularily delete my .pdsettings, because i don't need it and it only interferes with what i'm doing)
anyhow, since Pd is cool and despite of what i said above, it even allows you to save your preferences with shell-flags.
[1] pd -lib blu -send "pd save-preferences ;"
ah ha! the truth comes out! ;) so in trying to understand the flags above -lib loads the 'blu' library and -send sends PdX a message to save-preferences? is this prefs stored as the .pdsettings file?
thanks again for your PdX lessons - they help me understand the difference between Max and Pd :) ==================================
also, I found some other bugs/issues in [plugin~] see attached file for info
===================================
one thing not included in the file is a difference between what analyseplugins <foo> returns in the term versus what [info] returns from [plugin~] in the console
here is an example for the 'delayorama' LADSPA plug:
sudo analyseplugin delayorama_1402.so
"Random seed" input, control, 0 to 1000, default 0, integer "Input gain (dB)" input, control, -96 to 24, default 0 "Feedback (%)" input, control, 0 to 100, default 0 "Number of taps" input, control, 2 to 128, default 2, integer "First delay (s)" input, control, 0 to 5, default 0 "Delay range (s)" input, control, 0.0001 to 6, default 6 "Delay change" input, control, 0.2 to 5, default 1 "Delay random (%)" input, control, 0 to 100, default 0 "Amplitude change" input, control, 0.2 to 5, default 1 "Amplitude random (%)" input, control, 0 to 100, default 0 "Dry/wet mix" input, control, 0 to 1, default 1 "Input" input, audio "Output" output, audio
======================================= versus the PdX console sent when sending [info] to plugin~ =======================================
verbose( 1):plugin~: constructed plugin "Delayorama" successfully verbose( 1):plugin~: plugin ports: audio 1/1 ctrl 11/0 verbose( 1):plugin~: plugin active plugin~: "Delayorama" print: port in control Random seed 0 1000 error: [print]: close-paren without open-paren error: [print]: close-paren without open-paren print: port in control Number of taps 2 128 error: [print]: close-paren without open-paren error: [print]: close-paren without open-paren print: port in control Delay change 0.2 5 error: [print]: close-paren without open-paren print: port in control Amplitude change 0.2 5 error: [print]: close-paren without open-paren print: port in control Dry/wet mix 0 1 print: port in audio Input 0 1 print: port out audio Output 0 1
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/11/2010 09:22 AM, Kim Cascone wrote:
actually, it seems that the .pdsettings are loaded on start up -- no? so wouldn't that make them a sort of script too - in a sense?
yes, it's a script in a "declarative language", with a very minimalistic feature set. it's not what i would call a script in everyday life (which for me is usually very imperative). "in a sense" everything is a script.
yes, I was only interested in creating a workflow that would make testing plugin~ smoother no big deal about not being able to set -flags persistently
that's why i was wondering...
.pdsettings gets loaded on startup - no?
yes
so, if I make changes directly to this file in gedit won't those changes be loaded as well?
sure; that's the point of a configuration file.
though i don't get your point. if you have a shell script like:
<snip> #!/bin/sh pd -path /path/to/nowhere -lib rary </snip>
and you run this script, then Pd will persistently add /path/to/nowhere to it's search-path and it will persistently try to load the "rary" lib. every single time you run the script. if you open the script in gedit, and change the "nowhere" to "anywhere", then the Pd will persistently add /path/to/anywhere whenever started from this script.
you can then ignore the pdsettings.
but you can have multiple scripts with different AND still persistent configuration settings, that don't interfere with each other and you don't have to fiddle around with the "configuration-switcher" hack.
thanks again for your PdX lessons - they help me understand the difference between Max and Pd :)
my lessons are not PdX lessons; they are Pd-vanilla lessons; fortunately they also apply to PdX.
==================================
also, I found some other bugs/issues in [plugin~] see attached file for info
where do you have this helpfile from? it seems to be unrelated to mine. i have not found any traces of "bind" and the like in the source-code for plugin~.c have i fixed the wrong code?
===================================
plugin~: "Delayorama" print: port in control Random seed 0 1000
looks good, doesn't it?
error: [print]: close-paren without open-paren
oops; seems there is a problem with displaying symbols with parenthesis.
i don't seem to have this problem here (though i don't have the delayorama plugin; and the "invada_mono_tube_module_0_1" works just fine (with pd-vanilla 0.42.6)
fdgmasr IOhannes
IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/11/2010 09:22 AM, Kim Cascone wrote:
actually, it seems that the .pdsettings are loaded on start up -- no? so wouldn't that make them a sort of script too - in a sense?
yes, it's a script in a "declarative language", with a very minimalistic feature set. it's not what i would call a script in everyday life (which for me is usually very imperative). "in a sense" everything is a script.
sure if we 'go wide' on this I suppose even the Bible is a script - for some people... ;)
yes, I was only interested in creating a workflow that would make testing plugin~ smoother no big deal about not being able to set -flags persistently
that's why i was wondering...
.pdsettings gets loaded on startup - no?
yes
so, if I make changes directly to this file in gedit won't those changes be loaded as well?
sure; that's the point of a configuration file.
though i don't get your point. if you have a shell script like:
<snip> #!/bin/sh pd -path /path/to/nowhere -lib rary </snip>
and you run this script, then Pd will persistently add /path/to/nowhere to it's search-path and it will persistently try to load the "rary" lib. every single time you run the script. if you open the script in gedit, and change the "nowhere" to "anywhere", then the Pd will persistently add /path/to/anywhere whenever started from this script.
you can then ignore the pdsettings.
but you can have multiple scripts with different AND still persistent configuration settings, that don't interfere with each other and you don't have to fiddle around with the "configuration-switcher" hack.
right -- the script idea sounds like a good idea but not how I want to work right now I launch PdX from my Gnome-do dock
thanks again for your PdX lessons - they help me understand the difference between Max and Pd :)
my lessons are not PdX lessons; they are Pd-vanilla lessons; fortunately they also apply to PdX.
OK then...thanks for the Pd-vanilla lessons! :)
==================================
also, I found some other bugs/issues in [plugin~] see attached file for info
where do you have this helpfile from?
I've been working on testing plugin~ and ladspa~ and dssi~ so I can't remember exactly in all my downloads, compiles and testing where that might have come from but what's odd is how that bind subpatch appeared out of nowhere and that I'm using it as a .help file I'll replace this with one from the svn http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/plugin...
it seems to be unrelated to mine. i have not found any traces of "bind" and the like in the source-code for plugin~.c have i fixed the wrong code?
===================================
plugin~: "Delayorama" print: port in control Random seed 0 1000
looks good, doesn't it?
er, sure if it matched the console report (when plugin~ is sent [info]) it would look even better! ;)
is this a bug or known issue?
error: [print]: close-paren without open-paren
oops; seems there is a problem with displaying symbols with parenthesis.
I'm assuming here that not all LADSPA plugs send info with parentheses? so this would be a problem only for those plugs that send data with parentheses ??
also, I also noticed that I can't use a number in the [print] external in my current version of PdX that I'm working in without causing the error: 'expected symbol' but in the latest version of PdX I can use a number as well as a symbol in [print]
i don't seem to have this problem here (though i don't have the delayorama plugin;
I've attached it - see if this works for you?
and the "invada_mono_tube_module_0_1" works just fine (with pd-vanilla 0.42.6)
***do you have any info on how params are listed in [info]->[plugin~] versus [analyseplugin <foo>] in the term? how does one understand what to name the params when controlling a plugin?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/11/2010 10:36 AM, Kim Cascone wrote:
plugin~: "Delayorama" print: port in control Random seed 0 1000
looks good, doesn't it?
er, sure if it matched the console report (when plugin~ is sent [info]) it would look even better! ;)
it reports all "relevant" information.
is this a bug or known issue?
error: [print]: close-paren without open-paren
oops; seems there is a problem with displaying symbols with parenthesis.
I'm assuming here that not all LADSPA plugs send info with parentheses? so this would be a problem only for those plugs that send data with parentheses
correct. anyhow, when i try your plugin i get:
<snip> plugin~: "Delayorama" a: port in control Random seed 0 1000 a: port in control Input gain (dB) -96 24 a: port in control Feedback (%) 0 100 a: port in control Number of taps 2 128 a: port in control First delay (s) 0 5 a: port in control Delay range (s) 0.0001 6 a: port in control Delay change 0.2 5 a: port in control Delay random (%) 0 100 a: port in control Amplitude change 0.2 5 a: port in control Amplitude random (%) 0 100 a: port in control Dry/wet mix 0 1 a: port in audio Input 0 1 a: port out audio Output 0 1 </snip>
looks good to me.
??
i don't seem to have this problem here (though i don't have the delayorama plugin;
I've attached it - see if this works for you?
and the "invada_mono_tube_module_0_1" works just fine (with pd-vanilla 0.42.6)
***do you have any info on how params are listed in [info]->[plugin~] versus [analyseplugin <foo>] in the term? how does one understand what to name the params when controlling a plugin?
the message is: "port symbol:direction symbol:type symbol:name float:lowerlimit float:upperlimit"
with symbol:direction being either "in" or "out" with symbol:type being "control" or "audio" with symbol:name being the name of the port (e.g. "Amplitude random (%)")
and lower/upperlimit define the valid range of the value.
for controlling, you use "control symbol:name float:value"
symbol:name is not case-sensitive, and it tries to find a simple match. e.g. "Amplitude random (%)" can be controlled with "amp" or "AMPLItude" or "Amplitude random (%)". it will take the first port that matches, so if you have parameters "FrequencyUpper" and "FrequencyLower", then "freq" will match "FrequencyUpper", in order to conrol the other param you have to use at least "frequencyl"
also, I also noticed that I can't use a number in the [print] external in my current version of PdX that I'm working in without causing the error: 'expected symbol' but in the latest version of PdX I can use a number as well as a symbol in [print]
well, you can use [print :1], if you want to stay compatible with e.g. Pd-vanilla.
mfgasdr IOhannes
On Fri, 11 Jun 2010, Kim Cascone wrote:
I'm assuming here that not all LADSPA plugs send info with parentheses? so this would be a problem only for those plugs that send data with parentheses ??
yes, only if they use GridFlow's [print].
also, I also noticed that I can't use a number in the [print] external in my current version of PdX that I'm working in without causing the error: 'expected symbol' but in the latest version of PdX I can use a number as well as a symbol in [print]
ok, I'd like more info about this one, because I've never seen it and it sounds terrible. which versions of pd-extended and of gridflow ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/11/2010 05:26 PM, Mathieu Bouchard wrote:
ok, I'd like more info about this one, because I've never seen it and it sounds terrible. which versions of pd-extended and of gridflow ?
older Pd versions would not allow numeric arguments to [print]. newer versions seem to do allow it.
i don't think that the problem is related to GF.
fgasmdr IOhannes
Mathieu Bouchard wrote:
On Fri, 11 Jun 2010, Kim Cascone wrote:
I'm assuming here that not all LADSPA plugs send info with parentheses? so this would be a problem only for those plugs that send data with parentheses ??
yes, only if they use GridFlow's [print].
so there is a pd [print] and a GridFlow [print] object?
is there a way to use pd's [print] object instead of the GF one?
also, I also noticed that I can't use a number in the [print] external in my current version of PdX that I'm working in without causing the error: 'expected symbol' but in the latest version of PdX I can use a number as well as a symbol in [print]
ok, I'd like more info about this one, because I've never seen it and it sounds terrible. which versions of pd-extended and of gridflow ?
Pd version 0.41-4extended GridFlow 9.9
I'm using an older version of PdX because I'm on Ubuntu 9.04 still and unable to install the newest PdX due to dep issues which I don't have time to chase down right now
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Fri, 11 Jun 2010, IOhannes m zmölnig wrote:
On 06/11/2010 09:22 AM, Kim Cascone wrote:
error: [print]: close-paren without open-paren
oops; seems there is a problem with displaying symbols with parenthesis. i don't seem to have this problem here (though i don't have the delayorama plugin; and the "invada_mono_tube_module_0_1" works just fine (with pd-vanilla 0.42.6)
"close-paren without open-paren" is a GridFlow error message. The code for parsing nested-lists interferes with the [print] emulation that replaces the original [print]. The latest GridFlow renames the old [print] to [pd/print].
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/11/2010 05:13 PM, Mathieu Bouchard wrote:
"close-paren without open-paren" is a GridFlow error message. The code for parsing nested-lists interferes with the [print] emulation that replaces the original [print]. The latest GridFlow renames the old [print] to [pd/print].
but the message in question had open-parent and close-paren. so why does it throw the error.
furthermore, the parenthesis only appeared within a symbol. why does gf's print try to parse a symbol as a nested list?
fgmasdr IOhannes
On Fri, 11 Jun 2010, IOhannes m zmölnig wrote:
On 06/11/2010 05:13 PM, Mathieu Bouchard wrote:
"close-paren without open-paren" is a GridFlow error message. The code for parsing nested-lists interferes with the [print] emulation that replaces the original [print]. The latest GridFlow renames the old [print] to [pd/print].
but the message in question had open-parent and close-paren. so why does it throw the error.
Because GF doesn't parse the complete symbol because it needs to do it real fast as it has to continually do it for every symbol that comes into any inlet of GF. When I have a list like (1 2 3) then "(1" is a symbol and "3)" is a symbol. But when doing things like that, open-parens only happen at the beginning of a symbol and close-parens only happen at the end. In your case, one of the spaces is a real space inside of a symbol, therefore the "(" is not recognised as opening, but the ")" is before a separating space, and thus it counts.
furthermore, the parenthesis only appeared within a symbol. why does gf's print try to parse a symbol as a nested list?
because Pd's syntax is insufficiently developed. I used to be able to write {1 2 3} and the software's parser would parse it as an element of type 'list'. Then I had to switch to Pd and had to add weird hacks to keep on supporting such a thing.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Jun 9, 2010, at 12:34 PM, IOhannes m zmoelnig wrote:
On 2010-06-09 18:23, Kim Cascone wrote:
IOhannes m zmoelnig wrote:
On 2010-06-09 09:27, IOhannes m zmoelnig wrote:
- sending the [info] and [listplugins] messages to [plugin~]
make PdX crash immediately
i'll look into that.
i couldn't reproduce this as described. indeed i found a bug that would crash Pd, when a previously loaded plugin was "used" after calling [listplugins( (e.g. instantiate [plugin~ stereo_amp], call [listplugins( and
then call [info] -> kaboom!)IOhannes I just built the latest src for plugin~ I get the exact same behavior when sending down a [info] message
instantiate [plugin~ amp], connect [noise~] to it, turn on dsp, send [info] to [plugin~], pdx crashes
hmm, could you provide a test-patch? are you sure you are using the updated version of plugin~? (it now prints the name of the plugin when it loads).
try running it with from the console with "-stderr", and see what it prints before dying. try increasing the verbosity with "-verbose -verbose" (2 times)
also, which version of PdX are you using?
i'm using Pd-vanilla 0.42-5
I'm using Pd version 0.41-4extended
i have now tested it with PdX-0.42-5extended-rc1 and it works ok as
well.fgamksdr IOhannes
Just checked with Pd-extended 0.42.5-rc1 on Mac OS X 10.5.8/Intel
using 'ladspa-cmt' pacakge from Fink. I get no crashes. I do
randomly get this message: "error: plugin~: plugin not found".
If I convert all the 'print' messages to 'info', then I get the inlet/ outlet info from the left outlet.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Kim Cascone -
Mathieu Bouchard