I've back-merged the portaudio update to version 0.53 (tried a week ago but messed it up, hopefully have it correct now). If I understand correctly this will fix the hang-on-macos-13 trouble but won't prevent people from checking callback which also can hang Pd on a Mac.
Meanwhile there's Christof's semaphor feature which promises to lower latency (I tried doing this earlier in s_audio_pa.c but found it actually increased latency; not sure what's going on here). The PR is here: https://github.com/pure-data/pure-data/pull/1756
I'm now thinking I should get multichannel inlet~/outlet~ finished first, then study and hopefully incorporate the semaphore PR after that's all working. Then that can be 0.54 (so that 0.53 can be limited to bug-fixing).
I wanna get the 0.53 bugfix out as soon as it's pretty sure that it actually fixes things...
cheers Miller
I just don't understand how you're gonna hide features and stuff already done to release a bugfix (0.53-2) without multichannel objects and support for it in [send~]/[throw~] for instance.
Em sáb., 4 de fev. de 2023 às 14:58, Miller Puckette via Pd-dev < pd-dev@lists.iem.at> escreveu:
I've back-merged the portaudio update to version 0.53 (tried a week ago but messed it up, hopefully have it correct now). If I understand correctly this will fix the hang-on-macos-13 trouble but won't prevent people from checking callback which also can hang Pd on a Mac.
Meanwhile there's Christof's semaphor feature which promises to lower latency (I tried doing this earlier in s_audio_pa.c but found it actually increased latency; not sure what's going on here). The PR is here: https://github.com/pure-data/pure-data/pull/1756
I'm now thinking I should get multichannel inlet~/outlet~ finished first, then study and hopefully incorporate the semaphore PR after that's all working. Then that can be 0.54 (so that 0.53 can be limited to bug-fixing).
I wanna get the 0.53 bugfix out as soon as it's pretty sure that it actually fixes things...
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I made a git branch off 0.53-1 and back-applied the portaudio update to it. None of the multichannel stuff (or anything else since that release) is part of it.
cheers M
On Sat, Feb 04, 2023 at 03:46:48PM -0300, Alexandre Torres Porres wrote:
I just don't understand how you're gonna hide features and stuff already done to release a bugfix (0.53-2) without multichannel objects and support for it in [send~]/[throw~] for instance.
Em sáb., 4 de fev. de 2023 às 14:58, Miller Puckette via Pd-dev < pd-dev@lists.iem.at> escreveu:
I've back-merged the portaudio update to version 0.53 (tried a week ago but messed it up, hopefully have it correct now). If I understand correctly this will fix the hang-on-macos-13 trouble but won't prevent people from checking callback which also can hang Pd on a Mac.
Meanwhile there's Christof's semaphor feature which promises to lower latency (I tried doing this earlier in s_audio_pa.c but found it actually increased latency; not sure what's going on here). The PR is here: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/1756...
I'm now thinking I should get multichannel inlet~/outlet~ finished first, then study and hopefully incorporate the semaphore PR after that's all working. Then that can be 0.54 (so that 0.53 can be limited to bug-fixing).
I wanna get the 0.53 bugfix out as soon as it's pretty sure that it actually fixes things...
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
ok, that makes sense, hahaha, cool, thanks
Em sáb., 4 de fev. de 2023 às 15:58, Miller Puckette msp@ucsd.edu escreveu:
I made a git branch off 0.53-1 and back-applied the portaudio update to it. None of the multichannel stuff (or anything else since that release) is part of it.
cheers M
On Sat, Feb 04, 2023 at 03:46:48PM -0300, Alexandre Torres Porres wrote:
I just don't understand how you're gonna hide features and stuff already done to release a bugfix (0.53-2) without multichannel objects and
support
for it in [send~]/[throw~] for instance.
Em sáb., 4 de fev. de 2023 às 14:58, Miller Puckette via Pd-dev < pd-dev@lists.iem.at> escreveu:
I've back-merged the portaudio update to version 0.53 (tried a week
ago but
messed it up, hopefully have it correct now). If I understand
correctly
this will fix the hang-on-macos-13 trouble but won't prevent people
from
checking callback which also can hang Pd on a Mac.
Meanwhile there's Christof's semaphor feature which promises to lower latency (I tried doing this earlier in s_audio_pa.c but found it actually
increased
latency; not sure what's going on here). The PR is here:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/1756...
I'm now thinking I should get multichannel inlet~/outlet~ finished
first,
then study and hopefully incorporate the semaphore PR after that's all working. Then that can be 0.54 (so that 0.53 can be limited to bug-fixing).
I wanna get the 0.53 bugfix out as soon as it's pretty sure that it actually fixes things...
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at
https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
On 2/4/23 19:58, Miller Puckette via Pd-dev wrote:
I made a git branch off 0.53-1 and back-applied the portaudio update to it.
just a quick note: the current `master` seems to not build on Windows/MinGW any longer. seems to be related to ASIO.
see https://git.iem.at/pd/pure-data/-/jobs/46362
the '0.53-2' branch¹ however seems to build fine. which is a bit weird...
on close inspection, it turns out that the portaudio/ directories in the '0.53-2' branch and the 'master' branch are indeed different. i don't know why and how they have been imported (presumably with the 'portaudio/update.sh' script, but the portaudio/portaudio/src/common/pa_gitrevision.h now shows 'unknown' which is not very helpful)
gfmdasd IOhannes
¹ shouldn't that branch be called '0.53' instead, as it is (hopefully) will contain the entire 0.53-x history?
Yep, I originally made a "0.53" branch but then messed it up so badly I had to start over - and thought it better to change the name to avoid confusion.
I'll check on the windows build at some point; it's compiling just fine here using mingw so it's probably something stupid. But will go mostly AWOL til Thursday.
cheers M On Sun, Feb 05, 2023 at 10:15:08PM +0100, IOhannes m zmölnig wrote:
On 2/4/23 19:58, Miller Puckette via Pd-dev wrote:
I made a git branch off 0.53-1 and back-applied the portaudio update to it.
just a quick note: the current `master` seems to not build on Windows/MinGW any longer. seems to be related to ASIO.
see https://git.iem.at/pd/pure-data/-/jobs/46362
the '0.53-2' branch¹ however seems to build fine. which is a bit weird...
on close inspection, it turns out that the portaudio/ directories in the '0.53-2' branch and the 'master' branch are indeed different. i don't know why and how they have been imported (presumably with the 'portaudio/update.sh' script, but the portaudio/portaudio/src/common/pa_gitrevision.h now shows 'unknown' which is not very helpful)
gfmdasd IOhannes
¹ shouldn't that branch be called '0.53' instead, as it is (hopefully) will contain the entire 0.53-x history?
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
it's compiling just fine here using mingw so it's probably something stupid.
Are you building with ASIO support?
./configure --enable-portaudio --enable-asio -> FAIL
./configure --enable-portaudio --disable-asio -> FAIL
./configure --disable-portaudio -> SUCCESS
Christof
On 05.02.2023 22:37, Miller Puckette via Pd-dev wrote:
Yep, I originally made a "0.53" branch but then messed it up so badly I had to start over - and thought it better to change the name to avoid confusion.
I'll check on the windows build at some point; it's compiling just fine here using mingw so it's probably something stupid. But will go mostly AWOL til Thursday.
cheers M On Sun, Feb 05, 2023 at 10:15:08PM +0100, IOhannes m zmölnig wrote:
On 2/4/23 19:58, Miller Puckette via Pd-dev wrote:
I made a git branch off 0.53-1 and back-applied the portaudio update to it.
just a quick note: the current `master` seems to not build on Windows/MinGW any longer. seems to be related to ASIO.
see https://git.iem.at/pd/pure-data/-/jobs/46362
the '0.53-2' branch¹ however seems to build fine. which is a bit weird...
on close inspection, it turns out that the portaudio/ directories in the '0.53-2' branch and the 'master' branch are indeed different. i don't know why and how they have been imported (presumably with the 'portaudio/update.sh' script, but the portaudio/portaudio/src/common/pa_gitrevision.h now shows 'unknown' which is not very helpful)
gfmdasd IOhannes
¹ shouldn't that branch be called '0.53' instead, as it is (hopefully) will contain the entire 0.53-x history?
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Also, I can confirm that the 0.52-2 branch (with ASIO/portaudio support) compiles just fine.
On 05.02.2023 22:56, Christof Ressi wrote:
it's compiling just fine here using mingw so it's probably something stupid.
Are you building with ASIO support?
./configure --enable-portaudio --enable-asio -> FAIL
./configure --enable-portaudio --disable-asio -> FAIL
./configure --disable-portaudio -> SUCCESS
Christof
On 05.02.2023 22:37, Miller Puckette via Pd-dev wrote:
Yep, I originally made a "0.53" branch but then messed it up so badly I had to start over - and thought it better to change the name to avoid confusion.
I'll check on the windows build at some point; it's compiling just fine here using mingw so it's probably something stupid. But will go mostly AWOL til Thursday.
cheers M On Sun, Feb 05, 2023 at 10:15:08PM +0100, IOhannes m zmölnig wrote:
On 2/4/23 19:58, Miller Puckette via Pd-dev wrote:
I made a git branch off 0.53-1 and back-applied the portaudio update to it.
just a quick note: the current `master` seems to not build on Windows/MinGW any longer. seems to be related to ASIO.
see https://git.iem.at/pd/pure-data/-/jobs/46362
the '0.53-2' branch¹ however seems to build fine. which is a bit weird...
on close inspection, it turns out that the portaudio/ directories in the '0.53-2' branch and the 'master' branch are indeed different. i don't know why and how they have been imported (presumably with the 'portaudio/update.sh' script, but the portaudio/portaudio/src/common/pa_gitrevision.h now shows 'unknown' which is not very helpful)
gfmdasd IOhannes
¹ shouldn't that branch be called '0.53' instead, as it is (hopefully) will contain the entire 0.53-x history?
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 2/6/23 00:38, IOhannes m zmölnig wrote:
On 2/5/23 22:56, Christof Ressi wrote:
it's compiling just fine here using mingw so it's probably something stupid.
Are you building with ASIO support?
yes, that's crucial. make sure you have ASIO extracted as asio/ASIO/
i've submitted a fix to the 'develop' branch.
it seems dan's import of portaudio was partially broken (keeping some outdated files).
hopefully my fix doesn't further complicate merging...
gfmdras IOhannes
On 2/5/23 22:37, Miller Puckette via Pd-dev wrote:
Yep, I originally made a "0.53" branch but then messed it up so badly I had to start over - and thought it better to change the name to avoid confusion.
i see. it seems like the "avoid confusion" did not utterly succeed though ;-)
in any case: while it is possible to have branches and tags use the same name, i think this is really going to be super-confusing, and should therefore be avoided.
e.g., i expect the 0.53-2 release to carry the "0.53-2" tag (just like the other releases), but it is somewhat unclear what i get when doing a "git checkout 0.53-2" (see PS).
i would therefore recommend to use some "namespace" for maintenance branches, e.g. "maintenance/0.53".
alternatively (and i like this better), is to just revert to your original name "<major>.<minor>" without the bugfix number (that is "0.53"). since Pd releases always have a bugfix number ("0.53-0") this shouldn't collide in practice.
as for "messing up beyond repair": in this case i would just fix the problems locally (abandoning the broken branch; starting anew with the nice name) and force-push and be done with it. (in general "force-pushing" is frowned upon, but it's there for a purpose, and i think this purpose is to fix messed up things)
mgfadsr IOhannes
PS: checking out with tags and branches...
usually, to checkout a release, you (well: I) do something like this:
``` $ git checkout 0.53-1 Note: switching to '0.53-1'. [...] HEAD is now at b2dcb6ce [...] ```
and when switching between branches: ``` $ git checkout 0.53 branch '0.53' set up to track 'origin/0.53'. Switched to a new branch '0.53' ```
but if there's both a branch and a tag with the same name, i get:
``` $ git checkout 0.53-2 warning: refname '0.53-2' is ambiguous. Switched to branch '0.53-2' Your branch is up to date with 'origin/0.53-2'. ```
*or*
``` $ git checkout 0.53-2 Note: switching to '0.53-2'. [...] HEAD is now at 12345678 [...] ```
the last example gets me the "0.53-2" tag, whereas the former example gives me the "0.53-2" branch. what i get depends on whether i have already a local branch. so a 'git checkout FOO' gives you: 1. the local branch 'FOO' 2. if that doesn't exist, the tag 'FOO' 3. if that doesn't exist, the remove branch 'FOO'
Meanwhile there's Christof's semaphor feature which promises to lower latency (I tried doing this earlier in s_audio_pa.c but found it actually increased latency; not sure what's going on here).
I guess you are talking about the THREADSIGNAL part (which has never been enabled, except for a very brief moment).
There are two major differences to my new implementation:
a) I use a semaphore instead of a condition variable to avoid unnecessary mutex locking.
b) The old THREADSIGNAL implementation would sleep on the condition variable as soon as the FIFO is empty/full. This would waste precious time that could be spent otherwise, in particular with larger hardware buffer sizes. In my implementation, on the other hand, I check the ringbuffer in a loop and only sleep on the semaphore when Pd is really idle, i.e. sched_idletask() has returned 0. See also https://github.com/pure-data/pure-data/pull/1756/commits/de8c62e0ce726634cba....
Christof
-
Alexandre Torres Porres -
Christof Ressi -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Miller Puckette