t;giuliom...@yahoo.it>; Pd-List <pd-list@lists.iem.at>
Sent: Monday, 3 October 2016, 16:56
Subject: Re: [PD] Threading in Pd/libpd
> Subpatches with the same or smaller block size as the parent patch should not
> be threaded.
> Subpatches with larger blocksize should be
> Subpatches with the same or smaller block size as the parent patch should not
> be threaded.
> Subpatches with larger blocksize should be threaded, but it's left up to the
> user to enable that.
Do you have to revise every single signal object in order for this to work?
-Jonathan
Pd-List <pd-list@lists.iem.at>
Sent: Saturday, 1 October 2016, 6:08
Subject: Re: [PD] Threading in Pd/libpd
> The entire subpatch, which in principle can be used to wrap [fft~].> My plan
> is to have a common way of wrapping these objects with threads so that
> I do no
larger block size than the parent patch?
> Giulio
From: Jonathan Wilkes <jancs...@yahoo.com>
To: Giulio Moro <giuliom...@yahoo.it>; Pd-List <pd-list@lists.iem.at>
Sent: Saturday, 1 October 2016, 1:43
Subject: Re: [PD] Threading in Pd/libpd
> Yes,
Pd-List <pd-list@lists.iem.at>
Sent: Saturday, 1 October 2016, 1:43
Subject: Re: [PD] Threading in Pd/libpd
> Yes, that's the plan, by default I'd set it to the number of samples
> corresponding to the step determined by the specified overlap.
What exactly gets compute
> Yes, that's the plan, by default I'd set it to the number of samples
> corresponding to the step determined by the specified overlap.
What exactly gets computed in the separate thread? Is it only the revised
[fft~] object? Or is it the entire subpatch?
-Jonathan
t: Thursday, 29 September 2016, 2:33
>Subject: Re: [PD] Threading in Pd/libpd
>
>> So having a look at the source code I'd say what would happen is that
>
>> the second block prints the samples of the sound file.
>
>> I guess the point you are trying to make here is that
argument?
> Giulio
From: Jonathan Wilkes <jancs...@yahoo.com>
To: Giulio Moro <giuliom...@yahoo.it>; Pd-List <pd-list@lists.iem.at>
Sent: Wednesday, 28 September 2016, 23:00
Subject: Re: [PD] Threading in Pd/libpd
> Thanks Jonathan.
> Also [rea
of the whole of Pd.
Giulio
From: Jonathan Wilkes <jancs...@yahoo.com>
To: Giulio Moro <giuliom...@yahoo.it>; Pd-List <pd-list@lists.iem.at>
Sent: Wednesday, 28 September 2016, 23:00
Subject: Re: [PD] Threading in Pd/libpd
> Thanks Jonathan.
> Also [readsf~] supp
> Thanks Jonathan.
> Also [readsf~] supports threading and so do [udpsend] and [udpreceive], for
> obvious reasons involving system calls.
>> Can you guarantee that the revisions you've implemented generate the same
>> output as Pd Vanilla, for all cases?
> I'd rather say it does not, in all
e if I can put together a [blockthread~] object which can do
something useful.
Best,
Giulio
> From: Jonathan Wilkes <jancs...@yahoo.com>
>To: Giulio Moro <giuliom...@yahoo.it>; Pd-List <pd-list@lists.iem.at>
>Sent: Tuesday, 27 September 2016, 18:35
>Subject: Re: [PD
> So, probably this point has been discussed previously, I'd like to know:> -
> are there any existing objects doing this already?
There is a creation argument to [coll] in Pd-l2ork that enables threading.
> - what are the pitfalls that prevented such an approach from making its way
> into Pd?
It looks like I am not very lucky in getting attention, so let me try to re-up
this. Can we implement a threaded [block~] ? see details below
From: Giulio Moro <giuliom...@yahoo.it>
To: Pd-List <pd-list@lists.iem.at>
Sent: Sunday, 18 September 2016, 2:23
Subject: Thr
Hi all,if I understand correctly, using the [block~] and [switch~] objects to
increase the blocksize for a given subpatch, means that the DSP computation for
that subpatch is delayed until the moment when enough input samples have been
collected, at which point the entire DSP stack for the
14 matches
Mail list logo
