Affiliate this package with JuliaAudio

[KronosTheLate]

In looking for audio read and write packages in Julia, I quickly found https://github.com/JuliaAudio. It seems like this package is however a better fit for me than anything I found there, but it was a little random/accidental that I found WAV.jl. I was thinking that this package would be much more discoverable if it was affiliated with JuliaAudio - is there motivation to make this happen?

[mgkuhn]

My suggestion at some point would be that we take WAV.jl as the basis for a new package AudioIO.jl, and try to make that the main native (i.e., not based on a C library such as portaudio) Julia Audio I/O package. However, this should be done in a non-backwards-compatible way, because WAV.jl currently implements an obsolete MATLAB API quite closely (the old wavread/wavwrite/wavplay interface, which MATLAB dropped some years ago), and it does so in a very MATLAB-ideosyncratic way (e.g., string parameters, allowing floating-point time indices, etc.). I would quite like to change the API in a number of ways into something that is far closer to how APIs are done in modern Julia, and perhaps also consider the modern MATLAB Audio API (audioread/audiowrite). Also, the package shouldn't be limited to just the WAV file format, as there are a number of other similar loss-less audio file formats (e.g. Sun's *.au format) that could easily be supported as well in such a package.

[KronosTheLate]

I mean, a native Julia all-in-one package with a modernized API for all audio IO purposes sounds like the dream.

Do you think that the API of SampledSignals.jl is a good basis for what you are imagining? It sound like its mission statement is to be the basis for stuff like this.

[mgkuhn]

@KronosTheLate: I know of SampledSignals.jl but haven't used it yet. (One of the things I have learnt over the years is that no “mission statement” can ever replace practical experience with actually using the thing.) Having said that, I'm generally a bit wary of special-purpose types with wide usability claims. They usually constrain the set of applicable methods quite a bit in practice and thus can add syntactic overhead with the ongoing need for wrapping and unwrapping the actual raw data at many steps. Or distract the compiler's optimizer. One of the attractions of the (original) MATLAB APIs was that they avoid such syntactic and mental overhead caused by elaborate type systems that the user has to master first, in favour of just using the basic built-in array types of the language, rather than specialists types that e.g. convert units of measurements (time, voltage) and other metadata, or even try to do interpolation for sample-rate conversion under the hood (a big can of worms, as there are lots of different application-specific interpolation and conversion strategies).

Another attraction of WAV.jl is that it has hardly any other packages as dependencies (mainly FileIO.jl). Therefore, I'd probably isolate support for specialist types, such as SampledSignals.jl into a separate glue module/package, to avoid dependencies (both technical and mental) for those who don't want to use such specialist types, and just want to get basic types such as Vector{Int16} to the OS drivers and back.

[KronosTheLate]

That sounds like a very reasonable stance. Are you sceptical of the idea of a generalized API in general, or just very wary of the pitfalls of that approach? If it is the second case, then possibly a revamped API for WAV.jl, battle-tested by yourself, could inspire the API of SampledSignals.jl. It just seems like there are many advantages of having a uniform API, and therefore that it is a goal worth striving for.

So what you imagine in AudioIO.jl is a pure-Julia alternative to what is currently the JuliaAudio-ecosystem? Because that just sounds lovely. If so, I consider this issue closed.