hi pd-list!
i have recently tried to build some filters using cpole and czero, not completely unsuccessfull (at least the lowpass sounds somewhat like a lowpass...), but i have a problem calculating the right gain (or attenuation) factor. for the lp it seems to work more or less (ok for a subtractive synth, but still not good enough for effects etc.), but the hp is either too lound for lower frequencies and low resonance, or hardly audible. i think there might be a better way to find out the right gain than 'try and error'. and its getting worse with more poles involved... so is it possible to get the gain from the poles and zeros, without calculating all coefficients?
bis denn! martin
#N canvas 156 137 470 338 10; #X obj 82 263 dac~; #X floatatom 1 8 5 0 0 0 - - -; #X obj 235 4 hsl 128 15 0.05 0.99 0 1 empty empty empty -2 -6 0 8 -262144 -1 -1 4700 1; #X text 229 -16 res; #X text 91 -17 cut; #X obj 93 1 hsl 128 15 0 128 0 1 empty empty empty -2 -6 0 8 -262144 -1 -1 5600 1; #X obj 162 143 mtof; #X obj 3 47 phasor~ 222; #N canvas 190 170 920 635 simple_reson_lp1 0; #X obj -19 398 cpole~; #X obj 31 440 czero~; #X obj 27 494 outlet~; #X obj -173 141 inlet~; #X obj -53 364 *~; #X obj 31 118 /~ 2; #X obj 32 238 cos~; #X obj 95 182 -~ 0.25; #X obj 96 203 cos~; #X obj 96 256 *~; #X obj 225 183 clip~ 0.05 0.99; #X obj 236 146 inlet~; #X obj -60 305 *~; #X obj -81 266 +~ 2; #X obj -84 237 *~ 0.5; #X obj -27 279 -~; #X obj 32 90 clip~ 0 1; #X obj 36 34 /~ 11025; #X obj 34 5 inlet~; #X text -123 141 audio in; #X text 81 5 cutoff; #X text 287 143 resonance; #X text 55 368 zero at nyquist; #X text 99 35 1/4 samplerate; #X text -128 198 attenuation factor; #X text -128 214 (1-x)*(1/2*angle+2); #X text 70 118 pi/2 for audio cos; #X text -256 396 pole: cos(angle) , sin(angle)+res; #X text 39 220 cosine; #X text 147 191 sine; #X text -310 363 multiply input by attenuation factor; #X text -404 106 4/2008 martin brinkmann; #X text -405 8 slightly crude (especially the attenuatiun factor) lowpass filter design , made without knowing too much of the math involved. frequency is not very exact , but at least it sounds like a reson filter :-); #X text -404 63 a pole is moved along the unit-circle on a kind of rugby-egg-shaped path , while a zero sits at -1 , 0 (nyquist frequency) , which makes a resonant lowpass filter.; #X text 100 54 cutoff (or angle on the unit circle , usually 0..pi (0..nyquist) , but here 0..0.5 because of the cos~ audio object); #X obj -32 246 sig~ 1; #X obj 45 393 sig~ -1; #X obj 104 393 sig~ 0; #X connect 0 0 1 0; #X connect 0 1 1 1; #X connect 1 0 2 0; #X connect 3 0 4 0; #X connect 4 0 0 0; #X connect 5 0 7 0; #X connect 5 0 6 0; #X connect 6 0 0 2; #X connect 6 0 15 1; #X connect 7 0 8 0; #X connect 8 0 9 0; #X connect 9 0 0 3; #X connect 10 0 9 1; #X connect 11 0 10 0; #X connect 12 0 4 1; #X connect 13 0 12 0; #X connect 14 0 13 0; #X connect 15 0 12 1; #X connect 16 0 5 0; #X connect 16 0 14 0; #X connect 17 0 16 0; #X connect 18 0 17 0; #X connect 35 0 15 0; #X connect 36 0 1 2; #X connect 37 0 1 3; #X restore 102 192 pd simple_reson_lp1; #X connect 1 0 7 0; #X connect 2 0 8 2; #X connect 5 0 6 0; #X connect 6 0 8 1; #X connect 7 0 8 0; #X connect 8 0 0 0; #X connect 8 0 0 1;
#N canvas 69 503 470 338 10; #X obj 82 263 dac~; #X floatatom 1 8 5 0 0 0 - - -; #X obj 235 4 hsl 128 15 0.05 0.99 0 1 empty empty empty -2 -6 0 8 -262144 -1 -1 4500 1; #X text 229 -16 res; #X text 91 -17 cut; #X obj 93 1 hsl 128 15 0 128 0 1 empty empty empty -2 -6 0 8 -262144 -1 -1 12400 1; #X obj 144 81 mtof; #X obj 3 47 phasor~ 222; #N canvas 167 157 920 635 simple_reson_hp1 0; #X obj -19 398 cpole~; #X obj 49 519 czero~; #X obj 49 591 outlet~; #X obj -173 141 inlet~; #X obj 31 118 /~ 2; #X obj 16 184 cos~; #X obj 95 182 -~ 0.25; #X obj 96 203 cos~; #X obj 96 256 *~; #X obj 225 183 clip~ 0.05 0.99; #X obj 236 146 inlet~; #X obj 33 34 /~ 11025; #X obj 34 5 inlet~; #X text -123 141 audio in; #X text 81 5 cutoff; #X text 287 143 resonance; #X text 99 35 1/4 samplerate; #X text 70 118 pi/2 for audio cos; #X text -256 396 pole: cos(angle) , sin(angle)+res; #X text 29 167 cosine; #X text 147 191 sine; #X text -310 321 multiply input by attenuation factor; #X text 100 54 cutoff (or angle on the unit circle , usually 0..pi (0..nyquist) , but here 0..0.5 because of the cos~ audio object); #X text 55 368 zero at zero frequency; #X obj -59 222 -~; #X obj -45 327 *~; #X obj -92 181 sig~ 1; #X obj 49 392 sig~ 1; #X obj 99 393 sig~ 0; #X obj 32 94 clip~ 0 0.5; #X connect 0 0 1 0; #X connect 0 1 1 1; #X connect 1 0 2 0; #X connect 3 0 25 0; #X connect 4 0 6 0; #X connect 4 0 5 0; #X connect 5 0 0 2; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 8 0 0 3; #X connect 9 0 8 1; #X connect 9 0 24 1; #X connect 10 0 9 0; #X connect 11 0 29 0; #X connect 12 0 11 0; #X connect 24 0 25 1; #X connect 25 0 0 0; #X connect 26 0 24 0; #X connect 27 0 1 2; #X connect 28 0 1 3; #X connect 29 0 4 0; #X restore 101 192 pd simple_reson_hp1; #X connect 1 0 7 0; #X connect 2 0 8 2; #X connect 5 0 6 0; #X connect 6 0 8 1; #X connect 7 0 8 0; #X connect 8 0 0 0; #X connect 8 0 0 1;
so is it possible to get the gain from the poles and zeros, without calculating all coefficients?
Of Course it is. You must evaluate the transfer function of the filter in the unit circle. For a nice explanation on how to do this and some C code samples, see: Elements of Computer Music by F. R. Moore, Cap.1 pp. 119-133 Best Isi
--- martin brinkmann mnb@martin-brinkmann.de wrote:
hi pd-list!
i have recently tried to build some filters using cpole and czero, not completely unsuccessfull (at least the lowpass sounds somewhat like a lowpass...), but i have a problem calculating the right gain (or attenuation) factor. for the lp it seems to work more or less (ok for a subtractive synth, but still not good enough for effects etc.), but the hp is either too lound for lower frequencies and low resonance, or hardly audible. i think there might be a better way to find out the right gain than 'try and error'. and its getting worse with more poles involved... so is it possible to get the gain from the poles and zeros, without calculating all coefficients?
bis denn! martin
#N canvas 156 137 470 338 10;
#X obj 82 263 dac~; #X floatatom 1 8 5 0 0 0 - - -; #X obj 235 4 hsl 128 15 0.05 0.99 0 1 empty empty empty -2 -6 0 8 -262144 -1 -1 4700 1; #X text 229 -16 res; #X text 91 -17 cut; #X obj 93 1 hsl 128 15 0 128 0 1 empty empty empty -2 -6 0 8 -262144 -1 -1 5600 1; #X obj 162 143 mtof; #X obj 3 47 phasor~ 222; #N canvas 190 170 920 635 simple_reson_lp1 0; #X obj -19 398 cpole~; #X obj 31 440 czero~; #X obj 27 494 outlet~; #X obj -173 141 inlet~; #X obj -53 364 *~; #X obj 31 118 /~ 2; #X obj 32 238 cos~; #X obj 95 182 -~ 0.25; #X obj 96 203 cos~; #X obj 96 256 *~; #X obj 225 183 clip~ 0.05 0.99; #X obj 236 146 inlet~; #X obj -60 305 *~; #X obj -81 266 +~ 2; #X obj -84 237 *~ 0.5; #X obj -27 279 -~; #X obj 32 90 clip~ 0 1; #X obj 36 34 /~ 11025; #X obj 34 5 inlet~; #X text -123 141 audio in; #X text 81 5 cutoff; #X text 287 143 resonance; #X text 55 368 zero at nyquist; #X text 99 35 1/4 samplerate; #X text -128 198 attenuation factor; #X text -128 214 (1-x)*(1/2*angle+2); #X text 70 118 pi/2 for audio cos; #X text -256 396 pole: cos(angle) , sin(angle)+res; #X text 39 220 cosine; #X text 147 191 sine; #X text -310 363 multiply input by attenuation factor; #X text -404 106 4/2008 martin brinkmann; #X text -405 8 slightly crude (especially the attenuatiun factor) lowpass filter design , made without knowing too much of the math involved. frequency is not very exact , but at least it sounds like a reson filter :-); #X text -404 63 a pole is moved along the unit-circle on a kind of rugby-egg-shaped path , while a zero sits at -1 , 0 (nyquist frequency) , which makes a resonant lowpass filter.; #X text 100 54 cutoff (or angle on the unit circle , usually 0..pi (0..nyquist) , but here 0..0.5 because of the cos~ audio object); #X obj -32 246 sig~ 1; #X obj 45 393 sig~ -1; #X obj 104 393 sig~ 0; #X connect 0 0 1 0; #X connect 0 1 1 1; #X connect 1 0 2 0; #X connect 3 0 4 0; #X connect 4 0 0 0; #X connect 5 0 7 0; #X connect 5 0 6 0; #X connect 6 0 0 2; #X connect 6 0 15 1; #X connect 7 0 8 0; #X connect 8 0 9 0; #X connect 9 0 0 3; #X connect 10 0 9 1; #X connect 11 0 10 0; #X connect 12 0 4 1; #X connect 13 0 12 0; #X connect 14 0 13 0; #X connect 15 0 12 1; #X connect 16 0 5 0; #X connect 16 0 14 0; #X connect 17 0 16 0; #X connect 18 0 17 0; #X connect 35 0 15 0; #X connect 36 0 1 2; #X connect 37 0 1 3; #X restore 102 192 pd simple_reson_lp1; #X connect 1 0 7 0; #X connect 2 0 8 2; #X connect 5 0 6 0; #X connect 6 0 8 1; #X connect 7 0 8 0; #X connect 8 0 0 0; #X connect 8 0 0 1;
#N canvas 69 503 470 338 10;
#X obj 82 263 dac~; #X floatatom 1 8 5 0 0 0 - - -; #X obj 235 4 hsl 128 15 0.05 0.99 0 1 empty empty empty -2 -6 0 8 -262144 -1 -1 4500 1; #X text 229 -16 res; #X text 91 -17 cut; #X obj 93 1 hsl 128 15 0 128 0 1 empty empty empty -2 -6 0 8 -262144 -1 -1 12400 1; #X obj 144 81 mtof; #X obj 3 47 phasor~ 222; #N canvas 167 157 920 635 simple_reson_hp1 0; #X obj -19 398 cpole~; #X obj 49 519 czero~; #X obj 49 591 outlet~; #X obj -173 141 inlet~; #X obj 31 118 /~ 2; #X obj 16 184 cos~; #X obj 95 182 -~ 0.25; #X obj 96 203 cos~; #X obj 96 256 *~; #X obj 225 183 clip~ 0.05 0.99; #X obj 236 146 inlet~; #X obj 33 34 /~ 11025; #X obj 34 5 inlet~; #X text -123 141 audio in; #X text 81 5 cutoff; #X text 287 143 resonance; #X text 99 35 1/4 samplerate; #X text 70 118 pi/2 for audio cos; #X text -256 396 pole: cos(angle) , sin(angle)+res; #X text 29 167 cosine; #X text 147 191 sine; #X text -310 321 multiply input by attenuation factor; #X text 100 54 cutoff (or angle on the unit circle , usually 0..pi (0..nyquist) , but here 0..0.5 because of the cos~ audio object); #X text 55 368 zero at zero frequency; #X obj -59 222 -~; #X obj -45 327 *~; #X obj -92 181 sig~ 1; #X obj 49 392 sig~ 1; #X obj 99 393 sig~ 0; #X obj 32 94 clip~ 0 0.5; #X connect 0 0 1 0; #X connect 0 1 1 1; #X connect 1 0 2 0; #X connect 3 0 25 0; #X connect 4 0 6 0; #X connect 4 0 5 0; #X connect 5 0 0 2; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 8 0 0 3; #X connect 9 0 8 1; #X connect 9 0 24 1; #X connect 10 0 9 0; #X connect 11 0 29 0; #X connect 12 0 11 0; #X connect 24 0 25 1; #X connect 25 0 0 0; #X connect 26 0 24 0; #X connect 27 0 1 2; #X connect 28 0 1 3; #X connect 29 0 4 0; #X restore 101 192 pd simple_reson_hp1; #X connect 1 0 7 0; #X connect 2 0 8 2; #X connect 5 0 6 0; #X connect 6 0 8 1; #X connect 7 0 8 0; #X connect 8 0 0 0; #X connect 8 0 0 1;
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Isidro Gonzalez wrote:
so is it possible to get the gain from the poles and zeros, without calculating all coefficients?
Of Course it is. You must evaluate the transfer function of the filter in the unit circle. For a nice explanation on how to do this and some C code samples, see: Elements of Computer Music by F. R. Moore, Cap.1 pp. 119-133
thanks for the hints. i will see if i can find this book somewhere.
bis denn! martin
Hello,
There is the following error, if I try to open the help file of a Gem object:
sorry, couldn't find help patch for "gemhead.pd"
the help files for PD objects are ok.
Thanks, Birgit
Birgit Gasteiger wrote:
Hello,
There is the following error, if I try to open the help file of a Gem object:
sorry, couldn't find help patch for "gemhead.pd"
the help files for PD objects are ok.
which OS? which distribution? (how did you get Gem? did you compile it yourself? if so did you do a "make install"?)
fgmasdr IOhannes
IOhannes m zmoelnig schrieb:
Birgit Gasteiger wrote:
Hello,
There is the following error, if I try to open the help file of a Gem object:
sorry, couldn't find help patch for "gemhead.pd"
the help files for PD objects are ok.
which OS? which distribution? (how did you get Gem? did you compile it yourself? if so did you do a "make install"?)
fgmasdr IOhannes
Sorry, I installed the Pd version 0.40.3-extended-20080406 from puredata.info and I am running it on Kubuntu 7.1
Best, Birgit
I always get that problem on OSX, the files should be in gem/Gem/help, i think if you add the path in the pd preferences it should work, J
On Mon, Apr 14, 2008 at 4:39 AM, Birgit Gasteiger birgitg@sbox.tugraz.at wrote:
IOhannes m zmoelnig schrieb:
Birgit Gasteiger wrote:
Hello,
There is the following error, if I try to open the help file of a Gem object:
sorry, couldn't find help patch for "gemhead.pd"
the help files for PD objects are ok.
which OS? which distribution? (how did you get Gem? did you compile it yourself? if so did you do a "make install"?)
fgmasdr IOhannes
Sorry, I installed the Pd version 0.40.3-extended-20080406 from puredata.info and I am running it on Kubuntu 7.1
Best, Birgit
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
As I tried to open the path... pd terminated with the following error message:
*** stack smashing detected ***: pd terminated Pd: signal 6 pd_gui: pd process exited
Best, Birgit
Jaime Oliver schrieb:
I always get that problem on OSX, the files should be in gem/Gem/help, i think if you add the path in the pd preferences it should work,
J
On Mon, Apr 14, 2008 at 4:39 AM, Birgit Gasteiger <birgitg@sbox.tugraz.at mailto:birgitg@sbox.tugraz.at> wrote:
IOhannes m zmoelnig schrieb: > Birgit Gasteiger wrote: >> Hello, >> >> There is the following error, if I try to open the help file of a Gem >> object: >> >> sorry, couldn't find help patch for "gemhead.pd" >> >> the help files for PD objects are ok. > > which OS? > which distribution? (how did you get Gem? did you compile it yourself? > if so did you do a "make install"?) > > fgmasdr > IOhannes Sorry, I installed the Pd version 0.40.3-extended-20080406 from puredata.info <http://puredata.info> and I am running it on Kubuntu 7.1 Best, Birgit _______________________________________________ PD-list@iem.at <mailto:PD-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list-- Jaime E Oliver LR
joliverl@ucsd.edu mailto:joliverl@ucsd.edu www.realidadvisual.org/jaimeoliver http://www.realidadvisual.org/jaimeoliver www-crca.ucsd.edu/ http://www-crca.ucsd.edu/ www.realidadvisual.org http://www.realidadvisual.org
9168 Regents Rd. Apt. G La Jolla, CA 92037 USA
Birgit Gasteiger wrote:
As I tried to open the path... pd terminated with the following error
i think this is a know pdextended bug. you can add more information to the issue-tracker: http://sourceforge.net/tracker/index.php?func=detail&aid=1936531&gro...
fmgasdr IOhannes
Birgit Gasteiger wrote:
As I tried to open the path... pd terminated with the following error message:
*** stack smashing detected ***: pd terminated Pd: signal 6 pd_gui: pd process exited
another solution is to restructure your filesystem a bit.
create a extra/Gem/ folder in your Pd-extended (if it's not already there); iirc, Pd-extended installs itself into /usr/local/lib/pd, so your path should be /usr/local/lib/pd/extra/Gem
move(!) the Gem.pd_linux from extra/ to extra/Gem/ copy all the help-patches from doc/5.reference/Gem/ into extra/Gem/
that's it!
start Pd, load Gem (if not done automatically), create [pix_kaleidoscope], right click and enjoy!
mfga.sdr IOhannes
PS: btw, hans, what is the reason for Pd-extended to install all help-files into 5.reference/<dir> instead of besides the libraries? i guess it is just for legacy reasons, but i might be wrong
On Tue, 2008-04-15 at 09:31 +0200, IOhannes m zmoelnig wrote:
PS: btw, hans, what is the reason for Pd-extended to install all help-files into 5.reference/<dir> instead of besides the libraries? i guess it is just for legacy reasons, but i might be wrong
i cannot speak for hans, of course, but personally i do also install all help-files into 5.reference/<library>/, so that they are visible and accessible by pd's help-browser. it seemed to me an easy way to check, what classes are delivered by a certain library.
i take the opportunity for putting a request to unify the installation of different libraries. currently, i do install everything (the .pd_linux files and the help-patches) manually, because otherwise it is very likely to mess up the extra folder or help-patches are installed in many different locations, depending on the author of the makefile. probably i am just blind or stubborn, but i haven't figured out a clean way to automatically install something compiled from pd-svn (for a few years of doing pd). if there is already a way (by using pd-extended makefiles ?) to automatically install libraries in a unified manner, please let me know.
i am very much in favor of having the help-files in 5.reference. therefore i think it would be great, if '-helppath' could be specified relative to '/install/path/of/pd/doc/5.reference'. i don't see a particular use in having to speficy the whole help path '/usr/local/lib/pd/extra/doc/5.reference/library/' for each library installed (assuming doc/5.reference is the official path, where help-files belong). if this is not the 'official' location for help-files, then let's define one (or take the one, that is official, but obviously isn't known as such).
the same goes for '-path': couldn't it read pathes relative to extra as well, since this folder seems to be the official folder to put libraries in?
my two rappen
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
i cannot speak for hans, of course, but personally i do also install all help-files into 5.reference/<library>/, so that they are visible and accessible by pd's help-browser. it seemed to me an easy way to check, what classes are delivered by a certain library.
i think the help-browser is a very weak excuse.
i totally agree, that one should group all the help-patches belonging to a library together. i don't agree that the binaries and the help-patches should be kept in different places.
this can be done with plain Pd: it will automatically search the help-patches for objects coming from a library next to the binary. so if you have a Gem.pd_linux in extra/Gem/, then Pd will search for the help-patch of Gem's [pix_kaleidoscope] ("pix_kaleidoscope-help.pd") in extra/Gem/
the entire library can thus be distributed in one directory which you just drop into extra/, which is think is a very strong point.
the only remaining thing is the help-browser. it should probably be fixed to also offer the possibility to search extra/ and everybody would be happy.
fmga.dsr IOhannes
(btw, i never came to love the help-browser as it is so restrictive in what it allows me to see)
IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
i cannot speak for hans, of course, but personally i do also install all help-files into 5.reference/<library>/, so that they are visible and accessible by pd's help-browser. it seemed to me an easy way to check, what classes are delivered by a certain library.
i think the help-browser is a very weak excuse.
[...]
the only remaining thing is the help-browser. it should probably be fixed to also offer the possibility to search extra/ and everybody would be happy.
something like the attached. i am no tcl/tk programmer, i just quickly hacked this together with help of the internet.
fmgasd IOhannes
--- u_main.tk 2008-04-14 17:47:32.000000000 +0200 +++ ../bin/pd.tk 2008-04-15 12:28:31.107591424 +0200 @@ -461,8 +461,13 @@ toplevel .help_browser -menu .mbar wm title .help_browser "Pd Documentation Browser" frame .help_browser.frame
frame .help_browser.frame.docframe .help_browser.frame.extra pack .help_browser.frame -side top -fill both
doc_make_listbox .help_browser.frame $dir 0
pack .help_browser.frame.doc -side top -fill bothpack .help_browser.frame.extra -side top -fill bothdoc_make_listbox .help_browser.frame.doc $dir 0
}doc_make_listbox .help_browser.frame.extra $dir/../extra 0 }
IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
i cannot speak for hans, of course, but personally i do also install all help-files into 5.reference/<library>/, so that they are visible and accessible by pd's help-browser. it seemed to me an easy way to check, what classes are delivered by a certain library.
i think the help-browser is a very weak excuse.
[...]
the only remaining thing is the help-browser. it should probably be fixed to also offer the possibility to search extra/ and everybody would be happy.
something like the attached. i am no tcl/tk programmer, i just quickly hacked this together with help of the internet.
I think the whole help browser stuff is very messy. there is "1.manual" versus "manuals" "media" vs "sound" and "7.stuff" versus "examples" some of the stuff is pd patches, some are textfiles, some are html docs.
I think all html or text manuals should be in a separate section of the help menu, not in the browser (in pd-extended there already is a html menu-entry) 2.-4.and 6.(although, I am not sure about 6.) should be in a tutorials submenu. 5. reference should be called "help-patches" sound should be a part of media. then you get HELP: --- HTML --- --- Pd --- --- Gem --- --- (other manuals) --- BROWSER --- --- Tutorials --- --- --- (control examples) --- --- --- (audio examples) --- --- --- (data structures) --- --- --- (external tutorials??) --- --- Examples --- --- --- soundfile tools --- --- --- synths ... --- --- --- (tidied up content of 7.stuff) --- --- --- (tidied up content of examples) --- --- Help Patches --- --- Media --- --- --- images and video --- --- --- sounds --- --- --- obj., mtl. ...
I am sure this can be even further improved. and then people would actually find what they are looking for. marius.
marius schebella wrote:
I think the whole help browser stuff is very messy. there is "1.manual" versus "manuals" "media" vs "sound" and "7.stuff" versus "examples" some of the stuff is pd patches, some are textfiles, some are html docs.
that is interesting, i just have: 1.manual 2.control.examples 3.audio.examples 4.data.structures 5.reference 6.externs 7.stuff sound
which is not that badly organized :-)
I think all html or text manuals should be in a separate section of the help menu, not in the browser (in pd-extended there already is a html menu-entry) 2.-4.and 6.(although, I am not sure about 6.) should be in a tutorials submenu. 5. reference should be called "help-patches"
what makes "help-patch" better than "reference"?
most of pd's help patches are really "references", especially if you browse it via the menu (a help-patch is the thing you open via right mouseclick; a reference is the thing you browse)
sound should be a part of media. then you get HELP: --- HTML --- --- Pd --- --- Gem --- --- (other manuals) --- BROWSER --- --- Tutorials --- --- --- (control examples) --- --- --- (audio examples) --- --- --- (data structures) --- --- --- (external tutorials??) --- --- Examples --- --- --- soundfile tools --- --- --- synths ... --- --- --- (tidied up content of 7.stuff) --- --- --- (tidied up content of examples) --- --- Help Patches --- --- Media --- --- --- images and video --- --- --- sounds --- --- --- obj., mtl. ...
for me (if i understand your proposal correctly), this only makes sense if objects would be grouped by function rather than by library. this seems to have been unfeasible to do in the last year.
i think we should take practice into account.
fmgas.dr IOhannes
oops, so then all the mess comes from pd-extended... maybe we should differentiate between "normal" external behaviour and pd-extended behaviour that could actually be different because it recompiles the externals and also can relocate help-patches in its own way. the "normal" way would be to allow the developer to put her files wherever she wants. and come up with an individual installation method and probably the need to add a path and lib flag to the startup script for every external. but in pd-extended it should only be necessary to add startup flags for additional libraries that are not already included in pd-ext (like pdj, or some flext externals). and therefor I think the pd-ext installation paths should be uniform, either all into library subfolders or none. one problem remaining is that some help-file paths seem to be hardcoded in the externals, which I think is not a good idea? marius.
IOhannes m zmoelnig wrote:
marius schebella wrote:
I think the whole help browser stuff is very messy. there is "1.manual" versus "manuals" "media" vs "sound" and "7.stuff" versus "examples" some of the stuff is pd patches, some are textfiles, some are html docs.
that is interesting, i just have: 1.manual 2.control.examples 3.audio.examples 4.data.structures 5.reference 6.externs 7.stuff sound
which is not that badly organized :-)
I think all html or text manuals should be in a separate section of the help menu, not in the browser (in pd-extended there already is a html menu-entry) 2.-4.and 6.(although, I am not sure about 6.) should be in a tutorials submenu. 5. reference should be called "help-patches"
what makes "help-patch" better than "reference"?
most of pd's help patches are really "references", especially if you browse it via the menu (a help-patch is the thing you open via right mouseclick; a reference is the thing you browse)
sound should be a part of media. then you get HELP: --- HTML --- --- Pd --- --- Gem --- --- (other manuals) --- BROWSER --- --- Tutorials --- --- --- (control examples) --- --- --- (audio examples) --- --- --- (data structures) --- --- --- (external tutorials??) --- --- Examples --- --- --- soundfile tools --- --- --- synths ... --- --- --- (tidied up content of 7.stuff) --- --- --- (tidied up content of examples) --- --- Help Patches --- --- Media --- --- --- images and video --- --- --- sounds --- --- --- obj., mtl. ...
for me (if i understand your proposal correctly), this only makes sense if objects would be grouped by function rather than by library. this seems to have been unfeasible to do in the last year.
i think we should take practice into account.
fmgas.dr IOhannes
The core idea of libdirs is to have everything put into one
directory, so all have to do to install a library is drop the folder
into a directory that is in the path, then the objects, the help
files, the examples, and the manuals will all show up in the right
place, and you'll be able to load the library with [import], and use
namespace prefixes.
http://puredata.info/docs/developer/Libdir
This means rewriting the help browser to use generated lists of files
rather than just showing the file layout. Basically the rest is
already implemented.
Any help would be appreciated, if someone wants to take on a chunk of
this problem, like writing the help browser support. But I don't
plan on talking about it this much more since we have done a ton of
talking on this topic. Now we need doing. Then we can talk again
after we have done something to make sure it is good :)
.hc
On Apr 15, 2008, at 1:53 PM, marius schebella wrote:
oops, so then all the mess comes from pd-extended... maybe we should differentiate between "normal" external behaviour and pd-extended behaviour that could actually be different because it recompiles the externals and also can relocate help-patches in its
own way. the "normal" way would be to allow the developer to put her files wherever she wants. and come up with an individual installation method and probably the need to add a path and lib flag to the startup script for every external. but in pd-extended it should only be necessary to add startup flags
for additional libraries that are not already included in pd-ext (like
pdj, or some flext externals). and therefor I think the pd-ext installation paths should be uniform, either all into library subfolders or none. one problem remaining is that some help-file paths seem to be
hardcoded in the externals, which I think is not a good idea? marius.IOhannes m zmoelnig wrote:
marius schebella wrote:
I think the whole help browser stuff is very messy. there is "1.manual" versus "manuals" "media" vs "sound" and "7.stuff" versus "examples" some of the stuff is pd patches, some are textfiles, some are html docs.
that is interesting, i just have: 1.manual 2.control.examples 3.audio.examples 4.data.structures 5.reference 6.externs 7.stuff sound
which is not that badly organized :-)
I think all html or text manuals should be in a separate section of the help menu, not in the browser (in pd-extended there already is a html menu-entry) 2.-4.and 6.(although, I am not sure about 6.) should be in a
tutorials submenu. 5. reference should be called "help-patches"what makes "help-patch" better than "reference"?
most of pd's help patches are really "references", especially if you browse it via the menu (a help-patch is the thing you open via right mouseclick; a reference is the thing you browse)
sound should be a part of media. then you get HELP: --- HTML --- --- Pd --- --- Gem --- --- (other manuals) --- BROWSER --- --- Tutorials --- --- --- (control examples) --- --- --- (audio examples) --- --- --- (data structures) --- --- --- (external tutorials??) --- --- Examples --- --- --- soundfile tools --- --- --- synths ... --- --- --- (tidied up content of 7.stuff) --- --- --- (tidied up content of examples) --- --- Help Patches --- --- Media --- --- --- images and video --- --- --- sounds --- --- --- obj., mtl. ...
for me (if i understand your proposal correctly), this only makes
sense if objects would be grouped by function rather than by library. this seems to have been unfeasible to do in the last year.i think we should take practice into account.
fmgas.dr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
Quoting Hans-Christoph Steiner hans@eds.org:
The core idea of libdirs is to have everything put into one directory, so all have to do to install a library is drop the folder into a directory that is in the path, then the objects, the help files, the examples, and the manuals will all show up in the right place, and
that's exactly how i imagine it.
you'll be able to load the library with [import], and use namespace prefixes.
that's not how i imagine it :-) Pd can do most of this already without the need for [import].
mfga.ds#r IOhannes
This message was sent using IMP, the Internet Messaging Program.
Georg Holzmann wrote:
Hallo!
you'll be able to load the library with [import], and use namespace prefixes.
that's not how i imagine it :-) Pd can do most of this already without the need for [import].
? - What do you mean ? declare ?
not really, but probably yes
use-case#1 (Pd-vanilla) extra/mylib/mylib.dll (containing [mobj1]) extra/mylib/myobj1-help.pd . you load "mylib", e.g. by doing so on startup (-lib), or by instanting [mylib]. you create [myobj1], right-click on help and myobj1-help.pd opens up
use-case#2 (Pd-vanilla) extra/mylib/myobj1.dll extra/mylib/myobj1-help.pd . you 'load' "mylib" by adding it to the path, either on startup or with [declare] you create [myobj1], right-click on help and myobj1-help.pd opens up
use-case#3 (Pd-vanilla) extra/mylib/myobj1.dll extra/mylib/myobj1-help.pd . you create [mylib/myobj1], right-click on help and myobj1-help.pd opens up
use-case#4 (only Pd-extended) extra/mylib/mylib.pd extra/mylib/myobj1.dll . you load "mylib" by using [import mylib] you create [myobj1], right-click on help and myobj1-help.pd opens up
i still don't see what is provided by [import] that is not provided by Pd-vanilla anyhow. the good thing about use-cases#1-#3 is, that they will work on both Pd-vanilla and Pd-extended.
and if [declare] is broken, then it should be fixed.
but really, i probably just don't see the problem because of my special use of Pd. the problem might be real nevertheless.
mfg.asdr IOhannes
hi, I think your examples do not cover all usecases. declare is supposed to solve the nameclash problem: it should also provide local patch namespaces. (dealing with the whole problematic of abstractions/parents...). nameclashes can appear in several situations: (conflict between external/abstraction vs. external/abstraction) dealing with the current mess of double names on your local system, but also dealing with double names on your computer vs. other systems, especially when you want to share patches and make sure they work on other systems. for patch namespaces: it should enable users to use two different externals/abstractions with the same name in two different patches. patch1: declare -lib version1/myabs patch2: declare -lib version2/myabs I think namespaces should be expanded to abstractions and not the other way around (currently it is the other way round. I guess because abstractions are loaded before. right now declares in abstractions get ignored?)
IOhannes m zmoelnig wrote:
use-case#1 (Pd-vanilla) extra/mylib/mylib.dll (containing [mobj1]) extra/mylib/myobj1-help.pd . you load "mylib", e.g. by doing so on startup (-lib), or by instanting [mylib]. you create [myobj1], right-click on help and myobj1-help.pd opens up
problem: you don't want to load all libraries into memory, which is a waste of resources.
use-case#2 (Pd-vanilla) extra/mylib/myobj1.dll extra/mylib/myobj1-help.pd . you 'load' "mylib" by adding it to the path, either on startup or with [declare] you create [myobj1], right-click on help and myobj1-help.pd opens up
this is what I suggested, too, but it seems broken (at least on os x it does nothing). the -path at startup works, but does not provide local namespace. and it will not work with abbreviated objects.
use-case#3 (Pd-vanilla) extra/mylib/myobj1.dll extra/mylib/myobj1-help.pd . you create [mylib/myobj1], right-click on help and myobj1-help.pd opens up
that's the ugly thing that I want to avoid like hell. btw. with one of declare or import(?) I had the problem, that when I loaded a library into the namespace, then mylib/myobj1 could not be created any more, only myobj1.
use-case#4 (only Pd-extended) extra/mylib/mylib.pd extra/mylib/myobj1.dll . you load "mylib" by using [import mylib] you create [myobj1], right-click on help and myobj1-help.pd opens up
afaict this is broken.
i still don't see what is provided by [import] that is not provided by Pd-vanilla anyhow.
the possibility to printout the libs and paths
the good thing about use-cases#1-#3 is, that they will work on both Pd-vanilla and Pd-extended.
and if [declare] is broken, then it should be fixed.
it is broken and it should be fixed. but I read that miller gave up on this for 0.41??? marius.
On Apr 16, 2008, at 3:16 AM, zmoelnig@iem.at wrote:
Quoting Hans-Christoph Steiner hans@eds.org:
The core idea of libdirs is to have everything put into one
directory, so all have to do to install a library is drop the folder into a directory that is in the path, then the objects, the help files, the examples, and the manuals will all show up in the right place, andthat's exactly how i imagine it.
you'll be able to load the library with [import], and use namespace prefixes.
that's not how i imagine it :-) Pd can do most of this already without the need for [import].
The libdir format does not in any way require the use of [import]/
[declare], so it looks like we are in complete agreement about the
goals of the library format itself. Now it's time to implement
it :) My #1 priority for the rest of this month is to make that
work. Any help is always appreciated.
Some tasks that would be easy to break out:
- writing the help browser to support this
- writing code to scan to build the lists of help files, examples, etc.
- fixing import/declare to fully support this
- fixing the patch-local namespace stuff to fully support this
I'm going to start with the last two.
.hc
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
On Tue, 2008-04-15 at 11:46 +0200, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
i cannot speak for hans, of course, but personally i do also install all help-files into 5.reference/<library>/, so that they are visible and accessible by pd's help-browser. it seemed to me an easy way to check, what classes are delivered by a certain library.
i think the help-browser is a very weak excuse.
i totally agree, that one should group all the help-patches belonging to a library together. i don't agree that the binaries and the help-patches should be kept in different places.
this can be done with plain Pd: it will automatically search the help-patches for objects coming from a library next to the binary. so if you have a Gem.pd_linux in extra/Gem/, then Pd will search for the help-patch of Gem's [pix_kaleidoscope] ("pix_kaleidoscope-help.pd") in extra/Gem/
the entire library can thus be distributed in one directory which you just drop into extra/, which is think is a very strong point.
yeah, a simple 'cp <library> /pd/installation/extra'-install would be awesome, indeed.
the only remaining thing is the help-browser. it should probably be fixed to also offer the possibility to search extra/ and everybody would be happy.
yo, sounds very reasonable in my ears. so far, that is the best solution, i can think of.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Birgit Gasteiger wrote:
As I tried to open the path... pd terminated with the following error message:
*** stack smashing detected ***: pd terminated Pd: signal 6 pd_gui: pd process exited
another solution is to restructure your filesystem a bit.
create a extra/Gem/ folder in your Pd-extended (if it's not already there); iirc, Pd-extended installs itself into /usr/local/lib/pd, so your path should be /usr/local/lib/pd/extra/Gem
move(!) the Gem.pd_linux from extra/ to extra/Gem/ copy all the help-patches from doc/5.reference/Gem/ into extra/Gem/
I think it's at least a bit annoying that Gem sets a hardcoded help-path prefix to "Gem" and doesn't use the objnam-help.pd pattern.
I would much prefer it if Gem would behave like almost every other external/abstraction collection as this wouldn't require the special handling of Gem help files anymore. Currently some files in extra/Gem are abstractions (which have their "*-help.pd" files) other files are real help files for binary objects, but don't have a -help.pd suffix and it's all a bit, well, confusing, to say the least. Oki, I'm used to it over the years, but for a newcomer it surely is hard to follow.
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
I think it's at least a bit annoying that Gem sets a hardcoded help-path prefix to "Gem" and doesn't use the objnam-help.pd pattern.
afair, this has been removed from Gem.
I would much prefer it if Gem would behave like almost every other external/abstraction collection as this wouldn't require the special handling of Gem help files anymore. Currently some files in extra/Gem are abstractions (which have their "*-help.pd" files) other files are real help files for binary objects, but don't have a -help.pd suffix and it's all a bit, well, confusing, to say the least. Oki, I'm used to it over the years, but for a newcomer it surely is hard to follow.
afaik, your confusing setup is due to leftovers from old installations. a fresh "make install" of Gem should do:
- create extra/Gem/
- put Gem.pd_linux into extra/Gem/
- put all help-files (with "-help" suffix) into extra/Gem/
- put all abstractions into extra/Gem/
- put all help-files for abstractions (absname with "-help" suffix) into
extra/Gem/
- put the examples/ folder into doc/gem/
if it doesn't do so, please file a bug-report. one could argue that the examples/ should go into extra/Gem/examples/
mfga.sd IOhannes
IOhannes m zmoelnig wrote:
afaik, your confusing setup is due to leftovers from old installations. a fresh "make install" of Gem should do:
- create extra/Gem/
- put Gem.pd_linux into extra/Gem/
- put all help-files (with "-help" suffix) into extra/Gem/
- put all abstractions into extra/Gem/
- put all help-files for abstractions (absname with "-help" suffix) into
extra/Gem/
- put the examples/ folder into doc/gem/
if it doesn't do so, please file a bug-report.
alternatively check whether Gem's configure has detected an old version of Pd (<0.37) or no Pd-version at all, in which case it falls to legacy mode and installs help-patches into doc/5.reference/Gem
fmgasdr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
afaik, your confusing setup is due to leftovers from old installations.
Ah, you're right, sorry. I had checked this, but with an older CVS checkout on my disk. "cvs up" needed. ;(
Ciao
Frank
IOhannes m zmoelnig schrieb:
Birgit Gasteiger wrote:
As I tried to open the path... pd terminated with the following error message:
*** stack smashing detected ***: pd terminated Pd: signal 6 pd_gui: pd process exited
another solution is to restructure your filesystem a bit.
create a extra/Gem/ folder in your Pd-extended (if it's not already there); iirc, Pd-extended installs itself into /usr/local/lib/pd, so your path should be /usr/local/lib/pd/extra/Gem
move(!) the Gem.pd_linux from extra/ to extra/Gem/ copy all the help-patches from doc/5.reference/Gem/ into extra/Gem/
that's it!
start Pd, load Gem (if not done automatically), create [pix_kaleidoscope], right click and enjoy!
mfga.sdr IOhannes
PS: btw, hans, what is the reason for Pd-extended to install all help-files into 5.reference/<dir> instead of besides the libraries? i guess it is just for legacy reasons, but i might be wrong
Hello,
Thanks, I did what you described above and it works!
Best, Birgit
On Apr 14, 2008, at 7:39 AM, Birgit Gasteiger wrote:
IOhannes m zmoelnig schrieb:
Birgit Gasteiger wrote:
Hello,
There is the following error, if I try to open the help file of a
Gem object:sorry, couldn't find help patch for "gemhead.pd"
the help files for PD objects are ok.
which OS? which distribution? (how did you get Gem? did you compile it
yourself? if so did you do a "make install"?)fgmasdr IOhannes
Sorry, I installed the Pd version 0.40.3-extended-20080406 from puredata.info and I am running it on Kubuntu 7.1
Best, Birgit
Thanks for reporting this. Please add a bug report, with that
version of Pd-extended, you can do this via the Help menu:
Help->report bug
.hc
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
-
Birgit Gasteiger -
Frank Barknecht -
Georg Holzmann -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Isidro Gonzalez -
Jaime Oliver -
marius schebella -
martin brinkmann -
Roman Haefeli -
zmoelnig＠iem.at