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?
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 responsecheers
---------- 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