So the data formats that we definitely want are:
- Sample Values only.
- Indexed Sample Values
and for the following “header” information to be included:
“Sample Rate, Name (from file name) Append number for multiple tracks, Mono/Stereo”.
So the output could look something like:
indexed list .txt
Mono 44100 Hz
values only list .txt
Mono 44100 Hz
I’m getting a lot less keen on .CSV due to all of the different variations. I think best to keep it simple - if users want CSV they should be able to easily convert a plain text list to the particular CSV format they require. If we’re leaving out CSV, then may as well leave out HTML also and that eliminates one control altogether (and simplifies the code).
I think that splitting the track is probably unnecessary hassle for the user. If you can think of a good, clear, brief description I could add an option to output stereo samples values as either “Left Channel then Right Channel” or “Alternate L,R,L,R…”
It’s obvious now, I don’t know why I didn’t think of it before (probably because when I originally wrote the plug-in I only required a small number of sample values).
The “workaround” is that there is really no need to load the sound into memory in the first place. We don’t need to return the sound, so we can just read samples (destructively) from “s” as we need them. This way, “s” is not loaded into RAM so there is no problem with long selection.
Unfortunately this approach cannot be used to solve the “Normalize long selections” issue because for normalising we need to retain “s” so that we can return it (normalised) back to the track.
I would have thought that it should be pretty obvious that if you have millions of lines of text the file will be quite large?
I would expect users try the effect within the slider range before they start experimenting with extreme numbers. Once they’ve processed a few thousand samples they will see the size of the files produced. However, if there’s room in the help file there’s no harm in mentioning it. (It’s that darned small help screen issue again )
Yes, spotted that one.
Personally I find the “Append to Home” option really convenient.
What I may be able to do (need to test this) is just have one “Output Path” box without options, and:
If is empty, use “Home”
If home/ exists, use "home/
If home/ does not exist, look for (fully qualified output path)
If no valid path found, fall back to “Home”
For example, on my computer:
Desktop or /Desktop or /Desktop/ would output to /home//Desktop.
/home//Desktop would output to /home//Desktop (because /home//home//Desktop does not exist).
would output to /home/.
Yes I think it could be a useful option. I’ll keep it unless user feedback indicates that everyone prefers one or the other (once they have the choice, which they don’t yet).
Yes, me too.
It is required if writing to multiple files is supported so that the file counter can be reset to zero.
For example, with 5 tracks in Audacity, multi-file export, base file name “data”:
Output files will be:
data0.txt, data1.txt, data2.txt, data3.txt, data4.txt (or would it be better to start numbering from “data1.txt” ?)
Then you want to process a longer section of those tracks and overwrite the existing files.
Using Storer’s suggestion, the user could manually delete the files before re-exporting, but otherwise the files will not be overwritten and the exported files will be:
data5.txt, data6.txt, data7.txt, data8.txt, data9.txt
The “Reset” button provides a convenient method to reset the file number counter (it removes the property from SCRATCH)
A separate control “Reset file number counter: Yes / No” would be no more clear, because it is not possible to reset the counter and run the effect. It has to be done as a separate “run” of the plug-in. As I mentioned before, this is a case where it would be extremely useful to be able to run a plug-in and keep the plug-in open after it has finished.
The “Reset” button is only required if exporting to multiple files. Multiple tracks could be written (appended) to a single file without the need to use SCRATCH and so no need to have a Reset button. However, without using *SCRATCH" the “header” information could not include a track number.
SCRATCH and (get-env) are not in Audacity 1.3.12
SCRATCH is used as a track/file counter and (get-env) is used to locate the “home” directory. It is not possible to determine the users home folder without the (get-env) function.
Yes I think so.
I can include “Name (+ number), Mono/stereo and Sample Rate” as standard.
My reasoning for making them optional was if anyone was wanting to directly import the files into another application. If they were doing that then they would probably just want the data and no other text in the file. If no-one is doing that then there’s no need for the option. It would probably be easier to provide the option now but comment it out rather than adding the option later.
I think that “4 Output file path/name” needs to be displayed after the export has completed. Particularly important if the path entered was invalid and the fall-back path was used. Number of samples and duration would probably be useful too so that the user can see that they have processed what they intended. Something like:
Data written to:
C:Documents and Settings<username>data.txt
27 samples - 0.000 seconds.
You mean the bit-depth?
That’s a “Feature Request” or an item for the Nyquist Wish List
Nyquist does not know what the track bit-depth is. Nyquist always receives the data as 32 bit float.
It would often be useful if Nyquist knew more about “s”.
Audacity has information about the track that is not available to Nyquist.
The number of samples is passed to Nyquist in the variable “LEN” and the actual audio data in “S”, but that’s all.
What I would like to see is additional track data passed to Nyquist, possibly as a property list, to include:
- Track name,
- Channel allocation (for mono tracks),
- Peak Amplitude (solves the Normalising issue for some situations),
- Start time,
- Envelope Points,
Do you mean dBFS instead of linear?
Current output is the linear value. It could be output as “dB” (which would be dBFS as in the “Waveform (dB)” view).
I can add that as an option.
That’s another Nyquist wish list / Feature Request.
Nyquist does not know the track time. As far as Nyquist is concerned the beginning of the selection is t=0.
We could have the “index” as a time value relative to the start of the selection, but that’s probably not what the user wants, and at 48 kHz sample rate the index would be incrementing in steps of 0.000020833333 seconds.
If the user wants the track time value they need to look in the Selection Toolbar. Sample times will then be “start time + (index/sample rate)”