I agree with IOhannes in that it's an advantage to keep all of the sources together. Besides, we also only include those portaudio sources we actually need and build them manually, ie. as a static convince lib via autotools etc. When I helped with overhauling the autotools build some years ago, I kept that aspect as an expedient, but I think it's still a good practice in that Github, at the time, didn't actually check out the sources for submodules when downloading a zip or tarball via the online interface. I haven't checked, but this may have changed. In any case, best practice would be to general release tarballs using "make dist" but we currently don't do that, as far as I can tell.
Also, Github isn't the only public git host around and even though it's been quite useful for us, we should be relatively flexible to move hosting whenever we need or want to. Being reliant on submodules for core dependencies makes this a little more brittle.
I also agree with Christof that since portaudio development is much more active than it use to be, we should consider integrating newer stable versions as they come out. Note that I added update scripts which pull in the relevant portaudio or portmidi sources to automate this, ala:
https://github.com/pure-data/pure-data/blob/master/portaudio/update.sh https://github.com/pure-data/pure-data/blob/master/portaudio/update.sh
Note: We have integrated some custom patches for portmidi, ie. speed limiting etc, so it's a little more problematic to replace it as a submodule right now.
On Jan 21, 2022, at 8:53 PM, pd-dev-request@lists.iem.at wrote:
Message: 2 Date: Fri, 21 Jan 2022 18:22:48 +0100 From: IOhannes m zm?lnig <zmoelnig@iem.at mailto:zmoelnig@iem.at> To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at Subject: Re: [PD-dev] Why not use portaudio per default? Message-ID: <c46ce9b3-908e-917d-0c56-a8f580c7ab10@iem.at mailto:c46ce9b3-908e-917d-0c56-a8f580c7ab10@iem.at> Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 1/21/22 14:59, Christof Ressi wrote:
What about my proposition to include portaudio as a submodule
in general i do not like git submodules.
first of all they make problems when using 'git archive' to generate a source tarball (e.g. when you create a 'git tag', GitHub offers you a "Source Code" download which is created with this method). this is often a problem for downstream packagers (e.g. for the Debian packages) where crucial parts are missing from the source tarballs. in the specific case of portaudio i don?t really mind, as in Debian we are using the system-provided PortAudio (and explicitely do *not* use the vendored version).
2nd, submodules do not allow for patching the vendored sources (e.g. we *could* remove the annoying printout at Pa_Initialize() in our vendored copy, but not with 'git submodule'). otoh, we haven't really used this in the past, so we probably don't need this anyhow.
so i really do not care. what i do care about is that the portaudio backend implementation of Pd remains (API-)compatible with released stable versions of PortAudio (and ideally (API-)compatible with the version of portaudio shipped in major linux distributions, esp. Debian)
now that it's officially on GitHub?
this i don't really understand. what makes GitHub different from BitBucket, GitLab, SourceForge or git.jackaudio.org http://git.jackaudio.org/ with respect to 'git submodule's?
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Also, I would be happy to see integrating more modern backends for Windows, ala the portaudio waspi implementation. We don't build it for now as I only kept the those APIs which we were building at the time when we did the autotools overhaul. Just modify the portaudiuo/update.sh script to include those .c files for the additional implementations and add them to portaudio/Makefile.am.
Also, since the portaudio configure script was very old and delicate, especially on macOS, we opted to build portaudio and portmidi as convenience libs ourselves. This may have improved on the portaudio side, but I ran into many problems with the portaudio configure failing while building the c files directly worked.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Also, I would be happy to see integrating more modern backends for Windows, ala the portaudio waspi implementation.
Yes, I already mentioned this.
Note that WASAPI is only supported on Windows Vista and above. I think it's fair to require at least Windows 7 for the 64-bit Windows builds. The 32-bit builds can stay at Windows XP (without WASAPI support).
Christof
Just my 2 cents as a not-pd-dev (sorry). Given that PD is mostly conceived as a real-time enviroment, and all the non ASIO and most of all MME, MMIO stuff on Windows is pretty distant from the real life concept of real time due to latencies that mostly need to stay at minimum average of 10ms on the average Win based systems, i'd take away all the "useless" stuffas indeed all the MMIO drivers. WASAPI is the modern standard for Windows systems and btw it's still not on par with ASIO. In their recent versions it seems that Jack (and its Jackrouter ASIO "skin") and PortAudio are pretty stable on Windows. This one seems very interesting to in the ASIO department https://www.un4seen.com/
bests
Alfonso Santimone soundcloud.com/alfonsosantimone www.elgallorojorecords.bandcamp.com/ https://elgallorojorecords.bandcamp.com/ www.facebook.com/alfonsosantimone
On Sat, Jan 22, 2022 at 7:01 PM Christof Ressi info@christofressi.com wrote:
Also, I would be happy to see integrating more modern backends for Windows, ala the portaudio waspi implementation.
Yes, I already mentioned this.
Note that WASAPI is only supported on Windows Vista and above. I think it's fair to require at least Windows 7 for the 64-bit Windows builds. The 32-bit builds can stay at Windows XP (without WASAPI support).
Christof
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Also, Github isn't the only public git host around and even though it's been quite useful for us, we should be relatively flexible to move hosting whenever we need or want to. Being reliant on submodules for core dependencies makes this a little more brittle.
submodules is actually a Git feature.
Note that I added update scripts which pull in the relevant portaudio or portmidi sources to automate this, ala:
Ah, never noticed this. Nice.
Since we build the sources ourselves, as you have noted, it probably makes sense to keep them in our repo as well. I don't even know how to properly integrate an automake project...
On 22.01.2022 17:41, Dan Wilcox wrote:
I agree with IOhannes in that it's an advantage to keep all of the sources together. Besides, we also only include those portaudio sources we actually need and build them manually, ie. as a static convince lib via autotools etc. When I helped with overhauling the autotools build some years ago, I kept that aspect as an expedient, but I think it's still a good practice in that Github, at the time, didn't actually check out the sources for submodules when downloading a zip or tarball via the online interface. I haven't checked, but this may have changed. In any case, best practice would be to general release tarballs using "make dist" but we currently don't do that, as far as I can tell.
Also, Github isn't the only public git host around and even though it's been quite useful for us, we should be relatively flexible to move hosting whenever we need or want to. Being reliant on submodules for core dependencies makes this a little more brittle.
I also agree with Christof that since portaudio development is much more active than it use to be, we should consider integrating newer stable versions as they come out. Note that I added update scripts which pull in the relevant portaudio or portmidi sources to automate this, ala:
https://github.com/pure-data/pure-data/blob/master/portaudio/update.sh
Note: We have integrated some custom patches for portmidi, ie. speed limiting etc, so it's a little more problematic to replace it as a submodule right now.
On Jan 21, 2022, at 8:53 PM, pd-dev-request@lists.iem.at wrote:
Message: 2 Date: Fri, 21 Jan 2022 18:22:48 +0100 From: IOhannes m zm?lnig zmoelnig@iem.at To:pd-dev@lists.iem.at Subject: Re: [PD-dev] Why not use portaudio per default? Message-ID: c46ce9b3-908e-917d-0c56-a8f580c7ab10@iem.at Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 1/21/22 14:59, Christof Ressi wrote:
What about my proposition to include portaudio as a submodule
in general i do not like git submodules.
first of all they make problems when using 'git archive' to generate a source tarball (e.g. when you create a 'git tag', GitHub offers you a "Source Code" download which is created with this method). this is often a problem for downstream packagers (e.g. for the Debian packages) where crucial parts are missing from the source tarballs. in the specific case of portaudio i don?t really mind, as in Debian we are using the system-provided PortAudio (and explicitely do *not* use the vendored version).
2nd, submodules do not allow for patching the vendored sources (e.g. we *could* remove the annoying printout at Pa_Initialize() in our vendored copy, but not with 'git submodule'). otoh, we haven't really used this in the past, so we probably don't need this anyhow.
so i really do not care. what i do care about is that the portaudio backend implementation of Pd remains (API-)compatible with released stable versions of PortAudio (and ideally (API-)compatible with the version of portaudio shipped in major linux distributions, esp. Debian)
now that it's officially on GitHub?
this i don't really understand. what makes GitHub different from BitBucket, GitLab, SourceForge orgit.jackaudio.org http://git.jackaudio.org/with respect to 'git submodule's?
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
-
alfonso santimone -
Christof Ressi -
Dan Wilcox