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:
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?
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.
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:
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.
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.
So now when I have something like this: ( EDIT: that is, now it is so easy to produce this these kinds of exacting labels! )
I can easily get to something like this: ( Edit: with Export Multiple that is…noted for any others new to these things)
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.
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?
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).
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.
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.
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.
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.
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.