On 1/21/22 22:26, Christof Ressi wrote:
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').
Actually, you can commit changes to a submodule:
>
> we build the sources ourselves, as you have noted, it probably
> makes sense to keep them in our repo as well
>
[submodules] make problems when using 'git archive'
>
submodules do not allow for patching the vendored sources
>
Maybe it's the right use case for "git subtree"?
(see e.g
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
It's actually relatively easy, but very verbose since running configure then
runs the dependent lib configures as well. You just have to point the configure
script to the subdirectory with another configure script.
I have a couple projects which use autotools and rely on a couple custom
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
c, 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-requ...@lists.iem.at wrote:
Message: 2
Date: Fri, 21 Jan 2022 18:22:48 +0100
From: IOhannes m zm?lnig
To:pd-dev@lists.iem.at
Subject: Re: [PD-dev] Why not use portaudio per default?
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
t <mailto:pd-dev@lists.iem.at>
> Subject: Re: [PD-dev] Why not use portaudio per default?
> Message-ID: <mailto:c46ce9b3-908e-917d-0c56-a8f580c7a...@iem.at>>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
>
> On 1/21/22 14:5
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').
Actually, you can commit changes to a submodule:
https://stackoverflow.com/a/5542964/6063908. However, it's
On 21.01.22 18:00, IOhannes m zmölnig wrote:
my reference application is still audacity which on my system does not
set the JACK name (but then: i'm using audacity-2.4.2 which i understand
is not the latest and greatest)
I think Audacity should not be used as a reference application. Quoting
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
it happens at initialization time.
e.g. when i start "audacity".
there are no problems when i turn on DSP (or in audacity: when i start
playback)
That's interesting. I really never experienced/noticed this. If you have
time, check if this still happens with the latest portaudio release and
What about OSS? I understand that it's legacy, so maybe we can just
use the portaudio implementation?
i think the merit of OSS is that it allows to build Pd with *zero*
external dependencies and still have sound (and MIDI): no libalsa, no
libjack.
this is probably also the most
On 1/21/22 14:59, Christof Ressi wrote:
I'm not sure about ALSA. Here would should really compare and see if
there's a real showstopper in the portaudio implementation (that cannot
be easily patched).
my understanding is that the native ALSA implementation allows for the
lowest latencies
On 1/21/22 14:59, Christof Ressi wrote:
i never use portaudio, as it never really *worked* for me.
From what I read below, what you actually mean is: "I never use
portaudio's Jack implementation because it is too limited for my use
cases". I can't believe that portaudio never worked for
Thanks for your replies!
minor side-note: ESD is just a dummy.
the Enlightened Sound Daemon died some decade ago.
i'm not sure the Pd backend was ever used.
it should be removed.
Yes, this is what I got as well.
i never use portaudio, as it never really *worked* for me.
From what I read
On 21.01.22 09:34, Roman Haefeli wrote:
As IOhannes already mentioned, I find the aggressive probing annoying.
Audacity, for instance, doesn't even show up in JACK unless it is
playing. When the playing stops, it disappears again. That makes it
unnecessarily complicated to use except for the
Hi
I tend to side with IOhannes here. I find the flexibility of the
current JACK backend with the options -nojackconnect, -jackname,
-inchannels, -outchannels quite valuable. I don't know what portaudio
offers in comparison, but one would expect a general purpose audio API
covering a variety of
i'll start answering before reading your entire message, so...
On 1/21/22 02:58, Christof Ressi wrote:
Hi,
here's a question that has been bugging me for quite a while: Why do we
keep all those individual audio backends instead of just using portaudio
everywhere? Are there any other reasons
Hi,
here's a question that has been bugging me for quite a while: Why do we
keep all those individual audio backends instead of just using portaudio
everywhere? Are there any other reasons *besides* backwards
compatibility with existing setups (saved preferences)?
Currently we have the
20 matches
Mail list logo
