Re: [PD] deken: cannot unzip iemnet for w32

Hey Rolf On Fri, 2016-10-14 at 16:38 +0200, ro...@dds.nl wrote: > iemnet-v0.2.1~git20151118-(Windows-i386-32)-externals.zip > > this version tells me i don't have perrmission to unzip. > > the other: iemnet-v0.0.extended-(Windows-i386-32)-externals.zip > gives no problem. It was me who

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

I'm pretty confident [hip~] would not loose its efficiency when using iemlib's recipe. Both hi pass filters have a feed forward and feedback component, with coefficients for normalization and feedback. Calculation of these coefficients is a bit more involved with iemlib's recipe, using trig

Re: [PD] deken: cannot unzip iemnet for w32

hi roman after seeing your reaction i tried again to unzip; guess what: no hassle, no error message!! it doesn't matter where i unzip. i'm getting very suspicious about (my) W10, also lot's of troubles with internet connection and with networking. sorry for the noise. rolf

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

> But coefficients aren't recalculated so > often, therefore this difference will be negligible. That's a good point. You're right that both involve a feedback and feedforward, so I'm wondering why [hp1~] needs more CPU... otherwise, iemlib's filters are very efficient. Anyway, I researched a

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

> If iemlib's license allows to use the recipe in BSD IMHO, the correct formular for the cutoff frequency below (which I guess is also used in [hp1~] since the frequency response is the same) is 'common knowledge', so I don't think you'd have to pay attention to any licence. > Gesendet:

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

And my learning for the day is done. Thanks both On 15 October 2016 at 15:59, katja wrote: > Thanks for your pointers Christof. The recipe you mention from > arpchord.com is different than iemlib's, but yields identical > normalization and feedback coefficients, thus the

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

PS - I normally use cyclone/svf~ in my objects, but there is a good argument for a decent state-variable filter included in vanilla I think.Ed   On Sunday, 16 October 2016, 4:52, Ed Kelly wrote: Hey people, While I'm not an expert with digital filters, I did

[PD] Sigmund+reblocking

Hi all, Would reblocking a subpatch have any effect on [sigmund~]? Below is what I did. My idea was to delay the signal by one sample before going to sigmund. This is certainly not what is happening, though, but sigmund still works for all 10 tracks as if no reblocking had been made. Is

Re: [PD] on android to root n linux or not

its kinda crazy, am at the studio and found an old notebook with a beat matrix pattern drawn out for one of my drum loops like 20 years ago. i think the program that was used was called awave, it was a simple program, no midi just painting with waves on a grid. to change the pitch of an event, the

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

Jumping in on this thread: If anyone who can tackle improvements on these filters can provide a patch for lop~, hip~, bp~ and vcf~, please copy me when submitting the patch, so that I can merge it with pd-l2ork. Thank you. Best, Ico On 10/15/2016 7:59 AM, Christof Ressi wrote: If

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

Thanks for your pointers Christof. The recipe you mention from arpchord.com is different than iemlib's, but yields identical normalization and feedback coefficients, thus the same beautiful response. As you say, what's in the textbooks is common knowledge and can be used by everyone. Now I'll try