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@gmail.com> wrote:
2016-02-28 16:08 GMT-03:00 IOhannes m zmölnig <zmoelnig@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@fastmail.fm>
Date: 2014-09-26 22:20 GMT-03:00
Subject: Re: patconv~ bug
To: Alexandre Torres Porres <porres@gmail.com>, Hans-Christoph Steiner <hans@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@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list