hi folks,
here are some purepd representations of the [equalizer] [lowshelf] and [highshelf] objects for calculating eq biquad filter coefficients. i put these together as ggee was the only external lib dependency for a project which used these fairly extensively. the code is almost logic identical to the equivelent C internals, and i have avoided using [expr], so the math may look a little confusing.
i only ported the code for the objects i was using, but i will add the other eq-cookbook filters when i next get a chance.
ciao, dmotd
cheers. very useful!
silly question probably, but is biquad~ 100% vanilla? or is it sort of 'caramel' like expr ??
Hallo, dmotd hat gesagt: // dmotd wrote:
here are some purepd representations of the [equalizer] [lowshelf] and [highshelf] objects for calculating eq biquad filter coefficients. i put these together as ggee was the only external lib dependency for a project which used these fairly extensively. the code is almost logic identical to the equivelent C internals, and i have avoided using [expr], so the math may look a little confusing.
i only ported the code for the objects i was using, but i will add the other eq-cookbook filters when i next get a chance.
Very nice. Actually these three cookbook filters are the three that I didn't yet port to purepd, so they are very welcome! :)
The others are included in the rjdj library as u_lowpass, u_lowpassq, u_highpass, u_highpassq, u_bandpass1, u_bandpass1q, u_bandpass2 and u_bandpass2q. There also is a signal biquad~ as e_beequad available (which just does linear interpolation of parameters, so it's of course not really correct if you do larger jumps).
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
hello,
Frank Barknecht a écrit : ...
The others are included in the rjdj library as u_lowpass, u_lowpassq, u_highpass, u_highpassq, u_bandpass1, u_bandpass1q, u_bandpass2 and u_bandpass2q. There also is a signal biquad~ as e_beequad available (which just does linear interpolation of parameters, so it's of course not really correct if you do larger jumps).
it certainly is obvious, but where can i find them?
cyrille
Ciao
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
Frank Barknecht a écrit : ...
The others are included in the rjdj library as u_lowpass, u_lowpassq, u_highpass, u_highpassq, u_bandpass1, u_bandpass1q, u_bandpass2 and u_bandpass2q. There also is a signal biquad~ as e_beequad available (which just does linear interpolation of parameters, so it's of course not really correct if you do larger jumps).
it certainly is obvious, but where can i find them?
Here's their home page: http://trac.rjdj.me/wiki/RjLibnew rsp. $ svn co http://svn.rjdj.me/scenes/trunk/rjlib/ (They are GPL, but not yet tagged correctly)
Ciao
Frank
hello Frank,
nice to see all of this good stuff in pure vanilla pd.
i've got some questions : -why this is not available in pd-extended / in pd svn? -did you benchmark e_beequad~ regarding to bequad~ specially when cutoff / band is change frequently) -have you noticed that in svn/nusmuk/osc you can find lot's better bl saw that you can use (ok, it use expr~, but you can easily remove it). this bl oscillator use a personal enhancement of miller technique.
cyrille
Frank Barknecht a écrit :
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
Frank Barknecht a écrit : ...
The others are included in the rjdj library as u_lowpass, u_lowpassq, u_highpass, u_highpassq, u_bandpass1, u_bandpass1q, u_bandpass2 and u_bandpass2q. There also is a signal biquad~ as e_beequad available (which just does linear interpolation of parameters, so it's of course not really correct if you do larger jumps).
it certainly is obvious, but where can i find them?
Here's their home page: http://trac.rjdj.me/wiki/RjLibnew rsp. $ svn co http://svn.rjdj.me/scenes/trunk/rjlib/ (They are GPL, but not yet tagged correctly)
Ciao
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
nice to see all of this good stuff in pure vanilla pd.
i've got some questions : -why this is not available in pd-extended / in pd svn?
The rjdj-svn is the canonical location for rj-lib, but of course as it's GPL/BSD it can be copied anywhere. For contributions we can only accept stuff that either is BSD or transfers copyright to Reality Jockey as we want to avoid legal problems as a distributor of rjlib to others ("others" currently includes Apple, so we have to be extra-extra cautious about this.)
-did you benchmark e_beequad~ regarding to bequad~ specially when cutoff / band is change frequently)
Do you mean to "biquad~" or what is "bequad~"? biquad~ in Pd should be a lot faster, but I didn't benchmark it.
-have you noticed that in svn/nusmuk/osc you can find lot's better bl saw that you can use (ok, it use expr~, but you can easily remove it). this bl oscillator use a personal enhancement of miller technique.
No, I hadn't seen this. It doesn't seem to need the [samphold~] which would be cool to avoid anyway. Could you elaborate the algorithm a bit and how it's better?
I think, currently it's probably a bit slower because of the sin(), but maybe that could be put into a tabread~.
Ciao
Frank
hello
Frank Barknecht a écrit :
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
nice to see all of this good stuff in pure vanilla pd.
i've got some questions : -why this is not available in pd-extended / in pd svn?
The rjdj-svn is the canonical location for rj-lib, but of course as it's GPL/BSD it can be copied anywhere. For contributions we can only accept stuff that either is BSD or transfers copyright to Reality Jockey as we want to avoid legal problems as a distributor of rjlib to others ("others" currently includes Apple, so we have to be extra-extra cautious about this.)
ok.
-did you benchmark e_beequad~ regarding to bequad~ specially when cutoff / band is change frequently)
Do you mean to "biquad~" or what is "bequad~"? biquad~ in Pd should be a lot faster, but I didn't benchmark it.
yep, tipo, i mean biquad~. of course biquad~ look faster, but i'm wondering how many times... i'll have to look at performance when i'll have more time.
-have you noticed that in svn/nusmuk/osc you can find lot's better bl saw that you can use (ok, it use expr~, but you can easily remove it). this bl oscillator use a personal enhancement of miller technique.
No, I hadn't seen this. It doesn't seem to need the [samphold~] which would be cool to avoid anyway. Could you elaborate the algorithm a bit and how it's better?
it's sound lot's better! isn't that the aim? (i think it is almost perfect, and can easily be enhanced) try to fft's it if you're not convinced.
i think i would take me 1/2h to explain in french exactly what i made. so i really can't explain it in a mail in english.
in miller algorythm, the quick transition of the saw is replaced with a softer transition. this is fine. but the switch from saw~ to the soft transition is causing problem.
in "my" algo the transition is based on sinus cardinal (is that the english name?) and last for a whole period of the waveform.
if you need more explanation, you'll have to ask some math geek. (mathieu maybe?)
I think, currently it's probably a bit slower because of the sin(), but maybe that could be put into a tabread~.
i think the sin object is doing a linear interpolation in a 512 point table. (don't know how it is done in expr~, but expr~ is not used for rjlib because of it's licence, right?)
Cyrille
Ciao
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
I think, currently it's probably a bit slower because of the sin(), but maybe that could be put into a tabread~.
i think the sin object is doing a linear interpolation in a 512 point table. (don't know how it is done in expr~, but expr~ is not used for rjlib because of it's licence, right?)
Attached is an expr-less version of saw~ which from a quick glance at the scope looks and sounds the same. It is vanilla in that it uses [abs~] and [>~] which are part of 0.42 (and thus RjDj). On older Pd versions you can use for example the purepd abstractions for both from the SVN in abstractions/purepd
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
wow, this version is almost 2 time faster than the original. i did not know that expr~ was so slow...
do you mind if use this version to replace mine?
thanks Cyrille
Frank Barknecht a écrit :
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
I think, currently it's probably a bit slower because of the sin(), but maybe that could be put into a tabread~.
i think the sin object is doing a linear interpolation in a 512 point table. (don't know how it is done in expr~, but expr~ is not used for rjlib because of it's licence, right?)
Attached is an expr-less version of saw~ which from a quick glance at the scope looks and sounds the same. It is vanilla in that it uses [abs~] and [>~] which are part of 0.42 (and thus RjDj). On older Pd versions you can use for example the purepd abstractions for both from the SVN in abstractions/purepd
Ciao
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
wow, this version is almost 2 time faster than the original. i did not know that expr~ was so slow...
Yeah, expr-objects are slower than their builtin counterparts - so avoiding them in rjlib is also a kind of optimization.
Feel free to use it instead (preferable the updated version without >~.
Ciao
Frank
Hallo,
okay, attached is the pwm~ as well.
Ciao
Frank
cyrille henry hat gesagt: // cyrille henry wrote:
wow, this version is almost 2 time faster than the original. i did not know that expr~ was so slow...
do you mind if use this version to replace mine?
thanks Cyrille
Frank Barknecht a écrit :
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
I think, currently it's probably a bit slower because of the sin(), but maybe that could be put into a tabread~.
i think the sin object is doing a linear interpolation in a 512 point table. (don't know how it is done in expr~, but expr~ is not used for rjlib because of it's licence, right?)
Attached is an expr-less version of saw~ which from a quick glance at the scope looks and sounds the same. It is vanilla in that it uses [abs~] and [>~] which are part of 0.42 (and thus RjDj). On older Pd versions you can use for example the purepd abstractions for both from the SVN in abstractions/purepd
Ciao
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
unfortunately <~ is still missing in pd-0.42
"5.1. release notes New pow~, log~, exp~, abs~, and 'wrap' objects."
Frank Barknecht wrote:
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
I think, currently it's probably a bit slower because of the sin(), but maybe that could be put into a tabread~.
i think the sin object is doing a linear interpolation in a 512 point table. (don't know how it is done in expr~, but expr~ is not used for rjlib because of it's licence, right?)
Attached is an expr-less version of saw~ which from a quick glance at the scope looks and sounds the same. It is vanilla in that it uses [abs~] and [>~] which are part of 0.42 (and thus RjDj). On older Pd versions you can use for example the purepd abstractions for both from the SVN in abstractions/purepd
Ciao
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
And I am still forced to use [expr~] equivalents on many OSX and Windows systems I encounter because the > or < character cannot be used as a filename. This has actually changed between versions of Pd Extended, so I'm not sure where exactly the problem lies.
D.
Enrique Erne wrote:
unfortunately <~ is still missing in pd-0.42
"5.1. release notes New pow~, log~, exp~, abs~, and 'wrap' objects."
ok.here is a version using [pow~ -1] to replace [>~ 0] it should work with vanilla pd version >= 0.42 and with rjdj. and certainly with pd-extended.
cyrille
Enrique Erne a écrit :
unfortunately <~ is still missing in pd-0.42
"5.1. release notes New pow~, log~, exp~, abs~, and 'wrap' objects."
Frank Barknecht wrote:
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
I think, currently it's probably a bit slower because of the sin(), but maybe that could be put into a tabread~.
i think the sin object is doing a linear interpolation in a 512 point table. (don't know how it is done in expr~, but expr~ is not used for rjlib because of it's licence, right?)
Attached is an expr-less version of saw~ which from a quick glance at the scope looks and sounds the same. It is vanilla in that it uses [abs~] and [>~] which are part of 0.42 (and thus RjDj). On older Pd versions you can use for example the purepd abstractions for both from the SVN in abstractions/purepd
Ciao
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
#N canvas 232 120 652 594 10; #X obj 105 96 phasor~; #X obj 176 131 -~ 0.5; #X obj 311 179 *~ 2; #X obj 218 204 wrap~; #X obj 219 230 *~ 2; #X obj 219 255 -~ 1; #X obj 349 178 /~; #X obj 348 153 sig~ 22050; #X obj 311 206 *~; #X obj 312 228 abs~; #X obj 311 250 +~ 1.8955; #X obj 106 49 inlet~; #X obj 87 542 outlet~; #X obj 348 104 samplerate~; #X obj 348 81 loadbang; #X obj 348 127 * 0.5; #X obj 174 427 +~; #N canvas 104 42 701 480 sin(x)/x 0; #X obj 220 229 cos~; #X obj 221 204 -~ 0.25; #X msg 288 90 1; #X floatatom 288 162 5 0 0 0 - - -; #X obj 288 116 atan; #X obj 288 137 * 8; #X obj 220 181 /~ 6.238; #X obj 288 67 loadbang; #X obj 221 148 inlet~; #X obj 219 291 outlet~; #X obj 220 255 /~; #X connect 0 0 10 0; #X connect 1 0 0 0; #X connect 2 0 4 0; #X connect 3 0 6 1; #X connect 4 0 5 0; #X connect 5 0 3 0; #X connect 6 0 1 0; #X connect 7 0 2 0; #X connect 8 0 6 0; #X connect 8 0 10 1; #X connect 10 0 9 0; #X restore 311 280 pd sin(x)/x; #X obj 220 379 *~; #X text 247 374 v2*sin(v4)/v4; #X text 208 426 + v3; #X obj 87 482 -~; #X obj 175 183 pow~ -1; #X connect 0 0 1 0; #X connect 0 0 21 1; #X connect 1 0 2 0; #X connect 1 0 3 0; #X connect 1 0 22 0; #X connect 2 0 8 0; #X connect 3 0 4 0; #X connect 4 0 5 0; #X connect 5 0 18 0; #X connect 6 0 8 1; #X connect 7 0 6 0; #X connect 8 0 9 0; #X connect 9 0 10 0; #X connect 10 0 17 0; #X connect 11 0 0 0; #X connect 11 0 6 1; #X connect 13 0 15 0; #X connect 14 0 13 0; #X connect 15 0 7 0; #X connect 16 0 21 0; #X connect 17 0 18 1; #X connect 18 0 16 1; #X connect 21 0 12 0; #X connect 22 0 16 0;
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
ok.here is a version using [pow~ -1] to replace [>~ 0] it should work with vanilla pd version >= 0.42 and with rjdj. and certainly with pd-extended.
I also did one which replaces >~ with the tabread lookup from Enrique's [>~] embedded.
Ciao
Frank
Frank Barknecht a écrit :
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
ok.here is a version using [pow~ -1] to replace [>~ 0] it should work with vanilla pd version >= 0.42 and with rjdj. and certainly with pd-extended.
I also did one which replaces >~ with the tabread lookup from Enrique's [>~] embedded.
yep, this is a more clever vay to do this. thx. c
Ciao
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 29 Mar 2009, at 12:53, Frank Barknecht wrote:
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
I think, currently it's probably a bit slower because of the sin (), but maybe that could be put into a tabread~.
i think the sin object is doing a linear interpolation in a 512
point table. (don't know how it is done in expr~, but expr~ is not used for
rjlib because of it's licence, right?)Attached is an expr-less version of saw~ which from a quick glance at the scope looks and sounds the same. It is vanilla in that it uses [abs~] and [>~] which are part of 0.42 (and thus RjDj). On older Pd versions you can use for example the purepd abstractions for both from the SVN in abstractions/purepd
thanks for posting this.
for certain freqs i hear a noticeable periodic "zipping" in the sound
(try 230 hz e.g.).
since the algorithm is based on the sinc function (sin(x)/x), i
wonder how pd handles divide by zero in the signal domain. wouldn't
you have to check for that in the code/patch?
volker.
Hallo, volker b?hm hat gesagt: // volker b?hm wrote:
thanks for posting this. for certain freqs i hear a noticeable periodic "zipping" in the sound
(try 230 hz e.g.).
Hm, I don't hear it, but that may be my ears.
since the algorithm is based on the sinc function (sin(x)/x), i wonder how pd handles divide by zero in the signal domain. wouldn't you have to check for that in the code/patch?
A [/~] with no signal in the right inlet in Pd gives 0 as output. In saw~.pd x never becomes zero, it's always at least 1.8955. :)
Ciao
Frank
Frank Barknecht a écrit :
Hallo, volker b?hm hat gesagt: // volker b?hm wrote:
thanks for posting this. for certain freqs i hear a noticeable periodic "zipping" in the sound
(try 230 hz e.g.).Hm, I don't hear it, but that may be my ears.
don't hear it also.
since the algorithm is based on the sinc function (sin(x)/x), i wonder how pd handles divide by zero in the signal domain. wouldn't you have to check for that in the code/patch?
A [/~] with no signal in the right inlet in Pd gives 0 as output. In saw~.pd x never becomes zero, it's always at least 1.8955. :)
yep c
Ciao
for some reason my mails to the list take ages until they arrive,
which makes a discussion a little difficult...
ok, something weird going on here. abs~ is not doing what i would
think it should be doing - calculating the absolute value of the
incoming signal. instead it simply seems to pass input to output (no
errors in pd window).
if i replace abs~ with an abstraction then it works and the zipping
is gone.
this happens here with pd vanilla 0.42-4.
just tried pd-extended and there it works with abs~.
what could be wrong with my vanilla abs~?
On 29 Mar 2009, at 14:54, Frank Barknecht wrote:
Hallo, volker b?hm hat gesagt: // volker b?hm wrote:
thanks for posting this. for certain freqs i hear a noticeable periodic "zipping" in the sound (try 230 hz e.g.).
Hm, I don't hear it, but that may be my ears.
since the algorithm is based on the sinc function (sin(x)/x), i
wonder how pd handles divide by zero in the signal domain. wouldn't you
have to check for that in the code/patch?A [/~] with no signal in the right inlet in Pd gives 0 as output. In saw~.pd x never becomes zero, it's always at least 1.8955. :)
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Hallo Volker,
ah, there's a bug in d_math.c
Actually there are two: on is reported as "exp~ broken/fixed - ID: 2638371", but the same issue affects abs, too. Patch for both is attached.
(I hadn't recognized this because it seems I was using a different [abs~]. Freakying object aliassing...)
Ciao
Frank
volker b?hm hat gesagt: // volker b?hm wrote:
for some reason my mails to the list take ages until they arrive, which makes a discussion a little difficult...
ok, something weird going on here. abs~ is not doing what i would think it should be doing - calculating the absolute value of the incoming signal. instead it simply seems to pass input to output (no errors in pd window).
if i replace abs~ with an abstraction then it works and the zipping is gone. this happens here with pd vanilla 0.42-4.
just tried pd-extended and there it works with abs~.
what could be wrong with my vanilla abs~?
On 29 Mar 2009, at 14:54, Frank Barknecht wrote:
Hallo, volker b?hm hat gesagt: // volker b?hm wrote:
thanks for posting this. for certain freqs i hear a noticeable periodic "zipping" in the sound (try 230 hz e.g.).
Hm, I don't hear it, but that may be my ears.
since the algorithm is based on the sinc function (sin(x)/x), i
wonder how pd handles divide by zero in the signal domain. wouldn't you
have to check for that in the code/patch?A [/~] with no signal in the right inlet in Pd gives 0 as output. In saw~.pd x never becomes zero, it's always at least 1.8955. :)
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On 29 Mar 2009, at 16:44, Frank Barknecht wrote:
Hallo Volker,
ah, there's a bug in d_math.c
Actually there are two: on is reported as "exp~ broken/fixed - ID:
2638371", but the same issue affects abs, too. Patch for both is attached.(I hadn't recognized this because it seems I was using a different
[abs~]. Freakying object aliassing...)
aha, yes, i can see the bug in the source. thanks for pointing this out.
however i never succeeded in building pd vanilla on osx myself
(anyone?).
so it seems i can't apply the fix myself, but have to wait for a new
version.
vb
Hallo, volker b?hm hat gesagt: // volker b?hm wrote:
however i never succeeded in building pd vanilla on osx myself
(anyone?). so it seems i can't apply the fix myself, but have to wait for a new
version.
You could copy over some abs~.pd_darwin from pd-extended, pd-0.42 will happily use that instead.
Ciao
Frank
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Hallo, volker b?hm hat gesagt: // volker b?hm wrote:
however i never succeeded in building pd vanilla on osx myself
(anyone?). so it seems i can't apply the fix myself, but have to wait for a new
version.You could copy over some abs~.pd_darwin from pd-extended, pd-0.42 will happily use that instead.
Or use Enrique's table idiom instead. I attached it applied to abs~. (You can get sgn~ from it as well)
Ciao
Frank
On 29 Mar 2009, at 19:09, Frank Barknecht wrote:
You could copy over some abs~.pd_darwin from pd-extended, pd-0.42
will happily use that instead.
i tried that, but here pd vanilla always prefers its own internal abs~.
sticking the external abs~ into /Contents/Resources/extra/ didn't help.
neither did creating an extra folder (with abs~ inside) and adding
its path to pd's path preferences (this normally works for adding my
own externals).
where would i put the external, to overrule the internal?
as i understand from the recent discussions this process is rather
convoluted, but is it also unpredictable?
vb
Hallo, volker b?hm hat gesagt: // volker b?hm wrote:
i tried that, but here pd vanilla always prefers its own internal abs~. sticking the external abs~ into /Contents/Resources/extra/ didn't help. neither did creating an extra folder (with abs~ inside) and adding its path to pd's path preferences (this normally works for adding my own externals).
where would i put the external, to overrule the internal? as i understand from the recent discussions this process is rather
convoluted, but is it also unpredictable?
It's "strange" and in the opinion of several other developers like IOhannes (and I think me, too) buggy by design, too. But if you load the abs~.pd_darwin with "-lib abs~" then that should override the internal.
However it's better for now to replace the [abs~] with the tabread~ solution I posted as "absolute~.pd" yesterday. Just embed it into the patch.
Ciao
Frank
On 29/03/2009, at 17.41, volker böhm wrote:
however i never succeeded in building pd vanilla on osx myself
(anyone?).
No, not with the makefile shipped with vanilla. It would be nice to
know who Miller actually builds it.
On Mar 29, 2009, at 3:20 PM, Steffen Juul wrote:
On 29/03/2009, at 17.41, volker böhm wrote:
however i never succeeded in building pd vanilla on osx myself
(anyone?).No, not with the makefile shipped with vanilla. It would be nice to
know who Miller actually builds it.
You can build it with the Pd-extended build system. You just have to
remove the --enable-jack or use the old version of JackOSX.
.hc
¡El pueblo unido jamás será vencido!
On 30 Mar 2009, at 00:31, Hans-Christoph Steiner wrote:
On Mar 29, 2009, at 3:20 PM, Steffen Juul wrote:
On 29/03/2009, at 17.41, volker böhm wrote:
however i never succeeded in building pd vanilla on osx myself
(anyone?).No, not with the makefile shipped with vanilla. It would be nice
to know who Miller actually builds it.You can build it with the Pd-extended build system. You just have
to remove the --enable-jack or use the old version of JackOSX.
thanks hc, i remember you mentioned that before.
i did try it some time ago, but didn't get very far either.
didn't spend much time on this, so no complaints. it probably works
that way.
but i remember downloading a lot of files (part of which i didn't
actually want), trying to compile a huge amount of code and finally
stranding in some chaotic/confused state ;)
i thought that the documentation to end up with a simple vanilla
build wasn't particulary clear.
(if it's useful, i could go into greater detail here)
what remains is the impression that it shouldn't be so complicated
(compared to a simple linux build!).
but obviously osx doesn't play well in this respect.
vb
On Mon, Mar 30, 2009 at 3:52 AM, volker böhm vboehm@gmx.ch wrote:
On 30 Mar 2009, at 00:31, Hans-Christoph Steiner wrote:
On Mar 29, 2009, at 3:20 PM, Steffen Juul wrote:
On 29/03/2009, at 17.41, volker böhm wrote:
however i never succeeded in building pd vanilla on osx myself (anyone?).
No, not with the makefile shipped with vanilla. It would be nice to know who Miller actually builds it.
Hmm.. I build Pd on OS X all the time! I don't think I've done anything special but perhaps I did long ago. Of course, I don't know the process by which Miller assembles the Pd app bundle, but I simply build the pd binary and drop it in to the latest Pd.app from Miller's site.
Where is it failing? Best Luke
You can build it with the Pd-extended build system. You just have to remove the --enable-jack or use the old version of JackOSX.
thanks hc, i remember you mentioned that before. i did try it some time ago, but didn't get very far either. didn't spend much time on this, so no complaints. it probably works that way. but i remember downloading a lot of files (part of which i didn't actually want), trying to compile a huge amount of code and finally stranding in some chaotic/confused state ;) i thought that the documentation to end up with a simple vanilla build wasn't particulary clear. (if it's useful, i could go into greater detail here)
what remains is the impression that it shouldn't be so complicated (compared to a simple linux build!). but obviously osx doesn't play well in this respect.
vb _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 30 Mar 2009, at 14:01, Luke Iannini wrote:
On Mon, Mar 30, 2009 at 3:52 AM, volker böhm vboehm@gmx.ch wrote:
On 30 Mar 2009, at 00:31, Hans-Christoph Steiner wrote:
On Mar 29, 2009, at 3:20 PM, Steffen Juul wrote:
On 29/03/2009, at 17.41, volker böhm wrote:
however i never succeeded in building pd vanilla on osx myself (anyone?).
No, not with the makefile shipped with vanilla. It would be nice
to know who Miller actually builds it.Hmm.. I build Pd on OS X all the time! I don't think I've done anything special but perhaps I did long ago. Of course, I don't know the process by which Miller assembles the Pd app bundle, but I simply build the pd binary and drop it in to the latest Pd.app from Miller's site.
aha, that's interesting - thanks, luke, this works indeed!
i'm still on ppc and had to run ./configure with "--disable-fat" to
make the compilation work.
so far so good. i had already found that during my earlier attempts
to build pd.
doing this i end up with
libPdTcl.dylib, pd, pd-watchdog, pd.tk, pdreceive, pdsend
in the /bin folder.
BUT i wrongly assumed, i could start pd on osx just (as under linux)
directly from the bin folder by typing ./pd
this turned out to not work, giving me a pd window, but a
nonfunctional app (menus not filled, no reaction to key strokes,
indicating "wish" instead of "pd" etc.).
but replacing the pd bin in an old application bundle by the freshly
compiled pd binary did the trick.
(and now abs~ is performing fine!)
actually i have just tried with an old copy of pd-0.37-1 for osx and
there it works by starting pd directly from /bin - something
obviously changed in between.
i would be interested in knowing what's the startup sequence when
double clicking on the app bundle.
(and how one can build the app bundle after all).
thanks, vb
On 30/03/2009, at 16.31, volker böhm wrote:
i would be interested in knowing what's the startup sequence when
double clicking on the app bundle.
I think Hans has documented exactly that. Maybe you can find the
appropriate thread on the pd-dev list.
On 30/03/2009, at 14.01, Luke Iannini wrote:
On Mon, Mar 30, 2009 at 3:52 AM, volker böhm vboehm@gmx.ch wrote:
On 30 Mar 2009, at 00:31, Hans-Christoph Steiner wrote:
On Mar 29, 2009, at 3:20 PM, Steffen Juul wrote:
On 29/03/2009, at 17.41, volker böhm wrote:
however i never succeeded in building pd vanilla on osx myself (anyone?).
No, not with the makefile shipped with vanilla. It would be nice
to know who Miller actually builds it.Hmm.. I build Pd on OS X all the time! I don't think I've done anything special but perhaps I did long ago. Of course, I don't know the process by which Miller assembles the Pd app bundle, but I simply build the pd binary and drop it in to the latest Pd.app from Miller's site.
Ah ok. Thanks for sharing that tip. Maybe Miller actually make
the .app that way. That could explain why the CFBundleVersion tag in
Info.plist still is set to 0.38. Side note: I think Marius found that
to be the problem with newer versions not being the standard for
opening Pd patches.
Where is it failing?
It didn't really fail. IT just doesn't assemble a .app - as Volker
described.
volker böhm wrote:
for some reason my mails to the list take ages until they arrive, which makes a discussion a little difficult...
hmm, please bear in mind that "email" is an asynchronous medium. this medium was designed to make discussions with people who might be online only a few times a week. and i don't have the feeling that your mails takes "ages" (at least in this thread you have been able to reply indirectly to yourself within 3 hours)
if you feel that an asynchronous medium is not the right choice to lead a discussion, why not try IRC?
ok, something weird going on here. abs~ is not doing what i would think it should be doing - calculating the absolute value of the incoming signal. instead it simply seems to pass input to output (no errors in pd window).
yes, this is a known bug of [abs~] in Pd-0.42. see frank's other mails.
mfdsr IOhannes
On Sun, 29 Mar 2009, Frank Barknecht wrote:
volker b?hm hat gesagt: // volker b?hm wrote:
thanks for posting this. for certain freqs i hear a noticeable periodic "zipping" in the sound (try 230 hz e.g.).
Hm, I don't hear it, but that may be my ears.
since the algorithm is based on the sinc function (sin(x)/x), i wonder how pd handles divide by zero in the signal domain. wouldn't you have to check for that in the code/patch?
A [/~] with no signal in the right inlet in Pd gives 0 as output. In saw~.pd x never becomes zero, it's always at least 1.8955. :)
Well, if divide-by-zero happens any often in there, it would be worthwhile to do an explicit check for divide-by-zero in the patch, because in this case 0/0 is expected to give 1, as all neighbouring values of sin(x)/x are getting closer to 1 as x gets closer to 0: that's what you need to make sin(x)/x a smooth function.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
-
cyrille henry -
Derek Holzer -
dmotd -
Enrique Erne -
Frank Barknecht -
Hans-Christoph Steiner -
hard off -
IOhannes m zmoelnig -
Luke Iannini -
Mathieu Bouchard -
Steffen Juul -
volker böhm