Here's the deal, using such objects only make sense if converting to and back, right? I mean, at least for FFT that's the way it is, and I can't think of another example.
Oh, and let it be clear that only the phase value is coming out wrong (negative when it should be positive). And that is by using [cartopol~], of course.
Anyway, for any kind of spectral processing and stuff, it doesn't really matter if the phase is positive or negative. In other words, it sounds the same wether the phase value is theoretically correct or not. But this is only true if the backwards conversion with [poltocar~] is equally "incorrect".
This is an example where two wrongs make it right. And they were both wrong, but working. On the other hand, [cartopol] and [poltocar] where always correct, by the way.
So the issue was just that if you wanted plot or print the phase from [cartopol~] you get a wrong value. Not that much of a big deal. But it would hurt to make the audio objects rights like the data versions.
Now get ready for the ultimate issue. I had complained about all this way way long ago. And when Pd Extended 0.43 came out, apparently, something was done about it, but only one of the objects where changed (I guess [cartopol~]).
What doesn it mean? As of then, NONE of the spectral processing do work at all! Cause when [poltocar~] converts it back. It's just wrong.
In other words, it was better before, when two wrongs made it right.
> How many now working patches will break when the object
> behaviour changes? A workaround could be to create new> objects, e.g. cartopol2~ and poltocart2~ with the correct behaviour.
So, it was an honest concern. But the bottom line of what I'm telling you is: Nothing will break if this is corrected, and, actually, my patches using cartopol and poltocar are all broken in Pd Extended 0.43
So the only reasonable thing to do right now is just fix it as it is supposed to be. What do you say?
Can you follow all that I'm saying? I hope I was clear. Let me know if you need more details.
Thanks