I'm trying to do this "sound mass" type thing involving a large number of independent events triggered at random intervals. The problem is that for very high event density, it starts to have an audibly crappy sound (like bitcrushed noise) due to messages being sent at intervals of 64 samples.

I'd thought they were sent between audio blocks. Setting block size to larger than 64 samples does change the spacing between messages, but smaller block sizes don't seem to make a difference. The intervals don't get smaller than 64 samples. Is this just the way Pd schedules things?

Is there any way to send messages on a per sample basis (aside from maybe 64x oversampling)? I don't care about efficiency since I'm rendering this to a file.

I'm using the [delay] object to send "set" messages to biquads, if that makes any difference. Would something like [t3_delay] be a better idea?

The issue might be the [biquad~]s, not the messages. [delay] can definitely work accurately at intervals lower than the block size. Some audio objects, however, just won't update between blocks. [biquad~] might be one of them.

I checked a patch that I had made previously using [delay] and [line~] objects for a similar purpose, and it seemed to have the same problem.

I found an adequate, if not entirely ideal workaround that doesn't use [block~] or [switch~] to change the block size. I used [t3_delay] to generate a 1-sample duration impulse with a random delay between 0 and 63 samples. It's not perfect since it's still updating the [biquad~] coefficients at 64 sample intervals (this can produce its own transients), but I think think any remaining artifacts shouldn't be as intrusive.

As an alternative, you could use one of the biquad abstractions I posted here:

http://puredata.hurleur.com/viewtopic.php?pid=22929#p22929

I just updated [biquadm.mmb~] to use [vline~] instead of [line~] for the interpolation. So if you send an [interp 0( message to it, it should update between block boundaries. Of course, if you want to avoid transients, you probably should have some interpolation.

I'd love to see that patch. It's right in my zone of interest...

I ended up sticking a "clear" message in there before updating the coefficients, since I found the transients caused by the new coefficients were sometimes orders of magnitude larger than the actual impulses (I probably should have seen that coming...), but I'm otherwise satisfied with the result.

I'll definitely check out the interpolated biquads though, I've really been needing them for a variety of purposes.

Also, I'll share the patch if you want, but I don't think it's anything spectacular. I'm going to record 8 tracks total and then subject it to copious mixing and additional processing. It's a little irritating on its own.

Here's the patch, if anyone's still interested. The .zip file includes all abstractions I used. You'll also need [t3_del] and [t3_sig~] from iemlib. I recorded 8 tracks of this, filtered the results and put them through FDN resonators and my own reverb algorithm.

Here's the final recording: http://www.mediafire.com/?8bgnw2xko784y7d

http://www.pdpatchrepo.info/hurleur/Pd_rdens.zip

@acreil said:

Here's the final recording: http://www.mediafire.com/?8bgnw2xko784y7d

Thanks, that sounds great, will definitely study your patch.

@acreil said:

Here's the patch, if anyone's still interested. The .zip file includes all abstractions I used. You'll also need [t3_del] and [t3_sig~] from iemlib. I recorded 8 tracks of this, filtered the results and put them through FDN resonators and my own reverb algorithm.

Here's the final recording: http://www.mediafire.com/?8bgnw2xko784y7d

First of all, thanks for sharing it. The recording is really interesting.
Loading your patch I got lots of:

t3_del 0
... couldn't create

For some reasons, I discovered that in my Pd extended (0.42.5 on Windows), the "t3_del" from IemLib is called "t3_delay.dll" (anyone else?).
Replacing all:

t3_del -> t3_delay

in rdens.pd is making your patch working.

@acreil said:

I recorded 8 tracks of this, filtered the results and put them through FDN resonators and my own reverb algorithm.

Here's the final recording: http://www.mediafire.com/?8bgnw2xko784y7d

For understanding: is the sound engine a "battery" of 8x8 (or 16x16?) biquad-filtered pulses, generated with t3_sig~, each pulse randomly delayed
according to a Poisson distribution? That's very interesting.. :-O
After getting the separated recordings, did you mixed everything outside pd (in a DAW) or within it?

Cheers,
ALberto

@AlbertoZ said:

For some reasons, I discovered that in my Pd extended (0.42.5 on Windows), the "t3_del" from IemLib is called "t3_delay.dll" (anyone else?).
Replacing all:

t3_del -> t3_delay

in rdens.pd is making your patch working.

I think you can make a [t3_delay] in a blank patch before opening mine and it will work. They use [t3_del] in the help patches. I've had similar trouble with other IEM stuff.

@AlbertoZ said:

For understanding: is the sound engine a "battery" of 8x8 (or 16x16?) biquad-filtered pulses, generated with t3_sig~, each pulse randomly delayed
according to a Poisson distribution? That's very interesting.. :-O
After getting the separated recordings, did you mixed everything outside pd (in a DAW) or within it?

[t3_sig~] is just to send the trigger impulse at sub-block intervals, since I couldn't manage to get that with the set message. It sounds terrible if they're all quantized to 64 samples. So [t3_delay] shifts the impulse by 0 to 63 samples. It's just a kludge.

Anyway the impulses to the filters are triggered by Poisson events. The filter frequencies and q are normal distribution and vary smoothly over time.

All I did outside pd is filter it (since the patch's output has a "white" spectrum), adjust the level of each track over time to highlight the better sounding parts, and then the final mixdown. Otherwise all the important stuff is pd.