I think this depends what Nyquist can do. If it can switch to dB if it sees the case-insensitive string “dB” at least once anywhere in the box (irrespective of what comes before or after that string), it could be worth thinking about IMO. And maybe even if e.g. those two characters had to be first. How are you planning to treat non-numerical input in that box?
Can you give a couple of examples of those you cannot create?
Yes but it also depends on whose purpose - who the target audience is.
‘How about moving the posts that concern a “Pro Fade In” effect to a seperate topic? It’s pretty mixed up again and a lot of ideas could get lost in here.’
And Gayle was faster, that’s the tragic of my life…
Audacity isn’t completely demonetised. It has costs (for example, hosting this Forum) that have to be met by some income. We are always happy to accept donations at http://audacityteam.org/donate/ .
There is a small amount of money available for spending on some issue that might come up, but definitely not a lot, and not enough to regularly offer money for users doing quality assurance testing.
I’ve not ruled out the possibility but it adds another layer of complexity to the code.
If you remember the issues with cross-platform support for file I/O we ended up with a couple of hundred lines of code to get it (almost) right. We could end up with a similar situation with text input. Nyquist does not handle text processing very elegantly, but after all Nyquist is designed for audio rather than text.
Invalid input could be ignored, or throw an error.
I favour throwing an error as the error message could provide “help” for how to enter valid input data.
Checking that data is only numbers and is the correct number of numbers is easy, for example:
(cond
((not (listp input)) "Error, input must be a list")
((/= (length input) 2) "Error, input must be two numbers")
((or (not (numberp (first input)))
(not (numberp (second input))))
"Error, both values must be numbers")
(T "Input Valid"))
Extending support beyond this exact format rapidly increases in complexity.
For example, just one “simple” addition of supporting a comma as the decimal separator expands the amount of code to something like this:
I can do that later, but I think that it is highly relevant to this discussion.
If there is no “one size fits all” fade in effect for music, then I think that it becomes essential that this plug-in can provide sufficient suitable fade-ins for music.
Even if relevant, this topic will soon be 200 posts . Anyone not already involved won’t know where to start.
I think you should start a new topic with Pro Fade In posts split out of here, so we can get as much fresh insight as possible into this. I suggest pointing to that new topic as stickies in the three OS help boards, too.
If you really want to, you could copy the topic and delete all the “adjustable fade” posts from the copy but i think you should split it.
I think what you stated should be true whether or not there is a “one size fits all” fade in, because we are meeting a feature request for “partial fades”.
But many users will not have limitless patience or great understanding. The more complex it seems, the less they will want to try. “Complex” is a balance of not too many controls, and reasonably understandable concepts (IMO).
What that is missing in the v26 examples would most contribute to that?
“dB” is not much more complex than “d”, but anything more than numbers is complex. Numbers and strings are different data types. If a text widget is being used for entering numerical data, then the text needs to be “converted” (evaluated) as a number, but non-numerical data cannot be evaluated and will cause an error in Nyquist.
In terms of data types;
“3.6 dB” (in quotes) is one string. This is the initial data format that is passed to Nyquist from a text widget.
3.6 dB is a number and a symbol.
“3.6” “dB” is two strings.
3.6dB is one symbol
“3.6dB” is one string.
3.6 “dB” is a number and a string. This is the format that we would need. The numerical part then needs to be used as data and the text part needs to be tested to see if it is one of our “valid” strings.
In order to convert “3.6 dB” to a number and a string, the code needs to step through the string character by character. “Characters” are another data type, different from numbers or strings. So we would read “3.6 dB” one character at a time as: #3 #. #6#space#d#B
Which then needs to be reassembled as: 3.6 “dB”
“dB” can then be checked against our valid strings: “dB” and “%” with case insensitive comparison.
There is also quite complex logic involved in working out what is valid data and what is not. The code needs to be able to “handle” error cases as well as valid data - the plug-in should not just fail with no error message and should not fail with a cryptic error message that only appears in the debug window. For example, what should the code do if someone enters % and dB? We would not just want the generic “Nyquist did not return audio”.
On top of that, how do we make it clear in the UI what the user needs to enter?
It’s not impossible, but in “Click Track” it was considered not worth the complexity, hence the decision for “whole numbers only”.
There are 6 fade-in shapes available in v26. Testing these fades on a variety of music, in most cases none of the available fades gives me a result as good as I would like. The problem in my opinion is that preset fade shapes (only) are not flexible enough to meet real-world situations. It’s like trying to drive a car that will only go at 25, 50, 75 or 100 mph, but will not go at any speed between. Yes we could add 10 mph and 60 mph, but driving conditions may dictate that the speed should be 45 mph, or 30 mph, or 52 mph.
Accept the first valid text data as the required units, then discard any other valid text (message in debug window) to say what happened)? Or refuse with an explicit error message? I guess the latter is preferable.
It sounds as if that would be the easiest of the problems. Can the “%” or “dB” be anywhere in the box? Must it have a space either side? If the user was told for example that if they want dB they must type at the start the text “db” (case insensitive, no quotes) followed by a space, else they get % (so they have a default) I think that would be very understandable.
If the rule was that they have to write db (case insensitive) followed by a space at the start (for dB), or % followed by a space (for %) that is not so friendly, but would be quite acceptable.
I certainly don’t want to give you sleepless nights coding such a thing, but if it substantially improves the interface to have this feature, it may still be worth thinking about.
I vote for a new topic for pro fadde in — is too hard maybe to post here in this topic about that, but maybe I can give you some findings soon.
Hmm steve, mayve you need envelopoe tools after all ifyou cannot be satisfied with 6 or 8 preesets … or mayve what was it you thiunk of… testual enveloope??=
So we are again back to Mid Fade Boost? Do you want a v26d with:
fade type (choice of 14) (does not disable the other controls)
boost slider (and text box)
high and low linear gain sliders (0 to 1) (and text boxes)
units values text box for dB or % or original (units controlled by text input)
I really don’t like the confusion risk posed by linear gain as you know, especially as here it would effectively be the default units.
Of course at the risk of further complicating the units values text box, I suppose you could do away with the gain sliders and specify “l” or something for linear.
Or 26e:
fade type (choice of 14) (does not disable the other controls)
Units choice (dB, % of original, linear)
boost slider (and text box)
Units values text box (units controlled by “Units” control)
Wordings are purely illustrative. For clarity, 26e has much to commend it, and if 26d needs linear gain sliders I might prefer 26e.
However, 26e could actually be more irritating for those who want non-default units (because in 26d you could choose the non-default units and values in one control). I’m guessing most people would have a favoured default unit they’d use most of the time (and I’m still assuming “% of original”- however non-standard - will actually be the preferred choice for many people).
And if the sliders in 26d were % (at the price that we made people who wanted > 100% or > 200% use the text box to left of the slider) then 26d would be my choice (assuming away the issue of coding the text box).
Asking Steve another question… if you had to choose, is the Mid Fade Boost Slider or the linear gain sliders more important to you?
As for cars only going at selected speeds, I think that’s the problem with v27 - the “from” and “to” % presets will never be sufficient, so if we were to have one set of presets that disabled all the other controls, I think the presets must be the fade type. But I think v26d or v26e are better than v27 if we want Mid Fade Boost back.
I think that we only really need “Mid Fade Boost” (or whatever it is called) for “simple” curves. That is, curves similar to this set:
That is, for a fade-in:
A “simple” curve with the “Mid Fade Cut / Boost” at zero produces a linear fade.
When “Mid Fade Cut / Boost” is decreased (cut) the fade in will begin rising slowly at first, then gradually more rapidly (like the first few shapes in the above set)
When “Mid Fade Cut / Boost” is increased (boost) the fade in will begin rising more rapidly, then gradually more slowly (like the lower shapes in the above set)
(and similarly for fade out)
The Mid-Fade slider.
Whether the gain is in linear units, dB, %, log base 2, or anything else, the functionality is the same and I could get used to it no matter how obvious / convenient / peculiar / inconvenient (though “obvious and convenient” is to be preferred).
Without having some way to adjust the shape of the curve (at least a “bend a linear fade this way or that way”) then I think we lose important functionality.
yulac:
Could you write your messages in the default black text please. Shades of green/blue against the pale blue background are difficult to read on some monitors.
OK but this is not an interface complication is it - the boost will always be available?
OK then it’s back as far as my vote goes - I am not sure why you removed it from v26 when you had more or less made a convincing case for it. The help in the Manual could perhaps use some of those images you posted to explain it, together with an arrow for where the mid fade point is. Would it be more understandable as the “half-length fade point” or similar? I take it “mid fade” is standard terminology?
So what are your views on 26d, 26e or do you have a 26f to propose?
I’m increasingly drawn to 26d (with or without a pair of gain sliders for one of the units) on the grounds it’s one less control to deal with for the non-default units. Using “%” for the the slider pair might to some extent make up for not having “% to and from” presets.
But a lot depends on your views of letting the text box input determine the type of units, and whether % or dB might yet be sufficient as the units choices (in which case, if we have a pair of sliders, the text input box just takes the “other” format).
In an attempt to simplify the effect for novice users, but it is not acceptable. Too much functionality is lost.
Yes I think some images would be a big help in making it clear.
No, I made it up.
The only “standard” terminology that I’m aware of is “Curve” (on DJ crossfaders) where a higher setting means that a fade-in rises more rapidly at the beginning of the fade and a fade-out drops more rapidly at the end of the fade.
Outside of DJ mixer crossfaders I don’t recall seeing any description in words - the manuals generally just show pictures of the fade and avoid any description in words. (The Adobe Audition manual just says “drag up or down”).
Well it’s one slider more than not having it, but having tried the effect without that slider I think it is one control that we can’t do without.
Unless the “presets” include one option called something like: “Simple Curve (adjustable)”
and the “Mid-fade Cut / Boost” is called something like: “Adjust ‘Simple’ Curve”.
I don’t think that “Simple Curve” is a particularly brilliant description, but the idea is to distinguish it as a curve in one direction or the other as opposed to an S-shaped curve that curves “up” in the higher level half of the fade then “down” in the lower level half.
It may help to mitigate novice users “losing” the default shape settings if the other preset fade shapes are factory set, non-adjustable shapes.
So then “high/low point gain (dB)” OR “low and high as % of original” would be available for all “Fade Types”
and “Adjust Simple Curve” would “bend” the “Simple Curve (adjustable)”.
So we want sliders for the high and low points of the fade I think?
If we remove the controversial “linear gain” option, then the sliders can be “% of the original” or “gain dB”.
I’d prefer not to have both types of sliders.
If we use “% of the original” for the sliders then obvious choices for the range would be either 0 to 100% or 0 to 200%. I think that going beyond 200% would make selecting small values too fiddly. For a range of 0 to 100%, one click to the side of the slider produces a change of 10%. For a range of 0 to 200% one click gives a change of 20%. Ctrl+left/right cursor does the same.
If we use “gain dB” for the sliders then a suitable range might be -96 to +24 dB. This gives a “one click” change of 12 dB. We would need to “fudge” silence as the dB scale cannot go down to -inf, so the minimum setting could assume that the users means silence (zero gain). Unfortunately 12 dB is quite a big step as I’d imagine that users may frequently want to set the minimum level somewhere between 0 and -12 dB, but the low end needs to be close to silence, particularly for exponential fades where the minimum level makes a huge difference to the shape of the fade.
The main (practical) downside of % sliders is that even with a range up to 200%, that is still only +6 dB, which is not much when amplifying low level audio. However, I am still inclined to go with a linear (%) scale for the sliders as long as there is an alternative convenient method for entering larger gain values. Text input would provide that option. In which case I would vote for sliders with a range of 0 to 100% as this is likely to be most convenient in most cases.
If we agree on “% of the original” as the units for the sliders, then I see no compelling reason to make the text input different. So what I’m now suggesting is that we use % as the units for both sliders and (optional) text entry. If we must have gain expressed as a % of the original level, then I’d prefer that we used it consistently within the interface. If there is substantial demand for other units after release of the plug-in, then we can either provide a “Select Units:” control or allow units to be defined within the text input (for example " 0 -12 dB ")
I don’t think that this will lose anything functionally, and not needing to select the units will simplify both the interface and the manual.
Any colour you like, but if your posts are hard to read, people may not bother reading them.
. Anyone not already involved won’t know where to start.
stev e you bit hard man i think , i see a button for font colour you shold disable it if not allowe… black is boring 
what colors aree allowed??? 