Thanks for spending time on this, Steve.
No, it produces sample values without indices and without sample rate.
I get the impression that HTML output is not generally very useful (though it suited the original purpose of the plug-in).For the sake of simplicity, would it be better to drop that option altogether and stick with plain text output?
Nobody I have conversed with wanted HTML, but there seems no harm including it.
For stereo files, would it be better to: Alternate values as "Left channel sample > Right channel sample > Left channel sample > Right channel sample > …"or List the Left channel values first, then list the Right channel values?
No-one has objected to “list left, then right” but I think “alternate values” is more usual. If someone wants “left then right” they can split the stereo track I guess.
Regarding the limited number of samples that can be analysed.
With recent improvements to memory management I think it may be possible to work around this limitation. How much of an issue is this for users? Is it worth the effort?..
I suppose the question now is whether we still want to have the “Number of Samples” slider.
I think that it is probably still good to keep the slider so that the unwary user does not print out a multi-Gigabyte file and crash their computer trying to open it. Perhaps we should just increase the range of the slider up to say 10,000 samples, or are most of the users happy with a range up to 1,000?
What is the workaround for the limitation? I assume Nyquist still doesn’t release the memory until processing is finished?
I think the slider is best kept for the reason you state, but if the limitation does not exist any more, don’t limit the value that can be entered in the box. I think the help needs to state that exceeding the slider range will produce very large output files.
However I notice that in sample printer if I select say 50 samples and the slider is still at default (100) then “Nyquist did not return audio” occurs. I guess at the least that needs an error message. In fact I wonder if it would be more convenient if the number of samples specified in the plug-in was the first in the selection as now, but export continues if the selection is shorter than . In other words, the control could be “limit output to: [samples]” or similar and there would be much less need to fiddle with the slider if you had already selected exactly the samples you wanted on the screen.
1). Decide on Output Path.
How do we want to handle the output file path:
Valid paths that are common to all platforms are
- The users “Home” folder
- Root folder (often not writeable)
- Desktop (could be a problem)
- Fully qualified existing folder (must use forward slash)
“Home” folder is probably the safest.
“Append to Home” would be very convenient for many users (I would probably use this option).
“Fully Qualified Existing Path” is the most flexible, but may be too complex for some users.
Rather than just failing with an invalid path I think I could use the home folder as a fall-back.
Personally I would keep it simple as in 78rpm EQ Curve with only one “output” box for path, without options to choose. Your suggested “use home as fall-back” would I think be better for 78rpm EQ Curve too.
- Decide Multiple tracks vs.Append. (prefer append if not too slow)
I think “append” to file is less problematic than multiple files, and may be more convenient for many users (saves needing to open multiple files).
The users I’ve come across so far seem to prefer multiple files. Appending could limit the number of samples you could usefully specify. I think though it’s important enough to offer a choice for “multiple track write mode” as a control (more so than having two “output” boxes).
I’m a bit concerned about the “reset” choice being confusing until I see it working. It could be easier (though much less functional) just to have the plug-in export the first selected track.
Are we still facing a choice about “waiting for 1.3.13”? I don’t think it matters to wait.
- Decide on output file formats.
I think the current list of five “file types” is fine (though maybe “Samples List” would be a better term than “Data List”). I’m not sure if HTML really needs to be “extended” or user-defined given there is little demand for HTML anyway. I think additional header information should be an option for all file types.
Decide on output data formats.
Current options include “Data Only” and “Indexed Data”
Additional information could be included as an additional user option.
Additional information could precede the data (for any of the format options) and could include:
1 Sample Rate
2 Name (from file name) Append number for multiple tracks.
4 Output file path/name
5 Number of samples
6 Duration (seconds)
7 Average sample value
8 RMS value
9 Maximum / Minimum values
10 Optional user text (text field in GUI)
I don’t think that we can have “switches” for each of these in the interface, so it’s a matter of deciding which will be most useful and giving the option of including all of those or none of those (or some other subset of combinations).
My take is that the first three in the list above should be included as standard - you get them whether you like it or not. I assume most would like it since there are complaints that some current options don’t include sample rate. I think 4 and 10 are unimportant. A couple of people asked for sample format.
A couple of people asked for output in dB instead of dB FS which would have to be another control. If this is a feasible request I think it’s an important one.
One person asked for the index value to be an actual time position (he was selecting small numbers of samples at arbitrary regions in the track, so 1,2,3… wasn’t that helpful). I guess the only sensible way to accommodate that if we wanted to is to accept that if someone asked for indices it would be both the index number of the sample and its time position.