Easy way to put Selection Toolbar info into export filename?

Hello,

In Audacity I’m wondering if there’s any trick to be able to quickly and easily put
into the clipboard the time and length of a selected area.

What I do a lot these days is I browse recordings that I’ve done, and I
File> Export Selected Audio to a wav or mp3.

In the filename I put the selection start and the selection length,
for reference, in order to easily get back to that particular selected area
if I should ever want to, rather than saving the whole project file
(in order to save disk space), for example:

PJ_1-25-17_1_6m_23_166_len10_974.wav

6m_23_166_len10_974 is the part I’d love to be able to put into the clipboard
or something like that. For example, perhaps 6:23.166 10.974, etc.,
so I can just paste it into the filename, to ease my workflow so i don’t have to
manually look to see what the start and length is each time I wish to put that
info into the exported mp3/wav filename. It’s kind of a lot of looking back and
forth between the Selection Toolbar and the Export Selected Audio dialog box
filename each time I save a selection to mp3/wav.

For example, one thing I’m wondering is, when I go
Edit> Region Save
where is that data stored?
If I could access that, it may be useful for me.

What would you do in a situation where you want to create many, many
individual files using File> Export Selected Audio, and where you want
the individual filenames to contain the precise start and length of the
selected area of the Audacity project file?

Thanks for any ideas,

frew

Hi
Have you tried using labels and multiple export?

Here’s some code for the Nyquist prompt as a proof of concept.

(let* ((start (get '*selection* 'start))
   (end (get '*selection* 'end))
   (content (format nil "~a ~a" start end)))
 (list (list start end content)))

What it does:

  • you first have to select a region.
  • Then open the Nyquist prompt (under effects) and paste the code.
  • Press OK
  • A label track is being created with a label that has as only text content the start and end time of the region you had selected.

Now, you can make another selection and press “Ctrl+R”
Make sure that the label track is selected as well, otherwise you’ll get a new one with a single label.

This can also be made into a plug-in in order to avoid opening the Nyquist prompt each time at first usage or if you do something else between labelling.

You can also add non-changing text within the quotes after ‘(format …’, e.g.

(format nil "Project0114-02-16 ~a S ~a E ~a Len" start end (- end start))

The track title can be added automatically, only the date must be entered manually.

The times are in seconds and if you want it formated, it will need some special code to e.g. extract hours and minutes. Not a big deal though.

There’s also a way to just display the start and end times (or the length) if you prefer to copy them manually.

Robert

Hi Robert

Unless the selection is at the start of the track, the label seems to be placed after the end of the selection.


Gale

I think it’s a bug in that the times are stretched, with regard to the selection length.
I get the absolute times of the selection but on return they are scaled somehow or rather the start time seems to be added a second time.

Put the whole code within ‘abs-env’ like this:

(abs-env
   (let* ((start (get '*selection* 'start))
      (end (get '*selection* 'end))
      (content (format nil "~a ~a" start end)))
    (list (list start end content))))

Does this the trick for you?

The code correctly finds the start and end time of the selection, but these are not the correct times for the label placement.
When Nyquist returns labels to Audacity, Audacity interprets the start/end times as relative to the start of the selection.

For correct label placement, the numeric element(s) of the label must be relative to the start of the selection. Two examples are given below:

(let* ((start (get '*selection* 'start))
       (end (get '*selection* 'end))
       (content (format nil "~a ~a" start end)))
  (list (list (- start start) (- end start) content)))



(let* ((start (get '*selection* 'start))
       (end (get '*selection* 'end))
       (content (format nil "~a ~a" start end)))
  (list (list 0 (get-duration 1) content)))

Thanks for pointing me in this direction.
I’ll explore it further.

Yes thanks, these work to place the labels in the right spot.

Again my original goal is to easily paste the start/end times of a selection
(or the start/duration times) into a filename at the save dialog.

Now I’m wondering if it might be somehow easier to have these times automatically
put into the label names during an Export Multiple.

So for now I guess copy and paste the label into the filename, but not sure if that is much easier
than just looking at the Selection Toolbar and typing them into the filename.

It would be great to have the times formatted as hh:mm:ss + milliseconds

I know that’s a lot to ask so not really expecting all that.
But just wondering if there were a relatively easy way.
Seems like many would find this to be a useful Audacity feature.
Especially for those creating lots of loop extracts from long recordings,
where a reference to the time position of the loop in the original recording
is placed directly into the filename of the exported loops.

Thanks for any other ideas.

frew

Export Multiple can use the label text, if you are exporting based on labels: http://manual.audacityteam.org/man/export_multiple.html#name

Try this:

(setf decimal-places 3)

(defun format-time (sec)
  (setf *float-format*
    (format nil "%.~af" decimal-places))
  (let* ((hh (truncate (/ sec 3600)))
         (sec (- sec (* hh 3600)))
         (mm (truncate (/ sec 60)))
         (sec (- sec (* mm 60))))
    (cond 
      ((> hh 0)
        (format nil "~ah:~am:~as" (dd hh) (dd mm) (dd sec)))
      ((> mm 0)
        (format nil "~am:~as" (dd mm) (dd sec)))
      (t
        (format nil "~as" (dd sec))))))

(defun dd (n)
"pads n if required for double digit"
  (if (< n 10)
      (format nil "0~a" n)
      n))

(let* ((start (get '*selection* 'start))
       (end (get '*selection* 'end))
       (content (format nil "~a ~a"
                        (format-time start)
                        (format-time end))))
  (list (list 0 (get-duration 1) content)))

If you want to turn this code into a plug-in so that it can be installed for easy use, you just need to add the required “headers”. See: http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_Reference

Topic moved to the “adding features” section.

Is the feature request to make the code snippet an Audacity effect, or to have an option for Export Selected Audio to offer the selection start and end and length as file name?

Can we justify the latter as an option, given there is little time saving unless you want to export multiple selections? In that case you can use Export Multiple with this snippet.



Gale

frew’ requested (an) “Easy way to put Selection Toolbar info into export filename

Frew gave a very detailed use case in the first post, then described a more general use case:
(for) “those creating lots of loop extracts from long recordings,
where a reference to the time position of the loop in the original recording
is placed directly into the filename of the exported loops.”

I’m not sure that I’d described asking users to type, or even copy/paste thirty lines of code into the Nyquist Prompt, as an “easy way”, though the code could be made into a plug-in, and that may suffice.

Thank you very much Steve !

This works wonderfully.

So now when I have something like this: ( EDIT: that is, now it is so easy to produce this these kinds of exacting labels! )
Audacity_selection_start_end_times_label_names_to_export_multiple_filenames001.png
I can easily get to something like this: ( Edit: with Export Multiple that is…noted for any others new to these things)
Audacity_selection_start_end_times_label_names_to_export_multiple_filenames002.png
This is so easy to do now in Audacity.
It’s amazing really.

At the Nyquist Prompt I just pasted in your code, then did Save as a .ny file,
so now whenever I need it, I just load that .ny file into the Nyquist Prompt.
Thankfully the Nyquist prompt remembers the script even between opening and closing
various projects…perhaps even indefinitely…until other code is put into the prompt.

Often my workflow, when creating many loop extracts from a longer recording, does not
entail using various effects, so once I “Okay” the prompt for the first time after opening
a project, the Ctrl+R works nicely to keep going with Effect> Repeat Last Effect.

I would imagine many other Audacity users will find this Audacity capability to be very exciting,
very useful, and very time saving in their workflow.

This is very helpful indeed.

Thanks again,

frew

By the way, you can also save a script in the Nyquist prompt as a preset, I give the keyboard shortcuts here:

Alt-m (manage)
s (save)
Return

and for loading
Alt-m
u (user presets)
select preset by any mean (mouse click, arrows, first letter) Return

The text is now loaded and you can press OK.

Actually I read all that before asking. I asked because you provided a solution and then moved it to Feature Requests and it will probably be me who has to decide what to do with the request.

Frew seems happy with your solution (thanks), so unless someone else votes for some aspect of the proposition I won’t be adding this to the feature requests system.

I might suggest an improvement if it were possible, which is to run the code once after adding all the labels.


Gale

That’s not currently possible with Nyquist as label tracks are not readable for plug-ins.

Yes, because I think it is a valid feature request.
If we consider that a “solution” posted on the forum is adequate response to a feature request, then I suspect that many of the features requested on the wiki can be removed.

I don’t understand what needs to be “decided”. Isn’t it your policy to log and track feature requests?

OK, I now see it on Nyquist Wish List.

Usually if the original requester is satisfied by a solution, as here, we don’t add the request to the system. unless they change the request or want a better solution.

It’s vague as to what your preferred solution should be. All I see is a use case.

As I asked, should that solution only apply to export multiple?

You never yourself said that you supported this request, so I assumed you didn’t. So if you don’t give it a +1 and no-one else does, I would assume it now has no votes (because Frew is satisfied).

See above.

Yes if they have sufficient detail and it is clear that someone other than the original requester is now voting for it. There must be many ways the request could be met, such as by a multi-text clipboard. Normally we triage the requests here and end up with a focused request that has some implementation suggestions.


Gale

frew is clearly in favour of the feature, and is satisfied because the feature is now available in their one personal copy of Audacity, but it’s not available for anyone else unless they happen to stumble across this thread.

If we consider feature requests only in terms of usefulness to the individuals that make the requests, then is it really worth the time and effort? Even the “popular” requests have an insignificant number of votes as a percentage of all users. I don’t see that a 0.0005% vote is a strong argument for doing something (especially as we don’t record votes against). On the other hand, I do see value in having a record of the ideas that users put forward for improving Audacity.

Robert, thanks for that reminder.
And thanks again for pointing in this Nyquist direction for this workflow optimization request.

frew

Negative comments (reasons why a feature should not be implemented, or not implemented in the voted-for way) can be recorded (but not counted as negative votes) in a bullet point.

If you can see a good way with the current system to record negative votes (where we are sure the comment amounts to a negative vote) then please post it on the Talk page of Wiki Feature Requests. I suppose we could show something like “12 votes -2” but it is still meaningless without reading the comments.

What I am trying to get across is that Frew is presumably not now voting for this feature in a way that we can implement. Frew has not for example asked for a built-in effect to do what your plugin does.

You Steve have declined to vote for it.

So in terms of me transferring anything to Wiki Feature Requests there is nothing to transfer because there are no votes for it unless someone else votes for it before the month is out. This is how it usually works as far as I know. User asks for X and is then told they can do it with experimental plugin Y and then they don’t vote for X. I think you have cautioned against assuming votes when someone is satisfied with a workaround.

Even if there were votes for this, there are no details of a desired implementation. That doesn’t stop a vote being recorded if there were votes for it, but it isn’t all that helpful to someone who might want to implement a formal solution.


Gale

Frew, do you want to “vote” for a built-in solution, so you don’t have to use an optional piece of script? That script will be lost if you ever need to reset your pluginsettings.cfg file, even if you saved a preset.


Gale

We could write:

  • Feature short description: [votes +10 | -2]
    Long description …
    Optional dev notes.

but if we are going to move over to a Q2A system then I don’t think it’s worth the time/effort to change the current system at this late stage.

My interest here now is more about procedure than the specific case. I would prefer to split this to a different topic, but it’s become entangled, and frew’s request is a good example to work with.

Shouldn’t we still record this as +1 from frew?

  • Frew is clearly in favour of “the feature” because he’s using it.
  • The requested feature has not been implemented in a way that is generally available to users (not a “closed” or “resolved” issue except for one specific user).


Implementation details are really a matter for the developer(s). Users / QA may or may not have clear ideas about how a feature should be implemented, but it’s the developer(s) that have to implement it, and they have to work within what is possible, practical and safe.

I think where this is leading is: When is a feature request considered “done” / “implemented”?
You seem to be suggesting that frew’s feature request should not be recorded because (for frew) the request has been satisfied (it’s done). On the other hand, we still list the feature request “Stereo widener (2 votes)”, even though it has been available in the Channel Mixer plug-in for years.