Sample Printer

Thanks for spending time on this, Steve.

No, it produces sample values without indices and without sample rate.


Nobody I have conversed with wanted HTML, but there seems no harm including it.


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.


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.


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.

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.


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.


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.




Gale

So the data formats that we definitely want are:

  1. Sample Values only.
  2. 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

Sample-data01
Mono 44100 Hz

1   0.032451
2   0.042184
3   0.062345
....
....

values only list .txt

Sample-data01
Mono 44100 Hz

0.032451
0.042184
0.062345
....
....

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 :stuck_out_tongue: (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 :frowning: )

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),
  • RMS,
  • Start time,
  • Envelope Points,
  • Bit-depth.


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)”

I think HTML could be a time saver for web publication and I might be +0.5 on keeping it even though none of my small sample of users were interested in it. Your call.


My best shot so far:

;control chan "Channel layout for stereo" choice "L  -  R lines,L block above R" 0



It may depend whether this goes in an Audacity release (ATM I think there is a strong case especially as Analyze menu is not yet overloaded). If someone downloaded it optionally, the assumption would be they have some idea what it will do. If it’s in a release it could be open to a naïve user who just “tries” the effect to see what happens and opens the resulting file. They’ll be used to 3 MB for an MP3, so 3 MB for a text file won’t on the face of it seem outlandish.


I think the drawback is the amount of explanation this would need in the Help. in particular I think few on Windows would understand “Append to Home”. They can understand typing a path in a box (probably).


I think better to start from “data1.txt”. A “0” file is only used as far as I recall in export multiple for a file before the first label.


OK. I think the benefits of *SCRATCH" probably outweigh the potential confusion. I think the worst confusions are a) the word “Reset” itself; b) you can’t “see” the counter to know what value it has.

I think a “phrase” rather just “Reset” would help for a), as would not having it as first choice. I don’t think “Reset Counter” will help much. Does “Multi-file from 1” or similar convey any more, so that people leave that choice alone if they are not writing multiple files?

For b), could a choice “Show Multi-file name” or similar show you the counter, as Show Path shows you the path?


And even the multi-choice boxes (of which we’ll have many here) require 1.3.x, so I guess we accept you need latest Audacity for this plug-in, and also possibly consider a stripped down, simple legacy version if there is any demand.


I’m sure people are doing that but those same people still seem to want “sample rate” in the header. I think the reason is that in e.g. spreadsheets you can simply select the data to be used and then type what you want for the legend. If so then it’s handy to have text for the legend visible in the input. I suppose you could have the choice for header of “none”, “minimal” or “full”, but if only two choices are desired then “minimal” or “full”, not “none” or “full”.

Agreed.


Yes “sample format” as in the Quality Preferences = bit depth.

I’ve added that list (and “track time” as per below) to Nyquist Wish List.


Sorry for terminology mix up - just copied what someone wrote. But yes, the logarithmic Waveform (dB) values would be very welcome as an option.


Perhaps that might be a useful “tip” for the “Help” and possibly not that hard to get a spreadsheet to calculate it? I think “time from selection start” and “track time” are both useful, but not worth adding either until we can support both?



Gale

Edgar’s patch for handling slashes and back-slashes correctly in “string widgets” is implemented in 1.3.13, so that’s another good reason to make this a plug-in for 1.3.13 and later.
(This means that Windows users can use the standard path separator character).

Probably just as easy with plain text and wrap in

 tags.
I’m inclined to just loose the option and save one less control.

How about

;control chan "Channel layout for stereo" choice "Alternate Lines,L Channel First" 0



I put “Reset” first to draw your attention to it - I agree it’s problematic and I wanted to be sure that you would notice it as such but without biasing your view of what it should be. :slight_smile:
Roger’s recommendation regarding using SCRATCH is that there should always be a “clean up” option. However, what I think he had in mind was ensuring that SCRATCH did not get left with a large amount of data. In this case the amount of data is extremely small, and the “property” being used is almost certainly unique making data collision extremely unlikely, so I don’t think that it’s really an issue if it does not get cleaned up.

I think that “Multi-file from 1” would suggest that the plug-in would run and generate files starting at file number 1, but that is not the case. Resetting SCRATCH has to be done as a separate “run” of the plug-in from exporting multiple files.
How about

;control fcount "Mult-file counter" choice "Continue,Show Counter,Reset Counter" 0

Revised interface. The only thing that works is the help menu.
Does this cover all of the options that we want?
The help menu should make clear what each of the options is supposed to do.


OBSOLETE VERSION
sample-data-export.ny (3.95 KB)
NEW VERSION sample-data-export6.ny

Here’s a completely reworked “Sample Data Export” effect.

There’s no manual for it, but there are 4 help screens built in.
It’s a far cry from the simple effect that I originally intended, but now has a lot of cool features.

As it has become a rather complex piece of code I’ll be surprised if it’s bug free, so please test and let me know if there are any problems.

Unfortunately Audacity does not currently support Nyquist plug-ins in Chains, and the current alpha version only supports “Effect” plug-ins and not “Analyze” plug-ins.
Users of Audacity 2.0.1 that wish to use this plug-in in a chain will need to edit the file in a plain text editor (such as NotePad).
Change line 3 from:

;type analyze

to:

;type process

On restarting Audacity Sample Data Export will then appear in the Effect menu and may be used in a Chain for batch processing.
sample-data-export5.ny (18.2 KB)

Thanks! I would certainly like to get this released into Audacity.

I have not tested extensively but I have a few suggestions:

  • Do something more useful with an empty or zero samples value. Probably people who can’t work out how many samples they need to enter may enter “0” thinking this will give them the maximum in the selection or one million, whichever is less. Would that be good? Or it could give them one second for an empty value. I don’t think it would hurt to mention in the help that the project rate is the number of samples per second.
  • An option to show the header information in a message box (and/or possibly in Debug output) instead of running a file might be useful. It could be another choice in “Show Help File”.
  • Your reported offset is reduced but never zero even after running “Remove DC offset” in “Normalize” - different calculation system?
  • “Overwrite” isn’t useful with multiple tracks as only the file for the last track remains. Can you still produce separate files for each channel, but still overwrite each of those files when re-running?
  • Following on from that, I suppose some people will want an option to append results for subsequent tracks to the same file. If so, maybe that should limit the maximum number of samples accordingly?
  • Can the “Alternative Lines” layout append L or R after the value, or separate the pair values with a space?

I thought I might catch it out in no overwrite mode by renaming an already saved text file to the next number that it would save to, but it was clever enough to save to the number vacated by the rename. :slight_smile:

PS typo “Miscelaneous” in “Show Help FIle”.


Gale

Thanks as always for the comments.
“Miscellaneous” wasn’t a typo it was a spelling error :wink:

Before starting this rewrite I read through this entire thread several times to consider and reassess each suggested feature. I don’t claim to have got it exactly right and it’s inevitable that some users will want slightly different options from whichever we decide on. The code is very complex now because of all of the included features - I have tried to structure it as clearly and simply as possible, but with over 600 lines of code it is not easy for a beginner to customise unless they know what they are doing. For these reason I will also upload a very basic version (similar to the original version) that users can easily customise.

No that would be bad :stuck_out_tongue:
The default is set to 100 (and will be restored to 100 on launching Audacity because Nyquist plug-ins don’t remember their settings from previous sessions).
1 million samples produces a huge file. The minimum file size for 1 million samples is 4.8 MB (5 million bytes), and depending on the file data format it may be many times bigger. If a user enters “0” then we have no idea what they intended - perhaps they intended to enter “10” but missed the “1”, in which case they would be very surprised to get a massive file that may take several minutes to open.

The other possible occurrences of no samples selected is if (a) an empty file is analysed or (b) there is no selection. (This can occur with analyze type plug-ins, but for process plug-in Nyquist will throw an error). In such a cases the plug-in will correctly warn the user that there are no samples selected.

Of these possibilities I think the most likely is that the user has not made a selection.
On balance I think that if they type “0” then it is best to treat it as “0” but warn them of what has happened.

If the “Limit output to:” is left empty, it may be better to fall back to the default (100) rather than throw an error. I’ve added that now.


I’d expect that most people that use this plug-in will already know that. We have the usual problem with Nyquist help screens, very little space. If you really want that, where do you suggest putting it? (I don’t think it is necessary, but if released in Audacity that probably should be mentioned in the manual).


I originally had the entire output in the debug window, but took that out as it made the effect much slower for large numbers of samples. Showing the header in the debug window is fast, so that could be always enabled. I’ve enabled that for text/csv output options and added a note in the “Output Files” help screen (not very useful for html as the header info is in html format).


Three points here:

  1. The dc offset is for the specific number of samples that are analysed, not for the entire selection.
  2. The plug-in sums the sample values using the (integrate) function, which is single precision whereas I think the Audacity Normalize function uses double precision,
  3. I may have got the calculation wrong. I’ve tried some more tests and the discrepancy looks too great so I think this is a bug. I’ll look into it.


Correct, and that’s why it isn’t the default. The option to overwrite is only really useful when writing one file at a time, otherwise “Allow files to be overwritten” allows the file to be overwritten.

Not without creating other problems.
You may have noticed that there is no “Reset Counter” option, in fact there is none of the complexity of file numbering from the previous version. File numbering is now fully automatic, but at the cost of losing a little flexibility. With the default setting the plug-in looks to see if the file already exists, if it does then it adds a number to the end of the file name, and checks if that exists, if it does then it increments the number until it finds a unique file name. The result can get a bit odd if the user has a lot of numbered files and deletes some of them, but that will be a problem with any form of automatic file naming. By default the plug-in displays the full file name name of the file written.

As you say, that will limit the number of samples.
With the current code the plug-in could handle up to 2.2 million samples. With modification it could be unlimited (the rms calculation crashes out at 2.2 million samples).
Beyond about 1 million samples the output file size is becoming too big to be manageable. “Scite” text editor will open big files quickly, but NotePad and GEdit takes ages.
For smaller files, copy and paste is a wonderful thing :slight_smile:


Can we get some user feedback on that?
Yes it can be done (easily).
How will users use the data? Simple alternation without additional characters may be better for further analysis.
Will adding L/R or line breaks be a help or a hindrance?
Along the same lines I was wondering whether “Left Channel/Right Channel” should be left out of the “No header” option. We don’t have room in the interface for many more options, and no room in the help screens without adding “Miscellaneous 2” (which I’d rather not do) so users need to say what they want.

Update.
There is a bug in my dc-offset code AND a bug in the Audacity dc-offset (Normalize) code.

I’ll need to investigate further.

I’ve raised a new bug on Bugzilla http://bugzilla.audacityteam.org/show_bug.cgi?id=519
I’ll see if I can correct my code next week (busy weekend).

I’ve looked again at my code and and it appears to be accurate to within the precision available for the (integrate) function, but it can still be quite a way out so I’ve rewritten the function. It’s a bit slower, but as we’re only dealing with a maximum of 1 million samples that’s not too bad, and it is a lot more accurate.

Certainly that is an improvement, thanks.

My first thought, knowing that 100 samples was a miniscule length, was to enter 0 to see if I would get the maximum (or to see what it was). The reasoning is that if I have e.g 19.65 seconds of audio at 44100 Hz I really don’t want to start making those calculations to ensure I get the entire selection. I don’t know what the maximum is until I read the Help screens.

I wonder if it may not be useful to be able to enter seconds instead (I see someone asked for this a while ago but I have not added this to Wiki Feature Requests yet). One existing FR for Sample Printer asks to “include RMS data, not just peak values (1 votes)”.

Wavosaur has samples export as text. I don’t know what if any limit it has, but it produced a 90 MB file from 1 min 50 seconds of stereo music.

I would hope we can encourage some new explorers by putting this in Audacity. There isn’t much in the Analyze Menu now.

Here is my attempt (one more line than currently, three short of the maximum 25 lines):

 
'LIMIT OUTPUT TO FIRST' SAMPLES MAXIMUM:
This limits the number of samples even if the 
selected length exceeds this number. The maximum
samples written is 1 million, but files of this
size may be hard to open. To calculate the number
of samples to enter for a given number of seconds, 
multiply the project rate by number of seconds.n

Why not have this fourth screen as the first (including “Overview”, minus “OPTIONAL HEADER TEXT”) then re-order the screens so you have a logical progression (more or less) from top to bottom through the controls?

I thought a message box might perhaps be a quick way to find peak and RMS without running Amplify and Contrast.

I think that behaviour is a bit unexpected unless the user stops to think “why”. So I suggest the help could be a bit clearer on this limitation. This is three more words on one extra line:

By default, files will not be overwritten. If you
select multiple tracks, they will be saved to
separate files with a number appended to the
name. If you set "Allow files to be overwritten" 
to "Yes", only the last file for multiple tracks 
will be retained.n



It would help me to scan visually without software analysis. The relevant help screen has seven spare lines, and I think only one line of explanation is needed if we had a second, annotated “Alternate Lines”. I guess L/R may be less disruptive than line breaks for analysis software.


Thanks



Gale

The problem that I see with this is that “6 seconds” does not seem like much, but to print out every sample value it is “much” (about 530 thousand lines of text for a stereo track, or just short of the number of words in War and Peace).


I’ve not seen that Wavosaur feature, but 90 MB seems about right (about 9.7 million samples, and plain text being 1 byte per character). How long did it take NotePad to open that file?


It won’t be particularly quick. For anything other than a very short selection “Amplify” can calculate the peak very much faster than Nyquist can because it has access to the “summary data” (which Nyquist does not have access to).
I think that a simple analysis tool to show peak and rms levels would be very useful, but it would be much better coded in C++. Peak level can be calculated virtually instantly even for very large selections within Audacity because most of the work is already done within the project.

The other problem for Nyquist is that calculating peak level is normally done in memory, which limits the length of audio that can be computed (the old “Normalize big files” problem). It is possible to compute the peak value without running into memory problems, but to do so Nyquist must discard the audio data, which then prevents further processing.

I have a little plug-in for calculating peak levels (based on some code that Roger Dannenberg wrote a couple of years ago). The advantage that it has over the Amplify effect is that it gives separate left/right peak levels for stereo tracks. The disadvantage is that it’s not very quick (though it can handle extremely long selections).
peak-amplitude.ny (765 Bytes)
I’ve also previously looked at calculating rms level for large files, but doing so in Nyquist is either very complicated or very slow and I gave it up as not worth the effort.


Thanks for the suggestions regarding the help screens. I’ll spend some time on the help screens after the weekend.

Milliseconds? But then not quite so understandable?



Gale

Assuming that the tracks are the same sample rate as the project rate, look in the Selection Toolbar.

That’s why I decided to throw an error for too big a number rather than silently limiting the number. It makes the limit more easily discoverable.
Also, one of the reasons that I chose 1 million rather than 750,000 or 1.3 million is because it is memorable. The user sees the error message once and then they know that the limit is 1 million.

Reworked Help Screens.

OVERVIEW.
Sample Data Export reads the values of successive
samples from the selected audio and prints to a
file. Additional information may be added as a
‘header’ at the top of the page.

LIMIT OUTPUT TO FIRST (maximum number of samples):
Enter a number to limit the number of samples
processed from the selection. The maximum number
of samples is 1 million, but files this large may
be hard to open. The track sample rate indicates
the number of samples per second.

LINEAR/dB SCALE:
Sample values may be displayed on a linear scale
+/- 1 (as in the Audacity audio track “Waveform”
view) or on a dB scale relative to full scale (as
in the “Waveform (dB)” view).

HELP SCREENS:
Select only one track before viewing to avoid
repeated help screens. To run the plug-in set the
help option to “No”.
Select “Save Help File” to write all help
screens to a printable file.



FILE FORMAT.

Following any header information:

SAMPLE LIST: produces a list of sample values.

INDEXED LIST: includes the sample number.

TIME INDEXED: includes the sample time.
Both types of index are relative to the start of
the selection.

DATA (csv): prints the sample values separated
by commas.

WEB PAGE (html): produces an HTML 5 document that
contains all of the header information and a table
of sample data with sample number, time, linear
and dB values. Browsers that are not HTML 5
compliant may not display the page correctly.

CHANNEL LAYOUT: for text/csv output, stereo tracks
may be printed alternate left/right samples or all
of left channel then all of right channel.



OPTIONAL HEADER TEXT:
This is provided for adding notes to the output
file. For HTML output
may be used to start a
new line.

NO HEADER: Prints only the optional header text
(leave blank for none) followed by the sample data.

MINIMAL HEADER:
The sample rate.
Units (linear or dB).
Optional header text (leave blank for none).

STANDARD HEADER: minimal header plus:
File name.
Number of samples.
Duration (seconds).
Mono/Stereo.

FULL HEADER: standard header plus:
peak amplitude linear and dB.
Unweighted rms level (dB).
DC offset.



OUTPUT FILES.

The default output folder is the “home folder”:

To select a different output folder, enter the
full path name. The output folder must exist.

By default, files will not be overwritten. If you
select multiple tracks, they will be saved to
separate files with a number appended to the
name. If you set “Allow files to be overwritten”
to “Yes”, only the last file for multiple tracks
will be retained.

A notification message is displayed on completion
indicating the name and location of the file.

If the plug-in is used in a Chain (Audacity 2.0.1
or later) it may be useful to disable messages.

For text/csv output the file header is shown in
the debug window.

I’ve been thinking about this and it quickly gets complicated.

For easy viewing (visual analysis) the html format is probably best - all of the information nicely laid out in a table. The downside is that for 1 second 48 kHz stereo, the html file weighs in at a whopping 5.2 MB.

If we had L/R before alternate lines, would we want that for all of the text formats?
Would the L/R come before or after the index?
What about the csv format?
Would it need to be an option rather than pre-set?
Would we want “L/R” or “Left/Right” or a line break?

Not only would providing these options complicate the user interface but would probably need quite extensive documentation in the (tiny) help screens. To date we really don’t know if there is any demand for these features.

I think that for now we leave that as it is. Once the plug-in is in circulation we may get some useful feedback and we can update it if necessary.

Yes a reasonable workaround (but assuming it is already set to samples).

These look good, except maybe put the Help Screen info after the “Overview”?

OVERVIEW.
Sample Data Export reads the values of successive
samples from the selected audio and prints to a
file. Additional information may be added as a
‘header’ at the top of the page.

HELP SCREENS:
Select only one track before viewing to avoid
repeated help screens. To run the plug-in set the
help option to “No”.
Select “Save Help File” to write all help
screens to a printable file.

LIMIT OUTPUT TO FIRST (maximum number of samples):
Enter a number to limit the number of samples
processed from the selection. The maximum number
of samples is 1 million, but files this large may
be hard to open. The track sample rate indicates
the number of samples per second.

LINEAR/dB SCALE:
Sample values may be displayed on a linear scale
+/- 1 (as in the Audacity audio track “Waveform”
view) or on a dB scale relative to full scale (as
in the “Waveform (dB)” view).


Probably you would just have it for just all text formats. People who want a csv list probably really don’t want any interpolations.

I don’t think we need to go overboard; if we did it I would just append an L or an R to the values (no choice in the matter). It isn’t completely clear now that HTML files for “L Channel first” and “Alternate lines” actually have the same layout, so we don’t need to get hung up on descriptions of what “Alternate marked lines” or whatever means.

To be fair I don’t think the two indexed text files have much of a display problem, but it is more of a problem for the “sample list”. And if you had to submit any of the text or csv files to someone else, the other person doesn’t actually know for sure from the alternate lines versions that left comes first. So for all but html, how about putting “Left channel and right channel follow on alternate lines” or similar, not as a header, but just above the data, as you do with “Left Channel” and “Right Channel” for “L Channel first”?


I like the text export of the help file. I wonder if that is worth progressively including in all plug-ins that have help screens, without any choice of location? User could see the location from the help file.


Gale

Yes, good idea.


The same may well be true for people that want a plain list with no header.

I’m inclined to change:

NO HEADER: Prints only the optional header text
(leave blank for none) followed by the sample data.

To:

NO HEADER: Prints only the sample data list
unless optional header text is entered.

and, as implied by this wording, not include L/R or Left/Right text.

If there is a header, then as you suggest, add a line above the data to the effect of “Left channel and right channel follow on alternate lines”.


Yes, I thought that was a nice touch.
If the help screen is printed to the “home” folder then the code is fairly straightforward. If the destination folder is user defined than it adds a lot of code to the plug-in, but there may be a way to make writing files to user defined paths a lot more straightforward. More about this later.

That sounds reasonable. To be consistent then, shouldn’t you remove “Left Channel” and “Right Channel” from above the data when choosing “L Channel First” and “no header”?



Gale