IOhannes m zmölnig wrote:
sure if we 'go wide' on this I suppose even the Bible is a script - for some people... ;)-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1On 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 persistentlythat's why i was wondering....pdsettings gets loaded on startup - no?yesso, 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 infowhere 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~/plugin~-help.pd?view=log
er, sure if it matched the console report (when plugin~ is sent [info]) it would look even better! ;)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 1000looks good, doesn't it?
is this a bug or known issue?
error: [print]: close-paren without open-parenoops; 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 thedelayorama plugin;
I've attached it - see if this works for you?
***do you have any info on how params are listed in [info]->[plugin~] versus [analyseplugin <foo>] in the term?and the "invada_mono_tube_module_0_1" works just fine (with pd-vanilla 0.42.6)
how does one understand what to name the params when controlling a plugin?
delayorama_1402.so.tar.gz
Description: GNU Zip compressed data
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
