You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(21) |
Oct
(24) |
Nov
(11) |
Dec
(18) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(6) |
Feb
(4) |
Mar
(37) |
Apr
(12) |
May
(17) |
Jun
(17) |
Jul
(8) |
Aug
(5) |
Sep
(29) |
Oct
(18) |
Nov
(22) |
Dec
(41) |
2002 |
Jan
(31) |
Feb
(42) |
Mar
(41) |
Apr
(34) |
May
(12) |
Jun
(25) |
Jul
(23) |
Aug
(10) |
Sep
(20) |
Oct
(15) |
Nov
(25) |
Dec
(16) |
2003 |
Jan
(56) |
Feb
(30) |
Mar
(33) |
Apr
(13) |
May
(21) |
Jun
(6) |
Jul
(15) |
Aug
(6) |
Sep
(6) |
Oct
(14) |
Nov
(2) |
Dec
(15) |
2004 |
Jan
(28) |
Feb
(19) |
Mar
(7) |
Apr
(10) |
May
(9) |
Jun
(12) |
Jul
(15) |
Aug
(62) |
Sep
(45) |
Oct
(50) |
Nov
(45) |
Dec
(36) |
2005 |
Jan
(18) |
Feb
(17) |
Mar
(20) |
Apr
(18) |
May
(16) |
Jun
(15) |
Jul
(27) |
Aug
(27) |
Sep
(42) |
Oct
(24) |
Nov
(32) |
Dec
(21) |
2006 |
Jan
(22) |
Feb
(32) |
Mar
(32) |
Apr
(24) |
May
(18) |
Jun
(33) |
Jul
(8) |
Aug
(33) |
Sep
(22) |
Oct
(31) |
Nov
(33) |
Dec
(26) |
2007 |
Jan
(17) |
Feb
(55) |
Mar
(30) |
Apr
(10) |
May
(36) |
Jun
(33) |
Jul
(20) |
Aug
(12) |
Sep
(96) |
Oct
(27) |
Nov
(40) |
Dec
(31) |
2008 |
Jan
(71) |
Feb
(45) |
Mar
(61) |
Apr
(6) |
May
(18) |
Jun
(17) |
Jul
(14) |
Aug
(66) |
Sep
(49) |
Oct
(92) |
Nov
(57) |
Dec
(68) |
2009 |
Jan
(68) |
Feb
(52) |
Mar
(56) |
Apr
(65) |
May
(58) |
Jun
(38) |
Jul
(24) |
Aug
(75) |
Sep
(41) |
Oct
(98) |
Nov
(55) |
Dec
(107) |
2010 |
Jan
(66) |
Feb
(64) |
Mar
(45) |
Apr
(32) |
May
(90) |
Jun
(53) |
Jul
(39) |
Aug
(51) |
Sep
(102) |
Oct
(31) |
Nov
(30) |
Dec
(32) |
2011 |
Jan
(26) |
Feb
(65) |
Mar
(69) |
Apr
(35) |
May
(116) |
Jun
(23) |
Jul
(24) |
Aug
(32) |
Sep
(95) |
Oct
(60) |
Nov
(95) |
Dec
(89) |
2012 |
Jan
(139) |
Feb
(75) |
Mar
(88) |
Apr
(46) |
May
(58) |
Jun
(51) |
Jul
(95) |
Aug
(24) |
Sep
(33) |
Oct
(12) |
Nov
(18) |
Dec
(45) |
2013 |
Jan
(84) |
Feb
(56) |
Mar
(54) |
Apr
(24) |
May
(20) |
Jun
(16) |
Jul
(51) |
Aug
(75) |
Sep
(41) |
Oct
(45) |
Nov
(96) |
Dec
(38) |
2014 |
Jan
(42) |
Feb
(33) |
Mar
(47) |
Apr
(9) |
May
(50) |
Jun
(24) |
Jul
(17) |
Aug
(4) |
Sep
(10) |
Oct
(41) |
Nov
(20) |
Dec
(64) |
2015 |
Jan
(41) |
Feb
(43) |
Mar
(20) |
Apr
(14) |
May
(44) |
Jun
(34) |
Jul
(55) |
Aug
(20) |
Sep
(9) |
Oct
(10) |
Nov
(6) |
Dec
(40) |
2016 |
Jan
(17) |
Feb
(31) |
Mar
(27) |
Apr
|
May
(2) |
Jun
(19) |
Jul
(7) |
Aug
(27) |
Sep
(79) |
Oct
(4) |
Nov
(14) |
Dec
(146) |
2017 |
Jan
(7) |
Feb
(6) |
Mar
(14) |
Apr
(5) |
May
(7) |
Jun
(49) |
Jul
(27) |
Aug
(27) |
Sep
(28) |
Oct
(28) |
Nov
(26) |
Dec
(9) |
2018 |
Jan
|
Feb
(5) |
Mar
(6) |
Apr
(11) |
May
(9) |
Jun
(5) |
Jul
(14) |
Aug
(1) |
Sep
(13) |
Oct
(2) |
Nov
(3) |
Dec
(5) |
2019 |
Jan
(8) |
Feb
(8) |
Mar
(2) |
Apr
(1) |
May
(4) |
Jun
(1) |
Jul
(3) |
Aug
(6) |
Sep
|
Oct
(13) |
Nov
(4) |
Dec
(29) |
2020 |
Jan
(3) |
Feb
|
Mar
(12) |
Apr
(8) |
May
(36) |
Jun
(26) |
Jul
(27) |
Aug
(30) |
Sep
(2) |
Oct
|
Nov
(12) |
Dec
(2) |
2021 |
Jan
(4) |
Feb
(9) |
Mar
(4) |
Apr
(18) |
May
(21) |
Jun
(19) |
Jul
(5) |
Aug
(1) |
Sep
|
Oct
(16) |
Nov
(4) |
Dec
(2) |
2022 |
Jan
(5) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
(2) |
Sep
(3) |
Oct
|
Nov
(5) |
Dec
|
2023 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
|
May
(16) |
Jun
(1) |
Jul
|
Aug
|
Sep
(3) |
Oct
(7) |
Nov
(3) |
Dec
(2) |
2024 |
Jan
(9) |
Feb
|
Mar
(3) |
Apr
(14) |
May
(38) |
Jun
(15) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jan S. <ha...@st...> - 2024-07-17 12:16:21
|
On Jul 12 21:16:41, and...@gm... wrote: > I installed SoX from homebrew and it has been working fine > with my Electron app. > I am on Mac M1. > > However, when I switched Why? > to the Mac SoX binary I downloaded from SourceForge, Those are from 2014. I suppose HomeBrew gives you a much more recent version of SoX. > SoX cannot find my coreaudio devices. Meaning what? What command have you run, and what exactly did "sox -V ..." say? Please note that the notoriously underdocummented macos audio system has changed in many ways since the static mac binary of sox was released. > Is there an additional step I need or additional libs I need to include > with SoX to use it as part of an application vs calling the brew-installed > version? Using sox "as a part of an application" can be two things: 1. calling the "sox" binary, in which case th application (probably Electron in your case, whatevere that is) needs to find it. A typical place is /usr/local/bin/sox, nto sure where homebrew installs. The separate binary you downloaded is wherever you put it. 2. using the SoX library, typicaly /usr/local/lib/libsox.so.* I don't think this gets installed with the separate mac binary. Jan |
From: Andre L. <and...@gm...> - 2024-07-13 01:17:04
|
Hi, I installed SoX from homebrew and it has been working fine with my Electron app. I am on Mac M1. However, when I switched to the Mac SoX binary I downloaded from SourceForge, SoX cannot find my coreaudio devices. Is there an additional step I need or additional libs I need to include with SoX to use it as part of an application vs calling the brew-installed version? Thanks! Andre |
From: Jan S. <ha...@st...> - 2024-06-17 13:14:45
|
Thanks for the reports so far (mostly off-list). On top of that build branch, here is a branch that builds _and_documents_ libsox, i.e. brings libsox(3) to sync with reality, after many many years. https://github.com/janstary/sox/tree/libsox https://github.com/janstary/sox/issues/43 https://github.com/janstary/sox/issues/49 See the git log for more lolz: /** Client API: Signed twos-complement 8-bit type. Typically defined as signed char. */ typedef int8_t sox_int8_t; Please test everywhere and let me know if it works for you. (Let's see if anyone uses libsox at all.) Jan On Jun 10 20:21:58, ha...@st... wrote: > Dear fellow users of SoX, > > I would like to kindly ask you to test a build system for SoX: > the 'build' branch at https://github.com/janstary/sox/tree/build > > On the surface it is the same: ./configure && make (see INSTALL). > On the inside, it is a complete overhaul. > > Branching from Mans's latest commit (the spectrogram fix), > it consists of about 100 commits, should you want to read > the whole story; here is the gist of it. > > It replaces the GNU auto* system with a simple, hand-written > ./configure script, a straightforward Makefile, and a set of > have-*.c micro-programs testing the availability of libraries. > It "borrows" heavily (in fact, steals with love) from > Ingo Schwarze's build system for the mandoc package. > > This has no dependency on anything besides sh(1) and cc(1). > The main point is to get rid of the GNU autotools monster: > Do we have strlen()? Can <stdint.h> be included? What of "gcc -v"? > POSIX.1 came out more than fifteen years ago; all modern systems > are close to that and we should be coding against that standard. > > Functionaly, this system detects the optional external formats > and audio drivers the current autotools system tries to detect, > but correctly, much faster, using elementary tools, > and actualy respecting the results. > > The single exception is waveaudio, as I have no windows machine. > > A big change in the resulting build is this no longer builds > or install libsox the library, as opposed to sox the binary. > SoX itself seems to be the only user of that library. > Looking into the entire collection of ports and packages > of all the system below, I have found _two_ things using it. > (Not to be confused with libsoxr, the resampling library > extracted from sox by Rob Sykes, maintainer at the time.) > Details in https://github.com/janstary/sox/issues/43 > > Another change is the dynamic loading of libraries with dlopen(), > which I have completely dropped. Either have the library at build > and link against it, or don't, like everyone else. (But libltdl > is not completely gone, because the ladspa plugins need it.) > > Like gsm some years ago, the lpc codec is made an optional, > external dependecy, as opposed the carrying a copy of its > entire implementation. If you care about LPC as a format, > look at https://github.com/janstary/lpc for a separate lib; > note that the original LPC code (as opposed to the bundled subdir) > has just been made available, upon asking, by the original author: > https://github.com/jafingerhut/lpc10 > > While here, I have also done some cleaning, but nothing that > would change SoX's actual audio behaviour. I have removed > struct timeb, obsoleted ages ago and not even used here, > the homegrown strcasecmp(), #ifdef HAVE_STDINT_H and > other ancient cruft. See the git log for the lolz. > > I have been running and testing this for some time on > > OpenBSD/current (amd64, i386, arm64, armv7, powerpc, octeon) > FreeBSD 14.1 (amd64) > NetBSD 10.0 (amd64) > macOS 14.5 (M1 MacBook Air) > Debian 13.2 trixie (amd64) > Solaris (SunOS 5.11) > > and everything I could test seems to work. That is to say, > the build of sox and the detection of external libs as > optional extra formats and drivers works; the actual > audio signal processing code, which has its own problems, > has not been touched. > > During all that, going through the individual formats, > I have also reviewed the soxi(1) and soxformat(7) manpages, > untouched for a decade, and synced them with reality, > refactoring a bit, and rewriting in mdoc(7) not man(7). > Please read them. (The monstrous sox(1) is for later.) > > Please test on every system you use SoX on. Please test > the detection of every audio format and effect and driver > you care about (or, better yet, test them all). If anything > doesn't work as expected, please report here or open an issue: > https://github.com/janstary/sox/issues > > Thank you, > > Jan > > > > _______________________________________________ > Sox-users mailing list > Sox...@li... > https://lists.sourceforge.net/lists/listinfo/sox-users > |
From: Jan S. <ha...@st...> - 2024-06-12 07:17:28
|
On Jun 12 08:28:56, ha...@st... wrote: > Hello David, > > On Jun 11 21:19:07, D.C...@ut... wrote: > > Hi all, > > > > You may recall a thread a while back (Recording Specific Channels). I had to drop it at the time, but I’m digging in again. The last suggestion was to update to a more recent version, which I’ve tried, but now I’m just as confused. > > > > > > * I asked our tech staff to an install of a more recent version. He said got a number of errors, but wasn’t specific. I dropped it. > > * After getting the email from Jan, Call for Testers, I had them prepare an install that version. > > * They were able to do it (and they use a self-service install program, a protocol I more or less have to follow). > > * Using their self-service I installed it on my laptop and a machine at school. That worked, but when I run it (simply type “sox”) the top line still says SoX 14.4.2. That’s the same version as I was using, “nine years old.” > > if you installed the version from > https://github.com/janstary/sox/tree/build > then that's as recent as yesterday. > > The string "14.4.2" only means I didn't bother to change it > as this effort of mine is still pretty far from a release. > > With this change: > > > diff --git a/sox.h b/sox.h > index 0642261b..ccea9ccd 100644 > --- a/sox.h > +++ b/sox.h > @@ -264,7 +264,7 @@ The API version of the sox.h file. It is not meant to follow the version > number of SoX but it has historically. Please do not count on > SOX_LIB_VERSION_CODE staying in sync with the libSoX version. > */ > -#define SOX_LIB_VERSION_CODE SOX_LIB_VERSION(14, 4, 2) > +#define SOX_LIB_VERSION_CODE SOX_LIB_VERSION(15, 0, 0) > > /** > Client API: > > > > SoX will present itself as "15.0.0" but will be the same. > It's just a number, a nametag you can change. > > > If you installed from https://git.code.sf.net/p/sox/code > which is the official master branch (which I am working on top of), > you will get code as of 2024-05-30, the latest commit there. And it will also say "14.4.2". It's just a number. Jan |
From: Jan S. <ha...@st...> - 2024-06-12 06:29:10
|
Hello David, On Jun 11 21:19:07, D.C...@ut... wrote: > Hi all, > > You may recall a thread a while back (Recording Specific Channels). I had to drop it at the time, but I’m digging in again. The last suggestion was to update to a more recent version, which I’ve tried, but now I’m just as confused. > > > * I asked our tech staff to an install of a more recent version. He said got a number of errors, but wasn’t specific. I dropped it. > * After getting the email from Jan, Call for Testers, I had them prepare an install that version. > * They were able to do it (and they use a self-service install program, a protocol I more or less have to follow). > * Using their self-service I installed it on my laptop and a machine at school. That worked, but when I run it (simply type “sox”) the top line still says SoX 14.4.2. That’s the same version as I was using, “nine years old.” if you installed the version from https://github.com/janstary/sox/tree/build then that's as recent as yesterday. The string "14.4.2" only means I didn't bother to change it as this effort of mine is still pretty far from a release. With this change: diff --git a/sox.h b/sox.h index 0642261b..ccea9ccd 100644 --- a/sox.h +++ b/sox.h @@ -264,7 +264,7 @@ The API version of the sox.h file. It is not meant to follow the version number of SoX but it has historically. Please do not count on SOX_LIB_VERSION_CODE staying in sync with the libSoX version. */ -#define SOX_LIB_VERSION_CODE SOX_LIB_VERSION(14, 4, 2) +#define SOX_LIB_VERSION_CODE SOX_LIB_VERSION(15, 0, 0) /** Client API: SoX will present itself as "15.0.0" but will be the same. It's just a number, a nametag you can change. If you installed from https://git.code.sf.net/p/sox/code which is the official master branch (which I am working on top of), you will get code as of 2024-05-30, the latest commit there. > I follow this link<https://sourceforge.net/projects/sox/> > which says last update is 2024-06-04. If you click on that, you will see that's when I posted a comment announcing my branch. That comment is the "update" SF is talking about, not any new code. > I downloaded that file, uncompressed, > at it also says sox-14.4.2, Feb 22, 2015. That means you downloaded the latest release. There is no newer one, because SoX is not being properly maintained. Downstream packagers and end users have been mainly using the git repo recently, tired of waiting for another release. For example, OpenBSD builds it audio/sox package http://cvsweb.openbsd.org/ports/audio/sox/Makefile on top of a commit of 2021-05-09 so that's what you get when you 'pkg_add sox' on OpenBSD. Your OS might do something similar, so you might noit need to do this yourself. Do I remember right you are on macOS? macOS itself has no infrastructure for packaging third-party software (as do the BSDs and Linuxes), but there is MacPorts, and they have a version of SoX https://www.macports.org/ https://github.com/macports/macports-ports/tree/master/audio/sox - but that's apparantly just a slight tweak of 14.4.2. That being said, it is not very hard to build from source. > So now I’m confused. Where can I get a more recent copy? https://git.code.sf.net/p/sox/code holds the latest code in the "official" branch of SoX at SourceForge. https://github.com/janstary/sox/tree/build holds the latest code of my forked effort to resurrect SoX after a decade. Jan Once you get that working, do come back with the music school recordings, that was a pretty interesting use case. |
From: Michael C. (David) <D.C...@ut...> - 2024-06-11 21:19:34
|
Hi all, You may recall a thread a while back (Recording Specific Channels). I had to drop it at the time, but I’m digging in again. The last suggestion was to update to a more recent version, which I’ve tried, but now I’m just as confused. * I asked our tech staff to an install of a more recent version. He said got a number of errors, but wasn’t specific. I dropped it. * After getting the email from Jan, Call for Testers, I had them prepare an install that version. * They were able to do it (and they use a self-service install program, a protocol I more or less have to follow). * Using their self-service I installed it on my laptop and a machine at school. That worked, but when I run it (simply type “sox”) the top line still says SoX 14.4.2. That’s the same version as I was using, “nine years old.” * I follow this link<https://sourceforge.net/projects/sox/> which says last update is 2024-06-04. I downloaded that file, uncompressed, at it also says sox-14.4.2, Feb 22, 2015. So now I’m confused. Where can I get a more recent copy? |
From: Jan S. <ha...@st...> - 2024-06-10 18:22:13
|
Dear fellow users of SoX, I would like to kindly ask you to test a build system for SoX: the 'build' branch at https://github.com/janstary/sox/tree/build On the surface it is the same: ./configure && make (see INSTALL). On the inside, it is a complete overhaul. Branching from Mans's latest commit (the spectrogram fix), it consists of about 100 commits, should you want to read the whole story; here is the gist of it. It replaces the GNU auto* system with a simple, hand-written ./configure script, a straightforward Makefile, and a set of have-*.c micro-programs testing the availability of libraries. It "borrows" heavily (in fact, steals with love) from Ingo Schwarze's build system for the mandoc package. This has no dependency on anything besides sh(1) and cc(1). The main point is to get rid of the GNU autotools monster: Do we have strlen()? Can <stdint.h> be included? What of "gcc -v"? POSIX.1 came out more than fifteen years ago; all modern systems are close to that and we should be coding against that standard. Functionaly, this system detects the optional external formats and audio drivers the current autotools system tries to detect, but correctly, much faster, using elementary tools, and actualy respecting the results. The single exception is waveaudio, as I have no windows machine. A big change in the resulting build is this no longer builds or install libsox the library, as opposed to sox the binary. SoX itself seems to be the only user of that library. Looking into the entire collection of ports and packages of all the system below, I have found _two_ things using it. (Not to be confused with libsoxr, the resampling library extracted from sox by Rob Sykes, maintainer at the time.) Details in https://github.com/janstary/sox/issues/43 Another change is the dynamic loading of libraries with dlopen(), which I have completely dropped. Either have the library at build and link against it, or don't, like everyone else. (But libltdl is not completely gone, because the ladspa plugins need it.) Like gsm some years ago, the lpc codec is made an optional, external dependecy, as opposed the carrying a copy of its entire implementation. If you care about LPC as a format, look at https://github.com/janstary/lpc for a separate lib; note that the original LPC code (as opposed to the bundled subdir) has just been made available, upon asking, by the original author: https://github.com/jafingerhut/lpc10 While here, I have also done some cleaning, but nothing that would change SoX's actual audio behaviour. I have removed struct timeb, obsoleted ages ago and not even used here, the homegrown strcasecmp(), #ifdef HAVE_STDINT_H and other ancient cruft. See the git log for the lolz. I have been running and testing this for some time on OpenBSD/current (amd64, i386, arm64, armv7, powerpc, octeon) FreeBSD 14.1 (amd64) NetBSD 10.0 (amd64) macOS 14.5 (M1 MacBook Air) Debian 13.2 trixie (amd64) Solaris (SunOS 5.11) and everything I could test seems to work. That is to say, the build of sox and the detection of external libs as optional extra formats and drivers works; the actual audio signal processing code, which has its own problems, has not been touched. During all that, going through the individual formats, I have also reviewed the soxi(1) and soxformat(7) manpages, untouched for a decade, and synced them with reality, refactoring a bit, and rewriting in mdoc(7) not man(7). Please read them. (The monstrous sox(1) is for later.) Please test on every system you use SoX on. Please test the detection of every audio format and effect and driver you care about (or, better yet, test them all). If anything doesn't work as expected, please report here or open an issue: https://github.com/janstary/sox/issues Thank you, Jan |
From: Jan S. <ha...@st...> - 2024-06-09 07:43:29
|
Hi all, does anyone use the lpc codec bundled in lpc10/? Is anyone aware of a separate, standalone library? Does lpc in SoX work for you? https://github.com/janstary/sox/issues/12 https://github.com/janstary/lpc Jan |
From: Jan S. <ha...@st...> - 2024-06-06 08:42:00
|
The sys/timeb.h header declares the obsolete struct timeb, which is only used by the deprecated ftime() function, which we don't call anywhere. https://github.com/janstary/sox/issues/65 _When_ was ftime() deprecated, you ask? This has to be the new winner. Jan |
From: Jan S. <ha...@st...> - 2024-06-03 21:21:48
|
On Jun 03 23:18:25, ha...@st... wrote: > On Jun 04 00:10:31, ser...@ya... wrote: > > "monstrosity" - could you please elaborate ? > > What's there to elaborate on? > Meson itself is 26 MB (no, I am not counting the .git dir). > That's TEN TIMES the size of sox itself. > Plus it requires python and ninja. > > > Besides that, using Meson you don't have to develop > > yet another build system. > > The build system I use now is a shell script and a Makefile. > That's not "another build system", thats two straightforward > plain text files with NO dependencies on anything. > > > Also, how about projects using Meson build system: > > https://mesonbuild.com/Users.html ? > > What about them? Do you mean to say that > if so many projects use it, we should use it? > (Srsly, are you trolling or what?) Here is a quick test: write a Meson build for SoX. (I didn't think so.) |
From: Jan S. <ha...@st...> - 2024-06-03 21:18:38
|
On Jun 04 00:10:31, ser...@ya... wrote: > "monstrosity" - could you please elaborate ? What's there to elaborate on? Meson itself is 26 MB (no, I am not counting the .git dir). That's TEN TIMES the size of sox itself. Plus it requires python and ninja. > Besides that, using Meson you don't have to develop > yet another build system. The build system I use now is a shell script and a Makefile. That's not "another build system", thats two straightforward plain text files with NO dependencies on anything. > Also, how about projects using Meson build system: > https://mesonbuild.com/Users.html ? What about them? Do you mean to say that if so many projects use it, we should use it? (Srsly, are you trolling or what?) > And why is my message not posted to the list ? No idea - are you subscribed to the list? > On 03/06/2024 9:03, Jan Stary wrote: > > What a monstrosity. > > This is the kind of thing I want to _avoid_ . > > > > Jan > > > > > > On Jun 02 23:03:58,ser...@ya... wrote: > > > > > > > > > -------- Forwarded Message -------- > > > Subject: Re: [SoX-users] a build system > > > Date: Sun, 2 Jun 2024 05:58:12 +0300 > > > From: Sergei Steshenko<ser...@ya...> > > > To: sox...@li... > > > > > > > > > > > > Why not the Meson (https://mesonbuild.com/ ) build system ? It is claimed > > > to be fast and user friendly. > > > > > > --Sergei. > > > > > > On 30/05/2024 10:37, Jan Stary wrote: > > > > (sorry for cross-posting) > > > > > > > > For anyone interested, > > > > https://github.com/janstary/sox/tree/build > > > > > > > > This is a build system that replaces the GNU autotool > > > > with a readable shell script and a straightforward Makefile. > > > > > > > > In its current state, it builds and installs SoX itself, > > > > i.e. all the internal formats that SoX itself implements. > > > > It does not yet detect the external libraries and formats > > > > (such as flac or ogg, or alsa or sndio), except I just > > > > added the detection of CoreAudio. These come next. > > > > > > > > It is smaller and faster by orders of magnitude, > > > > and gets rid of the dependency on autotools. > > > > > > > > Please test everywhere. > > > > > > > > Jan > > > > > > > > > > > > > I very much see the current build system as a burden that needs > > > > > to be removed/replaced; that's why I started with that. > > > > > > > > > > Grep for HAVE_* and go through them all; I did, last night. > > > > > SoX is very much a child of the early nineties, and the current > > > > > build system caters to that, checking all over the place > > > > > whether you have e.g. mkstemp() or stdint.h, like it's 1991. > > > > > SoX implements its own strcasecmp() for crying out loud. > > > > > Catering to that is the opposite of my intention. > > > > _______________________________________________ > > > > Sox-users mailing list > > > > Sox...@li... > > > > https://lists.sourceforge.net/lists/listinfo/sox-users |
From: Jan S. <ha...@st...> - 2024-06-03 07:43:51
|
Is anyone using sox --multi-threaded, with OpenMP installed? Has anyone measured the difference, i.e. the speed benefit? Jan |
From: Jan S. <ha...@st...> - 2024-06-01 13:20:31
|
> The top level directory currently contains source files, > build files, the readme, license etc. Exactly: one dir containing everything. > I am not at all advocating recursive makefiles. You can > have a single make file (top-level ;-) which references > files in subdirectories. Yes; but that is exactly what I want to avoid :-) Jan |
From: Jan S. <ha...@st...> - 2024-06-01 13:17:37
|
> I suspect that bit-rot/ provides noting and can be safely deleted. https://github.com/janstary/sox/commit/c7a1015c984b3164202a7342978776fe6771ab5c |
From: Dr. T. T. <t....@gm...> - 2024-06-01 12:49:14
|
Hello Jan, you wrote: > > Since I am providing plugin versions of the most > > prominent SoX effects at > > https://github.com/prof-spock/SoX-Plugins > That begs the question: do you use libsox? That is to > say, do you call the functions of the undoccumented libsox > API? No, I reimplemented everything from scratch. The reason is that some SoX algorithms are distributed across the files, there is also some duplication and even different algorithm versions for similar tasks. And besides I wanted to use floating point arithmetic throughout. But others might need libsox: I do not. > > (reimplemented in C++, but functionally equivalent to > > SoX), > Eh, I'm not going there, sorry :-) Well, I think that C is still a good language for programming. But when you are using a C++-based framework for the plugin wrappers like JUCE, there is not much choice. And by the way: for complex projects I think that the abstraction mechanisms of C++ are really helpful. > > But I have one suggestion for your repository: I would > > appreciate it when all the SoX sources are in some > > subdirectory like e.g. src. If you left all sources as > > is, this would clutter up the top level and obscure > > things like the readme or the build shell files. > Why? > Obscure in what sense? > Not standing out in a ls(1) of the directory? The top level directory currently contains source files, build files, the readme, license etc. Hence the many source files "obscure" other files. "Clutter up" would also be a good description. > That is a tiny price to pay, compared to the needless > complexity of having subdirs and havein make(1) run > recursively. I am not at all advocating recursive makefiles. You can have a single make file (top-level ;-) which references files in subdirectories. The SoXPlugins project mentioned above uses a single CMake file doing exactly that (which - by the way - is itself contained in a subdirectory buildSetup together with some include files needed). But this is only my suggestion: you are the maintainer now and can do what you deem appropriate. Best regards, Thomas |
From: Jan S. <ha...@st...> - 2024-06-01 11:44:49
|
On Jun 01 13:39:17, ha...@st... wrote: > > Since I am providing plugin versions of the most prominent > > SoX effects at https://github.com/prof-spock/SoX-Plugins > > That begs the question: do you use libsox? That is to say, > do you call the functions of the undoccumented libsox API? > > > (reimplemented in C++, but functionally equivalent to SoX), > > Eh, I'm not going there, sorry :-) But, to be sure: you are not using libsox. I suspect nothing would be lost if we dropped the library and just shipped sox itself. Jan |
From: Jan S. <ha...@st...> - 2024-06-01 11:39:30
|
Hello Thomas, > first of all thank you for your effort to lift the deploment > pipeline of the SoX distribution to a more modern level! thank you for the encouragement. Hopefully, this is heading out of the nineties. > Since I am providing plugin versions of the most prominent > SoX effects at https://github.com/prof-spock/SoX-Plugins That begs the question: do you use libsox? That is to say, do you call the functions of the undoccumented libsox API? > (reimplemented in C++, but functionally equivalent to SoX), Eh, I'm not going there, sorry :-) > But I have one suggestion for your repository: I would > appreciate it when all the SoX sources are in some > subdirectory like e.g. src. Why? > That directory could also > contain the bit-rot and lpc10 directories. I have not decided what to do with those yet. I suspect that bit-rot/ provides noting and can be safely deleted. lpc10/ should IMHO be made an external format, like gsm some time ago. Then we don't have to carry that around. Then, we will finally have everything in one dir. Ein dir, ein code, ein Makefile. > If you left all sources as is, this would clutter up the top > level and obscure things like the readme or the build shell files. Obscure in what sense? Not standing out in a ls(1) of the directory? That is a tiny price to pay, compared to the needless complexity of having subdirs and havein make(1) run recursively. Sincerely, Jan |
From: Dr. T. T. <t....@gm...> - 2024-05-31 18:25:58
|
Hello Jan, first of all thank you for your effort to lift the deploment pipeline of the SoX distribution to a more modern level! Since I am providing plugin versions of the most prominent SoX effects at https://github.com/prof-spock/SoX-Plugins (reimplemented in C++, but functionally equivalent to SoX), I am very interested to see the command-line SoX revived! But I have one suggestion for your repository: I would appreciate it when all the SoX sources are in some subdirectory like e.g. src. That directory could also contain the bit-rot and lpc10 directories. If you left all sources as is, this would clutter up the top level and obscure things like the readme or the build shell files. So all the best for your endeavour! Best regards, Thomas |
From: Jan S. <ha...@st...> - 2024-05-30 07:37:49
|
(sorry for cross-posting) For anyone interested, https://github.com/janstary/sox/tree/build This is a build system that replaces the GNU autotool with a readable shell script and a straightforward Makefile. In its current state, it builds and installs SoX itself, i.e. all the internal formats that SoX itself implements. It does not yet detect the external libraries and formats (such as flac or ogg, or alsa or sndio), except I just added the detection of CoreAudio. These come next. It is smaller and faster by orders of magnitude, and gets rid of the dependency on autotools. Please test everywhere. Jan > I very much see the current build system as a burden that needs > to be removed/replaced; that's why I started with that. > > Grep for HAVE_* and go through them all; I did, last night. > SoX is very much a child of the early nineties, and the current > build system caters to that, checking all over the place > whether you have e.g. mkstemp() or stdint.h, like it's 1991. > SoX implements its own strcasecmp() for crying out loud. > Catering to that is the opposite of my intention. |
From: Jan S. <ha...@st...> - 2024-05-29 14:46:48
|
On May 29 07:56:05, sfn...@sl... wrote: > Hello, > > We performed updates to mailing list routing that resulted in some > interruption over the weekend. These issues were resolved yesterday. > > > Sincerely, > > SourceForge Support > > On Wed, May 29, 2024 at 12:25 AM Jan Stary <ha...@st...> wrote: > > > So what happened? > > Why didn't the mailing lists work for five days? > > > > Jan > > > > On May 28 15:41:06, sfn...@sl... wrote: > > > Hi, > > > > > > Thank you for your feedback. > > > We appreciate it. > > > > > > > > > Sincerely, > > > > > > SourceForge Support > > > > > > On Tue, May 28, 2024 at 1:53 PM Jan Stary <ha...@st...> wrote: > > > > > > > Hi, > > > > > > > > it seems to be working now: my email just arrived to sox-users > > > > and another one to sox-devel. > > > > > > > > What happened? > > > > > > > > Jan > > > > > > > > On May 28 11:16:58, sfn...@sl... wrote: > > > > > Hello, > > > > > > > > > > Is this still an issue? > > > > > Our team has been working on your report, and we would like to have > > your > > > > > feedback. > > > > > > > > > > > > > > > Sincerely, > > > > > SourceForge Support > > > > > > > > > > On Tue, May 28, 2024 at 10:35 AM Jan Stary <ha...@st...> wrote: > > > > > > > > > > > It seems that the mailing lists run by SF do stopped working: > > > > > > this is what happens when I try to post to sox-users or sox-devel. > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > On May 28 05:32:30, Mai...@so... wrote: > > > > > > > This message was created automatically by mail delivery software. > > > > > > > > > > > > > > A message that you sent could not be delivered to one or more of > > its > > > > > > > recipients. This is a permanent error. The following address(es) > > > > failed: > > > > > > > > > > > > > > sox...@li... > > > > > > > all hosts for 'lists.sourceforge.net' have been failing for > > a > > > > long > > > > > > time (and retry time not reached) > > > > > > > > > > > > > Reporting-MTA: dns; sfi-mx-2.v28.lw.sourceforge.com > > > > > > > > > > > > > > Action: failed > > > > > > > Final-Recipient: rfc822;sox...@li... > > > > > > > Status: 5.0.0 > > > > > > > > > > > > > Date: Fri, 24 May 2024 12:22:34 +0200 > > > > > > > From: Jan Stary <ha...@st...> > > > > > > > To: sox...@li... > > > > > > > Subject: update > > > > > > > > > > > > > > After yesterday's spectrogram fix (thanks again) > > > > > > > I updated the OpenBSD port of audio/sox. > > > > > > > I would like to use this opportunity to show > > > > > > > what the downstream ports do: > > > > > > > > > > > > > > http://cvsweb.openbsd.org/ports/audio/sox/ > > > > > > > https://cgit.freebsd.org/ports/tree/audio/sox/ > > > > > > > http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/audio/sox/ > > > > > > > > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sox;dist=unstable > > > > > > > https://github.com/macports/macports-ports/tree/master/audio/sox > > > > > > > > > > > > > > Given that the last release was 9 years ago, > > > > > > > downstream packages keep accumulating patches not incorporated > > into > > > > SoX, > > > > > > > and start either at 14.4.2 stacking up, or pick some git commit > > > > > > > or another and build on top of that. > > > > > > > > > > > > > > Currently, there is 59 bugreports and 23 patches at sox.sf.net, > > > > > > > and others used downstream; with a few exceptions, these haven't > > > > > > > been touched in years, some of them decades. (Some of them are no > > > > > > > longer relevant of course.) There is cruft that has been broken > > > > > > > for decades, such as the osxbuild script or release.sh (which > > > > > > > "automatizes the release process" - what a laugh). > > > > > > > > > > > > > > With due respect to the maintainers: > > > > > > > is there please any chance this will be sorted out, > > > > > > > as a way towards a proper release? > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > > > > |
From: Jan S. <ha...@st...> - 2024-05-28 22:19:04
|
My emails don't get through to sox-devel; will they get through to sox-users? |
From: Jan S. <ha...@st...> - 2024-05-28 19:49:13
|
Does it work yet? On May 28 11:16:58, sfn...@sl... wrote: > Hello, > > Is this still an issue? > Our team has been working on your report, and we would like to have your > feedback. > > > Sincerely, > SourceForge Support > > On Tue, May 28, 2024 at 10:35 AM Jan Stary <ha...@st...> wrote: > > > It seems that the mailing lists run by SF do stopped working: > > this is what happens when I try to post to sox-users or sox-devel. > > > > Jan > > > > > > On May 28 05:32:30, Mai...@so... wrote: > > > This message was created automatically by mail delivery software. > > > > > > A message that you sent could not be delivered to one or more of its > > > recipients. This is a permanent error. The following address(es) failed: > > > > > > sox...@li... > > > all hosts for 'lists.sourceforge.net' have been failing for a long > > time (and retry time not reached) > > > > > Reporting-MTA: dns; sfi-mx-2.v28.lw.sourceforge.com > > > > > > Action: failed > > > Final-Recipient: rfc822;sox...@li... > > > Status: 5.0.0 > > > > > Date: Fri, 24 May 2024 12:22:34 +0200 > > > From: Jan Stary <ha...@st...> > > > To: sox...@li... > > > Subject: update > > > > > > After yesterday's spectrogram fix (thanks again) > > > I updated the OpenBSD port of audio/sox. > > > I would like to use this opportunity to show > > > what the downstream ports do: > > > > > > http://cvsweb.openbsd.org/ports/audio/sox/ > > > https://cgit.freebsd.org/ports/tree/audio/sox/ > > > http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/audio/sox/ > > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sox;dist=unstable > > > https://github.com/macports/macports-ports/tree/master/audio/sox > > > > > > Given that the last release was 9 years ago, > > > downstream packages keep accumulating patches not incorporated into SoX, > > > and start either at 14.4.2 stacking up, or pick some git commit > > > or another and build on top of that. > > > > > > Currently, there is 59 bugreports and 23 patches at sox.sf.net, > > > and others used downstream; with a few exceptions, these haven't > > > been touched in years, some of them decades. (Some of them are no > > > longer relevant of course.) There is cruft that has been broken > > > for decades, such as the osxbuild script or release.sh (which > > > "automatizes the release process" - what a laugh). > > > > > > With due respect to the maintainers: > > > is there please any chance this will be sorted out, > > > as a way towards a proper release? > > > > > > Jan > > > > > > > |
From: Jan S. <ha...@st...> - 2024-05-22 14:38:06
|
> >> In general, though, sox's SF issue tracker seems to be ineffective, which > >> both impacts the quality and functionality of sox, but also discourages > >> well-intentioned people from contributing to it, as they start out > >> enthusiastic, follow what seem like the right steps, and then are ignored > >> for decades. I am one example of that. I've added log frequency axis to > >> sndfile-tools' sndfile-spectrogram and would have done the same for sox but > >> it seemed pointless after the FFTW patches being ignored for so long, making > >> me have to update them to stride code changes, until I eventually gave the > >> idea up as wasted work. > >> > >> There are contributions with patches from 2006, which may or may not be > >> useful these days. There are patch suggestions that give links to github > >> repos that have long since been deleted, but the pointless issue persists on > >> SF. > >> > >> This gives the public impression to developers is that it is abandonware or > >> only-us-not-you-ware. > >> > >> Could the project use some help, as I've been programming since I was 13 and > >> am now 60 and on a pension so I can choose what I work on, and resolving the > >> sox SF issues seems worth doing as it is an excellent tool that seems > >> neglected in that area. > > Yes. There has been a void in actual maintainership for a long time. > > Is anyone sure what the upstream actualy is? The downstream ports > > I care to follow either start at 14.4.2 and stack up their own patches > > (including random diffs floating around, or one of the github forks), > > or just gave up and chose one github repo or another. > > > > Is there anyone on this list who considers thamselves to be > > a "maintainer" of SoX? Or at least someone who even has the > > commit rights to sox.sf.net (the repo, the bugtracker)? > > Does anyone of the current users remember what SourceForge was? > > I have admin access to the SF project. Do you consider that to be the ultimate upstream of SoX code? If so, what is the relation of the SF git master to https://github.com/mansr/sox/commits/master/ ? > Unfortunately, I haven't been > able to spend much time on maintenance tasks recently. sox.sf.net says "Brought to you by: cbagwell, mansr, robs, uklauer" https://sourceforge.net/u/mansr/activity https://sourceforge.net/u/robs/activity https://sourceforge.net/u/uklauer/activity https://sourceforge.net/u/cbagwell/activity Is there anyone on these lists (cross-posting to both -devel and -users) willing to step up and maintain SoX? Jan |
From: Måns R. <ma...@ma...> - 2024-05-14 14:26:33
|
Sergei Steshenko via Sox-users <sox...@li...> writes: > "BTW, I don't think it's a signal that kills Michael's recording SoX process > (but of course it would be good to know)." - here is a non-SoX fascinating > example of SW failure: https://savannah.gnu.org/bugs/?60620 . As Jan said, > "it would be good to know". Please stay on topic or go away. If you don't behave yourself, I can make you go away. -- Måns Rullgård |
From: Sergei S. <ser...@ya...> - 2024-05-14 14:07:22
|
"BTW, I don't think it's a signal that kills Michael's recording SoX process (but of course it would be good to know)." - here is a non-SoX fascinating example of SW failure: https://savannah.gnu.org/bugs/?60620 . As Jan said, "it would be good to know". --Sergei. On 14/05/2024 9:17, Jan Stary wrote: > On May 14 00:33:31,ser...@ya... wrote: >> "This is a SoX mailing list. Keep it that way." - well, then this: "How can >> I tell in Linux which process sent my process a signal<https://stackoverflow.com/questions/8400530/how-can-i-tell-in-linux-which-process-sent-my-process-a-signal>" >> might be useful to find out what causes SoX to terminate. But implementing >> this would require change in SoX source code. > Of course not; there are debuggers such as ktrace and dtrace > that tell you that. This has nothing to do with SoX. > > BTW, I don't think it's a signal that kills Michael's > recording SoX process (but of course it would be good to know). > >> For example, I saw negative results of bad SW architecture >> in the medical sector. > Fascinating. Repreat after me: > this is a SoX mailing list. > |