Pd-list October 2016

pd-list@lists.iem.at

69 participants
103 discussions

Start a nNew thread

video & photo 360
by jma＠jeanmarie-adrien.net 16 Oct '16

16 Oct '16

Hello I am looking for a 360° video and a 360° photo reader on mac : any object available ? thanks JM

2 1

Sigmund+reblocking
by Fede Camara Halac 16 Oct '16

16 Oct '16

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 sigmund overriding the block object and reblocking to 128? [block~ 1] [inlet~] | [sigmund~ -hop 1024 -npeak 10 tracks] | [outlet~] Thanks! Fede fedecamarahalac.com

2 3

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?
by Ed Kelly 16 Oct '16

16 Oct '16

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 <morph_2016(a)yahoo.co.uk> wrote: Hey people, While I'm not an expert with digital filters, I did manage to piece together a decent-sounding ladder emulation instead of vcf~ a while ago. It only does resonant lowpass though. It's called mvcf~ and is found in the ekext externals library. I've since been reading about analogue filter design and I reckon there may be high pass and band pass filters available from the source code, with the correct adjustment to the algorithm. I'm trying to work out how to adjust the coefficients to accurately model the alternative functions (i.e. highpass, and hence bandpass through arithmetic processes) according to the resistance factors outlined in this paper. Any help would be appreciated :) So, currently, at line 78 in the code I have translations for highpass and bandpass (the current implementation is lowpass only with a gain factor) but I may be stupid in not trying this myself (or I've just been super-busy with other stuff!). The idea of implementing the other two modes comes from an Electronotes paper from Bernie Hutchins in the 1970s. This doesn't seem to be free online any more, but I've enclosed it. Take a look.Cheers,Ed Lone Shark releases: Light Vessel Automatic available now on 12" vinyl.Build Your Wings on the Way Down, the new digital album available @ http://scifirecords.co.uk/releases Earthlings compilation is out now @ http://www.pyramidtransmissions.com Ninja Jamm - the revolutionary music remix app for iOS and Android: http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, and Metastudio 5 live composition and improvisation suite, available at http://sharktracks.co.uk/html/software.html On Saturday, 15 October 2016, 22:10, Julian Brooks <jbeezez(a)gmail.com> wrote: And my learning for the day is done. Thanks both On 15 October 2016 at 15:59, katja <katjavetter(a)gmail.com> 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 same beautiful response. As you say, what's in the textbooks is common knowledge and can be used by everyone. Now I'll try to get the same result in C. By the way, [iemlib/hp~] seems to recalculate coefficients for every dsp vector which explains the higher CPU load. Katja On Sat, Oct 15, 2016 at 1:59 PM, Christof Ressi <christof.ressi(a)gmx.at> wrote: >> 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: Samstag, 15. Oktober 2016 um 13:52 Uhr >> Von: "Christof Ressi" <christof.ressi(a)gmx.at> >> An: katja <katjavetter(a)gmail.com>, "Miller Puckette" <msp(a)ucsd.edu> >> Cc: pd-list <pd-list(a)iem.at> >> Betreff: 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 bit and found the reason why the frequency response of Pd filters seems 'wrong': >> >> Miller uses a formular for calculating the cutoff frequency which is taken from analog filters but is not really adequate for digital filters since it doesn't reflect the cyclic nature of the digital domain (although you can see it in some articles on digital filters). >> >> Let's take [hip~] as an example: >> >> the formular for a 1-pole 1-zero highpass goes: >> y[n] = (x[n] - x[n-1]) * (1 + k) / 2 + k * y[n-1] >> >> Miller calculates the position of the pole with >> k = 1 - (fc * 2*pi / SR). >> >> The correct formular, however (if you want the frequency response to be zero at Nyquist!), would be >> k = (1-sin(a))/cos(a), where a = fc * 2*pi / SR. >> >> You can find it here: http://www.arpchord.com/pdf/ coeffs_first_order_filters_ 0p1.pdf >> >> BTW, the reason why [hip~] seems to get stuck at 7018 Hz is because Miller clips the coefficient below 0, so it never reaches -1 (where the gain would be all zero). >> >> Also, there is another approximation with a similiar behaviour, which goes like this: >> k = e^(-2*pi*fc/SR). I could find it here: http://www.dspguide.com/ch19/ 2.htm >> Here, the pole can only move from 1 to 0 and doesn't ever reach -1 as well. >> >> Now, is the behaviour of [hip~] 'wrong'? >> If you define at 1-pole 1-zero high pass filter as something which passes everything at fc = DC and blocks everything at fc = Nyquist, then I'd say yes. >> If it should roughly model an analogue filter (where the cutoff frequency can go up to infinity) for low cutoff frequencies only, then I'd say no. >> >> Also, as I tried to point out, this issue with the cutoff frequency is true for all Pd filters! >> >> So I think this behaviour should either be changed (great, if Katja is willing to submit a patch!) or documented in the help patch (gain is not 0 at Nyquist!). >> >> I'm not an engineer or any expert on filter design. It's just my two cents :-) >> >> Christof >> >> >> >> >> >> > Gesendet: Samstag, 15. Oktober 2016 um 11:39 Uhr >> > Von: katja <katjavetter(a)gmail.com> >> > An: "Christof Ressi" <christof.ressi(a)gmx.at> >> > Cc: pd-list <pd-list(a)iem.at> >> > Betreff: 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 functions. But coefficients aren't recalculated so >> > often, therefore this difference will be negligible. >> > >> > To reassure, it is not my intention to spark another 'what's wrong >> > with pd' thread. If iemlib's license allows to use the recipe in BSD >> > code I'll try patch the C of [hip~] and submit on the tracker for >> > review. Who knows, it may be a no-brainer. >> > >> > Katja >> > >> > >> > >> > >> > >> > On Sat, Oct 15, 2016 at 2:34 AM, Christof Ressi <christof.ressi(a)gmx.at> wrote: >> > > There are a number of big problems with all build-in filters in Pd (expect for the raw filters). >> > > >> > > Problem number 1: >> > > [lop~] and [hip~] both use a weird (you could also say: wrong) formula for the cutoff frequency which makes them gradually converge to a fixed output state (reached by about 7000 Hz). The same is true for [vcf~] and [bp~] with Q <= 1. Therefore the actual cutoff frequency is only correct for very low frequencies and approximately gets more and more off until it doesn't move at all. >> > > >> > > Problem number 2: >> > > [bp~] and [vcf~] don't have zeros at DC and Nyquist. For low Q values, the slope is different for each side and changes with frequency. >> > > >> > > Problem number 3: >> > > the gain at the center frequency is not 1 for both [bp~] and [vcf~]. It rather depends on frequency and Q. [bp~] even has has a gain of 2 for Q <= 1! >> > > >> > > I did some FFT plots, see the attachment. >> > > >> > > I remember Miller saying somewhere that these filters are not designed for high cutoff frequencies - but even for low frequencies, the behaviour of [bp~] and [vcf~] is horrible. I can see these filters are mere approximations to reduce CPU usage. >> > > [hip~] is indeed much more efficient than iemlib's [hp1~], so it's well suited for DC removal (but not much else). >> > > [bp~] only is a little bit more CPU friendly than iemlib's [bp2~] - but the latter one has a correct and stable frequency response. >> > > [vcf~], however, is a real CPU sucker!!! 100 [vcf~] objects need 3,40% on my laptop whereas 100 of iemlib's [vcf_bp2~] only need 1,80%! But you have to consider that [vcf_bp2~] not only acts correctly but lets you set the Q at audio rate. The high CPU usage of [vcf~] seems like a bug to me... >> > > >> > > I only use the vanilla filters for the most basic stuff like DC removal and smoothing. I guess these are the use cases which Miller had in mind and that way [lop~] and [hip~] have their justification (although there should be some more warning about the 'wrong' frequency response in the help file). >> > > But [bp~] and [vcf~] are almost unusable IMHO and should probably be replaced by better filters in the future (while keeping the old ones for compatibility reasons). >> > > >> > > Christof >> > > >> > > >> > >> Gesendet: Freitag, 14. Oktober 2016 um 23:51 Uhr >> > >> Von: katja <katjavetter(a)gmail.com> >> > >> An: pd-list <pd-list(a)iem.at> >> > >> Betreff: [PD] could vanilla borrow iemlib's hi pass filter recipe? >> > >> >> > >> In pd 0.47.1 [hip~] is still not perfect. Attenuation at cutoff is not >> > >> constant over the frequency range: -6 dB with cutoff=SR/8, -3 dB with >> > >> cutoff=SR/4, 0 DB with cutoff=SR/2. In contrast, iemlib's [hp1~] has >> > >> -3 dB at cutoff consistently. >> > >> >> > >> Could vanilla pd implement iemlib's hipass filter recipe? I don't know >> > >> if the license also covers the math. Documentation in >> > >> https://git.iem.at/pd/iemlib/ tree/master points to external literature >> > >> for part of the math (bilinear transform). I've implemented the recipe >> > >> with vanilla objects for comparison, see attached. >> > >> >> > >> Katja >> > >> ______________________________ _________________ >> > >> Pd-list(a)lists.iem.at mailing list >> > >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list >> > >> >> > >> >> ______________________________ _________________ >> Pd-list(a)lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list >> ______________________________ _________________ Pd-list(a)lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list _______________________________________________ Pd-list(a)lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

1 0

Re: [PD] on android to root n linux or not
by Dan Wilcox 15 Oct '16

15 Oct '16

> Maybe android is best used to send OSC messages to a pd patch running on a real computer. > You have the accelerometers and possibly other sensors builtin, the whole thing is a gesture controller not a dsp machine. > > Martin Tell that to RjDj. dsp on mobile has been a reality for some time now and getting more capable every year. How long ago was it we were all doing live patches on single core ~1 Ghz machines? :) -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

Re: [PD] deken: cannot unzip iemnet for w32
by rolfm＠dds.nl 15 Oct '16

15 Oct '16

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

1 0

Re: [PD] Purr Data beta 2
by Dan Wilcox 15 Oct '16

15 Oct '16

I use Homebrew all the time. It’s great. Definitely nicer to use than macports. I prefer Homebrew as it uses as many of the built in programs and libs already on OSX. That means it’s *much* faster to install/build packages since most things don’t require as many dependencies. You can, of course, also install packages to supersede the often older versions that come with the OS. Also, it uses the more standard /usr/local as opposed to Macport’s /opt, so most build systems find things automatically. One more point, Homebrew has prebuilt binaries as well so installing *big things* is relatively quick too. Actually, when Jonathan sent me the purr data wiki, I did a quick check and pretty much all of the libs y’all install via macports are available in Hombrew. -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Oct 9, 2016, at 11:35 PM, pd-list-request(a)lists.iem.at wrote: > > From: IOhannes m zmölnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>> > Subject: Re: [PD] Purr Data beta 2 > Date: October 9, 2016 at 3:20:17 PM MDT > To: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at> > > > On 10/09/2016 11:09 PM, Matt Barber wrote: >> Thanks for this, IOhannes. We've been using macports for most of the >> development of purr-data on OSX (with a couple of fink installs for some >> libraries). Do you find brew to be superior, or was this a comfortable >> default? > > i cannot really remember what led to the actual decision. > maybe brew was just the cool kid when i looked into it... > > however, i'm under the impression that so far i have had far less > troubles with brew than with fink and or macports. > keep in mind, that i hardly ever use any of these in real live. > (so while i probably find brew to be superior, i have virtually zero > data points to be able to defend this position). > > gfmd > IOhannes

5 24

Radio Randio: randio~
by Marco Matteo Markidis 13 Oct '16

13 Oct '16

Dear list, I'd like to signal this news from Facebook group: http://randio.apsu.it Radio Randio is an algorithmic in-real-time internet radio. We can contribute and so on. Best, Marco Matteo Markidis

1 0

OT: Dennis Ritchie
by William Huston 13 Oct '16

13 Oct '16

https://www.wired.com/2011/10/dennis-ritchie/ #include <https://www.facebook.com/hashtag/include?source=feed_text&story_id=10209829…> <stdio.h> int () { RIP++; sleep; void exit(); } -- -- May you, and all beings be happy and free from suffering :) -- ancient Buddhist Prayer (Metta)

1 0

Re: [PD] PD won't save preferences
by rolfm＠dds.nl 12 Oct '16

12 Oct '16

maybe W10 did some update? lately with the anniversary update my local network (with Pi and other computers) wasn't functioning anymore. i had to 'undo' the update(s). rolf

1 0

PD won't save preferences
by Liam Goodacre 12 Oct '16

12 Oct '16

Yesterday PD decided to clear my path and startup preferences and refused to save them when I tried resetting. Reinstalling PD fixed the issue, but it was a bit disconcerting nevertheless. I can't think of any system changes I made in the past few days that might have affected this. Has anyone encountered this problem before? I'm on 0.47.1 and Windows 10.

2 1

← Newer
1
...
4
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list October 2016