Re: [PD] efficient approximation of trig functions for hi pass formula

> Le 20/10/2016 à 02:20, Jonathan Wilkes via Pd-list a écrit : >> Does anyone know a tool that will display the line number of a vim session > why not just adding ":set number" into vimrc? Because it's tiny. ___ Pd-list@lists.iem.at mailing list

Re: [PD] efficient approximation of trig functions for hi pass formula

Le 20/10/2016 à 02:20, Jonathan Wilkes via Pd-list a écrit : Does anyone know a tool that will display the line number of a vim session why not just adding ":set number" into vimrc? <>___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and

Re: [PD] OT : using libre office for data regression; WAS Re: efficient approximation of trig functions for hi pass formula (was: could vanilla borrow iemlib's hi pass filter recipe?)

On Wed, Oct 19, 2016 at 6:32 PM, cyrille henry wrote: > > > Le 19/10/2016 à 17:34, katja a écrit : >> >> Thanks for your update Cyrille. This seems a useful approach to find >> approximations. I should really learn how to do that with libre >> office. Do you have tutorial links?

Re: [PD] efficient approximation of trig functions for hi pass formula (was: could vanilla borrow iemlib's hi pass filter recipe?)

Good point. :-) so let's put it this way: the difference in cpu cost is neglectible for well designed patches. Again, i might be wrong. > Gesendet: Mittwoch, 19. Oktober 2016 um 23:54 Uhr > Von: "IOhannes m zmölnig" > An: pd-list@lists.iem.at > Betreff: Re: [PD] efficient

Re: [PD] efficient approximation of trig functions for hi pass formula (was: could vanilla borrow iemlib's hi pass filter recipe?)

On 10/19/2016 11:40 PM, Christof Ressi wrote: > I guess, you can't change the cutoff frequency so often that the CPU cost > will actually matter. But maybe I'm wrong... well, the perform routing will be called *at most* for each block (which can be 1 sample when running with [block~ 1]) the

Re: [PD] efficient approximation of trig functions for hi pass formula (was: could vanilla borrow iemlib's hi pass filter recipe?)

I think a core commenting sprint would be *very* helpful, specially to those of us (me) who would like help in understanding the black magic inside. Dan Wilcox @danomatika danomatika.com robotcowboy.com

Re: [PD] efficient approximation of trig functions for hi pass formula (was: could vanilla borrow iemlib's hi pass filter recipe?)

> that's where some setup code before the actual loop can become a bottleneck. Hmmm, I forgot that in the case of [hip~] the coefficient is not calculated in the perform routine at all, so maybe efficiency is really not that important. I guess, you can't change the cutoff frequency so often

Re: [PD] efficient approximation of trig functions for hi pass formula (was: could vanilla borrow iemlib's hi pass filter recipe?)

> And the mysterious UNITBIT32 number in d_osc.c? Funny you mentioned that! I just wanted to add that instead of approximating trig functions through polynomials one could also read Pd's cosine table ( float * cos_table ) with linear interpolation like it's done in [cos~] and [osc~]. Miller

[PD] [PD-announce] abl_link~ --- Ableton Link external for desktop Pd

Hi everybody, I'm happy to announce the release of an Ableton Link external for desktop Pd. The new external is patch compatible with the previously released iOS version. It is available from deken; just search for abl_link~. Any feedback would be appreciated, especially about the accuracy of the

Re: [PD] efficient approximation of trig functions for hi pass formula (was: could vanilla borrow iemlib's hi pass filter recipe?)

> On Wed, Oct 19, 2016 at 4:25 PM, Jonathan Wilkes > wrote: >> When implemented in C, which approach takes the least amount of time >> to read, reason about, and fully comprehend? > That is an important question. Pd code is full of clever tricks and > bit hacks for dsp

Re: [PD] efficient approximation of trig functions for hi pass formula (was: could vanilla borrow iemlib's hi pass filter recipe?)

On Wed, Oct 19, 2016 at 1:07 PM, katja wrote: > On Wed, Oct 19, 2016 at 4:25 PM, Jonathan Wilkes > wrote: > > When implemented in C, which approach takes the least amount of time > > to read, reason about, and fully comprehend? > > That is an important

Re: [PD] efficient approximation of trig functions for hi pass formula (was: could vanilla borrow iemlib's hi pass filter recipe?)

On Wed, Oct 19, 2016 at 4:25 PM, Jonathan Wilkes wrote: > When implemented in C, which approach takes the least amount of time > to read, reason about, and fully comprehend? That is an important question. Pd code is full of clever tricks and bit hacks for dsp efficiency. What

[PD] OT : using libre office for data regression; WAS Re: efficient approximation of trig functions for hi pass formula (was: could vanilla borrow iemlib's hi pass filter recipe?)

Le 19/10/2016 à 17:34, katja a écrit : Thanks for your update Cyrille. This seems a useful approach to find approximations. I should really learn how to do that with libre office. Do you have tutorial links? So far I found this:

Re: [PD] Latency compensation

Hi everybody, I've been thinking about latency compensation in the context of making a Pd external for Ableton Link. For the purposes of latency sensitive externals, it would be good to have functions in m_pd.h that allow externals to query the input and output latencies of the underlying

Re: [PD] offline calculations with tilde objects?

On Wed, 2016-10-19 at 10:42 +0200, cyrille henry wrote: > > Is "0 logical time" and "good efficiency" at the same time possible > > somehow? > > you almost found the solution. > > you need to use the bang feature of the block~ object to compute one > (huge) block in 0 logical time. It seems it

Re: [PD] efficient approximation of trig functions for hi pass formula (was: could vanilla borrow iemlib's hi pass filter recipe?)

Thanks for your update Cyrille. This seems a useful approach to find approximations. I should really learn how to do that with libre office. Do you have tutorial links? So far I found this:

Re: [PD] efficient approximation of trig functions for hi pass formula (was: could vanilla borrow iemlib's hi pass filter recipe?)

When implemented in C, which approach takes the least amount of time to read, reason about, and fully comprehend? -Jonathan From: katja To: "pd-list@lists.iem.at" Sent: Wednesday, October 19, 2016 9:06 AM Subject: [PD] efficient

Re: [PD] Latency compensation

why don't you patch a little tester app that sends some generated sounds, preferably with very clear attack, out and record this back in. that way you can measure the (roundtrip) latency of the whole system. Of course, that is a way. "Knowing" the latency instead of "measuring" it would be

Re: [PD] efficient approximation of trig functions for hi pass formula (was: could vanilla borrow iemlib's hi pass filter recipe?)

since you manually adjust the coefficient, i wanted to see the difference with coefficient adjusted/optimised by a computer. I update the calc using X from -0.5 to 0.5 with X = (x-0.5)*Pi The coefficient i get are really different from yours (when considering the Pi factor between them). I

[PD] efficient approximation of trig functions for hi pass formula (was: could vanilla borrow iemlib's hi pass filter recipe?)

Changing the thread title to reflect the new approach. Extract of the original thread; - I suggested using iemlib's hi pass filter recipe to improve frequency response of [hip~] - Christof Ressi pointed to formula in http://www.arpchord.com/pdf/coeffs_first_order_filters_0p1.pdf - this formula

Re: [PD] Latency compensation

This has been on my mind a long time - Pd really should provide a way to query the audio devices to whatever accuracy the underling system is capable of giving it. I believe portaudio already does this - Pd can just piggyback on that and/or follow the portaudio model for whatever specialized I/O

Re: [PD] Latency compensation

> On 19 Oct 2016, at 10:20, Roman Haefeli wrote: > > [replying to pd-list] > > Hi Simon > > On Wed, 2016-10-12 at 09:30 +0200, Simon Iten wrote: >> it would very much surprise me, if pd could do that in a generic way >> on all platforms. even daws or live struggle to do

Re: [PD] raspberry pi 3 with noob Gem does not work

@Casaba as it has been already said several times on this list : deken only download files and extract it to a place Pd knows if you want to load a library, add it to the startup preferences or as Roman suggest use [declare] object -- do it yourself http://antoine.villeret.free.fr 2016-10-19

Re: [PD] raspberry pi 3 with noob Gem does not work

On Wed, 2016-10-19 at 11:43 +0200, Csaba Láng wrote: > Dear list, > > just got my pi 3 and tried to install 0.47.1, however under the links > on the page of Mr. Puckette, I can compile only 0.46.2 > Anyway, after installing deken and trying to get Gem, it is more or > less downloaded, but most of

Re: [PD] raspberry pi 3 with noob Gem does not work

does Gem load itself ? (i.e. you should see the Gem splash screen in Pd's console) -- do it yourself http://antoine.villeret.free.fr 2016-10-19 11:43 GMT+02:00 Csaba Láng : > Dear list, > > just got my pi 3 and tried to install 0.47.1, however under the links on > the page

[PD] raspberry pi 3 with noob Gem does not work

Dear list, just got my pi 3 and tried to install 0.47.1, however under the links on the page of Mr. Puckette, I can compile only 0.46.2 Anyway, after installing deken and trying to get Gem, it is more or less downloaded, but most of the Gem objects does not load. Can anybody give a hint how to

Re: [PD] offline calculations with tilde objects?

On Wed, 2016-10-19 at 10:42 +0200, cyrille henry wrote: > > Le 19/10/2016 à 10:30, Roman Haefeli a écrit : > > > > Hey all > > > > When doing calculations on a large set of numbers, it's for obvious > > reasons much faster to do with tilde objects than doing it in > > message > > domain with

Re: [PD] offline calculations with tilde objects?

Le 19/10/2016 à 10:30, Roman Haefeli a écrit : Hey all When doing calculations on a large set of numbers, it's for obvious reasons much faster to do with tilde objects than doing it in message domain with some until loop. Doing calculations on an array with dsp objects has the disadvantage

[PD] offline calculations with tilde objects?

Hey all When doing calculations on a large set of numbers, it's for obvious reasons much faster to do with tilde objects than doing it in message domain with some until loop. Doing calculations on an array with dsp objects has the disadvantage that they're tied to sampling rate and cannot be done

Re: [PD] Latency compensation

[replying to pd-list] Hi Simon On Wed, 2016-10-12 at 09:30 +0200, Simon Iten wrote: > it would very much surprise me, if pd could do that in a generic way > on all platforms. even daws or live struggle to do this *right* on > different systems.  I'm not sure it's totally impossible. With jack,