That’s right - you can’t return labels and a sound. Also, strictly speaking, modifying the sound should be an “Effect” (process) type plug-in whereas analysing the sound and returning information about the sound (labels) should be an “Analyze” type plug-in.
Yes it’s unfortunate that we can’t do that. When my C++/wxWidgets skills improve enough I’d like to make some enhancements to the Nyquist plug-ins interface, but I suspect that greying out controls will still be problematic. The interface cannot be controlled by the LISP code because the interface is created before the LISP interpreter is called and there is no mechanism for interaction between the LISP code and the interface. This shortfall could perhaps be fulfilled by introducing a new type of widget that has a Choice menu and a text input field.
For some cases it might also be a good solution to to force a secondary plug-in call with the controls ordered according to the first Input.
;control mode "make your choice" tags "Do this,Do that" 0
;control db "amplify by dB" real "dB" 6 0 24
;control percent "amplify by Percent" real "%" 200 0 800
The first Screen Shows only the “tags” control. After pressing ok,
The controls after the Chosen tag will be displayed.
Even better would be when XLISP code could also be executed inbetween the calls.
But we have discussed this already elsewhere - in parts at least.
Regarding the name of this effect I’m currently inclined to stick with “Stretch Silence…”
Although it may not be entirely correct when adding a fixed amount of silence within existing pauses, I think it is suitably brief for a name and (correctly) conveys the idea of making existing silences longer. I don’t think the term “Expand” is suitable because of possible confusion with dynamic compressors/expanders, but I’m open to other suggestions
As Robert mentioned, language lessons often have gaps that are roughly about right for the response to be spoken, but may be a bit short for the user to comfortably reply. That would be a “method C” user case.
Rethinking the options, a fairly simple solution would be to include all three methods as “additive”. That is:
Set the parameters for selecting the pauses.
Then into each pause:
2a) Add a % of the previous sound duration
2b) Add a fixed duration in seconds.
2c) Add a % of the current pause duration
Setting 2a, 2b and 2c to zero would give no effect.
Setting “2a” greater than zero produces “method A”
Setting “2b” greater than zero produces “Method B”
Setting “2c” greater than zero produces “method C”
Setting combinations of a, b and c would produce hybrid effects. For example:
Add 100 % of the previous sound duration (2a)
Add 2 seconds silence (2b)
Pause is increased by an amount equal to the phrase that is to be repeated, plus an additional 2 seconds “comfort factor” (modified silence marker to insert more silence - #15 by JH2013)
Possibly a better order for the controls would be:
Threshold for silence (dB) [or “Detect silences below … dB”
Min detected silence (seconds) [or “Detect silences longer than … seconds”]
Add constant duration (seconds) [or “Add duration of … seconds”]
Sounds reasonable, Steve.
Compression is not too far fetched.
Add 1 s to the gaps (method A)
reduce the gaps by 50 % (method C)
This is clearly a compression, just with seconds instead of Dezibel.
This might be good for e.g. audio books where the pauses vary too much.
If you allow this negative expansion, the name would be “Silence Compander”, otherwise “Silence Expander”.
Of course, the former is in some sense already implemented in “Trunc Silence”, except for the 2B control which takes the previous sound into account.
It might be necessary and convenient too add a Maximum Length control.
You have an Audiobook with rather short gaps. You extend them but you certainly do not want them to go over 3.5 s.
The same is true for e.g. Audio Dramas where soundeffects and music are inserted during the pauses. Most sound engineers have a quite structured system in that those background parts are seldom longer than 4 seconds.
I still don’t like “Stretch Silence” as a name, so I vote for “Extend Silence”.
Would you want that expansion to have the original silence added to it? Doing that (allowing positive compression values) seems to be the only way to add expansion without making the effect complicated again.
Indeed, that’s what I’d like.
The “Truncate Silence” mode would be left as it is.
The compression percentage would allow values up to 200 % or so.
The filling of the additional space can be accomplished in many different ways:
crossfading 3 copies of the original.
reversing the silence in the middle.
Several randomized FFT-spectra to fill the gap
Artificial Comfort noise with the same energy.
We do certainly agree that absolute silence wouldn’t be adequate.
I notice in “Stretch Silence” that if I have 1s of noise at -75 dB, then 2s of sound (Risset Drum in my case) then 4s of noise at -75 dB, then apply Stretch Silence to the entire selection at -40 dB, min 0.1s, insert 5s, the insertion is absolute silence, but the insertion is only before the sound, not after it, which I don’t understand.
I don’t see what the plural adds - any silence is extended or truncated. Plural could imply multiple selection regions.
Is your question "why does it not extend the final trailing silence (if present)?
I don’t think that users would normally need to do that because there is already infinite silence following the final sound (in the form or “white space”).
In most cases it is acting on multiple silent region(s).
Well clearly I wanted to do that and expected to. There isn’t infinite silence in the exported file if people plan to play files one after the other, also users may plan to append audio after running Extend Silence(s).
If you’re not planning that Truncate Silence should allow positive compression then I would expect Extend Silence(s) to at least have an option to extend the final silence.
Yes but it would be a pretty broken feature if it only worked on one silence within the selection. It’s working on all silence within the selection (with the current limitation above, which seems to make your suggested title inappropriate in any case).
I don’t know how a user who did not read the fine print of this long topic would find that out, but I see no reason to limit it to exclude the trailing silence. Of course you could wait to see if someone other than me asked for an option to include the trailing silence, or hide the option in the code.
It sounds if it may have something to do with dentistry, but I can’t think of anything better right now, except for “Extend Gaps” (verb first).
But if it’s only meant as a gap extender, why does it extend leading silence?
The problem is that Nyquist gets a sound that includes white spaces, especially if more than one track is selected.
Let’s say I have a question and answer dialog separated into two tracks–in the middle of a gap.
I can select both tracks ans extent the silences by 0.5 s.
If leading and tailing silences are enabled, the gap between question and answer will be one second +.
What’s more, the second track has probably 10 s leading white space followed by a shorter recorded silence. However, the white space will be extended and not the profile taken from the actual silence.
However, the second track has to be time-shifted in any case (unless sync-lock is enabled) to match the new length of the first track.
What the user should do:
Split at the very beginning of the answer track without background noise.
Sync-lock the tracks.
What the plug-in should do:
removing all leading and tailing white space.
extent the gaps that meet the requirements (threshold, min. length)
add the leading white space back and return the sound.
Either you make a control
or you let the actual selection decide.
It is clear that generated silence (or such with Ctrl-L) is treated as white space at the end and the beginning.
In conclusion, it is conceptionally wrong that Audacity passes the track object to Nyquist with all white space and not as if it was limited to the times obtainable with the shortcuts J and K.
The Truncate Silence effect seems to handle multiple tracks correctly.