Re: [PD] pause writing to delay line / hybrid of array and delay

[Dario Sanfilippo]

Hi, Max.

You could have a looper feeding into a variable delay line whose delay is
modulated appropriately.

A looper would be an N-sample feedback loop with some input feeding into
it, where the input gain and the feedback gain are mutually exclusive. That
would prevent new elements from being added and you'd have the same
recirculating material when you freeze it:

y[n] = Rx[n] + (1-R)y[n-N]

with R being 1 to write into it, or 0 to freeze it.

The output of the looper could then feed an N-sample delay line whose delay
is offset consistently to always point to the same buffer position:

delay[n] = (lineN[n] + element[n]) % N

where

lineN[n] = (1[n-1] + lineN[n-1]) % N

and element[n] is an int between 0 and N - 1 determining the array element
that is being output.

I don't have this in PD but here's the Faust implementation:

https://faustide.grame.fr/?autorun=1=0=lotkavolterra_A=aW1wb3J0KCJzdGRmYXVzdC5saWIiKTsKc2l6ZSA9IG1hLlNSOyAvLyBhc3N1bWluZyBhIDk2IGtIeiBzYW1wbGUtcmF0ZQpyZWMgPSBjaGVja2JveCgiRnJlZXplIik7IC8vIGNoZWNrIHRvIGZyZWV6ZSwgdW5jaGVjayB0byBhZGQgbmV3IGVsZW1lbnRzCnBvc2l0aW9uID0gKGJhLnBlcmlvZChzaXplKSArIGhzbGlkZXIoImFycmF5IGVsZW1lbnQiLCAwLCAwLCA5NjAwMCwgMSkpICUgKHNpemUpOwpsb29wZXIoeCkgPSArKHggKiAoMSAtIHJlYykpCiAgICAgICAgICAgIH4gZGUuZGVsYXkoc2l6ZSAtIDEsIHNpemUgLSAxKSAqIHJlYzsgLy8gbGVuZ3RoIGlzIHNpemUgLSAxIGJlY2F1c2Ugb2YgdGhlIGltcGxpY2l0IG9uZS1zYW1wbGUgZGVsYXkgaW4gZmVlZGJhY2sgbG9vcHMKYXJyYXkocG9zKSA9IGRlLmRlbGF5KHNpemUsIHBvc2l0aW9uKTsKcHJvY2Vzcyh4KSA9IGFycmF5KHBvc2l0aW9uLCBsb29wZXIoeCkpOwo%3D

Ciao,
Dario


On Fri, 26 Feb 2021 at 14:03, Max  wrote:

> Hi list,
>
> I'm looking for concepts like a queue or arrayDeque in Pd.
> Like a delay line which I can pause adding new elements into and it will
> act like an array until I decide to add more. At audio rate.
> Is there something simple that I have overlooked? What's the best
> strategy to implement this?
>
> M.
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Pd and sounds are running but windows are blank

[Dario Sanfilippo]

Thanks, Dan. This seemed to work. But is it normal that the displayed
values are still single-precision?

Best,
Dario

On Mon, 11 Jan 2021 at 14:12, Dan Wilcox  wrote:

> Do *not* install Pd to a system path unless you are using a newer version
> of Tcl/Tk as the included 8.5.9 is quite broken: blank windows, etc. As
> noted in INSTALL.txt:
>
> https://github.com/pure-data/pure-data/blob/master/INSTALL.txt#L268
>
> I know this is tempting, especially for those coming from Linux, but there
> are a number of issues with using Pd on macOS like this, including
> application defaults keys not working as launching a Tk script for the
> command line will not connect it to app bundle plist settings which are
> included within a Pd .app, etc. If you want to invoke Pd on the command
> line, I recommend using a shell alias as documented in INSTALL.txt as well.
>
> The safest bet is to build a Pd .app using "make app" although I'm not
> sure if the included pre-build Tcl/Tk Wish .app is up to date with Miller's
> releases yet:
>
> make
> make app
>
> This results in a Pd-0.51-4.app in the main Pd source tree. I'd recommend
> right-clicking and renaming it to "Pd-0.51-4-double.app" if you have
> multiple versions on the same machine.
>
> Also, the deprecation warning is from the system (macOS) and not from Pd.
> It basically means that Apple will remove the included Tcl/Tk from macOS in
> the future. Note: It is still shipped with macOS 11 but is unfortunately
> the broken 8.5.9 version.
>
> On Jan 11, 2021, at 12:00 PM, pd-list-requ...@lists.iem.at wrote:
>
> Message: 3
> Date: Sun, 10 Jan 2021 17:18:24 +0100
> From: Dario Sanfilippo 
> To: Christof Ressi 
> Cc: Pd-List 
> Subject: Re: [PD] Pd and sounds are running but windows are blank
> Message-ID:
> 
> Content-Type: text/plain; charset="utf-8"
>
> My apologies, Christof, I forgot. :-)
>
> That's right, I'm on 10.15.7. My Tclsh version is 8.5.
>
> Thanks,
> Dario
>
> On Sun, 10 Jan 2021 at 16:26, Christof Ressi 
> wrote:
>
> Hi,
>
> it always helps to mention the OS ;-) I assume you're on macOS?
>
> Christof
> On 10.01.2021 15:27, Dario Sanfilippo wrote:
>
> Hello, list.
>
> I'm giving a try to Pd double precision; I installed .51-4 using the
> autotools.
>
> My patch is running and producing signals, although all windows are blank.
> If I right-click, I can open the abstractions, blank again. I see a
> deprecation warning about Tk, any clue what the issue could be?
>
> Thanks for your help.
>
> --
> Dr Dario Sanfilippo
> http://dariosanfilippo.com
>
> ___pd-l...@lists.iem.at mailing
> list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
> _______
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
>
> 
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com
> robotcowboy.com
>
>
>
>

-- 
Dr Dario Sanfilippo
http://dariosanfilippo.com
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Pd and sounds are running but windows are blank

[Dario Sanfilippo]

My apologies, Christof, I forgot. :-)

That's right, I'm on 10.15.7. My Tclsh version is 8.5.

Thanks,
Dario

On Sun, 10 Jan 2021 at 16:26, Christof Ressi  wrote:

> Hi,
>
> it always helps to mention the OS ;-) I assume you're on macOS?
>
> Christof
> On 10.01.2021 15:27, Dario Sanfilippo wrote:
>
> Hello, list.
>
> I'm giving a try to Pd double precision; I installed .51-4 using the
> autotools.
>
> My patch is running and producing signals, although all windows are blank.
> If I right-click, I can open the abstractions, blank again. I see a
> deprecation warning about Tk, any clue what the issue could be?
>
> Thanks for your help.
>
> --
> Dr Dario Sanfilippo
> http://dariosanfilippo.com
>
> ___pd-l...@lists.iem.at mailing 
> list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Pd and sounds are running but windows are blank

[Dario Sanfilippo]

Hello, list.

I'm giving a try to Pd double precision; I installed .51-4 using the
autotools.

My patch is running and producing signals, although all windows are blank.
If I right-click, I can open the abstractions, blank again. I see a
deprecation warning about Tk, any clue what the issue could be?

Thanks for your help.

-- 
Dr Dario Sanfilippo
http://dariosanfilippo.com
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] bandpass makeup gain formula?

[Dario Sanfilippo]

Hi, Peter.

If useful, Zavalishin has a normalised BP in a 2p2z state-variable filter
based on the bilinear transform integrator (zero-delay feedback) and the
output seems to be consistent. See 4.4:
https://www.native-instruments.com/fileadmin/ni_media/downloads/pdf/VAFilterDesign_2.0.0a.pdf
.

Attached here you'll find the Faust code for the filter; you can paste that
on https://faust.grame.fr/ide/ and export a PD external. Unfortunately, you
can't give options to the compiler in the web app so it will be
single-precision, but it should still work without extreme settings.

Inputs are CF, Q, K (shelving boost, linear amp), input signal. Outputs are LP,
HP, BP, BP (normalised), LShelf, HS, BS, notch, peak AP.

Dario


On Wed, 4 Mar 2020 at 12:21, Peter P.  wrote:

> Hi list,
>
> I am trying to calculate a makeup gain factor for white noise sent into
> [bp~] and [vcf~] bandpass objects depending on the center frequency and
> the Q (width) so that it measures the same in dBRMS before and after the
> filter. I am currently measuring it but am wondering if
> a.) this has been done before
> and
> b.) if there is an analytical solution to it already
>
> Thanks!
> P
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>


svf2p2zblti.dsp
Description: Binary data
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] env~ argument confusion

[Dario Sanfilippo]

>
> > so you get the same number of values, but they use different time-frames
> > for doing the averaging.
>
> Wow, crazy! Thanks for this explanation! Would be interesting to know
> for what different applications this (eg a long window with short
> period) can be useful. Anyway, it's very good to know.
>

For continuous measurements, you can also calculate the RMS in the audio
domain by squaring a signal, low-passing it with a 1-pole low-pass, and
taking the square root. The period of the filter, roughly, is the analysis
window. See Zölzer's "DASP" from 2008, page 229, for more information.

D



>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Tcl/Tk error

[Dario Sanfilippo]

Hi, Christof.

I haven't been using PD much lately but I used to have that a lot. As far
as I remember, it also used to happen when closing a window, specifically,
an abstraction that I used to inspect signals by plotting them on arrays.
When closing those windows, PD GUI would all freeze but it was still
possible to change number boxes and everything else, though without having
the visual feedback.

I'll get back to this if I can reproduce the bug.

D




On Tue, 2 Apr 2019 at 11:56, Christof Ressi  wrote:

> hey oliver,
>
> other users (including myself) have experienced this as well and it's a
> serious regression. Now that I have some time I want to investigate this.
> I've already fixed a related bug in September (
> https://github.com/pure-data/pure-data/pull/467).
>
> can you do me a favour and file a bug report on GitHub? and can you try to
> find a minimal patch which triggers the problem (even if it doesn't happen
> all the time)? personally, I didn't have success in reproducing it, it only
> happenes very rarely and seemlingly randomly...
> to all the other people who have experienced this: please help!
>
> Christof
>
> > Gesendet: Dienstag, 02. April 2019 um 11:37 Uhr
> > Von: "oliver" 
> > An: "pd-l...@mail.iem.at" 
> > Betreff: [PD] Tcl/Tk error
> >
> > Hi,
> >
> > sorry for a not so precise bug-report, but it's all i can offer:
> >
> > recently i discovered a strange behaviour in Windows PD 0.49 (32bit)
> > when the closing of a patch window (or even the closing of a subpatch
> > window) would result in a Tcl/Tk error that i have not excperienced up
> > until PD 0.49.
> >
> > so, i close a window (main or subpatch - mostly with STRG+w), the patch
> > window turns white with some inlet relics still being displayed and the
> > console prints out a Tcl/TK error message in red colour.
> >
> > the console says for example this:
> >
> > (Tcl) UNHANDLED ERROR: bad window path name ".x3b212c8"
> >  while executing
> > "wm title $mytoplevel "$name$dirtychar$arguments - $path""
> >  (procedure "pdtk_canvas_reflecttitle" line 15)
> >  invoked from within
> > "pdtk_canvas_reflecttitle .x3b212c8 {D:/pd_0.49/_MYPATCHES_/MFPOW}
> > {metronome} { [edit]} 0"
> >  ("uplevel" body line 718)
> >  invoked from within
> > "uplevel #0 $docmds".x2596028: no such object
> > .x2596028: no such object
> > .x2596028: no such object
> > .x2596028: no such object
> >
> >
> > from this point on nothing can be done in PD anymore, the only way to
> > get out of this is to kill the PD process from the outside.
> >
> > the patch contains several GOP subpatches and also some of my own GUI
> > abstractions, that contain GOPs.
> >
> > (the patch is very involved so i couldn't really check what would
> > happen, if i replaced all of my abstractions with something else ...)
> >
> > any ideas ? ...
> >
> > best
> >
> > oliver
> >
> >
> > --
> > 
> > /// http://pendler.klingt.org //
> > \\\ http://oliver.klingt.org  \\
> > 
> >
> >
> >
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
> >
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] How can I weave multiple signals together?

[Dario Sanfilippo]

What comes to my mind is to write the three signals on three new arrays
which are three times the size of the original ones. These arrays would
have each sample from the original signal zero-padded by two samples. That
can be done by reading the original signals with tabread~ at a rate which
is 1/3 of the initial one (hence repeating each sample three times) and
multiply that by a function which is 1 every three samples (the first
sample should be 1). That, for example, could be a phasor~ with a period of
three samples followed by a [<~ 1/3] (it can be implemented with a max~,
-~, and /~). (44.1kHz SR seems to be too tight; use 48kHz.) Of course,
you'll need to sync all the phasors and writers involved with a bang. The
resulting signal could then be obtained by summing the three arrays,
delaying the second by 1 sample, and the third one by 2 samples.

I hope it works.

D




On Mon, 25 Mar 2019 at 19:00, RT  wrote:

> I have a Pd patch with 3 separate signals and I want to sequentially weave
> the signals together so instead of having three separate signals I create 1
> large signal that is created by weaving 3 signals together.
>
> Example: (note: the commas are just used as separators and I used letters,
> numbers, and symbols to help differentiate the signals)
> *signal_1 array*  is *A,B,C,D,E*
> *signal_2 array * is *1,2,3,4,5*
> *signal_3 array * is *@,#,%,&,(*
>
> The completed weaved signal to playback would look like this
> *A,1,@,B,2,#,C,3,%,D,4,&,E,5,(*
> I've attached an image along with the Pd file that I hope helps explains
> this.
>
> I've placed each signal into their own separate array in Pd but I'm not
> sure how to sequentially "weave" the signals together.  Any ideas?
> Thanks
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] filters with audio rate cutoff frequency

[Dario Sanfilippo]

For time-variant one-pole LP and HP, I use these coefficients with rpole~:
http://www.earlevel.com/main/2012/12/15/a-one-pole-filter/.

They have a fairly accurate response for basically the whole spectrum.
Below .01Hz or so, you need double precision.

Dario

On Wed, 13 Mar 2019 at 19:13, Alexandre Torres Porres 
wrote:

>
>
> Em qua, 13 de mar de 2019 às 07:30, Peter P. 
> escreveu:
>
>> * Alexandre Torres Porres  [2019-03-12 18:21]:
>> > Em ter, 12 de mar de 2019 às 06:31, Kosmas Giannoutakis <
>> > giannoutakiskos...@hotmail.com> escreveu:
>> >
>> > > Hi, is there any implementation of filters in Pd with audio rate
>> cutoff
>> > > frequency?
>> Forgive me if this has been posted already, but what about [vcf~] which
>> has a lowpass and bandpass output and a signal inlet for cutoff?
>
>
> yup, that and bob~ have been mentioned. I could add other lower level
> options like the raw filters [rpole~]/[rzero~]/etc) and [fexpr~], but that
> requires a deeper knowledge on how to use them. And on that topic, let me
> show off my advanced filters section in my Live electronics Tutorial, which
> presents this knowledge:
> https://github.com/porres/Live-Electronic-Music-Tutorial/tree/v-1.0beta-7/Vol.3(in.progress)/Part.09-Filters%26Reverb/31-Filters(Advanced)
>
> cheers
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] filters with audio rate cutoff frequency

[Dario Sanfilippo]

According to the author of the book below, the zero-delay feedback design
is particularly good for time-variant applications.

So have a look at the filters here:
https://www.discodsp.net/VAFilterDesign_2.1.0.pdf.

D




On Tue, 12 Mar 2019 at 10:31, Kosmas Giannoutakis <
giannoutakiskos...@hotmail.com> wrote:

> Hi, is there any implementation of filters in Pd with audio rate cutoff
> frequency? The filters in Super Collider provide this and it would be very
> handy to have it also in Pd.
>
> Thanks,
> Kosmas
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Help with reverb design and vanilla's abstractions ([rev1~]/[rev2~]/[rev3~])

[Dario Sanfilippo]

Hi, Alexandre.

On Thu, 7 Feb 2019 at 02:26, Alexandre Torres Porres 
wrote:

> Hi, I've read miller's book and I've always wanted to know a bit more
> about reverbs. I also want to better explain these examples to my students.
> One thing I wonder is about the choice of delay lengths for the early
> reflections and also for the recirculating delay lines. They seem quite
> arbitrary, right?
>
> All I could make of it is that these numbers are just broken down so they
> don't become multiples of each other, resulting in a rather complex mesh of
> reflection times.
>

Yes, as far as I understand, the idea is to have an FDN, with whatever
matrix you've chosen, whose impulse response is as close as possible to
white noise. The filters that you put inside the network can then be used
to model different environments.

>
> But also, it seems that a "room size" parameter can be controlled by the
> size of the delay lines, right?
>

There is an algorithm on the website of J. O. Smith to calculate the best
approximation for a desired size while keeping the coprime relationship
between the lengths:
https://ccrma.stanford.edu/~jos/pasp/Prime_Power_Delay_Line_Lengths.html.

My reverb in PD is a 16th order FDN with Hadamard matrix and 1pole lowpass
filters to model the absorption of high frequencies when bouncing on the
walls. For simplicity, I pilot the delay lengths through a signal to change
the exponent of 16 prime bases. Computationally acceptable and I like how
it sounds.


> Anyway, I'd appreciate if I could learn more about these abstractions and
> also some cool references for study (such as "digital reverb modelling for
> dummies").
>

I found these good reads:

Rocchesso, D. 1997. “Maximally diffusive yet efficient feedback delay
networks for artificial reverberation. ” In Signal Processing Letters, IEEE 4
(9), 252­255.

Rocchesso, D., and J. O. Smith. 1997. “Circulant and Elliptic Feedback
Delay Networks for Artificial Reverberation.” I EEE Transactions on Speech
and Audio Processing 5 (1):51–63.

Ciao,
Dario



> cheers
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Status of PD double precision

[Dario Sanfilippo]

I've just tested this release:
https://github.com/jonwwilkes/purr-data/releases/download/2.6.0/purr-double-trouble-test1-osx_10.11-x86_64-dmg.zip
.

I've added 1 to 1e10 and then subtracted 1e10 expecting to get 1, but I get
0, so it doesn't seem double. Do you get the same behaviour?

D

<http://dariosanfilippo.tumblr.com>


On Sun, 16 Dec 2018 at 13:16, Giulio Moro  wrote:

> It's been done this past summer for Purr-data/Pd-l2ork. Here is the
> report:
> http://disis.music.vt.edu/pipermail/l2ork-dev/2018-August/002019.html
>
> Best,
> Giulio
>
> On Sunday, 16 December 2018, 11:29:25 GMT, Dario Sanfilippo <
> sanfilippo.da...@gmail.com> wrote:
>
> Hello, list.
>
> I'm just curious to know if anybody is actively working on a double
> precision version of PD. Please let me know if I can help in any way.
>
> Best,
> Dario
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Status of PD double precision

[Dario Sanfilippo]

Hello, list.

I'm just curious to know if anybody is actively working on a double
precision version of PD. Please let me know if I can help in any way.

Best,
Dario
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Exporting a patch as a zip file

[Dario Sanfilippo]

Hello, list.

Do you have a workaround for exporting a patch as a zip file containing all
abstractions and externals in the patch?

It would be amazing to be able to do that because manually locating all the
necessary abstractions and externals from a supposedly large folder is a
bit tricky and many are often left behind.

Thanks,
Dario
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] PD .49 crashing when saving patches

[Dario Sanfilippo]

Hi, Miller.

This seems to work too.

Cheers,
Dario

<http://dariosanfilippo.tumblr.com>


On Fri, 12 Oct 2018 at 06:37, Miller Puckette  wrote:

> Thanks for the testing - may I ask you to test my builds, just to make
> sure?
>
> http://msp.ucsd.edu/tmp/misc/pd-0.49-1test1.mac.tar.gz
> http://msp.ucsd.edu/tmp/misc/pd-0.49-1test1-i386.mac.tar.gz
>
> thanks
> Miller
>
> On Fri, Oct 12, 2018 at 01:00:01AM +0200, Edwin van der Heide wrote:
> > It does solve the problem for me!
> >
> > > On 11 Oct 2018, at 17:24, Dan Wilcox  wrote:
> > >
> > > Can y'all try this test build: Pd-0.49-0test3-keyfix4.zip <
> http://docs.danomatika.com/pdbuilds/Pd-0.49-0test3-keyfix4.zip>
> > >
> > >> On Oct 11, 2018, at 1:15 PM, pd-list-requ...@lists.iem.at  pd-list-requ...@lists.iem.at> wrote:
> > >>
> > >> Date: Thu, 11 Oct 2018 12:59:28 +0200
> > >> From: Edwin van der Heide mailto:p...@evdh.net>>
> > >> To: pd-list mailto:pd-l...@iem.at>>
> > >> Subject: Re: [PD] PD .49 crashing when saving patches
> > >> Message-ID:  e1543228-34a5-464f-89a5-f4c932011...@evdh.net>>
> > >> Content-Type: text/plain; charset="utf-8"
> > >>
> > >> For me PD crashes when I create a new file, not when I overwrite an
> existing file.
> > >>
> > >>> On 11 Oct 2018, at 12:44, Dario Sanfilippo <
> sanfilippo.da...@gmail.com <mailto:sanfilippo.da...@gmail.com>> wrote:
> > >>>
> > >>> I also get a seg fault:
> > >>>
> > >>> Segmentation fault: 11
> > >>> gui socket 3 -
> > >>> closing audio...
> > >>>
> > >>> <http://dariosanfilippo.tumblr.com/ <
> http://dariosanfilippo.tumblr.com/>>
> > >>>
> > >>> On Thu, 11 Oct 2018 at 12:33, Edwin van der Heide  <mailto:ed...@evdh.net> <mailto:ed...@evdh.net <mailto:ed...@evdh.net>>>
> wrote:
> > >>> Hello,
> > >>>
> > >>> Yes, the same thing happens to me on macOS 10.13.6.
> > >>>
> > >>> Bellow follows a part of the crash report.
> > >>>
> > >>> If needed I could learn how to compile PD on OS X and run it in
> debug mode.
> > >>>
> > >>> Best,
> > >>>
> > >>> Edwin
> > >
> > > 
> > > Dan Wilcox
> > > @danomatika <http://twitter.com/danomatika>
> > > danomatika.com <http://danomatika.com/>
> > > robotcowboy.com <http://robotcowboy.com/>
> > >
> > >
> > >
> >
>
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] PD .49 crashing when saving patches

[Dario Sanfilippo]

Hi, Dan.

This seems to work.

Thanks,
Dario

On Thu, 11 Oct 2018 at 17:24, Dan Wilcox  wrote:

> Can y'all try this test build: Pd-0.49-0test3-keyfix4.zip
> <http://docs.danomatika.com/pdbuilds/Pd-0.49-0test3-keyfix4.zip>
>
> On Oct 11, 2018, at 1:15 PM, pd-list-requ...@lists.iem.at wrote:
>
> Date: Thu, 11 Oct 2018 12:59:28 +0200
> From: Edwin van der Heide 
> To: pd-list 
> Subject: Re: [PD] PD .49 crashing when saving patches
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
>
> For me PD crashes when I create a new file, not when I overwrite an
> existing file.
>
> On 11 Oct 2018, at 12:44, Dario Sanfilippo 
> wrote:
>
> I also get a seg fault:
>
> Segmentation fault: 11
> gui socket 3 -
> closing audio...
>
> <http://dariosanfilippo.tumblr.com/>
>
> On Thu, 11 Oct 2018 at 12:33, Edwin van der Heide  mailto:ed...@evdh.net >> wrote:
> Hello,
>
> Yes, the same thing happens to me on macOS 10.13.6.
>
> Bellow follows a part of the crash report.
>
> If needed I could learn how to compile PD on OS X and run it in debug mode.
>
> Best,
>
> Edwin
>
>
> 
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com
> robotcowboy.com
>
>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] PD .49 crashing when saving patches

[Dario Sanfilippo]

 + 10
> 1   libsystem_pthread.dylib 0x7fff57d8020e
> _pthread_wqthread + 1552
> 2   libsystem_pthread.dylib 0x7fff57d7fbe9 start_wqthread
> + 13
>
> Thread 6:
> 0   libsystem_kernel.dylib  0x7fff57bb928a
> __workq_kernreturn + 10
> 1   libsystem_pthread.dylib 0x7fff57d8020e
> _pthread_wqthread + 1552
> 2   libsystem_pthread.dylib 0x7fff57d7fbe9 start_wqthread
> + 13
>
> Thread 7:
> 0   libsystem_kernel.dylib  0x7fff57bb928a
> __workq_kernreturn + 10
> 1   libsystem_pthread.dylib 0x7fff57d8020e
> _pthread_wqthread + 1552
> 2   libsystem_pthread.dylib 0x7fff57d7fbe9 start_wqthread
> + 13
>
> Thread 0 crashed with X86 Thread State (64-bit):
>   rax: 0x7ffeefbff720  rbx: 0x7ffeefbff720  rcx:
> 0x0020  rdx: 0xffe0
>   rdi: 0x7ffeefbff7c0  rsi: 0x  rbp:
> 0x7ffeefbff600  rsp: 0x7ffeefbff5e0
>r8: 0x0001   r9: 0x0001  r10:
> 0x6040001161d0  r11: 0x00010174b8a0
>   r12: 0x  r13: 0x  r14:
> 0x7fff2de3f6fb  r15: 0x
>   rip: 0x0001000bfd0f  rfl: 0x00010283  cr2: 0x
>
> Logical CPU: 6
> Error Code:  0x0004
> Trap Number: 14
>
>
>
> > On 11 Oct 2018, at 11:16, Dario Sanfilippo 
> wrote:
> >
> > Hello.
> >
> > I just wanted to let you know that PD .49 crashes almost regularly after
> saving a patch. I've just tested opening PD, saving a simple patch with an
> inlet~ and another with an inlet, either with the DSP on or off, and it
> crashes immediately after saving the patch. It does manage to write the
> file, though.
> >
> > It doesn't crash if the patch that I save is empty.
> >
> > Has anything similar happened to you? I'm on OSZ 10.11.6.
> >
> > Dario
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] PD .49 crashing when saving patches

[Dario Sanfilippo]

Hello.

I just wanted to let you know that PD .49 crashes almost regularly after
saving a patch. I've just tested opening PD, saving a simple patch with an
inlet~ and another with an inlet, either with the DSP on or off, and it
crashes immediately after saving the patch. It does manage to write the
file, though.

It doesn't crash if the patch that I save is empty.

Has anything similar happened to you? I'm on OSZ 10.11.6.

Dario
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] PD .48.1 GUI freezing when resizing windows with arrays whose content is being updated.

[Dario Sanfilippo]

Hello.

Just to let you know about this behaviour which I noticed recently: if I
have three or four arrays which I'm using to display signals in a window,
when resizing that window PD freezes for a good couple of minutes. It
eventually comes back but it really struggles.

I'm aware that that kind of display operations are heavy but I can't recall
this behaviour from past PD versions.

I'm on 10.11.6.

Cheers,
Dario
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Dario Sanfilippo]

That's certainly the way to go for efficiency: 256 rpole~ objects are about
10% load against 44% load of the PD-implemented counterpart.

D


On 4 February 2018 at 14:41, Matt Davey <hard@gmail.com> wrote:

> Really at that point, you’d have to be asking youself if there is any way
> to use an external.
>
>
> On Sunday, February 4, 2018, Dario Sanfilippo <sanfilippo.da...@gmail.com>
> wrote:
>
>> Hi, Roman. I guess that fexpr~ implies block 1 but probably a few other
>> things too: 256 instantiations of the feedback loop in my abstractions are
>> around 44% load whereas the same number of [fexpr~ max($x1[0],
>> $y[-1]*$x2[0])] are peaking at 95%.
>>
>> D
>>
>>
>> On 4 February 2018 at 12:33, Roman Haefeli <reduz...@gmail.com> wrote:
>>
>>> On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote:
>>> > There's an implementation of a peak holder in this blog post: http://
>>> > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in-
>>> > pure-data.
>>>
>>> BTW: the peak envelope part could be also implemented using fexpr~:
>>>
>>> [fexpr~ max($x1[0], ($y[-1]*$f2)]
>>>
>>> This has the advantage of not requiring a re-blocked subpatch with
>>> blocksize=1. However, I wonder which is computationally less expensive.
>>> Is there a rule of thumb whether [fexpr~] or [block~ 1] is faster?
>>>
>>> Roman
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>>> stinfo/pd-list
>>>
>>>
>>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Dario Sanfilippo]

Hi, Roman. I guess that fexpr~ implies block 1 but probably a few other
things too: 256 instantiations of the feedback loop in my abstractions are
around 44% load whereas the same number of [fexpr~ max($x1[0],
$y[-1]*$x2[0])] are peaking at 95%.

D


On 4 February 2018 at 12:33, Roman Haefeli <reduz...@gmail.com> wrote:

> On Fre, 2018-02-02 at 18:31 +0000, Dario Sanfilippo wrote:
> > There's an implementation of a peak holder in this blog post: http://
> > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in-
> > pure-data.
>
> BTW: the peak envelope part could be also implemented using fexpr~:
>
> [fexpr~ max($x1[0], ($y[-1]*$f2)]
>
> This has the advantage of not requiring a re-blocked subpatch with
> blocksize=1. However, I wonder which is computationally less expensive.
> Is there a rule of thumb whether [fexpr~] or [block~ 1] is faster?
>
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Dario Sanfilippo]

I see what you mean, Roman. So you'd need the N-size block to be processed
beforehand, which would imply an N-size delay in the output, is that right?
I haven't thought of it, no idea whether that could be achieved by changing
the feedback period in the peak holder and/or adding a delay in the input.
Maybe I'll try something later.

Cheers,
Dario

On 3 February 2018 at 09:33, Roman Haefeli <reduz...@gmail.com> wrote:

> On Sam, 2018-02-03 at 02:47 +0000, Dario Sanfilippo wrote:
> > Thanks, Roman.
> >
> > On 2 February 2018 at 21:28, Roman Haefeli <reduz...@gmail.com>
> > wrote:
> > > On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote:
> > > > There's an implementation of a peak holder in this blog
> > > post: http://
> > > > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-
> > > in-
> > > > pure-data. I remember testing it but please let me know if you
> > > find a
> > > > bug.
> > >
> > > Very nice write up. Thanks for sharing.
> > >
> > > > The current peak is replaced to whatever the input is after a
> > > desired
> > > > time, and the counter is reset whenever a new peak is found. It
> > > > should be easy to change it so that the peak is reset
> > > periodically.
> > >
> > > It's not exactly equivalent with what I've asked, since your
> > > implementation only takes new peaks into account after the hold
> > > period
> > > has ended.
> > Perhaps my wording in the previous email was confusing: what happens
> > is that every new peak will update the output immediately, and
> > whenever that happens the countdown starts so that, should no other
> > peak be detected after that time, the output will be set to whatever
> > the input is in that moment.
> >
> > > Assume an input signal consisting of a series of 1-sample
> > > impulses with a period that is slightly lower than the hold period.
> > > The
> > > output signal has a gap before each second impulse. For the use
> > > case in
> > > your article (which is also the use case I'm interested in), that
> > > doesn't matter much, because the peak holder signal is fed to a
> > > peak
> > > enveloper which somewhat masks those gaps.
> > In that case, we should expect a full-amp DC out of the peak holder
> > for the impulses are faster than the hold time, and that's what we
> > actually get:
>
>
> Yes, correct. If the peaks  reach the same level or are higher than the
> ones before, then the hold period is prolonged. But when they have less
> amplitude than the ones before, gaps appear. See:
>
> https://netpd.org/~roman/tmp/peakholder_gaps.png
>
> With a true max(x[0-(-N)], a downward stairway would appear and there
> wouldn't be any gaps.
>
> As I said, that is only small difference and for the purpose of a look-
> ahead limiter it probably doesn't matter that much.
>
> Roman
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Dario Sanfilippo]

Thanks, Roman.

On 2 February 2018 at 21:28, Roman Haefeli <reduz...@gmail.com> wrote:

> On Fre, 2018-02-02 at 18:31 +0000, Dario Sanfilippo wrote:
> > There's an implementation of a peak holder in this blog post: http://
> > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in-
> > pure-data. I remember testing it but please let me know if you find a
> > bug.
>
> Very nice write up. Thanks for sharing.
>
> > The current peak is replaced to whatever the input is after a desired
> > time, and the counter is reset whenever a new peak is found. It
> > should be easy to change it so that the peak is reset periodically.
>
> It's not exactly equivalent with what I've asked, since your
> implementation only takes new peaks into account after the hold period
> has ended.


​Perhaps my wording ​in the previous email was confusing: what happens is
that every new peak will update the output immediately, and whenever that
happens the countdown starts so that, should no other peak be detected
after that time, the output will be set to whatever the input is in that
moment.


> Assume an input signal consisting of a series of 1-sample
> impulses with a period that is slightly lower than the hold period. The
> output signal has a gap before each second impulse. For the use case in
> your article (which is also the use case I'm interested in), that
> doesn't matter much, because the peak holder signal is fed to a peak
> enveloper which somewhat masks those gaps.
>

​In that case, we should expect a full-amp DC​ out of the peak holder for
the impulses are faster than the hold time, and that's what we actually get:

[image: Inline images 2]

So the peak envelope is only used to transition from the peak to the
non-peak value exponentially.



>
> I'm going to use your implementation for peak holding. Thanks!
>
> Roman
>

​Sure, you're welcome. I hope that this makes more sense.

Dario​



>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Dario Sanfilippo]

There's an implementation of a peak holder in this blog post:
http://dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in-pure-data.
I remember testing it but please let me know if you find a bug.

The current peak is replaced to whatever the input is after a desired time,
and the counter is reset whenever a new peak is found. It should be easy to
change it so that the peak is reset periodically.

I hope it helps.

Dario


On 2 February 2018 at 13:52, Roman Haefeli  wrote:

> Hey all
>
> Can this be done in vanilla? I'd like to output the maximum value of
> the last N input samples in the signal domain. Ideally N would be
> adjustable.
>
> It bugs my mind, but I can't think of a solution for this simply
> problem.
>
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Pd 0.48-1 test version released

[Dario Sanfilippo]

Hi, Miller.

At a first glance, I'm experiencing that my abstractions which used to
cause the tcl problem/gui freeze when opened/closed are now making PD crash
when deleted. I'll see if I can create a patch which shows the crash.

Cheers,
Dario


On 4 December 2017 at 20:28, Miller Puckette  wrote:

> To pd-announce:
>
> Pd 0.48-1 is available in a first test version (0.48-1test3).  This should
> fix or at least improve the spacing problems in 0.48-0 on macintosh
> computers,
> and contains many other bug fixes.
>
> With luck it will be possible for me to make the formal 0.48-1 release
> sometime next week.
>
> cheers
> Miller
>
> ___
> Pd-announce mailing list
> pd-annou...@lists.iem.at
> https://lists.puredata.info/listinfo/pd-announce
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Bandlimited oscils (was Re: anti-aliasing filtering)

[Dario Sanfilippo]

​Thanks for sharing this, Orm. Is there no bibliography at all about this
implementation?

Cheers,
Dario​


On 29 October 2017 at 05:21, Orm Finnendahl <
orm.finnend...@selma.hfmdk-frankfurt.de> wrote:

> Hi,
>
>  concerning avoiding aliasing in the first place, here are
> abstractions for generating bandlimited versions of the most popular
> analog waveforms I developed for a seminar some time ago:
>
> https://www.selma.hfmdk-frankfurt.de/selmafile/f/9eed9b01b9/
>
> Open "bl-oscil-example.pd" to see how to use it. Note that the rect~
> oscillator has an additional pulse-width input.
>
> The patch uses wavetable lookup with 128 wavetables of an ideal
> bandlimited sawtooth with partials 1 through 127 for each wavetable
> respectively and the non-bandlimited phasor wavetable for the
> 128th. In the oscillator the wavetable is determined on each phasor
> wraparound based on frequency.
>
> At a samplerate of 44100 Hz this gives no aliasing above 173.6 Hz
> which my ear considered good enough (for 173.6 Hz the aliasing happens
> at about -42 dB for the first aliased partial relative to the first
> partial, diminishing by 6 dB per Octave downwards). Increase the
> number of wavetables for better signal/aliasing ratio.
>
> As this method gives ideal results and is as efficient as it can get
> it's strange I haven't found it on my web research of this topic, but
> maybe I've looked at the wrong places. In times when wavetable lookup
> synthesis has regained popularity in commercial soft-synths I could
> well imagine companies like NI or Ableton also use this or simlar
> methods under the hood of the oscils for their standard analogue
> waveforms.
>
> --
> Orm
>
> Am Samstag, den 28. Oktober 2017 um 19:24:00 Uhr (-0200) schrieb
> Alexandre Torres Porres:
> > 2017-10-28 18:30 GMT-02:00 cyrille henry : Its very
> > different : a sawtooth have an infinite number of harmonics, but >
> > not a signal distorted with tanh. And a band limited sawtooth is
> > lot's > better (from sound and performance perspective) than an
> > oversampled / > filtered phasor.
> > >
> >
> > yeah, I know it's got infinite harmonics, and that a band-limited
> > oscillator is better. But this is also because I'm using this to measure
> > the efficiency of the anti-aliasing filter, how good it works and all
> >
> > cheers
>
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] tanh~ (core dumped)

[Dario Sanfilippo]

Hi, Kosmas.

I'm using (1 - e^-2x)/(1 + e^-2x) and it seems to work fine though you
wouldn't have the parameters you mentioned.

Cheers,
D

On 15 August 2017 at 13:41, Kosmas Giannoutakis <
giannoutakiskos...@hotmail.com> wrote:

> Hi, i want to implement the tanh function in PD Vanilla. I use the formula
> y(x) = (1 - b*e^-(a*x + lnb))/(1/b + e^-(a*x + lnb)) where (a) is a
> steepness parameter and b controls the amplitude range. You can see my
> implementation which seems to work,  but when I incorporate it to larger
> patches, I get a core dumped...
>
> Any clue why is this happening or any suggestions for a better
> implementation?
>
> Thanks,
> Kosmas
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] test5, problem with special characters in patches' filenames

[Dario Sanfilippo]

There seems to be a problem with special characters in filenames, namely
round parentheses (I haven't tested the other ones).

I'm on OSX 10.11.6 and, if PD is closed and I open the attached patch, I
get the following error (below) on the PD window. If PD is open and I drag
the on to the PD icon I get the same kind of error as an Application Error
pop-up window.

This patch will still work after I get the errors but I have a large patch
containing parentheses in the filename and things are different: If PD is
closed and I right-click on the file and ask to open with PD, I get the
error in the PD window but the patch works; if PD is open and I drag the
file on it, I get the pop-up error and no operations can be performed on
the patch. I.e., I can't change any of the GUI with the mouse or even close
the patch pressing cmd + w. I can still close it by clicking on the "close"
button in the window.

Cheers,
Dario

(Tcl) UNHANDLED ERROR: 2017-07-24 09:56:45.727 defaults[2085:48740] Could
not parse: /Users/dariosanfilippo1/Dropbox/PureData
patches/abstractions/delta(t)~.pd.  Try single-quoting it.
while executing
"exec /bin/sh -rc "defaults write $adomain $akey -array-add $escaped""
(procedure "write_config" line 13)
invoked from within
"write_config $::recentfiles_list $::pd_guiprefs::domain $::recentfiles_key
 $::recentfiles_is_array"
(procedure "::pd_guiprefs::write_recentfiles" line 2)
invoked from within
"::pd_guiprefs::write_recentfiles "
(procedure "::pd_menus::update_openrecent_menu_aqua" line 13)
invoked from within
"::pd_menus::update_openrecent_menu_aqua .openrecent $write"
(procedure "::pd_menus::update_recentfiles_menu" line 4)
invoked from within
"::pd_menus::update_recentfiles_menu"
(procedure "::pd_guiprefs::update_recentfiles" line 10)
invoked from within
"::pd_guiprefs::update_recentfiles $filename"
(procedure "open_file" line 14)
invoked from within
"open_file $filename"
(procedure "open_filestoopen" line 3)
invoked from within
"open_filestoopen"
(procedure "pdtk_pd_startup" line 24)
invoked from within
"pdtk_pd_startup 0 48 0 {test5} {} {} {DejaVu Sans Mono} normal"
("uplevel" body line 15)
invoked from within
"uplevel #0 $docmds"


delta(t)~.pd
Description: Binary data
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Is PD using CPU optimisation?

[Dario Sanfilippo]

Hello, list.

Would it be sensible to, for example, start using multiplications over
divisions when possible or will the compiler take care of that?

Cheers,
Dario
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] detect silence

[Dario Sanfilippo]

If you want to work in the audio domain, consider calculating the RMS by
simply squaring, low-passing, and taking the sqrt of the signal. The cutoff
determines your averaging window.

You can implement relational operators in the audio domain by using [/~],
as the same signal connected to both of its inputs will give 0 when the
signal is 0, and 1 otherwise. There was a nice conversation on the PD
facebook group on this. Thanks to Matt Barber.

For example:

[inlet~] [inlet~]
| \  |
|   \|
| \  |
|[max~]
| /
[-~   ]
|\
[/~   ]
|
[outlet~]

is [<~].

You can then use a lowpass to slow down the transitions between true or
false. The impulse response of [rpole~] will decrease of ~60dB (1/1024) in
a desired time by setting the feedback coefficient B with B = .001^t/T60. t
is the feedback period N/Fc and T60 is the decay time in sec. [rpole~] is
an IIR but it will truncate to 0 when its output gets very small.
Approximately, using the formula above, it will get to 0 after a desired
time if you multiply the decay time by .158065.

Cheers,
D

On 9 September 2016 at 07:47, enrike  wrote:

> thanks Jaime. I was checking fiddle~ and bonk~ but I guess env~ goes more
> to the point.
>
> og., 2016.eko iraren 08a 18:08(e)an, Jaime Oliver igorleak idatzi zuen:
>
> env~ should help you do that.
>>
>> J
>>
>>
>>
>> On Sep 8, 2016, at 9:01 AM, enrike  wrote:
>>>
>>> hi all
>>>
>>> is there any abstraction or external that allows to detect silence in
>>> the sound in? I mean if the amplitude drops below a threshold for a given
>>> period of time.
>>>
>>> I was thinking about how to get this going to try to build it myself
>>> then I thought there might be some external or abstraction that already
>>> does what I need. Tired of reinventing the wheel...
>>>
>>> thanks
>>>
>>> enrike
>>>
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>>> stinfo/pd-list
>>>
>>
>>
>>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
> stinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Experiencing a higher CPU load with 0.47-0 and 0.47-1.

[Dario Sanfilippo]

Hi, Miller.

The comparison was between 64bit versions of the software. Like a mentioned
in another email, there was ~15% higher CPU load (however accurate that
estimation is) in .47 when running 512 instantiations of a simple patch
with an [osc~]-driven [vd~] and [delwrite~]. I can try putting together a
list of the most used objects in my project to narrow down any potential
problem.

Cheers,
Dario

On Wed, 3 Aug 2016 at 01:21 Miller Puckette <m...@ucsd.edu> wrote:

> I just loaded a nice fat benchmark patch (based on smeck, the guitar
> processor) in a few different versions of Pd.  I got no difference between
> Pd-0.46-7 and pd-0.47-1 ... however, in each version the "64 bit" compile
> ran in about 85% of the CPU load that the non-64-bit version did.  Perhaps
> you're comparing 0.46 634 bit with 0.47 32 bit?
>
> cheers
> Miller
>
>
> On Mon, Jun 27, 2016 at 09:19:35AM -0700, Miller Puckette wrote:
> > Yes, the whole thing is baffling, but I gather something changed from
> 0.46
> > to 0.47 ... I've gt a coupld of benchmark patches I can try to see if I
> can
> > see what's going on.
> >
> > cheers
> > Miller
> >
> > On Mon, Jun 27, 2016 at 12:14:56PM +0200, cyrille henry wrote:
> > >
> > >
> > > Le 27/06/2016 11:58, Dario Sanfilippo a écrit :
> > > >Hi, Christof.
> > > >
> > > >It is a rather large project and relatively new, so I'd prefer not to
> share it at this point as it still kind of a work in progress. I will try
> putting together some test patches isolating some of the most used objects
> and see if there's any significant change in the different PD versions when
> instantiating many of them.
> > > >
> > > >Cyrille: I'm just using PD's Load Meter patch. The test I performed
> had had just the patch on, without me doing anything. In 0.46-7, the
> average CPU load when turning DSP on is around 40-50%, with peaks at about
> 60-70% when acting on the patch. No dropouts experienced. In 0.47, the
> initial CPU load is around 60% or more and it gets to the point of
> producing audio dropouts when acting on the patch. So, empirically, 0.47
> does seem to have a different CPU load.
> > > >
> > >
> > > different cpu load: yes, but since you don't know the cpu frequency,
> you can't know if it's a higher load, a lower load, and if it's a
> significative change.
> > >
> > >
> > > >I can see the same behaviour by looking at Activity Monitor on OSX. I
> wouldn't know how else to measure the CPU load, though.
> > > i'm afraid it's the same problem with activity monitor.
> > >
> > > cheers
> > > c
> > >
> > >
> > >
> > >
> > > >
> > > >Thanks for your help, guys.
> > > >
> > > >Dario
> > > >
> > > >
> > > >
> > > >On 27 June 2016 at 10:00, cyrille henry <c...@chnry.net  c...@chnry.net>> wrote:
> > > >
> > > >hello,
> > > >
> > > >how are you doing cpu load measurement?
> > > >
> > > >I find it very hard to do reliable measurement of cpu load
> nowadays, since computer have a variable cpu speed depending on load.
> > > >
> > > >For exemple, pd CPU load can be at 75%, with CPU frequency at
> 800MHz. When increasing the patch complexities, the CPU frequency increase,
> and the apparent load reported by pd decrease.
> > > >
> > > >On linux, you can bloc the processor to a fixed frequency, and
> then make reliable load measurement.
> > > >But i don't know how to do than on OSX. Did you find a way?
> > > >otherwise, your measurement are useless.
> > > >
> > > >cheers
> > > >c
> > > >
> > > >
> > > >
> > > >
> > > >Le 27/06/2016 10:44, christof.re...@gmx.at  christof.re...@gmx.at> a écrit :
> > > >
> > > >Do you want to share your patch? I could test it on my
> machine with 0.46 and 0.47
> > > >
> > > >-Ursprüngliche Nachricht-
> > > >Gesendet: Sonntag, 26 Juni 2016 um 13:27:23 Uhr
> > > >Von: "Dario Sanfilippo" <sanfilippo.da...@gmail.com  sanfilippo.da...@gmail.com>>
> > > >An: pd-list <pd-l...@iem.at <mailto:pd-l...@iem.at>>
> > > >Betreff: [PD] Experiencing a higher CPU load with 0.47-0 and
> 0.47-1.
> > > >

Re: [PD] Experiencing a higher CPU load with 0.47-0 and 0.47-1.

[Dario Sanfilippo]

Hi, Christof.

It is a rather large project and relatively new, so I'd prefer not to share
it at this point as it still kind of a work in progress. I will try putting
together some test patches isolating some of the most used objects and see
if there's any significant change in the different PD versions when
instantiating many of them.

Cyrille: I'm just using PD's Load Meter patch. The test I performed had had
just the patch on, without me doing anything. In 0.46-7, the average CPU
load when turning DSP on is around 40-50%, with peaks at about 60-70% when
acting on the patch. No dropouts experienced. In 0.47, the initial CPU load
is around 60% or more and it gets to the point of producing audio dropouts
when acting on the patch. So, empirically, 0.47 does seem to have a
different CPU load.

I can see the same behaviour by looking at Activity Monitor on OSX. I
wouldn't know how else to measure the CPU load, though.

Thanks for your help, guys.

Dario



On 27 June 2016 at 10:00, cyrille henry <c...@chnry.net> wrote:

> hello,
>
> how are you doing cpu load measurement?
>
> I find it very hard to do reliable measurement of cpu load nowadays, since
> computer have a variable cpu speed depending on load.
>
> For exemple, pd CPU load can be at 75%, with CPU frequency at 800MHz. When
> increasing the patch complexities, the CPU frequency increase, and the
> apparent load reported by pd decrease.
>
> On linux, you can bloc the processor to a fixed frequency, and then make
> reliable load measurement.
> But i don't know how to do than on OSX. Did you find a way?
> otherwise, your measurement are useless.
>
> cheers
> c
>
>
>
>
> Le 27/06/2016 10:44, christof.re...@gmx.at a écrit :
>
>> Do you want to share your patch? I could test it on my machine with 0.46
>> and 0.47
>>
>> -Ursprüngliche Nachricht-
>> Gesendet: Sonntag, 26 Juni 2016 um 13:27:23 Uhr
>> Von: "Dario Sanfilippo" <sanfilippo.da...@gmail.com>
>> An: pd-list <pd-l...@iem.at>
>> Betreff: [PD] Experiencing a higher CPU load with 0.47-0 and 0.47-1.
>> Hi, list.
>>
>> I'm loading the same patch with 0.46-7, 0.47-0 and 0.47-1 - all 64bit. The
>> last two have a significantly higher CPU load. I'm on OSX 10.11.5.
>>
>> Has any of you experienced anything similar?
>>
>> I haven't changed my [vd~] objects into [delread4~], are they calling the
>> same piece of code?
>>
>> The patch is almost exclusively using signal objects, have some of these
>> been modified in 0.47-0 and 0.47-1?
>>
>> Thanks for your help.
>>
>> Dario
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>>
>>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Experiencing a higher CPU load with 0.47-0 and 0.47-1.

[Dario Sanfilippo]

Hi, list.

I'm loading the same patch with 0.46-7, 0.47-0 and 0.47-1 - all 64bit. The
last two have a significantly higher CPU load. I'm on OSX 10.11.5.

Has any of you experienced anything similar?

I haven't changed my [vd~] objects into [delread4~], are they calling the
same piece of code?

The patch is almost exclusively using signal objects, have some of these
been modified in 0.47-0 and 0.47-1?

Thanks for your help.

Dario
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] lop~ and hip~ difference equations

[Dario Sanfilippo]

Thank you so much for your answer, Joe and Alexandre.

You're right, Joe. I was actually referring to hip~ when talking about the
impulse response, indeed hip~ is one-pole and one-zero. It might be good to
specify it in the help file.

What formula would you use for the coefficients of rpole~ and rzero~ to
implement it?

Cheers,
Dario



On 18 February 2016 at 20:27, Alexandre Torres Porres <por...@gmail.com>
wrote:

> let me share some patches too.
>
> as said: lop~ is not the same as rpole~ but is possible to be implemented
> using rpole~, hip~ can be implemented with rpole~ and rzero~
>
> my patches show the difference equations and all, they're in portuguese,
> and part of my computer music class examples available here
> <https://sites.google.com/site/porres/Live%20Electronics%20%28EL%20Locus%20Solus%29%20-%20Porres.zip?attredirects=0=1>
>
> cheers
>
> 2016-02-18 14:32 GMT-02:00 Joe White <white.j...@gmail.com>:
>
>> Hey Dario,
>>
>> [lop~] can be implemented with just an [rpole~], did you make sure to set
>> the coefficients correctly? I've attached an example patch to implement
>> [lop~].
>>
>> [hip~] is an [rpole~] and [rzero~] in series. You can find the
>> coefficients in the source code.
>>
>> Cheers,
>> Joe
>>
>> On 18 February 2016 at 14:59, Dario Sanfilippo <
>> sanfilippo.da...@gmail.com> wrote:
>>
>>> Hello, list.
>>>
>>> Do you know what the difference equations of [lop~] and [hip~] are?
>>>
>>> Just hoping that one of you has a quick answer, otherwise I'll try
>>> figuring it out by looking at the code.
>>>
>>> Anyway, they don't seem to be the same as [rpole~] as the impulse
>>> response is different.
>>>
>>> Thanks,
>>> Dario
>>>
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] lop~ and hip~ difference equations

[Dario Sanfilippo]

Hello, list.

Do you know what the difference equations of [lop~] and [hip~] are?

Just hoping that one of you has a quick answer, otherwise I'll try figuring
it out by looking at the code.

Anyway, they don't seem to be the same as [rpole~] as the impulse response
is different.

Thanks,
Dario
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list