Pd-list November 2020

pd-list@lists.iem.at

45 participants
49 discussions

Re: [PD] is [hid] dead? can t be 64 bits?
by Dan Wilcox 24 Nov '20

24 Nov '20

Following Christof, I second the suggestion to change the build to use pd-lib-builder as it makes building an external much easier by doing most of the heavy work. Then people on other platforms can more easily pitch in with testing and maintenance. This makes more sense then you having to set up a bunch of systems and OS installs if you are not doing it already and/or using those systems. Those that cannot wait for binaries can simply build it themselves. (Yeah de-centralized model.) > On Nov 24, 2020, at 5:34 PM, pd-list-request(a)lists.iem.at wrote: > > Message: 3 > Date: Tue, 24 Nov 2020 17:34:37 +0100 > From: Albert Rafetseder <albert.rafetseder+pd(a)univie.ac.at <mailto:albert.rafetseder+pd@univie.ac.at>> > To: Pd-List <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>> > Subject: Re: [PD] is [hid] dead? can t be 64 bits? > Message-ID: <e28f49ca-e436-bfd7-fc38-ea0d96aa623d(a)univie.ac.at <mailto:e28f49ca-e436-bfd7-fc38-ea0d96aa623d@univie.ac.at>> > Content-Type: text/plain; charset=utf-8 > > Thank you for the supportive words, everyone! > > If you promise to not hold your breath just yet, I can try my hands on > Linux x86 / amd64 / ARM (think: Raspberry) builds as well. > > For Windows, I have no idea whether [hid] is even supposed to work, and > have no opportunity to test for the time being. Any hints welcome. > > Best, > Albert. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD] is [hid] dead? can t be 64 bits?
by mitchell turner 24 Nov '20

24 Nov '20

Albert, Thanks so much for working on [hid] for MacOS. I know there are many that appreciate it. — Mitch ------------------------------ Message: 3 Date: Tue, 24 Nov 2020 12:02:50 -0300 From: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>> To: Albert Rafetseder <albert.rafetseder+pd(a)univie.ac.at <mailto:albert.rafetseder+pd@univie.ac.at>> Cc: Pd-List <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>> Subject: Re: [PD] is [hid] dead? can t be 64 bits? Message-ID: <CAEAsFmj+1Jr_i6Qf9N6kCOZZ6ED2CnQAKkF5vqsL2JF7ERAUUw(a)mail.gmail.com <mailto:CAEAsFmj+1Jr_i6Qf9N6kCOZZ6ED2CnQAKkF5vqsL2JF7ERAUUw@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" oh, I had only seen the mail at pd-dev :) nice well, this is awesome, thanks! But what about other OSes? Do you need help compiling/uploading? Maybe others can help here. cheers Em ter., 24 de nov. de 2020 às 08:27, Albert Rafetseder < albert.rafetseder+pd(a)univie.ac.at <mailto:albert.rafetseder+pd@univie.ac.at>> escreveu: > Thank you all for helping me overcome inertia :-) > > It's my pleasure to present on deken > > hid[v0.7.3](Darwin-amd64-32)(Sources).dek > Uploaded by albert @ 2020-11-24 11:10:37 > > Have fun, and kindly report any errors over at > > https://gitlab.com/aaaaalbert/pd-hid/issues <https://gitlab.com/aaaaalbert/pd-hid/issues> > > Cheers, > Albert. > > > Am 19/11/20 um 20:42 schrieb Alexandre Torres Porres: >> +1000 >> >> Em qui., 19 de nov. de 2020 às 16:32, Christof Ressi < > info(a)christofressi.com <mailto:info@christofressi.com>> >> escreveu: >> >>>> Shall I push it, like, Real Soon Now This Time? >>> +1 >>> >>> On 19.11.2020 20:20, Albert Rafetseder wrote: >>>>> i dont see it for my mac but older 32bit ones >>>>> >>>>> is compiling for 64 bits possible? >>>> I managed to compile it with minimal tweaks a few months ago: >>>> >>>> https://gitlab.com/aaaaalbert/pd-hid/ <https://gitlab.com/aaaaalbert/pd-hid/> (sources) >>>> >>>> Sorry for not pushing the binary to deken yet - I'm all too easily >>>> distracted! >>>> >>>> (Shall I push it, like, Real Soon Now This Time?) >>>> >>>> Best wishes, >>>> Albert.

2 1

delay compensation in pitch-shifting
by info＠hansroels.be 24 Nov '20

24 Nov '20

Hello, Hopefully people with more knowledge of audio processing can answer the following questions. Background: I make patches in which the microphone input is modified by different kinds of pitch-shifting, I would like to compensate the delays caused by these pitch-shifts and thus avoid artefacts. 1) How much delay does a pitch-shifter based on a variable delay (the classic rotating-tape-head style) produce? as in G09.pitchshift.pd in the audio.examples folder. I did a quick test with a one-sample-audio-trigger going immediately to the first channel of a recording patch in Pd and simultaneously going to a variable delay pitchshift (pp.pitchshift~ from AudioLab), routed into the second channel of the recorder. The delays are quite large and vary between 30 and 80 milliseconds, there seems to be no relation with the amount of pitch-shift. In the pitch-shifting patch I also notice that the delay varies between zero and the window size. Is there a way/patch to calculate and compensate for this delay? (for example, if you want to combine the original with the pitch-shifted signal in a patch). Or is this impossible because the delay is variable... 2) I'd like to know the delay in ms with FFT processing if you have a 1024 sample window with overlap factor of 4, for example, in a pitch-shifting vocoder? I found this info on a MAx/MSP mailing list, is it correct?: "The I/ O delay is equal to the window size minus the hop size (e.g., for a 1024-sample FFT window with an overlap factor of 4, the hop size is equal to 256, and the overall delay from input to output is 768 samples)"; at 44100 sampling rate this is around 17ms delay (for a window of 1024 samples, overlap 4). 3) Conclusion: any pitch-shifting technique introduces tens of milliseconds delay? (Pitch-shifting based on granular synthesis is not a solution, I think it also requires a buffer of at least 50ms.) Hans --

3 3

is [hid] dead? can t be 64 bits?
by Alexandre Torres Porres 24 Nov '20

24 Nov '20

i dont see it for my mac but older 32bit ones is compiling for 64 bits possible? cheers

3 5

Re: [PD] delay compensation in pitch-shifting (info@hansroels.be)
by Julián Villegas 24 Nov '20

24 Nov '20

Hi Hans, I’m sorry I’m late to the party and that I can’t answer your questions, but I wanted to call your attention to [shifter~], this is a PSOLA pitch shifter object that I ported to Pd from its eponymous version in Max-MSP, developed by Tristan Jehan. The source code and MacOS compiled library are here: https://bitbucket.org/julovi/shifter/src/master/ Cheers, Julian.

5 4

Re: [PD] Pd 64 bits precision "for real"?
by Dan Wilcox 23 Nov '20

23 Nov '20

I think "pd64" is fine, otherwise the list get's catchy/dumb: pdpd (haha) pd two-times pd again pd double trouble pd dubs' pd-sharp (less rounding) ... I would fine "dppd" confusing unless we go ahead and re-brand ala "pd vanilla" and "double-dipped pd" aka "dppd"... > On Nov 23, 2020, at 12:00 PM, pd-list-request(a)lists.iem.at wrote: > > Message: 1 > Date: Mon, 23 Nov 2020 09:22:49 +0100 > From: IOhannes m zmoelnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>> > To: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at> > Subject: Re: [PD] Pd 64 bits precision "for real"? > Message-ID: <57e459d6-e8d1-516c-da37-af88912aaf21(a)iem.at <mailto:57e459d6-e8d1-516c-da37-af88912aaf21@iem.at>> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 11/23/20 12:25 AM, Martin Peach wrote: >> It should be named dppd to avoid confusion imho. > > or pddp (or is that already taken?) > > when csound switched to double precision they renamed things to > "csound64" (with "things" being at least the libraries that hold the > engine). > > so i like pd64 better, as it is obvious that this is still Pd (and not > just some nice palindromic acronym). > > but anyhow, yes: we probably need a catchy name. > > fgmadsr > IOhannes -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 2

Re: [PD] Pd 64 bits precision "for real"?
by Dan Wilcox 23 Nov '20

23 Nov '20

Note: until the sound file updates branch with the CAF file support is merged, 64 bit sample indices aren't yet useful with the current core file formats (WAV, AIFF, SND) as they use 32 bit indices. > On Nov 20, 2020, at 8:17 PM, pd-list-request(a)lists.iem.at wrote: > > Message: 2 > Date: Fri, 20 Nov 2020 14:16:45 -0300 > From: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>> > To: Pd-List <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>> > Subject: [PD] Pd 64 bits precision "for real"? > Message-ID: > <CAEAsFmi2xraTaNURCXWJPeJgEmLxEoD80NLRBAr-ztZhXEdRLw(a)mail.gmail.com <mailto:CAEAsFmi2xraTaNURCXWJPeJgEmLxEoD80NLRBAr-ztZhXEdRLw@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > Hi there, it's known Pd can be built with 64 bits precision, but when can > we expect it to also be available for download as such? > > I'm currently working on externals that play large files without running > into precision issues, but that'd be unnecessary once Pd 64 bits is more of > a thing. > > It seems to me all should be good to go once it's already possible for > those who compile it like that... so I guess the main issue would be with > externals that also need to be compiled for that. > > cheers -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

6 7

Re: [PD] external: How to force calling the "dsp" function?
by Matthias Geier 21 Nov '20

21 Nov '20

Thanks a lot, Christof and Sebastian, for your answers! On Fri, Nov 20, 2020 at 8:40 PM Christof Ressi wrote: > [...] > > > However, my external accepts an "open" message which might allocate a > > new internal buffer, and I would like Pd to call my dsp function in > > order to update a few pointers so that the "perform" function can > > access the new buffer. > > If the buffer can change, you shouldn't directly pass it to the perform > method. Instead you should pass the object which contains the buffer, > then the perform method will always see the most recent state. > > Generally, most externals pass the object, the individual signals and > finally the vector size. I know that's the canonical way, but I need to "insert" a few additional channels between the existing ones. And this changes with the "open" message. But now I found a different (and better!) solution where I store the pointers to the signals within my object instead of directly passing them to the perform function (I pass only the object itself). This solves my problem and it also makes the code much simpler at the same time! > > Will the "perform" function be > > called even if the "open" handler isn't finished yet? > > No, all methods are executed *synchronously*. Thanks for confirming this. I suspected this to be true, but I wasn't quite sure. [...] > > Christof ---- On Fri, Nov 20, 2020 at 9:48 PM Sebastian Shader wrote: > > why don't you just have a function that does the things that you want to have happen when the dsp graph changes and when > the open message is received? > then just call that function from both the dsp function and the open handler Yes, that's exactly what I was thinking of after reading Christof's response. As so often, the problem can be solved by adding another level of indirection! > But it seems like in your case you just want to send the new allocated buffer to perform, so why not just store a > pointer to it in the object and then access that in perform? Because my buffer is actually storing pointers to channels. And those pointers have to be updated using the pointers to the outlet signals that are provided in the "dsp" function. But my buffer also contains pointers that are not related to outlets and that have to be updated in the "open" handler. In the meantime I have updated my object to contain a list of pointers to the outlet signals, which is kept up-to-date in the "dsp" function. And I've created a function that moves those pointers around to another list of pointers, and this function is called from both the "dsp" function and the "open" handler. Now everything works as expected, no more segfaults (at least for now ...). In case somebody is interested, this is the mentioned change: https://github.com/AudioSceneDescriptionFormat/asdf-rust/commit/ef81f91c6f8… cheers, Matthias > if your open handler takes awhile it will stop pd entirely until it's finished I believe, unless it's threaded somehow. > > -seb > > -----Original Message----- > From: Matthias Geier <matthias.geier(a)gmail.com> > To: Pd-List <Pd-list(a)lists.iem.at> > Sent: Fri, Nov 20, 2020 10:37 am > Subject: [PD] external: How to force calling the "dsp" function? > > Dear list. > > I'm working on a Pd external > (https://github.com/AudioSceneDescriptionFormat/asdf-rust/tree/master/pure-d…) > which uses class_addmethod() with gensym("dsp") to register a "dsp" > function. > > I guess this function is called whenever the audio graph changes, and > that works fine. > > However, my external accepts an "open" message which might allocate a > new internal buffer, and I would like Pd to call my dsp function in > order to update a few pointers so that the "perform" function can > access the new buffer. > > So my question is: Can I somehow, after handling my "open" message, > force the "dsp" method to be called? > > And a related question: What happens when my handling of the "open" > message takes longer than expected? Will the "perform" function be > called even if the "open" handler isn't finished yet? > > Or can I somehow tell Pd that it should stop calling my "perform" > function for a little bit while I allocate a new buffer and then tell > it to call the "dsp" function and afterwards resume calling the > "perform" function? > > BTW, with "perform" function I mean the function that has been > registered with dsp_addv(). > > cheers, > Matthias

1 0

external: How to force calling the "dsp" function?
by Matthias Geier 20 Nov '20

20 Nov '20

Dear list. I'm working on a Pd external (https://github.com/AudioSceneDescriptionFormat/asdf-rust/tree/master/pure-d…) which uses class_addmethod() with gensym("dsp") to register a "dsp" function. I guess this function is called whenever the audio graph changes, and that works fine. However, my external accepts an "open" message which might allocate a new internal buffer, and I would like Pd to call my dsp function in order to update a few pointers so that the "perform" function can access the new buffer. So my question is: Can I somehow, after handling my "open" message, force the "dsp" method to be called? And a related question: What happens when my handling of the "open" message takes longer than expected? Will the "perform" function be called even if the "open" handler isn't finished yet? Or can I somehow tell Pd that it should stop calling my "perform" function for a little bit while I allocate a new buffer and then tell it to call the "dsp" function and afterwards resume calling the "perform" function? BTW, with "perform" function I mean the function that has been registered with dsp_addv(). cheers, Matthias

2 1

Pd 64 bits precision "for real"?
by Alexandre Torres Porres 20 Nov '20

20 Nov '20

Hi there, it's known Pd can be built with 64 bits precision, but when can we expect it to also be available for download as such? I'm currently working on externals that play large files without running into precision issues, but that'd be unnecessary once Pd 64 bits is more of a thing. It seems to me all should be good to go once it's already possible for those who compile it like that... so I guess the main issue would be with externals that also need to be compiled for that. cheers

2 2

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 November 2020