On 26.11.2021 17:52, IOhannes m zmölnig wrote:
Am 26. November 2021 17:39:09 MEZ schrieb Christof Ressi
<[email protected]>:
@christof Deken is prepared for that.
"vstplugin~[v0.5.3](Windows-amd64-32).dek". See the last -32 should be
-64 for double.
Ah, I didn't realize! That's cool! So that part is already solved :-)
This was actually my main concern.
Thanks lucarda for answering before me: yes, deken is not the problem. At least
the Pd side is not a problem at all. There might be issues with the deken
cmdline tool detecting the t_float size (the code is there, its just not much
tested...)
From my perspective the main problem is co-instability of externals of
multiple float sizes: currently if Pd loads an external with the wrong float
size, it will stop searching for another external (that might load the right
floatsize)
Yes! Also, they can't reside in the same folder. Both issues can be
easily solved with https://github.com/pure-data/pure-data/issues/902. Of
course, this still needs discussion.
However, these issues can be solved later. I kind of agree with Alex now
that there is nothing really standing in the way for releasing official
double precision builds. Or do you see any real showstoppers?
also I would actually like Pd to automatically bridge externals of the wrong
floatsize (doing an in place conversion to/from the external's floatsize)
I don't think this is realistic. You would have to provide wrappers for
every single struct and function in m_pd.h (and probably also in the
semi-private headers) that has a 't_float' or 't_floatarg'... It would
be a massive undertaking.
mfg.sfg.jfd
IOhannes
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
