Easy way to put Selection Toolbar info into export filename?

Both Peter and I think there are problems with using Q2A for feature requests, notably how we get the rich information we have now onto that system (or how we remind to also look at previous votes for the same or related things), and the unwanted/irrelevant posts if we open Q2A to the public.

I assume yes Q2A can handle downvotes. I never thought negative votes were common.

With the current system I do think we could add the date of the last vote when incrementing the vote count.

As I said, that would be going against what we usually do, and what you yourself have cautioned against (making assumptions for people). Because you have transferred the request here, which is fine except I was unsure if you were voting for it, then at the least we can archive it even if it has no countable votes.

Another real life example I’ve seen at least twice. The user asks in the Windows or Mac board for silence-padded Sound Activated Recordings. You Steve point out that they can use standard record then the Noise Gate plugin. User makes no further input or says something like “OK I can try that”. The original request does not get transferred to the “Adding Features” board and no vote for silence padded Sound Activated Recording is counted.

If there were several votes for a generic request, I still think it would assist developers to know what implementation is preferred by users, in case more than one solution is safe and practical.

I expect that happened because Channel Mixer appeared after the votes for stereo widener were recorded. If we dated the votes, we’d know.

If the votes were made after Channel Mixer appeared, it means that a shipped effect is wanted (exactly what I’m asking Frew about for his request).


Gale

A built in solution would be nice, but the curent solution works fine for me.
I just save the script in a separate .ny file from the Nyquist prompt,
in case I ever need to find it again.
But yes, sure, I would vote for it to be built in because I like it so much,
and I think many others would find it more readily and thus use it if it were built in.

The idea that others who would very likely highly enjoy this particular script’s capability would
only be able to enjoy this script’s workflow optimizing functions if they should happen across
this particular thread is a bit disconcerting I suppose.

I can see how that makes a lot of sense. It’s an interesting subject…how to discover clearly what Audacity users
want, need, enjoy, find useful, etc. And then deciding what to implement…certain things and not others. And then the
process of how to do the implementing. I personally would find that all a bit daunting. Yet it holds a certain fascination
as such a beautiful program continues to evolve in such amazing ways.

Thanks again,

frew

Thanks for explicitly stating your support for this feature.

A significant difference in that case, as with “stereo widener”, is that the ability to do what is being requested is readily available in Audacity.
For frew’s request, we don’t have anything like it as far as I’m aware.

By posting “answers”. See Stack Exchange as an example.

I don’t think that frew’s enthusiasm for the requested feature is an assumption.

I think that’s the case, but now that we have Channel Mixer available on the wiki plug-ins page, does that mean that the requested feature is now available (the issue is “resolved”), or is it only resolved if the feature is shipped in the standard Audacity bundle? What is the basis for moving feature requests to “Completed Features” ?

Audacity does not ship with Noise Gate or Channel Mixer. So there is still a potential request that such should be shipped without the extra work of downloading and installing a plugin.

So do you propose we should post answers (and questions where no relevant question exists yet) for each entry on Feature Requests? That seems a lengthy task. I don’t buy an argument that old requests are necessarily invalid or can never contain some idea a developer may want to take up.

No vote could be added on our existing system until Frew voted for something that was implementable. We can’t implement an experimental plugin that has already been implemented. :wink: Thanks for your reply, Frew.

Perhaps if we do use Q2A for brainstorming, some of the archived Feature Requests that spawned no recorded votes could be trawled for possible “questions”. I don’t see that as a priority.

In order to expedite removing unarguably completed requests from Wiki Feature Requests, Peter and I have agreed not to add further to Completed Features. Instead I will be proposing a separate detailed CHANGELOG file to be added to our sources. We would move the “Changes since” sections of README.txt to that new file.

As it’s impossible to know if the original requesters of a stereo widener would accept a plugin or prefer a shipped effect, I’d suggest the request remains, and so it’s now treated as a request for a shipped effect. No solution can be faultless, but if such requests remain listed they may help us determine which effects are “essential” for Audacity (a question you raised yourself recently).

Now that Frew has clarified, I suggest we might split this topic if further discussion of policies is needed.


Gale

Hello,

All is going well with this script, however I have one request.

At Export Multiple I get an error message asking me if I want to
change the filename to not include illegal characters in the filenames.

I’m wondering if the script can be modified to make it so that this
error message will not come up for each label/filename whose
location is at or beyond the one minute mark.

So in the following examples, the first section exports fine,
but the section beyond one minute runs into the filename
illegal character problem.

The two sections:
Audacity_label_names_to_export_multiple_filenames_not_legal_filename_error_message_001.png
The error message, with it’s option to automatically fix the filename:
Audacity_label_names_to_export_multiple_filenames_not_legal_filename_error_message_002.png
I wish I were at the point where I knew how to adjust the script,
but I don’t understand how to do the coding yet.

Also, a very fine point, but can the script be adjusted to put an underscore
between the start and end times?
So that something like this
15.000s 20.000s
would become this
15.000s_20.000s

Thanks,

frew

The text formatting is shown in red:

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

~a is a place holder for the hour, minute or second data. The rest of the red text is literal text.
Taking the first red line as an example. ~a occurs 3 times. The first time it is substituted with “hours”, the second time with “minutes” and the third time with “seconds”.
So the literal text is “h:” then “m:” then “s”

If we use as an example 3 hours 12 minutes and 24 seconds, and we want it to print as “3 hours 12 minutes and 24 seconds” that first red text would be rewritten as:
~a hours ~a minutes and ~a seconds

So putting that into context:
(format nil “~a hours ~a minutes and ~a seconds” (dd hh) (dd mm) (dd sec)))


Does that make sense?
Have a go and let me know how you get on.

Steve, thank you very much !

Yes, that was really helpful.

Here’s how I varied the script:

((> hh 0)
(format nil “~ah_~am_~as” (dd hh) (dd mm) (dd sec)))
((> mm 0)
(format nil “~am_~as” (dd mm) (dd sec)))

And down a bit in the script I made another variation here:

(content (format nil “~a_~a”

So now the dialog to change filename does not come up when labeled
sections are past the one minute mark, and I get this kind of result with
Export Multiple, by using the above variations in the script.

01h_05m_28.000s_01h_11m_23.000s

Thanks again for the great help,

frew