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
[LAD] forking (was Re: Aeolus)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-18 23:54, geoff wrote: Fons mentions the second fork seems to be changing the license. hold your horses. Fons said: 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 now what does this mean? i would read adding his copyright as adding a line 'Copyright (c) 2013 Joe Mubara'. this is *not* changing any license. it is claiming to have contributed code to the given file. but this is my personal reading of Fons' statement. since he has been very vague about the actual fork, i did a quick google, and found https://github.com/mgavioli/oscAeolus/ i didn't bother to checkout the entire project, so instead i just sampled a few source-files and in oscaeolus/addsynth.cpp i found indeed the lines: Copyright(C) 2003-2008 Fons Adriaensen f...@kokkinizita.net Copyright(C) 2013 Maurizio M. Gavioli m...@vistamaresoft.com i compared that to the aeolus source-code as shipped in debian (as i was too lazy to go to Fons' homepage) and find that the two files are virtually identical, apart from a rename (.cc - .cpp), a different indentation style and the said added copyright. i'm pretty sure that maurizio's contributions do not justify the added copyright. Both situations are ignorant of the spirit of FOSS in my opinion. in which ways? i'm not following either MuseScore nor Maurizio's development, but i *guess* that: - - Maurizio's fork is an experiment; he took the code and tried out how far he could push the project to his needs; the project has been active for *1 month* (during June), and has been dormant since. the only problem is see, is that Maurizio has made his changes available to the world, by putting it on github. i fail to see how this is ignorant of the spirit of FOSS. - - MuseScore *probably* included Aeolus originally for convenience reasons (so their users' only need to download a single package). once you have done *that* , it's darn easy to do your little amendments to the swallowed software (to fit better into their framework) without really thinking about it anymore. and then you have the curse of FLOSS: because MuseScore publishes their code (just like upstream) it becomes obvious that they forked! again: how ignorant is that? nevertheless i do share some feelings with fons. as an upstream developer myself (though not as successful as fons in whatever i publish), it happens every now and then, that somebody takes my code and does things to it. this has become even more apparent since i started using github, which provides information about people who forked the project on-site (which doesn't tell me anything about who else forked the project). i have to admit, that it often hurts a little bit, if a project gets forked and the forker never ever communicated with upstream about their desires, and whether it would be possible to integrate them directly into upstream. one thing i found crucial here is how to encourage potential contributors to actually contribute to the code (rather than fork it silently). (it became weirder in github times, as i now can see how many people (not really many) people create a public fork without *ever* doing anything to it...what is that about?) mfgadsrt IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlI7Gc4ACgkQkX2Xpv6ydvRxqQCbB5Ju29pej++94vcMi25yZqT5 lDgAn38oq+Bf3qfMBc7djR3gxrIMvXZq =aJA6 -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] forking (was Re: Aeolus)
On Thu, Sep 19, 2013 at 05:35:45PM +0200, IOhannes m zmoelnig wrote: i compared that to the aeolus source-code as shipped in debian (as i was too lazy to go to Fons' homepage) and find that the two files are virtually identical, apart from a rename (.cc - .cpp), a different indentation style and the said added copyright. And in some files, renaming variables to 'hungarian' style. Which pretty much excludes the possibility of any 'improvements' being integrated with the original. i'm pretty sure that maurizio's contributions do not justify the added copyright. Plus that in order to to do what he claims (provide an OSC interface) you don't need to touch this file at all, it's part of the DSP code. Aeolus already has a pretty complete separation of DSP and GUI, the latter technically being a plugin and communicating with the rest via asynchronous messages only. So to OSC-ify Aeolus you only need to write a new plugin. 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] forking (was Re: Aeolus)
On Thu, 19 Sep 2013 17:35:45 +0200, IOhannes m zmoelnig wrote Fons said: 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 now what does this mean? i would read adding his copyright as adding a line 'Copyright (c) 2013 Joe Mubara'. this is *not* changing any license. it is claiming to have contributed code to the given file. Yes, and why shouldn't it? I read it as a marker to show which files have been changed. but this is my personal reading of Fons' statement. since he has been very vague about the actual fork, i did a quick google, and found https://github.com/mgavioli/oscAeolus/ i didn't bother to checkout the entire project, so instead i just sampled a few source-files and in oscaeolus/addsynth.cpp i found indeed the lines: Copyright(C) 2003-2008 Fons Adriaensen f...@kokkinizita.net Copyright(C) 2013 Maurizio M. Gavioli m...@vistamaresoft.com i compared that to the aeolus source-code as shipped in debian (as i was too lazy to go to Fons' homepage) and find that the two files are virtually identical, apart from a rename (.cc - .cpp), a different indentation style and the said added copyright. i'm pretty sure that maurizio's contributions do not justify the added copyright. Well, I would take it as a _marker_ - a small side rant: since non of the original code is trakable with some version control system (svn/git/bzr/hg...) I think it's a good idea to add such markers. I've local modifications to Aeolus and that's exactly how I mark the files I changed. With a working VCS a simple 'git diff' of 'git blame' could tell you what and how the original was changed (and, with a caring coder, the commit messages would explain why those changes were made). And of course, for every update of Aeolus I have to hand-patch my local changes into uptream insteda of a simple 'git merge' (or the hg/svn equivalent). Both situations are ignorant of the spirit of FOSS in my opinion. in which ways? i'm not following either MuseScore nor Maurizio's development, but i *guess* that: - - Maurizio's fork is an experiment; he took the code and tried out how far he could push the project to his needs; the project has been active for *1 month* (during June), and has been dormant since. the only problem is see, is that Maurizio has made his changes available to the world, by putting it on github. i fail to see how this is ignorant of the spirit of FOSS. Au contraire - FOSS is all about sharing. When I read Fon's mail yesterday evening I got the impression of an agressive/inpolite fork, but after looking at the source code I fail to see this. The readme/webpage explicitly mentions the upstream project and Fons' authorship. What else could the author have done? Inform Fons? Maybe, but maybe he considered the project to young/un- official. Where _would_ you put a project to share with co-coders, iff not on github? Somehow I fail to see the crime commited ... Adding an OSC interface to Aeolus seems a usefull adition - after all, isn't Fons planning to add one? nevertheless i do share some feelings with fons. as an upstream developer myself (though not as successful as fons in whatever i publish), it happens every now and then, that somebody takes my code and does things to it. this has become even more apparent since i started using github, which provides information about people who forked the project on-site (which doesn't tell me anything about who else forked the project). i have to admit, that it often hurts a little bit, if a project gets forked and the forker never ever communicated with upstream about their desires, and whether it would be possible to integrate them directly into upstream. one thing i found crucial here is how to encourage potential contributors to actually contribute to the code (rather than fork it silently). Sometimes the tone on the mailing list (and comments about the required quality of coding) make such enquiries seem daunting ... ;-) Anyqay, just my 0.02$ Cheers, RalfD ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] forking (was Re: Aeolus)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-19 17:45, Fons Adriaensen wrote: On Thu, Sep 19, 2013 at 05:35:45PM +0200, IOhannes m zmoelnig wrote: i compared that to the aeolus source-code as shipped in debian (as i was too lazy to go to Fons' homepage) and find that the two files are virtually identical, apart from a rename (.cc - .cpp), a different indentation style and the said added copyright. And in some files, renaming variables to 'hungarian' style. Which pretty much excludes the possibility of any 'improvements' being integrated with the original. :-) i'm pretty sure that maurizio's contributions do not justify the added copyright. Plus that in order to to do what he claims (provide an OSC interface) you don't need to touch this file at all, it's part of the DSP code. Aeolus already has a pretty complete separation of DSP and GUI, the latter technically being a plugin and communicating with the rest via asynchronous messages only. So to OSC-ify Aeolus you only need to write a new plugin. i'm not saying that he improved Aeolus, in general. i *think* he was making it do something that it did not yet (with the new 10th anniversary aeolus not yet being available), and he used his own coding conventions (however inferior they are) if FLOSS is *only* about making perfect software by improving giants, it becomes a little bit too neo-liberal for my taste. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlI7HtIACgkQkX2Xpv6ydvRyNQCcDIo5Y5JNJGzCkXnpUHrLmQoQ rVQAoL2NqFFY2MYP0tH9tNav6YIO5PXW =iALT -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 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] forking (was Re: Aeolus)
On Thu, 19 Sep 2013 17:35:45 +0200 IOhannes m zmoelnig zmoel...@iem.at wrote: (it became weirder in github times, as i now can see how many people (not really many) people create a public fork without *ever* doing anything to it...what is that about?) Just a quick response. The fork on github is AFAIK intended for something else. Not for stealing and rebranding an entire project but for maintaining a working copy which then can ask for pull requests upstream, conveniently managed by github and made possible by the de-central git philosophy. Also: The fork button there is easy to click by accident and it is inconvenient to remove such a fork from your account. So sometimes forks appear and do nothing, just because someone clicked the wrong button. Nils ___ 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] forking (was Re: Aeolus)
On 09/19/13 17:57, IOhannes m zmoelnig wrote: if FLOSS is *only* about making perfect software by improving giants, it becomes a little bit too neo-liberal for my taste. in any case, FLOSS for me is also about a lot about learning. i know only a single effective way to learn to code, and that is by getting your hands dirty: no amount of books and *reading* code will ever teach you anything. you have to write code. and if you don't want to keep writing 99 bottles of beer on the wall, you probably should get some decently written project and hack your way in. and i'm sure that when it comes to decently written software, there are a lot worse projects someone could choose than aeolus. so my hope is, that whoever forks aeolus will learn more than just appropriating others' code. hopefully some time they will even learn how to properly name variables. fmgasdr IOhannes PS: i'm getting a bit too patronizing for my taste. should get some sleep... 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] forking (was Re: Aeolus)
On Thu, Sep 19, 2013 at 06:01:42PM +0200, R. Mattes wrote: Yes, and why shouldn't it? I read it as a marker to show which files have been changed. There is world of difference (also legally) between Copyright (c) xx' and Additional code/modifications by x Well, I would take it as a _marker_ Like a dog pissing on a lamppost, or some juvenile spraying his tags on someone else's property ? And of course, for every update of Aeolus I have to hand-patch my local changes into uptream insteda of a simple 'git merge' (or the hg/svn equivalent). Of course. If you don't bother to let me known what changes you require, even if they may be of interest to others, why should I care ? Au contraire - FOSS is all about sharing. That is one aspect of it, and one that by definition should go both ways. Sometimes the tone on the mailing list (and comments about the required quality of coding) make such enquiries seem daunting ... ;-) And that is entirely intentional. What do you expect ? Try and go to your whatever - baker, sports team, bar keeper... and tell them you can instantly improve what they do. Maybe they'll listen. But chances are 99.9% that they will tell you to learn your trade first and then come back. 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] forking (was Re: Aeolus)
On Thu, Sep 19, 2013 at 2:05 PM, Fons Adriaensen f...@linuxaudio.org wrote: There is world of difference (also legally) between Copyright (c) xx' and Additional code/modifications by x On Sep 19, 2013, at 17:22 03, J. Liles wrote: Fons, I've been around the free-software block a time or two and I have to say I have never *once* encountered the latter form of notation. Adding a Copyright (c) line with dates is the standard practice, but (obviously?) only to files that have actually been altered significantly. Anyone interested (even those weasely lawyers) can run a diff against the two codebases to see what was actually changed. FWIW, I have come across both notations in the wild, and have even done (been guilty of?) both practices myself. Personally, I would certainly never add a copyright notice to a file to which I had made no substantive change, but I have done so on files to which I have made significant modifications (being careful to preserve the original attributions and copyright notice(s) in the process). So it would seem that this may be a gray area. My own inclination therefore would be to cut the offenders some slack. We were all new at this at one point or another -- it'd be a shame to see one's work closed down over something like this. Cheers! |-| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-| | A strong conviction that something must be done is the parent of many | | bad measures. | | -- Daniel Webster | |-| ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] forking (was Re: Aeolus)
On Thu, Sep 19, 2013 at 2:05 PM, Fons Adriaensen f...@linuxaudio.orgwrote: On Thu, Sep 19, 2013 at 06:01:42PM +0200, R. Mattes wrote: Yes, and why shouldn't it? I read it as a marker to show which files have been changed. There is world of difference (also legally) between Copyright (c) xx' and Additional code/modifications by x Fons, I've been around the free-software block a time or two and I have to say I have never *once* encountered the latter form of notation. Adding a Copyright (c) line with dates is the standard practice, but (obviously?) only to files that have actually been altered significantly. Anyone interested (even those weasely lawyers) can run a diff against the two codebases to see what was actually changed. Well, I would take it as a _marker_ Like a dog pissing on a lamppost, or some juvenile spraying his tags on someone else's property ? Who cares? Yes, that's the first thing a young, naive developer is going to do. Fork some big project with grand intentions, go ahead and smear his filty moniker all over the source, and then nothing. Nobody would have ever even known about this fork if you hadn't brought it up. It would only become relevant if it actually offered something you don't. And on what grounds would you prevent that? Because making something better is somehow perverting it? That's life. No ill will here, Fons, but I hope you don't think you'll live forever. One day you'll be gone and somebody will get their filthy mits on your code. That's better than having it die with you, don't you think? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] forking (was Re: Aeolus)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 19 Sep 2013 17:35:45 +0200 IOhannes m zmoelnig zmoel...@iem.at wrote: (it became weirder in github times, as i now can see how many people (not really many) people create a public fork without *ever* doing anything to it...what is that about?) Creating a fork and not doing anything: Either the local experiments didn't work out. Or one needs just a stable(*) version at a certain url for personal use. (*) stable in the sense that its not changing or going away unexpectedly. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlI7hPAACgkQuYLL1cDjHx298QCdGcEbIyvFy2nds8Z4hUJlcl+e EUcAnA1zVwNxi7zRoVPGGSiewhCuXnHQ =dgus -END PGP SIGNATURE- ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] forking (was Re: Aeolus)
On Thu, Sep 19, 2013 at 7:12 PM, Arnold Krille arn...@arnoldarts.de wrote: (it became weirder in github times, as i now can see how many people (not really many) people create a public fork without *ever* doing anything to it...what is that about?) Creating a fork and not doing anything: Either the local experiments didn't work out. Or one needs just a stable(*) version at a certain url for personal use. it is also much easier for project maintainers to handle pull requests than simple patches, which means that someone having their own fork on github can actually be doing the project a service, rather than seeking to split from it. --p ___ 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
