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/>
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/>
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
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
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
Hi,
got a new dell 13 5301. It comes with a sof-hda-dsp card. After installing Ubuntu 20.04, Qjackctl was not working. I found a solution here:
https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg5830075.html
Qjackctl started fine with sr 48000 and period 1008 and I have clean sound from vlc, audacity, ardour, etc but Pd 0.50.2 is constantly crackling.
I tried pd -jack in terminal and there's a "Partial read" message constantly appearing. With callbacks the message turn into "jack: nframes 1008 not a multiple of blocksize 64"
Then I tried pd -jack -blocksize 252 (also 504, 1008) but the problem continues. Probably I'm missing something, so any help to fix this will be appreciated.
best, rc.
interesting, didn´t know about that ircam site, thanks for sharing!
(and now brought the mail back to pd list, which i omitted in my original post)
good luck with the mac arm64 build - was looking at the specs of their mac mini today and some benchmarks, did look interesting.
hans
> Am 19.11.2020 um 02:02 schrieb Dan Wilcox <danomatika(a)gmail.com>:
>
> I added some basic info about loading custom data sets from what was already there. Maybe that's worth trying. Could be good to have some sort of way to convert something like data from here to earplug~: http://recherche.ircam.fr/equipes/salles/listen/download.html.
>
> In any case, we use it in Zirkonium and will need build for mac arm64 soon.
>
>> On Nov 19, 2020, at 1:57 AM, hans w. koch <hansw.koch(a)gmail.com> wrote:
>>
>> thanks dan,
>>
>> this can be very useful!
>> compiled here easily (mac os 10.14.6) and runs in pd 0.51-3
>>
>> best
>> hans
>>
>>> Am 19.11.2020 um 01:04 schrieb Dan Wilcox <danomatika(a)gmail.com>:
>>>
>>> Howdy all,
>>>
>>> We use the old, but venerable earplug~ external in a project at work which we are currently updating. I went ahead and pulled the earplug~ git dump from svn onto a GitHub repo and have made some updates for a version 0.2.2 release:
>>>
>>> https://github.com/pd-externals/earplug
>>>
>>> As it's a pure C external with pd-lib-builder, it should be easy to build.
>>>
>>> --------
>>> Dan Wilcox
>>> @danomatika
>>> danomatika.com
>>> robotcowboy.com
>>>
>>>
>>>
>>> _______________________________________________
>>> Pd-list(a)lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>>
>
> --------
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
>
>
Hi list,
sorry if this has been discussed before, the list archive didn't give a
good search result, but how would I reverse items in a given list
immediately, so that
[1 2 3<
becomes
[3 2 1<
?
cheers, P