Adjustable Fade

[Gale Andrews]

Is there any mileage in entering "%" in the text box to switch format to "% of original gain" (or for that matter, entering dB to switch to dB)?

I had considered that, but I think that it makes text entry too complicated. There is little or no scope to make it clear whether the correct format should be (for example)@
dB 0.0 -30
or
0dB -30dB
or
0 dB -30 dB
or
0 to -30 dB
or
0,0 30,0 dB
or something else.

Attempting to cover all of the possibilities in software is extremely complex.
Expecting the user to use exactly the correct format is probably expecting too much.

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?

The problem that I'm having with v26 is that I'm finding that quite often I can't create the fade that I want

Can you give a couple of examples of those you cannot create?

being "fit for purpose" must be the overriding priority.

Yes but it also depends on whose purpose - who the target audience is.


Thanks


Gale

[Gale Andrews]

I think it would be worth splitting some of the recent posts here to a "Professional Fade In" or similar topic.


Gale

[Robert J. H.]

I was just writing:

'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...

[Gale Andrews]

Do you have an insentive scheme where you pay or offer a prize to participate in the listening pannels? Mayve Or tit he software testings... mayve even for free company it is not bad idea to put som e monies aside for it.

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.


Gale

[steve]

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.

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.

How are you planning to treat non-numerical input in that box?

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:

Code: Select all

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

Code: Select all

;control input-string "Enter two numbers" string ""  

(defun check-values (txt)
  (if (and (string-to-numberp (first txt))
           (string-to-numberp (second txt)))
       "Input Valid"
       "Error, both values must be numbers"))

(defun string-to-numberp (var)
  (cond
    ((numberp var) T)
    ((numberp (char-replace #, #. var)) T)
    (T nil)))

(defun char-replace (old-char new-char in-string)
  (if (not (stringp in-string))
      "error"
      (let ((out-string ""))
        (dotimes (char-num (length in-string))
          (setf out-string 
            (if (char-equal (char in-string char-num) old-char)
                (format nil "~a~a" 
                  out-string 
                  (string new-char))
                (format nil "~a~a" 
                  out-string 
                  (char in-string char-num)))))
        (read (make-string-input-stream out-string)))))

(setf input ())
(let ((temp ""))
  (dotimes (i (length input-string))
    (cond
      ((and (char= (char input-string i) #space)
            (> (length temp) 0))
        (push temp input)
        (setf temp ""))
      (t (setf temp
          (format nil "~a~a" temp (string (char input-string i)))))))
  (when (> (length temp) 0)(push temp input)))

(cond
  ((not (listp input)) "Error, input must be a list")
  ((/= (length input) 2) "Error, input must be two numbers")
  (T (check-values input)))
 

[steve]

'How about moving the posts that concern a "Pro Fade In" effect to a seperate topic? I

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.

Can you give a couple of examples of those you cannot create?

"Professional" sounding fade-ins.

[Gale Andrews]

'How about moving the posts that concern a "Pro Fade In" effect to a seperate topic? I

I can do that later, but I think that it is highly relevant to this discussion.

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.

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.

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

Can you give a couple of examples of those you cannot create?

"Professional" sounding fade-ins.

What that is missing in the v26 examples would most contribute to that?


Gale

[Gale Andrews]

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.

I've not ruled out the possibility but it adds another layer of complexity to the code.

Is it a function of the number of characters - adding "%" or "d" as a format decider is less complex than adding "dB"?


Gale

[steve]

Is it a function of the number of characters - adding "%" or "d" as a format decider is less complex than adding "dB"?

"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".

[steve]

Can you give a couple of examples of those you cannot create?

"Professional" sounding fade-ins.

What that is missing in the v26 examples would most contribute to that?

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.