In response to my comment about acoustic mirror sounding muddy.
I think that most of the directx effects sounded muddy at that time.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
--- On Thu, 4/7/11, Mathieu Bouchard wrote:
> From: Mathieu Bouchard
> Subject: Re: [PD] Making a Realtime Convolution External
> To: "IOhannes m zmoelnig"
> Cc: pd-list@iem.at
> Date: Thursday, April 7, 2011, 5:15 PM
> On Wed, 6 Apr 2011, IOhannes m
> zmoeln
if you're not realtime, your main process could get yanked by the
scheduler too seems more like "realtime vs not-realtime" than
"threads: yes/no".
On Thu, Apr 7, 2011 at 8:15 AM, Mathieu Bouchard wrote:
> On Wed, 6 Apr 2011, IOhannes m zmoelnig wrote:
>
>> using "threats" does not mean that t
On Wed, 6 Apr 2011, IOhannes m zmoelnig wrote:
using "threats" does not mean that things have to get non-deterministic,
and indeed a lot of software uses threads and stays completely
deterministic.
Suppose that you launch a second fred on another cpu. How do you
synchronise the main fred and
SONOFA$#*&! I keep posting from the wrong email address and getting
bounced ;-) Sorry to Henry & IOhannes for the dupes...
> In the context of threading/part. conv, I had an idea to compute ahead.
> Most of the calculations for a given block can be computed ahead. Only the
> most recent block of
On Apr 6, 2011, at 2:52 PM, IOhannes m zmoelnig wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2011-04-06 20:26, Hans-Christoph Steiner wrote:
Pd has its own scheduling system which is best to stick to as long as
you can so that you can keep the deterministic operation intact. For
On Wed, Apr 6, 2011 at 2:08 PM, IOhannes m zmoelnig wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 2011-04-06 21:04, Seth Nickell wrote:
> > I use a thread per core, it does parallelize nicely.
> >
>
> that's what i thought.
>
> please don't let yourself turn down by all those mi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2011-04-06 21:04, Seth Nickell wrote:
> I use a thread per core, it does parallelize nicely.
>
that's what i thought.
please don't let yourself turn down by all those misers :-)
fgmasdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.
Hi Charles,
I have a few partitioning methods. I used to do profiling when you
first load the plugin, to determine the optimal partitioning, but
found that on intel/amd cpus with sse3, it didn't vary much, and just
hardcoded a simple rule set for when to use each partitioning style.
In the more cr
Hi Hans,
The thread in question here would be invoked when a "set" message is
sent to the object. In this case, I need to load the Impulse Response
from the disk and optionally do a test convolution and normalize it.
I'm assuming (yeah, I should just check ;-) if I block on an inlet,
I'm blocking
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2011-04-06 20:26, Hans-Christoph Steiner wrote:
>
> Pd has its own scheduling system which is best to stick to as long as
> you can so that you can keep the deterministic operation intact. For
> convolution, I can't see a reason to use a thread. I
On Apr 4, 2011, at 10:48 PM, Seth Nickell wrote:
2) Anyone have requests for features/api? Its currently simplistic:
- takes a "read FILENAME" message, loads the file, does a test
convolution against pink noise to normalize the gain to something
sane
Is this done within the main Pd audio
Hi Seth,
In terms of feature requests, since you are doing all the work already,
it would be nice to have 1x4 mode, meaning one input ->4 convolutions->4
outputs. That would be great for ambisonic (b-format) 4-channel room
impulse responses.
Regards,
Archontis
On 4/5/11 3:54 AM, Seth Nickel
> the calculation as well, so that you could deliberately stagger the
> blocks and more evenly distribute the calculation in cpu-intensive
> situations. I'm imagining something like two 4096 blocks running say,
> 64 samples apart so that one is does its calculation while the other
> is still collec
> Just scanned the source... big difference would be performance, and if
> you're picky (you have to be pretty picky, honestly), some difference
> in accuracy due to floating point's reduced precision at large/small
> values. Convolution is still expensive enough for performance to
> really matter.
On Tue, Apr 5, 2011 at 2:33 PM, Seth Nickell wrote:
> Hi Mathieu,
>
> Thanks, I assumed (without checking :-P) that the dsp call happened
> every time, didn't realize it was a setup/patching call that registers
> my "_perform" function with a call graph. Exactly what I need.
>
> I think the diffe
Hi Mathieu,
Thanks, I assumed (without checking :-P) that the dsp call happened
every time, didn't realize it was a setup/patching call that registers
my "_perform" function with a call graph. Exactly what I need.
I think the difference in approach comes from the needs of the
external. fiddle~ pr
On Tue, Apr 5, 2011 at 8:38 AM, Mathieu Bouchard wrote:
> On Mon, 4 Apr 2011, Seth Nickell wrote:
>
>> 5) I'd love to build a granular convolution engine takes two real-time
>> signals, and extracts grains from one to convolve against the other. Anyone
>> have ideas about this?
>
> What's the
Hi Jamie,
Just scanned the source... big difference would be performance, and if
you're picky (you have to be pretty picky, honestly), some difference
in accuracy due to floating point's reduced precision at large/small
values. Convolution is still expensive enough for performance to
really matter
On Mon, 4 Apr 2011, Seth Nickell wrote:
Are the DSP calls liable to vary t_signal->s_n (block size) without
notification? 64 samples, apparently the default on pd-extended, is
doable without buffering for partitioned convolution on a modern
computer, but it exacts a pretty high CPU toll, and if
On Mon, 4 Apr 2011, Peter Plessas wrote:
This would be of interest for all Pd users, no matter if they like their
externals included in a distribution of Pd ('extended') or manuall
adding them to their vanilla Pd.
But pd-extended is not merely a bundling of externals.
For example, the [initb
On Mon, 4 Apr 2011, Seth Nickell wrote:
5) I'd love to build a granular convolution engine takes two
real-time signals, and extracts grains from one to convolve against the
other. Anyone have ideas about this?
What's the fundamental difference between this and a windowed FFT
convolution
Hi Seth,
On 5 Apr 2011, at 01:54, Seth Nickell wrote:
> I'm planning to release our realtime convolution engine (extracted
> from http://meatscience.net/pages/convolution-reverb) as a GPLed Pd
> external.
>
What is the advantage of this over Ben Saylor's [partconv~] external, which
provides
On Tue, 5 Apr 2011, Billy Stiltner wrote:
I remember there were lots of tricks that could be done with graphics
and integer math as well as binary bit twidling before math coprocessors
were in every machine. Look at fractint. Example of circle code seems
like I optimized this further but can't
I just looked and with 512 sample buffer Reason defaults to 15ms
latency output at 44.1k and 48k. at 96k it is 9ms output latency.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
>From a users standpoint here's my 2 cents.
I have 2 tunes that use Reason's FFT vocoder. In FFT mode it has 32
frequency bands.
The carrier input on these tunes are water recordings at 96k and the
modulator is drum beats of which samples were recorded at 44.1k.
I usually work in 48khz. So being ab
>> Also, since convolution is much more efficient around block sizes of
>> 256 or 512, perhaps I should default to one of these, buffer a little,
>> and have a "runatpdblocksize" message or somesuch?
>
> I still have not understood if/how the user can set the duration of the
> first partition of yo
Dear Seth,
Seth Nickell wrote:
Another question on similar lines...
Are the DSP calls liable to vary t_signal->s_n (block size) without
notification? 64 samples, apparently the default on pd-extended, is
doable without buffering for partitioned convolution on a modern
computer, but it exacts a
Another question on similar lines...
Are the DSP calls liable to vary t_signal->s_n (block size) without
notification? 64 samples, apparently the default on pd-extended, is
doable without buffering for partitioned convolution on a modern
computer, but it exacts a pretty high CPU toll, and if I hav
>> 2) Anyone have requests for features/api? Its currently simplistic:
>> - takes a "read FILENAME" message, loads the file, does a test
>> convolution against pink noise to normalize the gain to something sane
>
> Is this done within the main Pd audio thread?
The convolution engine has support
Seth Nickell wrote:
I'm planning to release our realtime convolution engine (extracted
from http://meatscience.net/pages/convolution-reverb) as a GPLed Pd
external.
This is a good idea!
It currently accepts 4-channel ('true stereo'), two channel or mono
impulse responses, with stereo or mono o
I'm planning to release our realtime convolution engine (extracted
from http://meatscience.net/pages/convolution-reverb) as a GPLed Pd
external.
It currently accepts 4-channel ('true stereo'), two channel or mono
impulse responses, with stereo or mono output. Performance is
excellent if you have S
32 matches
Mail list logo
