Re: [LAD] Aeolus 0.9.0 backtrace
В письме от 3 декабря 2013 12:12:43 пользователь Zlobin Nikita написал: В письме от 2 декабря 2013 16:06:14 пользователь Fons Adriaensen написал: On Mon, Dec 02, 2013 at 11:52:34AM +0600, Zlobin Nikita wrote: I rebuilt aeolus again agains of debuggable clxclient, now backtrace is a bit more full. Before i got it i added debug printing lines with args, and printing internals of some structs. However, Display struct seems to be not for user, and its structure is quite huge, including other structs as well. The things to check first are i, n, and _txt. Just try to print _txt as a string (%s). If that fails, try something like for (int k = 0; k 40; k++) printf (%3d %02x\n, k, _txt [k]); Ciao, First two values are, args, so see both in backtrace and printed by my lines (where it says entered textip: ). Btw, are you enjoying, writing obviosly printable text by specifying their code? :) (i'm sure, there are should be printable versions for printf, like %c, %s, %i, etc). Or printf indeed supports some unprintable codes as formating sequences. Ad as usually, full gdb output. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev Hm, it seems, i don't know format enough full :) Forgot about other specificators. Will do more experiments eventually. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus 0.9.0 backtrace
On Mon, Dec 02, 2013 at 11:52:34AM +0600, Zlobin Nikita wrote: I rebuilt aeolus again agains of debuggable clxclient, now backtrace is a bit more full. Before i got it i added debug printing lines with args, and printing internals of some structs. However, Display struct seems to be not for user, and its structure is quite huge, including other structs as well. The things to check first are i, n, and _txt. Just try to print _txt as a string (%s). If that fails, try something like for (int k = 0; k 40; k++) printf (%3d %02x\n, k, _txt [k]); Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus 0.9.0 backtrace
В письме от 2 декабря 2013 16:06:14 пользователь Fons Adriaensen написал: On Mon, Dec 02, 2013 at 11:52:34AM +0600, Zlobin Nikita wrote: I rebuilt aeolus again agains of debuggable clxclient, now backtrace is a bit more full. Before i got it i added debug printing lines with args, and printing internals of some structs. However, Display struct seems to be not for user, and its structure is quite huge, including other structs as well. The things to check first are i, n, and _txt. Just try to print _txt as a string (%s). If that fails, try something like for (int k = 0; k 40; k++) printf (%3d %02x\n, k, _txt [k]); Ciao, First two values are, args, so see both in backtrace and printed by my lines (where it says entered textip: ). Btw, are you enjoying, writing obviosly printable text by specifying their code? :) (i'm sure, there are should be printable versions for printf, like %c, %s, %i, etc). Or printf indeed supports some unprintable codes as formating sequences. Ad as usually, full gdb output. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus segmentation fault
Am 01.12.2013 07:22, schrieb Zlobin Nikita: Reading '/home/nick87720z/.aeolus-presets' Program received signal SIGSEGV, Segmentation fault. What happen when you remove .aeolus-presets ? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus segmentation fault
On Sun, Dec 01, 2013 at 11:51:48AM +0600, Zlobin Nikita wrote: It seems to be problem of gui, aeolus 0.8.4 and 0.9.0 both have this problem. Backtrace below is got using 0.9.0. First time i reported directly to Fons, but still no reply. Don't know, is it accepted at all for such things as bug reporting. It's perfectly OK to do that (since there is no public bug tracker for Aeolus). Sorry for not responding earlier to your message - it arrived at a moment when I was already multitasking over my capabilities... I can't reproduce this. And the error occurs quite deep into libfreetype, itself called from libXft (i.e. at a point one could assume those libs have already checked function arguments). Could you try to obtain the function argements at these points: #6 0x0039bd40a06a in XftTextExtentsUtf8 () from /usr/lib/x86_64-linux- and/or #7 0x0039a840e7ff in X_textip::textwidth(int, int) () from If these ar OK, the problem must be within libXft or libfreetype. It was suggested to remove you presets file - this is a good thing to try first. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus segmentation fault
В письме от 1 декабря 2013 10:38:00 пользователь hermann meyer написал: Am 01.12.2013 07:22, schrieb Zlobin Nikita: Reading '/home/nick87720z/.aeolus-presets' Program received signal SIGSEGV, Segmentation fault. What happen when you remove .aeolus-presets ? Same. It is gui bug, happening somewhere in freetype routines. Look to backtrace. Bug doesn't happen using text mode. More exactly crash happens when window appears, but fully unfilled, only gray background. It stays less than second, thant program terminates. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus segmentation fault
On Sun, Dec 01, 2013 at 12:22:34PM +0600, Zlobin Nikita wrote: Strang problem with debugging info. I built both clxclient and aeolus with modified makefiles, removing optimization and adding -g -ggdb to flags. But gdb still says: warning: no loadable sections found in added symbol-file system-supplied DSO at ,,, Hoped to get a bit more detailed backtrace. Are you sure to be debugging the locally compiled version ? It should be in /usr/local/bin, and the libraries in /usr/local/lib. You'd also have to enable the latter in /etc/ld.so.conf.d. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus segmentation fault
В письме от 1 декабря 2013 15:57:43 пользователь Fons Adriaensen написал: On Sun, Dec 01, 2013 at 12:22:34PM +0600, Zlobin Nikita wrote: Strang problem with debugging info. I built both clxclient and aeolus with modified makefiles, removing optimization and adding -g -ggdb to flags. But gdb still says: warning: no loadable sections found in added symbol-file system-supplied DSO at ,,, Hoped to get a bit more detailed backtrace. Are you sure to be debugging the locally compiled version ? It should be in /usr/local/bin, and the libraries in /usr/local/lib. You'd also have to enable the latter in /etc/ld.so.conf.d. Ciao, Yes. I changed prefix as well, because 0.8.4 is latest in repo. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus segmentation fault
В письме от 1 декабря 2013 15:57:43 пользователь Fons Adriaensen написал: On Sun, Dec 01, 2013 at 12:22:34PM +0600, Zlobin Nikita wrote: Strang problem with debugging info. I built both clxclient and aeolus with modified makefiles, removing optimization and adding -g -ggdb to flags. But gdb still says: warning: no loadable sections found in added symbol-file system-supplied DSO at ,,, Hoped to get a bit more detailed backtrace. Are you sure to be debugging the locally compiled version ? It should be in /usr/local/bin, and the libraries in /usr/local/lib. You'd also have to enable the latter in /etc/ld.so.conf.d. Ciao, And 'aeolus -h' reports version 0.9.0. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus 0.9.0 backtrace (checking fontconfig settings)
В письме от 2 декабря 2013 12:29:30 пользователь Zlobin Nikita написал: Fons, what are versions of your clxclient dependencies? or distro. What it it is indeed xft/freetype bug, fixed in some recent version. And yet, i made manual fontconfig configuration - switching to one cool engine with many parameters, having even predefined settings for various versions of win, mac, several more,. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev Tried to change /etc/fonts/conf.d to symlink to backup (probably default) dir and even replace with empty. Nothing changes. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus segmentation fault
В письме от 1 декабря 2013 11:51:48 пользователь Zlobin Nikita написал: It seems to be problem of gui, aeolus 0.8.4 and 0.9.0 both have this problem. Backtrace below is got using 0.9.0. First time i reported directly to Fons, but still no reply. Don't know, is it accepted at all for such things as bug reporting. (gdb) run Starting program: /usr/bin/aeolus -J warning: no loadable sections found in added symbol-file system-supplied DSO at 0x77ffa000 [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [New Thread 0x77faa700 (LWP 9934)] [New Thread 0x77f29700 (LWP 9935)] [New Thread 0x77ea8700 (LWP 9936)] [New Thread 0x755fd700 (LWP 9937)] [New Thread 0x755ec700 (LWP 9938)] [New Thread 0x755db700 (LWP 9939)] Reading '/usr/share/aeolus/stops/Aeolus/definition' [New Thread 0x755ca700 (LWP 9940)] [New Thread 0x74ecb700 (LWP 9941)] Reading '/home/nick87720z/.aeolus-presets' Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x74ecb700 (LWP 9941)] 0x75d78da1 in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (gdb) backtrace #0 0x75d78da1 in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6 #1 0x75d7dd1f in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6 #2 0x75d7f5af in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6 #3 0x75d2bbd5 in FT_Render_Glyph_Internal () from /usr/lib/x86_64- linux-gnu/libfreetype.so.6 #4 0x0039bd40c670 in XftFontLoadGlyphs () from /usr/lib/x86_64-linux- gnu/libXft.so.2 #5 0x0039bd409c64 in XftGlyphExtents () from /usr/lib/x86_64-linux- gnu/libXft.so.2 #6 0x0039bd40a06a in XftTextExtentsUtf8 () from /usr/lib/x86_64-linux- gnu/libXft.so.2 #7 0x0039a840e7ff in X_textip::textwidth(int, int) () from /usr/lib/libclxclient.so.3 #8 0x0039a840ed6d in X_textip::update(bool) () from /usr/lib/libclxclient.so.3 #9 0x76533023 in Instrwin::show_tuning(int) () from /usr/lib64/aeolus_x11.so #10 0x7653c974 in Xiface::handle_mesg(ITC_mesg*) () from /usr/lib64/aeolus_x11.so #11 0x7653cab7 in Xiface::thr_main() () from /usr/lib64/aeolus_x11.so #12 0x0039a7c0309a in P_thread_entry_point () from /usr/lib/libclthreads.so.2 #13 0x77974e9a in start_thread (arg=0x74ecb700) at pthread_create.c:308 #14 0x76c873fd in clone () at ./sysdeps/unix/sysv/linux/x86_64/clone.S:112 #15 0x in ?? () (gdb) kill ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev Strang problem with debugging info. I built both clxclient and aeolus with modified makefiles, removing optimization and adding -g -ggdb to flags. But gdb still says: warning: no loadable sections found in added symbol-file system-supplied DSO at ,,, Hoped to get a bit more detailed backtrace. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
On jeu. 19/09/13 17:50 , IOhannes m zmoelnig zmoel...@iem.at wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-19 05:31, hermann meyer wrote: I'm sad to hear that. :-( Please don't let you lead from the things you didn't like, let you lead from the things you like instead. I guess then it's necessary to let you know that we use /as well/ a fork of your work, the zita-convolver library, in the guitarix project. But we leave your copyright untouched, and the fork will only come in use, when the user set a explicit compile flag. We didn't promote it, or force the fork. Ordinary your original code is in use. We do it to use ffmpeg instead fftw3 FFT, which perform better on ARM devices. but this sounds like the perfect opportunity to not do a simple fork, but to send patches to upstream so fons' aeolus could support both fftw3 and ffmpeg FFTs. it might be a win-win situation, where not only more than just the original aeolus users can profit from fons' work (because you use his code) but also more than just your users can profit from your work (because you changes are included into upstream aeolus). I fully agree. As the main fvwm-crystal developer, I know how hard it can be to get good users returns. I find it scary if even developers cannot share with each others. I begun to write my own fvwm-crystal functions because I wanted them, and when I was done, I contacted upstream. At first, I get no answer, so I done a fork. Some months later, it was a discussion about my fork on fvwm-crystal email list, and that time I get in touch with upstream, and my work was incorporated into Crystal. Form there, I am now the main contributor. It is not always easy, but so is life. As the main fvwm-crystal developer, I just don't have the time to check what can be the special requirements of each distribution or each user that use it. And I find it very sad when they make modifications and don't contribute them. From users, I can understand that very well, but from developers, I think they just miss a very important point about FOS : a community is always about solidarity. That imply we must communicate more with each other. I think this is a big problem, and not only related to Fons work, or the LAD, but to the whole community. And it is not easy to solve if developers that make patches just say nothing to the original developers. We are living in an individualistic society, so are commercial softwares, but with FOS, peoples must really take on them to communicate more about what they are doing, that especially when they are making interesting patches or forks. Dominique fmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ [1] iEYEARECAAYFAlI7D0UACgkQkX2Xpv6ydvTc+gCdGdTegTkJmgsRvZ5xz39AyxCe VEIAnRFYLyRpmcUOUsPZ8jsZ5ceuo21g =v6Hr -END PGP SIGNATURE- ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev [2] Links: -- [1] http://awebmail.vtx.ch/parse.php?redirect=http://www.enigmail.net/ [2] http://awebmail.vtx.ch/parse.php?redirect=http://lists.linuxaudio.org/listi nfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
On Fri, 2013-09-20 at 11:00 +0200, michel dominique wrote: That imply we must communicate more with each other. But we all know that some people can't communicate with each other, not only when it comes to forks, even when reporting bugs. That's bad, but natural. Btw. within the Linux audio community I only experience one issue. The coder of the HDSPe AIO driver did misbehave and isn't interested in a bug report. Outside this community there are many examples when communication is unwanted. I experienced more than one time that it's a problem and there are much more where I'm not involved, but a usual reply is if ..., then fork it. IOW usually people get encouraged to fork FLOSS. That sometimes somebody makes a mistake, e.g. regarding to a copyright entry is common, but not an issue, since usually just a friendly mail is enough, to make those people to correct their offence and to apologize for it, with an clarification why it unintended happened. So if somebody missed to talk to the original coder/coders, than is it useful to complain about If this is typical for the attitude taken by the Linux Audio community at two mailing lists or would it be sane to contact the offender/s first? Perhaps my request will get them in contact. https://github.com/mgavioli/oscAeolus/issues/1 Nobody of us does know the reason for the offence, misunderstanding or what ever it is. Speculations and/or what would be the best way to do a fork or not won't solve the issue Fons has got. The people involved in this issue first need to talk to each other. Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
On ven. 20/09/13 13:14 , Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Fri, 2013-09-20 at 11:00 +0200, michel dominique wrote: That imply we must communicate more with each other. But we all know that some people can't communicate with each other, not only when it comes to forks, even when reporting bugs. That's bad, but natural. Communication is the ground of civilisation. Unfortunately, our society is so individualistic that some peoples miss it even when doing FLOSS. It is why they have to learn to communicate at the first place. And that's not that hard, it can begin by just sending an email. Perhaps my request will get them in contact. https://github.com/mgavioli/oscAeolus/issues/1 [1] That's a good initiative! Best, Dominique Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev [2] Links: -- [1] http://awebmail.vtx.ch/parse.php?redirect=https://github.com/mgavioli/oscAe olus/issues/1[2] http://awebmail.vtx.ch/parse.php?redirect=http://lists.linuxaudio.org/listi nfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
Am 20.09.2013 11:00, schrieb michel dominique: On jeu. 19/09/13 17:50 , IOhannes m zmoelnigzmoel...@iem.at wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-19 05:31, hermann meyer wrote: I'm sad to hear that.:-( Please don't let you lead from the things you didn't like, let you lead from the things you like instead. I guess then it's necessary to let you know that we use/as well/ a fork of your work, the zita-convolver library, in the guitarix project. But we leave your copyright untouched, and the fork will only come in use, when the user set a explicit compile flag. We didn't promote it, or force the fork. Ordinary your original code is in use. We do it to use ffmpeg instead fftw3 FFT, which perform better on ARM devices. but this sounds like the perfect opportunity to not do a simple fork, but to send patches to upstream so fons' aeolus could support both fftw3 and ffmpeg FFTs. it might be a win-win situation, where not only more than just the original aeolus users can profit from fons' work (because you use his code) but also more than just your users can profit from your work (because you changes are included into upstream aeolus). I fully agree. As the main fvwm-crystal developer, I know how hard it can be to get good users returns. I find it scary if even developers cannot share with each others. Oh, we have announced this on the list(s) here some time ago: Am 18.07.2013 23:29, schrieb Andreas Degert: The Guitarix developers proudly present Guitarix release 0.28.0 magic chainsaw trick *) [ . . .] List of changes: [ . . ] * Optimizations for embedded systems / ARM processors with NEON * --faust-vectorize-float, --convolver-ffmpeg [ . . . ] without a single (list) reply, which imply us a low interest in this here. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
Am 20.09.2013 15:07, schrieb hermann meyer: Am 20.09.2013 11:00, schrieb michel dominique: On jeu. 19/09/13 17:50 , IOhannes m zmoelnigzmoel...@iem.at wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-19 05:31, hermann meyer wrote: I'm sad to hear that.:-( Please don't let you lead from the things you didn't like, let you lead from the things you like instead. I guess then it's necessary to let you know that we use/as well/ a fork of your work, the zita-convolver library, in the guitarix project. But we leave your copyright untouched, and the fork will only come in use, when the user set a explicit compile flag. We didn't promote it, or force the fork. Ordinary your original code is in use. We do it to use ffmpeg instead fftw3 FFT, which perform better on ARM devices. but this sounds like the perfect opportunity to not do a simple fork, but to send patches to upstream so fons' aeolus could support both fftw3 and ffmpeg FFTs. it might be a win-win situation, where not only more than just the original aeolus users can profit from fons' work (because you use his code) but also more than just your users can profit from your work (because you changes are included into upstream aeolus). I fully agree. As the main fvwm-crystal developer, I know how hard it can be to get good users returns. I find it scary if even developers cannot share with each others. Oh, we have announced this on the list(s) here some time ago: Am 18.07.2013 23:29, schrieb Andreas Degert: The Guitarix developers proudly present Guitarix release 0.28.0 magic chainsaw trick *) [ . . .] List of changes: [ . . ] * Optimizations for embedded systems / ARM processors with NEON * --faust-vectorize-float, --convolver-ffmpeg [ . . . ] without a single (list) reply, which imply us a low interest in this here. And more over we didn't announce any release here anymore. Because if communication becomes a one way route, it becomes meaningless. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
On Thu, Sep 19, 2013 at 07:07:37PM +0200, hermann meyer wrote: I've attached the diff, for your review. Some of the changes are not necessary needed, but handy for our use case. Ignore please the #include gx_compiler.h and __rt_func Thanks. It would seem possible to merge the two versions, but I have a few questions/remarks. 1. You shouldn't have removed the 'options'. In the current release they are used for things not related to the FFT library, and other options may be added in the future. It has no performance penalty. 2. You have changed the gain normalisation from 0.5 / partition to 1.0 / partition. Why ? The 0.5 is not related to anything specific FFTW. It's there because the FFT size is twice the partition size. The result should be that convolution with a single impulse of 1.0 amplitude reproduces the input without a gain change. 3. If av_malloc() can ever fail, this should raise an exception. 4. Assuming that the 'swap' operation that is part of the av FFT only changes the order of complete complex values (and not of their components), all the swaps can be removed. The only thing that happens in the F-domain is that values with the same index are multiplied. Their order is not important. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
Am 20.09.2013 17:58, schrieb Fons Adriaensen: On Thu, Sep 19, 2013 at 07:07:37PM +0200, hermann meyer wrote: I've attached the diff, for your review. Some of the changes are not necessary needed, but handy for our use case. Ignore please the #include gx_compiler.h and __rt_func Thanks. It would seem possible to merge the two versions, but I have a few questions/remarks. It will be very welcome, if you merge ffmpeg support into zita-convolver and we will switch to official version as soon you release it. :-) 1. You shouldn't have removed the 'options'. In the current release they are used for things not related to the FFT library, and other options may be added in the future. It has no performance penalty. 2. You have changed the gain normalisation from 0.5 / partition to 1.0 / partition. Why ? The 0.5 is not related to anything specific FFTW. It's there because the FFT size is twice the partition size. The result should be that convolution with a single impulse of 1.0 amplitude reproduces the input without a gain change. we experience a reduced gain , with 1.0 / partition for ffmpeg FFT and 0.5 / partition for fftw3, we get comparable results when switching between ffmpeg and fftw3. 3. If av_malloc() can ever fail, this should raise an exception. 4. Assuming that the 'swap' operation that is part of the av FFT only changes the order of complete complex values (and not of their components), all the swaps can be removed. The only thing that happens in the F-domain is that values with the same index are multiplied. Their order is not important. Ciao, ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
On 18/09/13 Fons Adriaensen f...@linuxaudio.org wrote: ... If this is typical for the attitude taken by the Linux Audio community then my motivation to contribute to it will take a serious blow. Well you've been a member of the Linux Audio community as long as anyone, you should know if this is the typical attitude taken by the Community... ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-19 05:31, hermann meyer wrote: I'm sad to hear that. :-( Please don't let you lead from the things you didn't like, let you lead from the things you like instead. I guess then it's necessary to let you know that we use /as well/ a fork of your work, the zita-convolver library, in the guitarix project. But we leave your copyright untouched, and the fork will only come in use, when the user set a explicit compile flag. We didn't promote it, or force the fork. Ordinary your original code is in use. We do it to use ffmpeg instead fftw3 FFT, which perform better on ARM devices. but this sounds like the perfect opportunity to not do a simple fork, but to send patches to upstream so fons' aeolus could support both fftw3 and ffmpeg FFTs. it might be a win-win situation, where not only more than just the original aeolus users can profit from fons' work (because you use his code) but also more than just your users can profit from your work (because you changes are included into upstream aeolus). fmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlI7D0UACgkQkX2Xpv6ydvTc+gCdGdTegTkJmgsRvZ5xz39AyxCe VEIAnRFYLyRpmcUOUsPZ8jsZ5ceuo21g =v6Hr -END PGP SIGNATURE- ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
On Thu, Sep 19, 2013 at 05:18:27PM +0200, hermann meyer wrote: Sorry, you miss-match aeolus and zita-convolver here. As well, we didn't add ffmpeg support to zita-convolver, we replace fftw3 with ffmpeg, and only use this under special circumstances (ARM support), we didn't distribute it as zita-convolver library IFF * the only change is the fft library used, * the full functionality and API of the original is preserved, * and the modified library is kept in sync with the original one, then I have no objections to it being called 'zita-convolver', and I would even consider to merge the two (which would ensure the third condition). Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
On Thursday 19 September 2013 11:10:31 IOhannes m zmoelnig did opine: On 2013-09-19 05:31, hermann meyer wrote: I'm sad to hear that. :-( Please don't let you lead from the things you didn't like, let you lead from the things you like instead. I guess then it's necessary to let you know that we use /as well/ a fork of your work, the zita-convolver library, in the guitarix project. But we leave your copyright untouched, and the fork will only come in use, when the user set a explicit compile flag. We didn't promote it, or force the fork. Ordinary your original code is in use. We do it to use ffmpeg instead fftw3 FFT, which perform better on ARM devices. but this sounds like the perfect opportunity to not do a simple fork, but to send patches to upstream so fons' aeolus could support both fftw3 and ffmpeg FFTs. it might be a win-win situation, where not only more than just the original aeolus users can profit from fons' work (because you use his code) but also more than just your users can profit from your work (because you changes are included into upstream aeolus). fmasdr IOhannes +1 (or more if I could stuff the box, but as a long time broadcast engineer I use a toothpick for a rowing oar in this crowd) because its an everybody wins situation then. Cheers, Gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) My web page: http://gene.homelinux.net:6309/gene should be up! If you don't have time to do it right, where are you going to find the time to do it over? A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
Am 19.09.2013 16:50, schrieb IOhannes m zmoelnig: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-19 05:31, hermann meyer wrote: I'm sad to hear that. :-( Please don't let you lead from the things you didn't like, let you lead from the things you like instead. I guess then it's necessary to let you know that we use /as well/ a fork of your work, the zita-convolver library, in the guitarix project. But we leave your copyright untouched, and the fork will only come in use, when the user set a explicit compile flag. We didn't promote it, or force the fork. Ordinary your original code is in use. We do it to use ffmpeg instead fftw3 FFT, which perform better on ARM devices. but this sounds like the perfect opportunity to not do a simple fork, but to send patches to upstream so fons' aeolus could support both fftw3 and ffmpeg FFTs. it might be a win-win situation, where not only more than just the original aeolus users can profit from fons' work (because you use his code) but also more than just your users can profit from your work (because you changes are included into upstream aeolus). Sorry, you miss-match aeolus and zita-convolver here. As well, we didn't add ffmpeg support to zita-convolver, we replace fftw3 with ffmpeg, and only use this under special circumstances (ARM support), we didn't distribute it as zita-convolver library No useful patch is available. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
Am 19.09.2013 17:36, schrieb Fons Adriaensen:
On Thu, Sep 19, 2013 at 05:18:27PM +0200, hermann meyer wrote:
Sorry, you miss-match aeolus and zita-convolver here.
As well, we didn't add ffmpeg support to zita-convolver, we
replace fftw3 with ffmpeg, and only use this under special
circumstances (ARM support), we didn't distribute it as
zita-convolver library
IFF
* the only change is the fft library used,
* the full functionality and API of the original is preserved,
* and the modified library is kept in sync with the original one,
then I have no objections to it being called 'zita-convolver',
and I would even consider to merge the two (which would ensure
the third condition).
Ciao,
Hi Fons
I've attached the diff, for your review.
Some of the changes are not necessary needed, but handy for our use case.
Ignore please the #include gx_compiler.h and __rt_func
regards
hermann
diff -uN ./zita-convolver/README ./zita-convolver-ffmpeg/README
--- ./zita-convolver/README 2012-12-06 11:09:33.644204127 +0100
+++ ./zita-convolver-ffmpeg/README 2013-05-05 14:16:32.446644834 +0200
@@ -1,8 +1,3 @@
Files in this directory are from zita-convolver by
-Fons Adriaensen f...@kokkinizita.net
-
-Please refer to the version official archive
-http://kokkinizita.linuxaudio.org/linuxaudio/
-
-These files are only included to ease compilation
-and installion of Guitarix. Don't modify.
+Fons Adriaensen f...@kokkinizita.net, which changes
+to use ffmpeg FFT instead of fftw3.
diff -uN ./zita-convolver/zita-convolver.cc ./zita-convolver-ffmpeg/zita-convolver.cc
--- ./zita-convolver/zita-convolver.cc 2012-12-06 11:09:33.644204127 +0100
+++ ./zita-convolver-ffmpeg/zita-convolver.cc 2013-05-08 04:35:21.602005621 +0200
@@ -22,9 +22,13 @@
#include stdlib.h
#include string.h
#include stdio.h
+#include cmath
+extern C {
+#define __STDC_CONSTANT_MACROS // needed for UINT64_C (libavutil 0.8.6)
+#include libavutil/common.h
+}
#include zita-convolver.h
-
-
+#include gx_compiler.h
int zita_convolver_major_version (void)
{
@@ -38,7 +42,6 @@
Convproc::Convproc (void) :
_state (ST_IDLE),
-_options (0),
_skipcnt (0),
_density (0),
_ninp (0),
@@ -61,12 +64,6 @@
}
-void Convproc::set_options (unsigned int options)
-{
-_options = options;
-}
-
-
void Convproc::set_density (float density)
{
_density = density;
@@ -147,7 +144,7 @@
if (cfft d * cmac) npar = nmin;
}
_convlev [pind] = new Convlevel ();
- _convlev [pind]-configure (prio, offs, npar, size, _options);
+ _convlev [pind]-configure (prio, offs, npar, size);
offs += size * npar;
if (offs maxsize)
@@ -281,7 +278,7 @@
}
-int Convproc::process (bool sync)
+int __rt_func Convproc::process (bool sync)
{
unsigned int k;
int f = 0;
@@ -303,7 +300,6 @@
{
if (++_latecnt = 5)
{
- stop_process ();
f |= FL_LOAD;
}
}
@@ -354,7 +350,6 @@
}
_state = ST_IDLE;
-_options = 0;
_skipcnt = 0;
_density = 0;
_ninp = 0;
@@ -398,14 +393,11 @@
_stat (ST_IDLE),
_npar (0),
_parsize (0),
-_options (0),
_pthr (0),
_inp_list (0),
_out_list (0),
_plan_r2c (0),
_plan_c2r (0),
-_time_data (0),
-_prep_data (0),
_freq_data (0)
{
}
@@ -422,36 +414,28 @@
{
void *p;
-if (posix_memalign (p, 16, size)) throw (Converror (Converror::MEM_ALLOC));
+p = av_malloc(size);
memset (p, 0, size);
return p;
}
-
void Convlevel::configure (int prio,
unsigned int offs,
unsigned int npar,
- unsigned int parsize,
- unsigned int options)
+ unsigned int parsize)
{
-int fftwopt = (options OPT_FFTW_MEASURE) ? FFTW_MEASURE : FFTW_ESTIMATE;
-
_prio = prio;
_offs = offs;
_npar = npar;
_parsize = parsize;
-_options = options;
-_time_data = (float *)(alloc_aligned (2 * _parsize * sizeof (float)));
-_prep_data = (float *)(alloc_aligned (2 * _parsize * sizeof (float)));
_freq_data = (fftwf_complex *)(alloc_aligned ((_parsize + 1) * sizeof (fftwf_complex)));
-_plan_r2c = fftwf_plan_dft_r2c_1d (2 * _parsize, _time_data, _freq_data, fftwopt);
-_plan_c2r = fftwf_plan_dft_c2r_1d (2 * _parsize, _freq_data, _time_data, fftwopt);
+_plan_r2c = av_rdft_init (int(log2(2 * _parsize)), DFT_R2C);
+_plan_c2r = av_rdft_init (int(log2(2 * _parsize)), IDFT_C2R);
if (_plan_r2c _plan_c2r) return;
throw (Converror (Converror::MEM_ALLOC));
}
-
void Convlevel::impdata_create (unsigned int inp,
unsigned int out,
unsigned int step,
@@ -462,7 +446,7 @@
unsigned int k;
intj, j0, j1, n;
float norm;
-fftwf_complex *fftb;
+fftwf_complex *fftb;
Macnode*M;
n = i1 - i0;
@@ -477,7 +461,7
Re: [LAD] Aeolus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-19 17:18, hermann meyer wrote: Am 19.09.2013 16:50, schrieb IOhannes m zmoelnig: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-19 05:31, hermann meyer wrote: I'm sad to hear that. :-( Please don't let you lead from the things you didn't like, let you lead from the things you like instead. I guess then it's necessary to let you know that we use /as well/ a fork of your work, the zita-convolver library, in the guitarix project. But we leave your copyright untouched, and the fork will only come in use, when the user set a explicit compile flag. We didn't promote it, or force the fork. Ordinary your original code is in use. We do it to use ffmpeg instead fftw3 FFT, which perform better on ARM devices. but this sounds like the perfect opportunity to not do a simple fork, but to send patches to upstream so fons' aeolus could support both fftw3 and ffmpeg FFTs. it might be a win-win situation, where not only more than just the original aeolus users can profit from fons' work (because you use his code) but also more than just your users can profit from your work (because you changes are included into upstream aeolus). Sorry, you miss-match aeolus and zita-convolver here. ah yeah, sorry. pleas do s/aeolus/zita-convolver/g in my answer. As well, we didn't add ffmpeg support to zita-convolver, we replace fftw3 with ffmpeg, and only use this under special circumstances (ARM support), i'm not sure what you mean. zita-convolver depends on FFTW3 for doing the FFTs. if you replace fftw3 with ffmpeg, you create modifications to zita-convolves to not use fftw3 anymore (in some special circumstances), and instead use ffmpeg's FFT (whether as a library or statically compiled in). in any case, this seems to be a substantial change to some parts of zita-convolver, so you should definitely add your copyright to the files you modified (substantially). we didn't distribute it as zita-convolver library so? it seems that you did distribute it in some form (else what are we talking about?). MuseScore doesn't distribute a disfigured version of Aeolus in order to pile praise upon themselves and/or to denounce fons. they distribute MuseScore which comes bundled with a version of Aeolus that integrates into their system. similar goes for Maurizio: he has a project called oscAeolus which makes it quite clear that it is a derivative of Aeolus (and not the real thing itself). No useful patch is available. i didn't say that contributing is easy. more often than not it requires a lot of work and interaction with upstream until you have prepared a patch that can be accepted. what i did say is that you should make a useful patch available. i'd love to see a zita-reverb that performs ideally on all platforms (and that unfortunately includes ARM-systems by now) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlI7HScACgkQkX2Xpv6ydvTf7wCffveaT7UQIrfEHbEggjOQ49YY N7IAoMFG7gtNrnts7zpuA8RLUEbklhkx =wc/9 -END PGP SIGNATURE- ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
Am 19.09.2013 18:57, schrieb hermann meyer: Am 19.09.2013 17:50, schrieb IOhannes m zmoelnig: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-19 17:18, hermann meyer wrote: Am 19.09.2013 16:50, schrieb IOhannes m zmoelnig: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-19 05:31, hermann meyer wrote: I'm sad to hear that. :-( Please don't let you lead from the things you didn't like, let you lead from the things you like instead. I guess then it's necessary to let you know that we use /as well/ a fork of your work, the zita-convolver library, in the guitarix project. But we leave your copyright untouched, and the fork will only come in use, when the user set a explicit compile flag. We didn't promote it, or force the fork. Ordinary your original code is in use. We do it to use ffmpeg instead fftw3 FFT, which perform better on ARM devices. but this sounds like the perfect opportunity to not do a simple fork, but to send patches to upstream so fons' aeolus could support both fftw3 and ffmpeg FFTs. it might be a win-win situation, where not only more than just the original aeolus users can profit from fons' work (because you use his code) but also more than just your users can profit from your work (because you changes are included into upstream aeolus). Sorry, you miss-match aeolus and zita-convolver here. ah yeah, sorry. pleas do s/aeolus/zita-convolver/g in my answer. As well, we didn't add ffmpeg support to zita-convolver, we replace fftw3 with ffmpeg, and only use this under special circumstances (ARM support), i'm not sure what you mean. zita-convolver depends on FFTW3 for doing the FFTs. if you replace fftw3 with ffmpeg, you create modifications to zita-convolves to not use fftw3 anymore (in some special circumstances), and instead use ffmpeg's FFT (whether as a library or statically compiled in). in any case, this seems to be a substantial change to some parts of zita-convolver, so you should definitely add your copyright to the files you modified (substantially). No, a disclaimer in the source tree which clarify this will be enough. we didn't distribute it as zita-convolver library so? it seems that you did distribute it in some form (else what are we talking about?). MuseScore doesn't distribute a disfigured version of Aeolus in order to pile praise upon themselves and/or to denounce fons. they distribute MuseScore which comes bundled with a version of Aeolus that integrates into their system. similar goes for Maurizio: he has a project called oscAeolus which makes it quite clear that it is a derivative of Aeolus (and not the real thing itself). That's why I wrote On 2013-09-19 05:31, hermann meyer wrote: I guess then it's necessary to let you know that we use/as well/ a fork of your work, the zita-convolver library, in the guitarix project. we do exactly the same, we modify the source to our needs. EDIT: Sorry, not exactly the same, we contacted Fons before we start to use/include his work in our project. We have done the same with zita-resampler for some time, as long Fons takes to include the provided patch. No useful patch is available. i didn't say that contributing is easy. more often than not it requires a lot of work and interaction with upstream until you have prepared a patch that can be accepted. what i did say is that you should make a useful patch available. This is pretty new, and we have a lot stuff where we are working on. ;-) I could provide a diff, which shows the changes. i'd love to see a zita-reverb that performs ideally on all platforms (and that unfortunately includes ARM-systems by now) I'm not aware of any relation between zita-reverb and zita-convolver. greets hermann ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
Am 19.09.2013 17:50, schrieb IOhannes m zmoelnig: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-19 17:18, hermann meyer wrote: Am 19.09.2013 16:50, schrieb IOhannes m zmoelnig: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-19 05:31, hermann meyer wrote: I'm sad to hear that. :-( Please don't let you lead from the things you didn't like, let you lead from the things you like instead. I guess then it's necessary to let you know that we use /as well/ a fork of your work, the zita-convolver library, in the guitarix project. But we leave your copyright untouched, and the fork will only come in use, when the user set a explicit compile flag. We didn't promote it, or force the fork. Ordinary your original code is in use. We do it to use ffmpeg instead fftw3 FFT, which perform better on ARM devices. but this sounds like the perfect opportunity to not do a simple fork, but to send patches to upstream so fons' aeolus could support both fftw3 and ffmpeg FFTs. it might be a win-win situation, where not only more than just the original aeolus users can profit from fons' work (because you use his code) but also more than just your users can profit from your work (because you changes are included into upstream aeolus). Sorry, you miss-match aeolus and zita-convolver here. ah yeah, sorry. pleas do s/aeolus/zita-convolver/g in my answer. As well, we didn't add ffmpeg support to zita-convolver, we replace fftw3 with ffmpeg, and only use this under special circumstances (ARM support), i'm not sure what you mean. zita-convolver depends on FFTW3 for doing the FFTs. if you replace fftw3 with ffmpeg, you create modifications to zita-convolves to not use fftw3 anymore (in some special circumstances), and instead use ffmpeg's FFT (whether as a library or statically compiled in). in any case, this seems to be a substantial change to some parts of zita-convolver, so you should definitely add your copyright to the files you modified (substantially). No, a disclaimer in the source tree which clarify this will be enough. we didn't distribute it as zita-convolver library so? it seems that you did distribute it in some form (else what are we talking about?). MuseScore doesn't distribute a disfigured version of Aeolus in order to pile praise upon themselves and/or to denounce fons. they distribute MuseScore which comes bundled with a version of Aeolus that integrates into their system. similar goes for Maurizio: he has a project called oscAeolus which makes it quite clear that it is a derivative of Aeolus (and not the real thing itself). That's why I wrote On 2013-09-19 05:31, hermann meyer wrote: I guess then it's necessary to let you know that we use/as well/ a fork of your work, the zita-convolver library, in the guitarix project. we do exactly the same, we modify the source to our needs. We have done the same with zita-resampler for some time, as long Fons takes to include the provided patch. No useful patch is available. i didn't say that contributing is easy. more often than not it requires a lot of work and interaction with upstream until you have prepared a patch that can be accepted. what i did say is that you should make a useful patch available. This is pretty new, and we have a lot stuff where we are working on. ;-) I could provide a diff, which shows the changes. i'd love to see a zita-reverb that performs ideally on all platforms (and that unfortunately includes ARM-systems by now) I'm not aware of any relation between zita-reverb and zita-convolver. greets hermann ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
On 09/19/13 18:57, hermann meyer wrote: i'd love to see a zita-reverb that performs ideally on all platforms (and that unfortunately includes ARM-systems by now) I'm not aware of any relation between zita-reverb and zita-convolver. oh darn. there's so much cool software by fons that i keep mixing all the names. in any case, i hope you got what i meant. fgmasrd IOhannes signature.asc Description: OpenPGP digital signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
On Thu, 2013-09-19 at 15:36 +0100, James Morris wrote: On 18/09/13 Fons Adriaensen f...@linuxaudio.org wrote: ... If this is typical for the attitude taken by the Linux Audio community then my motivation to contribute to it will take a serious blow. Well you've been a member of the Linux Audio community as long as anyone, you should know if this is the typical attitude taken by the Community... I wonder that there is such a long discussion on two mailing lists, but seemingly the coder/coders never were contacted. Assumed Maurizio M. Gavioli or anybody else should do something wrong, then why not simply contact him/them and ask him/them not to continue to do something wrong? Perhaps this does help: https://github.com/mgavioli/oscAeolus/issues/1 IMO Maurizio M. Gavioli and Fons should talk to each other. Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
On Wed, Sep 18, 2013 at 2:16 PM, Fons Adriaensen f...@linuxaudio.orgwrote: Hello all, It has come to my attention that there are ATM at least two 'forks' of Aeolus. The first by the MuseScore team, the second by one Maurizio Gavioli. Neither of them even had the decency to let me know of their work, and both are taking Aeolus in a direction I do not approve of. Gavioli has even added his 'copyright' to the sources of the libraries that Aeolus depends on but which are not part of its source distribution. Apparently the intention is to release incompatible versions of those as well. If this is typical for the attitude taken by the Linux Audio community then my motivation to contribute to it will take a serious blow. As announced previously, there will be a fully reworked release of Aeolus next year (on the occasion of its 10th birthday). Apart from major improvements to the audio code it will be completely OSC controlled. None of this will be compatible with the forks of course, they'll find themselves instantly obsolete. And I will make sure that this sort of thing won't happen again, even if that means a more restrictive license. Ciao, Respectfully, you granted people the right to fork your code in the first place. Now you say you might take this right away, but why? How has it harmed you or anyone else? Why should you have been notified that a fork took place? The whole point of free software is that people can adapt it to their needs and share their changes with those with similar needs. If those forks are better suited to the task at hand than your original code, then people may well use them (and that's a good thing!). If your new release is better, people may well use that. Isn't that the point? To help people? Plus, if the forks did/do make any improvements that you value, hey, that's great merge them, not that I think you'd ever do that ;-) We can't all be all things to everybody all the time. The value of your projects isn't necessarily in the complete package with your name on it. If someone takes your engine and slaps a new interface on it that people like better, well, they still use your engine, right? It's hard to put your ego aside sometimes, but I really recommend that you do. You've contributed a lot to Linux Audio and I'd hate to see that ruined by bruised egos and non-free licenses. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
On Wed, 18 Sep 2013 14:29:02 -0700 J. Liles malnour...@gmail.com wrote: On Wed, Sep 18, 2013 at 2:16 PM, Fons Adriaensen f...@linuxaudio.orgwrote: Hello all, It has come to my attention that there are ATM at least two 'forks' of Aeolus. The first by the MuseScore team, the second by one Maurizio Gavioli. Neither of them even had the decency to let me know of their work, and both are taking Aeolus in a direction I do not approve of. Gavioli has even added his 'copyright' to the sources of the libraries that Aeolus depends on but which are not part of its source distribution. Apparently the intention is to release incompatible versions of those as well. If this is typical for the attitude taken by the Linux Audio community then my motivation to contribute to it will take a serious blow. As announced previously, there will be a fully reworked release of Aeolus next year (on the occasion of its 10th birthday). Apart from major improvements to the audio code it will be completely OSC controlled. None of this will be compatible with the forks of course, they'll find themselves instantly obsolete. And I will make sure that this sort of thing won't happen again, even if that means a more restrictive license. Ciao, Respectfully, you granted people the right to fork your code in the first place. Now you say you might take this right away, but why? How has it harmed you or anyone else? Why should you have been notified that a fork took place? The whole point of free software is that people can adapt it to their needs and share their changes with those with similar needs. If those forks are better suited to the task at hand than your original code, then people may well use them (and that's a good thing!). If your new release is better, people may well use that. Isn't that the point? To help people? Plus, if the forks did/do make any improvements that you value, hey, that's great merge them, not that I think you'd ever do that ;-) We can't all be all things to everybody all the time. The value of your projects isn't necessarily in the complete package with your name on it. If someone takes your engine and slaps a new interface on it that people like better, well, they still use your engine, right? It's hard to put your ego aside sometimes, but I really recommend that you do. You've contributed a lot to Linux Audio and I'd hate to see that ruined by bruised egos and non-free licenses. This is not about ego, it is about politness are recognition. A part of the motivation of creating open source software of any kind is creating a brand name from your name. Because there is no other positive feedback then happy users and the usage of your software. Other commercial things like getting paid, a pat on the back from your boss, some magazine prizes or whatever usually don't happen. And of course forks are an important part of the open source culture and there are many reasons to create a fork. But if you do it be polite and nice and notify the original author so she or he (in this case fons) can port back interesting or good changes. Especially in a scene and community like Linux Audio where it is actually possible to know most of the persons names and projects by name. I don't think that is too much to ask for. I look forward to the new Aeolus version. Thank you, please keep up the good work Fons. Many people (I know personally) use your software and are very statisfied. Me included. Nils http://www.laborejo.org ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
What, my way or the djb way? On 9/19/13, Nils Gey i...@nilsgey.de wrote: On Wed, 18 Sep 2013 14:29:02 -0700 J. Liles malnour...@gmail.com wrote: On Wed, Sep 18, 2013 at 2:16 PM, Fons Adriaensen f...@linuxaudio.orgwrote: Hello all, It has come to my attention that there are ATM at least two 'forks' of Aeolus. The first by the MuseScore team, the second by one Maurizio Gavioli. Neither of them even had the decency to let me know of their work, and both are taking Aeolus in a direction I do not approve of. Gavioli has even added his 'copyright' to the sources of the libraries that Aeolus depends on but which are not part of its source distribution. Apparently the intention is to release incompatible versions of those as well. If this is typical for the attitude taken by the Linux Audio community then my motivation to contribute to it will take a serious blow. As announced previously, there will be a fully reworked release of Aeolus next year (on the occasion of its 10th birthday). Apart from major improvements to the audio code it will be completely OSC controlled. None of this will be compatible with the forks of course, they'll find themselves instantly obsolete. And I will make sure that this sort of thing won't happen again, even if that means a more restrictive license. Ciao, Respectfully, you granted people the right to fork your code in the first place. Now you say you might take this right away, but why? How has it harmed you or anyone else? Why should you have been notified that a fork took place? The whole point of free software is that people can adapt it to their needs and share their changes with those with similar needs. If those forks are better suited to the task at hand than your original code, then people may well use them (and that's a good thing!). If your new release is better, people may well use that. Isn't that the point? To help people? Plus, if the forks did/do make any improvements that you value, hey, that's great merge them, not that I think you'd ever do that ;-) We can't all be all things to everybody all the time. The value of your projects isn't necessarily in the complete package with your name on it. If someone takes your engine and slaps a new interface on it that people like better, well, they still use your engine, right? It's hard to put your ego aside sometimes, but I really recommend that you do. You've contributed a lot to Linux Audio and I'd hate to see that ruined by bruised egos and non-free licenses. This is not about ego, it is about politness are recognition. A part of the motivation of creating open source software of any kind is creating a brand name from your name. Because there is no other positive feedback then happy users and the usage of your software. Other commercial things like getting paid, a pat on the back from your boss, some magazine prizes or whatever usually don't happen. And of course forks are an important part of the open source culture and there are many reasons to create a fork. But if you do it be polite and nice and notify the original author so she or he (in this case fons) can port back interesting or good changes. Especially in a scene and community like Linux Audio where it is actually possible to know most of the persons names and projects by name. I don't think that is too much to ask for. I look forward to the new Aeolus version. Thank you, please keep up the good work Fons. Many people (I know personally) use your software and are very statisfied. Me included. Nils http://www.laborejo.org ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
I agree with Nils 100%. Fons mentions the second fork seems to be changing the license. Both situations are ignorant of the spirit of FOSS in my opinion. If you go commercial let me know. I'll buy everything you make ! g Sent from my smartphone. Original message From: Fons Adriaensen f...@linuxaudio.org Date: 19/09/2013 7:16 AM (GMT+10:00) To: Linux Audio Users linux-audio-u...@lists.linuxaudio.org,Linux Audio Developers linux-audio-dev@lists.linuxaudio.org Subject: [LAD] Aeolus Hello all, It has come to my attention that there are ATM at least two 'forks' of Aeolus. The first by the MuseScore team, the second by one Maurizio Gavioli. Neither of them even had the decency to let me know of their work, and both are taking Aeolus in a direction I do not approve of. Gavioli has even added his 'copyright' to the sources of the libraries that Aeolus depends on but which are not part of its source distribution. Apparently the intention is to release incompatible versions of those as well. If this is typical for the attitude taken by the Linux Audio community then my motivation to contribute to it will take a serious blow. As announced previously, there will be a fully reworked release of Aeolus next year (on the occasion of its 10th birthday). Apart from major improvements to the audio code it will be completely OSC controlled. None of this will be compatible with the forks of course, they'll find themselves instantly obsolete. And I will make sure that this sort of thing won't happen again, even if that means a more restrictive license. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
On Wed, Sep 18, 2013 at 02:29:02PM -0700, J. Liles wrote: Respectfully, you granted people the right to fork your code in the first place. Yes, and now I know that was a mistake. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Aeolus
Am 19.09.2013 00:28, schrieb Fons Adriaensen: On Wed, Sep 18, 2013 at 02:29:02PM -0700, J. Liles wrote: Respectfully, you granted people the right to fork your code in the first place. Yes, and now I know that was a mistake. Ciao, I'm sad to hear that. :-( Please don't let you lead from the things you didn't like, let you lead from the things you like instead. I guess then it's necessary to let you know that we use /as well/ a fork of your work, the zita-convolver library, in the guitarix project. But we leave your copyright untouched, and the fork will only come in use, when the user set a explicit compile flag. We didn't promote it, or force the fork. Ordinary your original code is in use. We do it to use ffmpeg instead fftw3 FFT, which perform better on ARM devices. We do our best to let all users know that it is your work, which comes in use for the convolution. I really hope you re-think your stance and keep going with the GPL to enable Forks of your work, instead force us to re-invent the wheel. greets hermann ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
