[PD] s~ & r~ with block size other than 64?

[Matt Barber]

Just to confirm, this bug is only on patch load, right? Does it only happen
when it's loading a table stored in a patch, or does it do the same if the
table is loaded via soundfiler it generated algorithmically?

Is this fixable in partconv~ or is it a consequence of the design of the
patch load sequence?
On Feb 28, 2016 4:57 PM, "Alexandre Torres Porres" <porres at gmail.com> wrote:

> 2016-02-28 16:08 GMT-03:00 IOhannes m zmölnig <zmoelnig at iem.at>:
>
>> On 02/27/2016 10:33 PM, Alexandre Torres Porres wrote:
>> > by the way, partconv~ is buggy, we should fix it... I emailed bsaylor a
>> > couple of years ago and he said he didnt have time for it
>>
>> what's that bug?
>> has it been reported in some public place? why not?
>>
>
>
> I contacted ben saylor in private in 2014, thing is that it needs to
> receive a set message, otherwise it wont work with the specified array
> given as first argument.
>
> here's the response
> cheers
>
>
> ---------- Forwarded message ----------
> From: Ben Saylor <bensaylor at fastmail.fm>
> Date: 2014-09-26 22:20 GMT-03:00
> Subject: Re: patconv~ bug
> To: Alexandre Torres Porres <porres at gmail.com>, Hans-Christoph Steiner <
> hans at at.or.at>
>
>
> Hi Alexandre,
>
> I'm aware of the issue but don't have time to fix it myself,
> unfortunately. Here's an explanation I wrote to someone else, and a
> workaround.
>
> I think the reason the seemingly redundant "set" is required is that
>> the table is empty when the patch is loaded, and so when partconv~ is
>> created it initializes with an empty array. Because of the
>> computation involved in preparing the impulse response, it only does
>> it on creation and when sent a "set" message. The workaround is to
>> populate the table with a loadbang - then, if the table doesn't
>> change, you don't need a set message.
>>
>> One of these days, I will have to make partconv~ handle these kinds
>> of things better and not crash.
>>
>
> All the best,
> Ben
>
>
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160228/7cf8e396/attachment-0001.html>