[PD] Avoiding clipping with tabread4
Hi list, I hope my repeating questions don't annoy anyone. I've sent a similar question a while back to [pd-ot] but with out response, have been thinking over it, found no answer so far. Although I had never concerned it till recently, I've learned that 4 point interpolation may at times return values less than -1 or greater than 1 even when the 4 reference points are with in that range. i.e., having a table of [-1 1 1 -1], an index of 1.5 will return 1.25 with [tabread4] Are there any common practices to avoid unexpected clipping introduced by [tabread4] or [tabosc4~] ? Further more, under what circumstances (what 4 values referred to) will the returned value exceed the range most? Thanks in advance.. -- David Shimamoto ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Disabling a [gemhead] by default (Re: Writing texture to different sides of cube in GEM)
PSPunch a écrit : The attached example works great. Going slightly off topic, if I am not mistaken, the rectangle on the top of the cube is rendered twice as seen in some other cases I've seen in patches using the dual gemhead technique. Disabling the [gemhead] by sending it a 0 seems to avoid this. Since this seems to be a common usage, is there a way to have a gemhead already turned off on creation? (put it in a state as if it had a 0 sent to its inlet) If not done yet, are there any plans to implement arguments that will do this? I thought of -1 for a second but according to the help file, [gemhead] seems to accept negative numbers so I guess it is not an option.. what is the problem with : [loadbang] | [0 ??? -- David Shimamoto Adityo Pratomo skrev: i've tried this method yesterday, buat still found it hard to stick the square's edge to form a cube. It still looked like a cube, but it's not solid try attached. .:..:..:..:. mvh Stef ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Disabling a [gemhead] by default (Re: Writing texture to different sides of cube in GEM)
Hi cyrille what is the problem with : [loadbang] | [0 Yes, that will work. For example, [gemwin] starts out disabled and without the window showing, or say, [metro] being off by default. It is reasonable that [gemhead] is on by default, but being able to state in the object itself, self concluding, that it is intended to being off may make help clear its function. Maybe I just feel so because the dual gemhead method is something I use regularly with my Gem projects. -- David Shimamoto ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] filtering: a lowpass resonant filter
can anyone point out to me a nice pure-pd resonant lowpass filter? the only lowpass filter i know about is vcf_lp2~ from iemlib, but i can't use iemlib in the project i'm working on. so - how do i make a resonant lowpass resonant filter? can i chain two biquad~s together? or is there some other trick? thanks d -- damian stewart | +31 6 5902 5782 | [EMAIL PROTECTED] frey | live art with machines | http://www.frey.co.nz ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] filtering: a lowpass resonant filter
Damian Stewart wrote: can anyone point out to me a nice pure-pd resonant lowpass filter? I made one a while ago, following miller's book, not necessarily nice but it is a resonant lowpass filter... http://lists.puredata.info/pipermail/pd-list/2007-11/056865.html Claude ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Disabling a [gemhead] by default (Re: Writing texture to different sides of cube in GEM)
Quoting PSPunch [EMAIL PROTECTED]: Yes, that will work. For example, [gemwin] starts out disabled and without the window showing, or say, [metro] being off by default. It is reasonable that [gemhead] is on by default, but being able to state in the object itself, self concluding, that it is intended to being off may make help clear its function. i totally agree. however, since i am currently planning to replace [gemhead] with an abstraction, which would allow you define the behaviour as you like it, i don't want to add complexity to the current implementation. don't know when this will be implemented yet, but it is rather high on my todo list. mfga.r IOhannes This message was sent using IMP, the Internet Messaging Program. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] filtering: a lowpass resonant filter
Damian Stewart wrote: can anyone point out to me a nice pure-pd resonant lowpass filter? the only lowpass filter i know about is vcf_lp2~ from iemlib, but i can't use iemlib in the project i'm working on. so - how do i make a resonant lowpass resonant filter? can i chain two biquad~s together? or is there some other trick? thanks d to answer my own question: use [biquad~] with coefficients taken from the [lowpass] external. now, to turn the [lowpass] external into pure-pd... -- damian stewart | +31 6 5902 5782 | [EMAIL PROTECTED] frey | live art with machines | http://www.frey.co.nz ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Disabling a [gemhead] by default (Re: Writing texture to different sides of cube in GEM)
Hallo, [EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote: however, since i am currently planning to replace [gemhead] with an abstraction, which would allow you define the behaviour as you like it, i don't want to add complexity to the current implementation. don't know when this will be implemented yet, but it is rather high on my todo list. And of course one could do a little wrapper [gemhead-off] immediatly for this. Or even wrap the whole double gemhead into an abstraction as attached. Ciao -- Frank #N canvas 339 288 724 390 10; #X obj 116 158 dgemhead; #X obj 116 133 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 116 247 translateXYZ; #X obj 142 215 unpack 0 0; #X obj 116 278 square 0.1; #X obj 118 73 gemwin; #X msg 118 47 create \, 1; #X msg 217 144 -2.72 1.52 \, -1.12 0.56 \, 3.04 -1.68 \, -2.8 3.92 \, -2.48 3.28 \, -0.4 -0.72 \, -3.92 -2.64 \, 1.2 -3.28 \, -1.04 -2.16 \, 1.76 -0.24 \, 0.8 -1.68 \, 3.36 -2.88 \, 0.88 -3.52 \, 0.72 2.64 \, -3.28 -1.68 \, 2.72 -1.04 \, 1.92 -2.56 \, -1.68 2 \, 0.32 3.52 \,; #X text 259 119 do something here:; #X connect 0 0 2 0; #X connect 0 1 3 0; #X connect 0 2 7 0; #X connect 1 0 0 0; #X connect 2 0 4 0; #X connect 3 0 2 1; #X connect 3 1 2 2; #X connect 6 0 5 0; #X connect 7 0 0 1; #N canvas 458 354 450 300 10; #X obj 173 181 gemhead; #X obj 104 123 loadbang; #X msg 104 149 0; #X obj 318 93 gemhead; #X obj 173 24 inlet; #X obj 173 247 outlet; #X obj 173 84 t b a; #X obj 235 247 outlet; #X obj 318 246 outlet; #X obj 318 216 b; #X obj 74 26 inlet; #X connect 0 0 5 0; #X connect 1 0 2 0; #X connect 2 0 0 0; #X connect 3 0 9 0; #X connect 4 0 6 0; #X connect 6 0 0 0; #X connect 6 1 7 0; #X connect 9 0 8 0; #X connect 10 0 3 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Disabling a [gemhead] by default (Re: Writing texture to different sides of cube in GEM)
Frank Barknecht a écrit : Hallo, [EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote: however, since i am currently planning to replace [gemhead] with an abstraction, which would allow you define the behaviour as you like it, i don't want to add complexity to the current implementation. don't know when this will be implemented yet, but it is rather high on my todo list. And of course one could do a little wrapper [gemhead-off] immediatly for this. Or even wrap the whole double gemhead into an abstraction as attached. the best would be not to use the double gemhead trick, but the repeat (or until) trick instead : it's faster, and don't have this problem, so i think it's easier to understand. see attachment cyrille Ciao ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 366 83 738 436 10; #X obj 118 73 gemwin; #X msg 118 47 create \, 1; #X msg 121 154 -2.72 1.52 \, -1.12 0.56 \, 3.04 -1.68 \, -2.8 3.92 \, -2.48 3.28 \, -0.4 -0.72 \, -3.92 -2.64 \, 1.2 -3.28 \, -1.04 -2.16 \, 1.76 -0.24 \, 0.8 -1.68 \, 3.36 -2.88 \, 0.88 -3.52 \, 0.72 2.64 \, -3.28 -1.68 \, 2.72 -1.04 \, 1.92 -2.56 \, -1.68 2 \, 0.32 3.52 \,; #X text 256 126 do something here:; #X obj 121 107 gemhead; #X obj 121 237 gemlist; #X obj 121 131 t b a; #X obj 121 259 separator; #X obj 121 216 t b l; #X obj 121 309 translateXYZ; #X obj 148 284 unpack 0 0; #X obj 122 331 square 0.1; #X connect 1 0 0 0; #X connect 2 0 8 0; #X connect 4 0 6 0; #X connect 5 0 7 0; #X connect 6 0 2 0; #X connect 6 1 5 1; #X connect 7 0 9 0; #X connect 8 0 5 0; #X connect 8 1 10 0; #X connect 9 0 11 0; #X connect 10 0 9 1; #X connect 10 1 9 2; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] loopool63
hi where can i find it? though it shouldn't, the version on tim blechmann's member page (http://puredata.info/Members/timblech/loopool63/view) is still 64. thx mik ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Disabling a [gemhead] by default (Re: Writing texture to different sides of cube in GEM)
Hallo, cyrille henry hat gesagt: // cyrille henry wrote: the best would be not to use the double gemhead trick, but the repeat (or until) trick instead : it's faster, and don't have this problem, so i think it's easier to understand. Yes: Everyone is on the latest Gem should use gemlist instead of the old double gemhead approach. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 'pure' pd DSP abstractions wanted!
On Sun, 2008-08-24 at 15:08 -0400, Enrique Erne wrote: Anton Hörnquist wrote: In my view jon~ is open source so feel free to use it in any way. I'm not sure how to... well.. document this. What's the best and simplest way? Should I write something about it in the help patch? What license should I use - GPL? Any hints about this are appreciated. :) i'd like to see the purepd project having the same licence as puredata. I think BSD-style would be better than GPL, which seems a bit inappropriate for Pd abstractions with its emphasis on linkage and source vs binary distributions etc which don't really apply. Personally, I vote for these patches being public domain, PD patches for Pd! Frank B has argued for this in the past, and I think its quite convincing. Jamie -- www.postlude.co.uk http://www.linkedin.com/in/jamiebullock ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Disabling a [gemhead] by default (Re: Writing texture to different sides of cube in GEM)
Jack a écrit : We are talking about [gemlist]. Is there a difference with [any] ? gemlist is a gem object, that work only with gem data any is an (iem) external that work with any data. you can replace gemlist with any in your patch, but gemlist should work without any dependency (except Gem of course) cyrille Thanx. ++ Jack Le 25 août 08 à 18:51, Frank Barknecht a écrit : Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: Hallo, cyrille henry hat gesagt: // cyrille henry wrote: the best would be not to use the double gemhead trick, but the repeat (or until) trick instead : it's faster, and don't have this problem, so i think it's easier to understand. Yes: Everyone is on the latest Gem should use gemlist instead of the old double gemhead approach. oh, and of course if people have been usign some abstraction like the dgemhead, it's easy to update it to use [gemlist], if that's available. Ciao -- Frank ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Disabling a [gemhead] by default (Re: Writing texture to different sides of cube in GEM)
OK, thank you for the precisions. ++ Jack Le 25 août 08 à 19:32, cyrille henry a écrit : Jack a écrit : We are talking about [gemlist]. Is there a difference with [any] ? gemlist is a gem object, that work only with gem data any is an (iem) external that work with any data. you can replace gemlist with any in your patch, but gemlist should work without any dependency (except Gem of course) cyrille Thanx. ++ Jack Le 25 août 08 à 18:51, Frank Barknecht a écrit : Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: Hallo, cyrille henry hat gesagt: // cyrille henry wrote: the best would be not to use the double gemhead trick, but the repeat (or until) trick instead : it's faster, and don't have this problem, so i think it's easier to understand. Yes: Everyone is on the latest Gem should use gemlist instead of the old double gemhead approach. oh, and of course if people have been usign some abstraction like the dgemhead, it's easy to update it to use [gemlist], if that's available. Ciao -- Frank ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Avoiding clipping with tabread4
On Mon, Aug 25, 2008 at 7:48 AM, PSPunch [EMAIL PROTECTED] wrote: i.e., having a table of [-1 1 1 -1], an index of 1.5 will return 1.25 with [tabread4] This is correct. The interpolated values can exceed the values in the samples. Think about drawing a polynomial through your points, and where the maximum actually can occur. Are there any common practices to avoid unexpected clipping introduced by [tabread4] or [tabosc4~] ? Common practices, not sure. But I think we can establish an upper bound on the peak value, analytically. Our polynomial for tabread4~: g(x)= f[-1]*x(x-1)(x-2)/-6 + f[0]*(x+1)(x-1)(x-2)/2 + f[1]*(x+1)x(x-2)/-2 + f[2]*(x+1)x(x-1)/6 So, the maximum value must occur as a function of x between 0 and 1. Taking our input peak value as 1, the maximum output peak is the sum of the absolute value of the coefficients of f[-1], f[0], f[1], f[2] x(x-1)(x-2)/6 + (x+1)(x-1)(x-2)/2 - (x+1)x(x-2)/2 - (x+1)x(x-1)/6 = -x^2 + x + 1 vertex: x=1/2, f(1/2) = 1.25 Further more, under what circumstances (what 4 values referred to) will the returned value exceed the range most? How do you like answering your own questions :) Your example is exactly it. Chuck Thanks in advance.. -- David Shimamoto ___ 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
Re: [PD] filtering: a lowpass resonant filter
Damian Stewart wrote: to answer my own question: use [biquad~] with coefficients taken from the [lowpass] external. i while ago i have tried to build a resonant lp with biquad~, but had problems with clicks, when the coefficient were changed (even with quite slow changes). only very slow changes did not produce clicks, which is a little strange, since biquad-filters in my vst-plugins do not produce any clicks (and i compute the coefficients only every 96 samples or so (iirr), i use the other biquad form though. i had better luck with the cpole/zero~ objects, the result sounded at least like a resonant lp, good enough for a little squelchy bassline synth. though i still have not found out how to calculate the a0 (volume level scaling) coefficient right (and i could not get hold of the book that was reccomended on the list yet) bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [Style Guide] 1. Separators in Send/Receive/Value names
On Wed, Aug 13, 2008 at 12:52 AM, Steffen Juul [EMAIL PROTECTED] wrote: On 13/08/2008, at 9.27, Luke Iannini wrote: I think we should adopt - for spaces, since it's the most prevalent style I've encountered. I personal don't care if it's dash or underscore or camelCase. And, I think whatever we decide on as the hierarchical separator should be used to separate $0, $1 etc from the name itself. When creating a hierarchy in a send/receive, one usually gloms together keys from parent abstractions, e.g. start with /bigsynth, then inside pass $1/filter to a child abstraction, then inside that use $1/cutoff to get /bigsynth/filter/cutoff. I see $0 as no different; it means (or, is used to mean) this-instance/cutoff, and thus should be separated accordingly. I agree. And, I have a slight leaning towards . over / as the send/receive hierarchical separator since it provides a distinction from OSC addresses and namespaces. I would be cool if you/someone could cook up some use case examples of this to makes things more clear in a practical way and less theoretical/bikeshedcolor-like. I think Frank suggested similar earlier on. This is a good suggestion, as actually putting this into practice revealed at least one issue, which is when using a set of nested abstractions that you also want to use with OSC, as in Memento and my in-progress OSC-enabled SSSAD. I still like the idea of having a Pd-style for hierarchies to distinguish them from OSC, as I personally think it's a bit confusing to, e.g., have a [routeOSC /synth/filter/resonance] and an [r /synth/filter/resonance] in the same patch. I'm going to work with the idea in practice for a while so I can try to figure out a solution to this... I made a special [routeOSC] that can accept a Pd-style hierarchy and convert it to an OSC address as a first stab, but maybe that ends up causing just as much confusion? So, this is another reason to have some other people's perspectives on all this, as I'm not sure how much convenience when using OSC should factor into a Pd style. I am interested in deciding this issue first as I think, as Enrique said, there is no real precedent in place, and, because this is the most critical component for having patches talk to each other. That's why I'd like to define a syntax that has enough flexibility to cover most cases (e.g. NetPd/PdMTL/s-abstractions/DIYlib and so on). That way, patch collections could speak to one another without worrying.about whoUses which-syntax for_which_abstractions. Best Luke Ps. I think it's very cool that you attempt this work, and also honorable (though i hate that word) that you follow up on it and organize peoples opinions into a wiki-page. Maillists are such a terrible structured kind of documentation. ___ 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
[PD] Csound opcode Moogladder to Pd?
I've used the Csound opcode Moogladder (based on an algorithm by Antti Huovilainen) in Pd using csoundapi~. It uses a lot of cpu cycles but it sounds really good. The csoundapi~ external is useful but it only allows one instance per patch on windows so ideally I would like to have this opcode as a Pd abstraction or external and get rid of the csoundapi~ external. Is it possible to convert the Moogladder opcode to a Pd abstraction? Csound code: http://www.csounds.com/udo/displayOpcode.php?opcode_id=32 /Anton ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Csound opcode Moogladder to Pd?
Anton Hörnquist wrote: I've used the Csound opcode Moogladder (based on an algorithm by Antti Huovilainen) in Pd using csoundapi~. It uses a lot of cpu cycles but it sounds really good. The csoundapi~ external is useful but it only allows one instance per patch on windows so ideally I would like to have this opcode as a Pd abstraction or external and get rid of the csoundapi~ external. Is it possible to convert the Moogladder opcode to a Pd abstraction? Csound code: http://www.csounds.com/udo/displayOpcode.php?opcode_id=32 It should be possible to make an external with that. I could give it a go, but there's already an extern [moog~] in ggee of the pd-extended. Is that not the same? Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Csound opcode Moogladder to Pd?
Hallo, Martin Peach hat gesagt: // Martin Peach wrote: Anton H?rnquist wrote: I've used the Csound opcode Moogladder (based on an algorithm by Antti Huovilainen) in Pd using csoundapi~. It uses a lot of cpu cycles but it sounds really good. The csoundapi~ external is useful but it only allows one instance per patch on windows so ideally I would like to have this opcode as a Pd abstraction or external and get rid of the csoundapi~ external. Is it possible to convert the Moogladder opcode to a Pd abstraction? Csound code: http://www.csounds.com/udo/displayOpcode.php?opcode_id=32 It should be possible to make an external with that. I could give it a go, but there's already an extern [moog~] in ggee of the pd-extended. Is that not the same? I think [moog~] follows the older Stilson/J.O.Smith model of the moog filter from 1996, while the moogladder opcode is an implementation of a later publication from 2004: http://dafx04.na.infn.it/WebProc/Proc/P_061.pdf I think, it may also be possible to implement it as a pure Pd abstraction with some stacked [rpole~]s and fine tuning, as from a quick look it seems to be just a bunch of first order filters with tanh()-distorted filter coefficients. But quick looks may be deceiving ... Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 'pure' pd DSP abstractions wanted!
hi, pdmtl is compatible with the last release of pd-extended (0.40.3). only xsample / py (flext stuff) are not included in pd-extended. the sad thing is that people need to edit the lib to load tof and iemmatrix. i don't know why tof and iemmatrix are not in the list of loaded libs... hans? jamie, what do you mean by providing a reference to purepd implementations, rather than holding them in their repository. we use goto10 svn server, this way we don't need a pd-dev account to maintain pdmtl. pat ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Csound opcode Moogladder to Pd?
Frank Barknecht wrote: I think, it may also be possible to implement it as a pure Pd abstraction with some stacked [rpole~]s and fine tuning, as from a quick look it seems to be just a bunch of first order filters with tanh()-distorted filter coefficients. But quick looks may be deceiving ... You have been deceived, the filter has the tanh()s inside the recursive loops, so it's not a linear filter. Claude ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Disabling a [gemhead] by default (Re: Writing texture to different sides of cube in GEM)
Thanks all for the ideas. I thought the dgemhead and repeat methods were just a matter of preference. If one is trendy and the other out dated, I guess I can just drop the one said to be less efficient. -- David Shimamoto ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Disabling a [gemhead] by default (Re: Writing texture to different sides of cube in GEM)
PSPunch wrote: I thought the dgemhead and repeat methods were just a matter of preference. If one is trendy and the other out dated, I guess I can just drop the one said to be less efficient. as far as I understand it, there are now 3 methods: 1: double [gemhead] 2: [repeat] 3: [until] with [gemlist] 1 requires only Gem, but is least efficient 2 requires Gem and zexy, but is most efficient 3 requires only Gem, but Gem newer than a certain version 3 is very close to 2 in efficiency They may also have different behaviour, I think (1) implies a built-in [separator] which may or may not be what you want? Please correct this if I'm wrong! Claude ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Avoiding clipping with tabread4
Hi Charles, Common practices, not sure. But I think we can establish an upper bound on the peak value, analytically. Ok, So to be secure, [* 0.8] (1/1.25) will prevent such clips I guess. As the series being somewhat are, perhaps for wavetable synthesis, I guess a larger factor or a simple [clip] may be practical as well. Anyway I appreciate you backing me up with my question. How do you like answering your own questions :) Your example is exactly it. It was a rough guess taken from my understanding of what the formula did, however, I had no idea why. The whole idea of polynomial interpolation to me, was something I had to read multiple explanations before understanding. Yours certainly carried me through the last few steps to reach my goal. Thank you so much. -- David Shimamoto ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 'pure' pd DSP abstractions wanted!
Quoting Jamie Bullock [EMAIL PROTECTED]: On Sun, 2008-08-24 at 09:54 -0400, Enrique Erne wrote: Hi Jamie It's not much but might be helpful to port other stuff to purepd. you'll find gt~.pd (~) lt~.pd (~) sgn~.pd http://www.netpd.org/eni/purepd/ That's great actually, and I'd love to contribute back into this. However, if I'm not mistaked aren't there two purepd projects netpd/purepd and Hans's purepd in pd svn? Would it be worth feeding your patches into Hans's, and then any other abstractions I make/find I can also feed into svn? just out of curiosity: ~.pd, ~.pd, sgn~ and what else in zexy are already pd-vanilla abstractions (some of them are both abstractions and externals for performance reasons); is there an advantage in collecting these things in yet another arbitrary (as opposed to grouped by functionality) library? fgmasdr IOhannes This message was sent using IMP, the Internet Messaging Program. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] find formants from fft table
Hi, I want to find the max values of a table what is the result of a fft. I tried using a counter and comparing manually, but it take too long, and I need to do it as fast as possible, without compromising audio processing. Do you know if there is some external what I can use to do that? I just need to do it one time for every block, or even less, I just want to know the formants of a sound (speech). Thanks. _Ricardo. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
