First message

[João Felipe Santos]

Hello everybody, and thank you for joining this list!

Just trying to sum up everything that was discussed at julia-dev so far:

1. the package KDSP.jl has to be updated to work with Julia 0.2.0 (it will be also renamed to DSP.jl since this package does not exist anymore). This includes both dropping redundant functions (FFTs, correlations, etc) and making sure everything else works with the current standard library implementations.

2. The initial idea is to have DSP.jl as a base package with things that are related to signal processing but domain-independent (FIR/IIR filter design, spectrograms, periodograms, etc), and develop separate packages for each domain/subdomain.

3. Licensing: as Simon pointed out, during a previous discussion (https://groups.google.com/forum/#!topic/julia-dev/XLnlzzM5LEg) it was suggested that in case we need to port code from other libraries, it is better to port it from projects with less-restrictive licenses (BSD and MIT, for example). One suggestion was to port code from SciPy, which is BSD-licensed. He adds: "If there are cases where we need the Octave code and can't get the original contributors to license it under a less restrictive license (even LGPL is better, since it makes it possible to call the code from non-GPL code) then we should probably put it in a separate package."

4. Some current work on different audio DSP algorithms:
- Spencer Russell: audio segmentation/onset detection (no releases yet)
- David van Leeuwen: speech recognition (https://github.com/davidavdav/elftal) (note: his code is currently licensed as GPL, and at least a part has to be, as he ported some code from Octave)
- João Felipe Santos: auditory filters (https://github.com/jfsantos/auditory.jl) (currently, a gammatone filterbank implementation based on Malcolm Slaney's auditory toolbox and a modulation filterbank are implemented).
- Howard Mao: PortAudio wrappers (https://github.com/zhemao/Bebop.jl) (to enable playing/recording audio from Julia).

5. Following the example from the JuliaStats folks, I created a JuliaDSP "organization" at Github, which currently hosts a fork of kDSP.jl (https://github.com/JuliaDSP/DSP.jl). I guess we'll have to add everybody who's interested in contributing with packages, but if all you want is submitting pull requests, you don't need to be added to the organization. Is that correct? It is actually the first time I've done such a thing at Github.

[Simon Kornblith]

On Wednesday, November 27, 2013 11:13:23 PM UTC-5, João Felipe Santos wrote:

Hello everybody, and thank you for joining this list!

Just trying to sum up everything that was discussed at julia-dev so far:

1. the package KDSP.jl has to be updated to work with Julia 0.2.0 (it will be also renamed to DSP.jl since this package does not exist anymore). This includes both dropping redundant functions (FFTs, correlations, etc) and making sure everything else works with the current standard library implementations.

I just submitted a PR that does the first part, but we still need to make sure everything works.

2. The initial idea is to have DSP.jl as a base package with things that are related to signal processing but domain-independent (FIR/IIR filter design, spectrograms, periodograms, etc), and develop separate packages for each domain/subdomain.

Sounds good to me. I also have a bunch of code in https://github.com/simonster/FrequencyDomainAnalysis.jl that should be split up along these lines. The DPSS code and some version of the multitaper code probably belong in DSP.jl (although the version there is designed to handle accumulation of arbitrary statistics across large datasets, which may be more complex than is desirable for the core package); the continuous wavelet transform code probably belongs in a separate package; and then there are a lot of measures of signal "synchrony" that may not be all that applicable outside of biological signal processing. I also have some other code not in that package that may be of general interest (e.g. overlap-save FIR filtering).

5. Following the example from the JuliaStats folks, I created a JuliaDSP "organization" at Github, which currently hosts a fork of kDSP.jl (https://github.com/JuliaDSP/DSP.jl). I guess we'll have to add everybody who's interested in contributing with packages, but if all you want is submitting pull requests, you don't need to be added to the organization. Is that correct? It is actually the first time I've done such a thing at Github.

Anyone can submit pull requests, but only people who are members of the organization with push permission on a given repository to can commit code, merge pull requests, and close bugs.

Simon

[João Felipe Santos]

Thanks for the pull request, Simon, amazing job. I'll merge everything during the weekend. I am also wondering on how we should do the tests so we can add some to DSP.jl. One thing I use to do is use PyCall with Scipy for running tests and comparing the results (e.g., design a bandpass with these requirements using a Butterworth approx. in Julia and Python and compare the coefficients). Having a bunch of known fixed filter coefficients for comparison is a simpler approach that may also work well. I'll take a look at Scipy's repository to see if I can figure out how do they do this kind of test.

I agree that Wavelets should be added to a separate package, as one can go really far in the implementation of different wavelet families, discrete/continuous transforms, etc.

--
João Felipe Santos

--
You received this message because you are subscribed to the Google Groups "julia-dsp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to julia-dsp+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[David van Leeuwen]

Hello, 

On Thursday, November 28, 2013 5:13:23 AM UTC+1, João Felipe Santos wrote:

Hello everybody, and thank you for joining this list!

Just trying to sum up everything that was discussed at julia-dev so far:

4. Some current work on different audio DSP algorithms:

- David van Leeuwen: speech recognition (https://github.com/davidavdav/elftal) (note: his code is currently licensed as GPL, and at least a part has to be, as he ported some code from Octave)

I have attempted to split the code in separate packages, for reasons of functionality and code source (and hence license)

 - signalprocessing (a bare minimum of missing routines, modeled after matlab (which is a trademark) API, recoded from Octave, GPL)

 - speech feature extraction (recoded from rastamat, 2-clause BSD)

 - feature processing (deltas, warping, original work)

 - feature modeling (GMMs, original work) 

Concerning licenses, I can only change these for the last two if there would be the need (currently GPLv2).   If you'd want to be GPL-free (a new use of the word "free" here) then you'd need to blindfold yourself and re-implement the few routines in signalprocessing---it isn't that much. 

Cheers, 

---david

[João Felipe Santos]

Hi David,

this is great, thank you very much for all the work!

I believe the functions you have in the SignalProcessing package would be interesting to add to our DSP.jl package (which is MIT-licensed). I believe it would be better to have a single go-to package for these basic functions. We are missing the Levinson-Durbin, Toeplitz, and specgram functions. Fortunately, those are the less complicated from all the code you wrote :)

I will try to come up with compatible, non-GPL'd implementations for those in the coming weeks (well, after the Christmas break) and then we can test your other packages to see if my implementations are really compatible. From my quick searches at Github, only the "levinson" function is required by the other modules. Is this correct?

Cheers

--
João Felipe Santos

--

[David van Leeuwen]

Hello, 

Since last time I've managed to find Paul Kienzle (having written the octave implementation that SignalProcessing is based upon), and he is willing to move his license from GPL to MIT.  

Since we're at licensing issues, does anyone know if you can dual licence something with GPL and MIT?

---david

On Fri, Dec 20, 2013 at 6:21 PM, Paul Kienzle <...> wrote:
> David,
>
> You are welcome to move my octave code from GPL to MIT like core Julia.
>
>   - Paul
>
> PS, sorry about the dead email addresses…
>
> On Dec 20, 2013, at 9:52 AM, David van Leeuwen <...> wrote:
>
>> Dear Paul,
>>
>> I have been using Octave's signal processing tools a lot in recent
>> years.  However, I am now steadily moving towards Julia, which is a
>> prettier language imho.
>>
>> So for speech feature extraction I need a few of the octave routines,
>> and the ones I need I've put at
>> https://github.com/davidavdav/SignalProcessing .
>>
>> Now there is a debate going on in the digital signal processing
>> community about the license.  Apparently GPL is felt as too
>> restrictive, and as I understand, my Julia-recoding of your octave
>> implementation is required to be GPL for the reason of re-coding.
>> This would prevent the routines to be included in a larger DSP
>> package, which has MIT / X-windows license (this seems the standard
>> license of everything coded in Julia).
>>
>> I am personally happy with keeping everything GPL, but for the sake of
>> wider distribution in a more general package, would you be willing to
>> license my re-coding of your octave work into Julia under the MIT /
>> X-windows license?
>>
>> Cheers,
>>
>> ---david

>>

On Friday, December 20, 2013 2:26:21 PM UTC+1, João Felipe Santos wrote:

Hi David,

this is great, thank you very much for all the work!

I believe the functions you have in the SignalProcessing package would be interesting to add to our DSP.jl package (which is MIT-licensed). I believe it would be better to have a single go-to package for these basic functions. We are missing the Levinson-Durbin, Toeplitz, and specgram functions. Fortunately, those are the less complicated from all the code you wrote :)

I will try to come up with compatible, non-GPL'd implementations for those in the coming weeks (well, after the Christmas break) and then we can test your other packages to see if my implementations are really compatible. From my quick searches at Github, only the "levinson" function is required by the other modules. Is this correct?

Cheers

--
João Felipe Santos

[Simon Kornblith]

My understanding is that, since MIT is such a permissive license, there is no need to dual license. Work licensed under the MIT license can be freely combined with work licensed under the GPL, and the GPL will apply to the combined work.

Simon