This is where two noble goals of software features collide--ease of use vs. versatility. The software focusing too much on the former often lacks the ability to provide generalized and comprehensive features. On the other hand, the software boasting its versatility often requires a "learning curve" on the user side because it is not easy to use on Day 1. Like many other software architects, I want to seek both. Then, how? To do so, compromises must be made somewhere in the middle and we need to make wise decisions where and how to make compromises.
In the end, I want an AUX code to 1) be consistent with our conception of sounds (easy to use) AND 2) be unambiguous and determinsitic as is. Here, I am giving up more on the latter than on the former; i.e., the syntax should stay intuitive and represent ideas and concepts. If it is not sufficient to define one and only one sound, well, then we should at least document the details so capable users could dig deeper and make use of them.
Before we proceed, let's clarify what we mean by "unambiguous and deterministic" vs "not deterministic." Time to consider some technical details. Here we have two cases:
- Sounds or sound processing with unique and unambiguous and deterministic representation
- Sounds or sound processing where our conceptual description doesn't provide deterministic representation of signals
At this point, if you wonder whether one needs to know how to actually make the tone glide, I would say, it depends on who you are. If you are an engineer, you do need to be able to do it yourself, if need be. If you are an experimental psychologist doing research with human auditory perception or an architectural acoustician measuring some sort of characteristics of a room, and if you have no clue about how to generate a tone-glide from scratch, most likely you are forgiven. In either case, what's important is, understanding the perceptual entity of this thing called "tone-gilde," a tone that begins with a certain frequency and ends with a different frequency, rather than how the equation is actually written and how to do a low-level coding to implement that.
A third example is shifting the spectrum of a sound by a certain frequency. Once again, it is done with a relatively straightforward algorithm and one can produce the result indisputably with a certain level of training in signal processing. Given the signal x, another signal with the same spectrum but shifted by d Hz in frequency is x->d. There is no ambiguity.
On the other hand, there are plenty of cases where our conceptualization of sounds or sound processing is insufficient to describe them. One example is filtering. Say, you have a customer who wants a "generic" lowpass filter with a cutoff frequency of 1000 Hz. If you are an engineer, you would naturally ask for more technical specifications--the filter order, the slope, the stopband attenuation the passband ripple, etc. Even with the full technical spec, there are multiple ways to build a filter with each of them offering pros and cons. A naive customer without an understanding of how filters are designed often finds it perplexed why this has to be so complicated, all he wants is a damned lowpass filter with 1000 Hz cutoff frequency, something that he considers common and easy to make. You might tell him that there is no such thing as a "common" filter spec and ask him to be more specific. Well, good luck with that. More often than not he would be your boss. Then you might as well figure out what he needs based on the limited information without confronting him, so perhaps try to collect some examples he would find acceptable and make something similar.
The lesson here is that, in the field of acoustics and audio engineering, both perspectives have valid points. There are plenty of professionals without a full knowledge of signal processing but with a great deal of insights on sounds and auditory perception. Or, they may know signal processing, so it's not about the level of their signal processing knowledge, but within their domain there may be truly some form of common specifications of filters they use frequently, which engineers are not familiar with, unless they have interacted with them enough.
Therefore, however awkward it may seem to the engineers' perspective, in the scope of AUX, I decided to acknowledge the need for "generic" filtering based on the cutoff frequencies and included them as built-in functions: lpf, hpf, bpf, and bsf, all of which filter the signal with an IIR filter with "default" parameters. Now you can simply respond to your boss with just one line of AUX
The chances are, he will be satisfied. Of course, if he is not, you can try putting in more parameters to this and fine-tune the output. You might say that that the AUX philosophy has been compromised, because the meaning of x.lpf(1000) is not universal. There is a risk of disagreement between my choice of "default" filtering parameters and yours. But, from the user's perspective, having default parameters and evaluating them to see if they are appropriate for their needs (and if not, they can always put additional parameters, that's an easy solution) is better than not having the "default" because they may never be perfect. Therefore, in terms of practical functionality of the software, I consider this an acceptable compromise. Those who still do not agree with this approach can simply ignore these four functions and design their own filters and use the filt or filtfilt function, as done in MATLAB.
It goes even further. Another example is time-stretching(-expanding) or frequency-altering of the signal. For those who are haven't studied signal processing enough, this is completely different from the case of shifting the spectrum mentioned above. Much like filtering, there is no single algorithm for this type of processing that everyone indisputably agrees. Worse than filtering, not all engineers can do this off the top of their head. That is why most of the algorithms for these kinds of processing are proprietary and usually included in expensive DAW packages. Regardless of engineer's opinion, for "audio people," these seemingly simple features--just stretch or compress the signal in time without changing the pitch, or increase or decrease the pitch while keeping the duration--are so appealing and desired. Therefore, I included them as built-in functions.
x.tscale(1.1) //stretch the signal by 1.1 times longer
x.fscale(5) //increase the pitch by 5 semitones
Notice that these examples are an even worse deviation from the AUX philosophy than filtering, as more advanced algorithms are required and not readily understandable to many users. Again, I think users would be happy to have them as built-in functions, because the alternative is, not having them. Plus, AUXLAB is free, you can't beat the cost. For whatever reasons, if you don't like the performance of these functions, you are welcome to develop your own functions (and please share them with others), now with the debugger, AUXLAB offers significantly more user-friendly environment to develop audio processing algorithms than any other platforms.
Anyway, there is no regret for allowing these compromises. With proper justifications, functionality can override philosophy.
What do you think?