Thank you guys for the detailed feed back. I have to reply in portions, it seems.
I am blind, therefore I know exactly what the output is alike. As a matter of fact, the accessibility issue is the point that brought me to writing my own plug-ins.
If one is a little familiar with the functionality of the plug-in, the navigation is actually quite easy. Let’s say I want to choose the cosine S-curve fade-in effect, all I have to do is starting the plug-in, press two times “tab” and then two times “s” and that’s it. What we could do is to take the trim modes to the very top.
"Action choice"
> Trim & append
> Trim & align at time zero
---
"Threshold for trimming"
---
"Transition type"
> No Fade effect
> Fade-out linear
> ...
---
This feature would only be helpful, if you exclusively want to trim without the application of Gap/overlap and cross fade. It would be much more important to enable Nyquist to see the start and end times of the current track/selection and to modify them…
I know Steve’s plug-in. But it lacks (through implementation issues of Nyquist) the ability to choose the files within a conventional file dialog. Furthermore, you can only apply a cross fade between different titles if you split the track again and position them manually, thus nothing gained.
Well, in the german version, the chain command has the hidious Name “Stapelverarbeitung”, what essentially means batch processing. But you’re right, “append” should certainly appear in the plug-in’s name. I firstly contemplated “append and fade” but I don’t want to be involved in your “fade effects battle”…
How about “Append and blend”?
The plug-in won’t chain up if one of the following tracks is the same as the first one (its therefore not suited for looping). If the program wouldn’t recognise the first track, the following would happen:
if the plug-in is called several times with the same selection, the lengths of the previous tracks would be added to the first selected track and thus all tracks would be moved to the right.
Chain-it-up tries to create a “finger print” of the tracks in order to compare them to the first track. It is just like the check sum of your bank account number and as different accounts can have the same check sum, so different tracks can have the same finger print. I am still trying to improve this algorithm, but there are limits.
The trim effect is necessary to determine the length of the track.
imagine that you have two tracks, one is three minutes and the other two minutes and you select them both.
Audacity gives the sounds in the following manner over to Nyquist:
The first is not modified, since it is the longest one. you can readily take their duration and length (get-duration and variable len), but you do not know this, therefore you have to look if there is digital silence in front or appended to the track. In the case of the second track, Audacity still gives a length of 3 minutes over. The program searches now for the zeros at the end and removes them, calculates the new length and stores it in a list that survives different calls.
You mean “Extras & Help”, that is what it should read like. I am going to change this.
The examples were inserted shortly before publication, the menu point is wrongly linked, will be corrected.
I presume you refer to the debug window output. This information was and is necessary during the development to see how the plug-in reacts in certain situations. I fancy that the “force first call” will be removed in the near future. It is maybe replaced by a “two track mode”. The first track handling is primarily internally important. The changing of the vertical order doesn’t influence the plug-ins execution, as long as any parameter is changed in a new plug-in call.
For visually impaired people, the normal output is useless anyway, since one can’t scroll in the text. We could keep the output very brief with the hint that the verbose version can be examined in the debug window. I intent to write a proper tutorial as soon as the functionality and layout of the plug-in is somewhat constant.
Yes, it could be generally be used, where it makes sense. It has some draw backs though, it doesn’t function properly on Linux it seems, on Mac, no one has tested yet. But it is surely an improvement for visually impaired people (which do not use Linux in general).
At the moment, it plays 0.5 s before a fade-out, after a fade-in and also 0.5 before and after a cross-fade. We can change this to 1 second. There are also some clicks, which could be removed to get a more pleasant preview.
I hope Mr Bell hasn’t seen that…
Thank you very much, Gale, that helped me a lot.