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
Ah yes, I remember that issue now. I will leave the warnings in place for now.
> On Jan 21, 2022, at 8:42 PM, IOhannes m zmölnig wrote:
>
> Am 21. Jänner 2022 20:31:57 MEZ schrieb Dan Wilcox :
>>
>> Would it be safe to do a cast to (unsigned long)?
>>
>> sprintf(buf, ".x%lx", (unsigned
Am 21. Jänner 2022 20:31:57 MEZ schrieb Dan Wilcox :
>
>Would it be safe to do a cast to (unsigned long)?
>
>sprintf(buf, ".x%lx", (unsigned long)x);
no, because on LLP64 systems, an 'unsigned long' is only 32bit.
there relevant GitHub issue is
I'd like to fix a few warnings but I want to double check the cast.
The warnings come from creating object hex names from pointers. sys_vgui()
doesn't trigger this warning, but sprintf() does. For example:
../src/x_text.c:101:31: warning: format specifies type 'unsigned long' but the
argument
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
13 matches
Mail list logo
