progwolff wrote:
What exactly are the use cases?
Well, actually many. The theory to measure responses of systems does not vary among (classical) Physics fields. The only things that are peculiar in acoustics are post-processing things (Loudness metrics, Various Levels metrics, psicoacoustics models etc...), but I was not thinking to include them here. I would like this to be a tool to only measure (with errors) objective signals and systems properties. The only one feature I would add is the ability to export results to various formats. I would for sure support Matlab/Octave, Scilab, R and Julia binary formats (and cvs and similar), so that people can use measured quantities directly with their scripts or spreadsheets, without us having to mess with supporting 195264386 different metrics.
The fact that measuring systems and signals is not different in Acoustics means that the program can be used to measure electric circuit responses as well, for example.
progwolff wrote:
Should the program be an effects plugin or a jack client?
I think it should be a standalone JACK client, so that the program outputs can be routed to sound-card channels using JACK, without the program having to mess with the routing itself. Perhaps it could be possible to have the measurements to be performed on recorded data, so the plugin approach could work as well I guess, but I confess I did not have this in mind.
progwolff wrote:
Maybe you could draw some sketches of the GUI you have in mind?
Well, something along these lines (hopefully cooler than this):
- Screenshot from 2016-10-16 15-19-08.png (33.77 KiB) Viewed 1196 times
So, pretty much I would like the program to be able to execute many measurements in parallel. There would be a sort of list where measurements can be added and configured. For example, measurement 1 could be a cross-spectrum based frequency response measurement using white noise and reference channel. As such, it would allocate for itself two jack inputs (for example measurement1_system, measurement1_reference) and one output (measurement1_testsigout). The user would connect those to the sound-card channels he wishes. Measurement 2 could be instead still a frequency response measurement, but with a MLS test signal, without reference channel. As such, it would need one input and one output (measurement2_system and measurement2_testsigout). All of this would be decided in the setup window.
I imagine the application to be multi-window or multi-tab. The plotting would happen in another window or tab, which would have a tab for each measurement. The plot layout for each measurement would be configured in the setup window as well. For measurements that support it, the test signal could be streamed to output also independently from the measurement.
To clarify this last point, many measurements would work like this: stream the test signal to a sound-card output while listening to input(s). Window out input chunks, calculate quantities of interest, store results. Repeat for a given amount of iterations. Calculate mean and error of the stored results.
So, if the user could start the stream, he could see in the plot tab the quantities being calculated for each windowed signal chunk, being able to understand whether the results are going to make sense. Then, he could hit the start button and trigger the data collection algorithm. Pretty much, Start/Stop Streaming would be a real-time version of the measurement, without averaging and error calculation, just display of result window after window.
Not all measurements support this tho. For example, the Ant Novak method or MLS methods need to record all the output of the test signal before to be able to calculate something.
When the start all button is pushed all the measurements cycles would start at the same time, in parallel. I would like this to happen so that the user can use multichannel sound-cards to make many measurements at the same time of many systems. I imagine that the user could save the measurements line-out (the list of parallel measurements), with all their setup, and either load them or decide to execute various line-outs one after the other, either with the use of a timer or a trigger that could be a keyboard press or other event (maybe even MIDI). In this case it could be useful for the program to remember to which JACK clients it has connect the various measurements tho...
There needs to be a section somewhere to calibrate. Digitalized waves go from -1 to 1, but voltage signals in input (output) to the sound-card might go from -2 V to 2 V. It is possible to calibrate both input and output using sine waves and an oscilloscope, so that the program can map numbers to -1 from 1 to voltages. The functionality should be provided. Finally, I would like support for transducer sensitivity. If one uses a microphone, the microphone will translate pressure [Pa] to volts. Sensitivity is the quantity governing the conversions between pressure and voltage and must be known so that one can measure the target physical quantity. I would like the user to be able to manage calibrations and transducers into a database of some kind.
So, as you can see... it is a lot of stuff. The way I was thinking of doing it was by baby steps. For example, one could start from the simplest measurement possible, implementing it as a command line JACK client. And then move to another, trying to keep in mind that after each step there should be software that can be modular enough to be plugged easily in the bigger picture.