Managed to get a double precision Pd working with PortAudio, after small modifications in s_audio_pa.c. <div><br></div><div>In function pa_open_audio(), *soundin and *soundout (pointers to type t_sample) used to be aliased to *pa_soundin resp. *pa_soundout, pointers to type float. If instead, *pa_soundin and *pa_soundout (and it's own aliases) are declared of type t_sample, the hard copying of samples from PortAudion arrays to Pd arrays and vice versa does the typecast between types of different sizes correctly (tested for Pd 0.42.6, I'll do it for 0.43 soon as possible).<br>
<br><div class="gmail_quote">Since I am not familiar with this part of Pd code, my proceedings are slow and I've not found the time to scan s_audio_jack.c, s_audio_alsa.c etcetera for similar issues. Yet, on the dsp side of things, I feel we're close to a properly functioning double precision Pd.<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
</blockquote></div><br></div><div>In the meantime I'd like to toss another topic of concern. While testing, I found that a single precision Pd can easily load double precision executables if they are present in the search path for some reason. The other way round will undoubtedly be possible as well - the C symbols in single and double precision builds are identical. Pd crashes on such a size mismatch. Some protection against the loading of 'type aliens' must be implemented before double precision Pd (and externals in particular) can be distributed as stable release, whenever that will happen. And this protection must preferably be backwards compatible, in such a way that old Pd installations from the 'single only era' can not accidentally load new double precision classes. </div>
<div><br></div><div><br></div><div>Katja</div>