Re: An idea for an entirely new effect -- warning, long post

Robert Hänggi <[email protected]> Mon, 17 May 2021 13:29:46 +0200
Newsgroups gmane.comp.audio.audacity.devel
Message-ID <CAJhgUZ1dhWQQKmqD=P9aDRZLtDf3MsOL3Wreayr3sCGkGvOnfQ@mail.gmail.com>
On 17/05/2021, Steve Fiddle <[email protected]> wrote:
> Interesting stuff.
> The final line of Robert's "squaring two signals and adding them together"
> assumes that the selected audio is a mono track.
> For a two channel track it needs to be:
> (sum (s-square (h1 (aref *track* 0))) (s-square (h2 (aref *track* 1))))
>
We will use multichan-expand in the end so that it works with either
track type, unless the stereo track effect has some linked parameter
e.g. feeding L back in to R...
Robert

> Steve
>
> On Mon, 17 May 2021 at 09:10, Robert Hänggi <[email protected]> wrote:
>>
>> Here is the plug-in:
>>
>> https://www.dropbox.com/t/AK66Xx2uxpvatEOH
>> It works only on stereo tracks.
>> The idea is to rotate the right channel by 90° at each application.
>> So, at the second time, you have basically inverted the right track
>> and at the forth, it will be back to the original state (although it
>> won't be exactly the original due to the nature of the IIR/HT with the
>> needed one sample delay).
>> In other words, the left and right channels represent the real and
>> imaginary part of the signal, especially if the track is dual-mono
>> (same content in both channels).
>> Let's look at the last line:
>> (vector  (h1 (aref *track* 0)) (h2 (aref *track* 1)))
>> The signal that comes from the track is always *track*.
>> If it is mono, you can work with it as it is.
>> If it is stereo however, it is represented as an array with two
>> elements. Aref references the left (=0) and right (=1) channel.
>> The function h1 creates the original signal, the real part. Of course,
>> this would normally not be necessary but we need to adapt it for the
>> delay introduced through the IIR (ideally, the delay would be only
>> half a sample for h2).
>> the function vector creates again an array from the two sounds.
>> OK, let's assume that we work only with a mono track.
>> We could for instance use the Hilbert transform to return the
>> amplitude envelope of the signal.
>> This is done by squaring the two signals and adding them together.
>> First, create a mono track with e.g. a chirp or some other signal or file.
>>
>> Copy all the text from the plug-in into the Nyquist prompt.
>> replace  the line with '(vector...' with the following:
>>
>> (defun s-square (sig)
>>    (mult sig sig))
>> (sum (s-square (h1 *track*)) (s-square (h2 *track*)))
>>
>> (you can save this as a preset if you go to the manage button)
>>
>> Apply the effect. You should (almost) hear nothing because the track
>> represents now the amplitude instead of the signal, in other words,
>> just plenty  of DC offset.
>>
>> HTH
>> Robert
>>
>>
>>
>> On 17/05/2021, Federico Miyara <[email protected]> wrote:
>> >
>> > Petr,
>> >
>> > There is a free program called SPEAR that you can download here:
>> >
>> > http://www.klingbeil.com/spear/downloads/
>> > <http://www.klingbeil.com/spear/downloads/>
>> >
>> > It models a signal by detecting partials and representing their time
>> > evolution by sine waves
>> >
>> > I'm not sure it is sufficiently accessible, but it allows several types
>> > of edits such as the partial displacemente you mention.
>> >
>> > Regards,
>> >
>> > Federico Miyara
>> >
>> >
>> >
>> > On 16/05/2021 02:34, Petr Pařízek via audacity-devel wrote:
>> >> Hello to all of you,
>> >>
>> >> to introduce myself a bit, I'm a piano player and a music composer and
>> >> a music theorist who is very interested in things regarding digital
>> >> audio effects. Many years ago, I wrote a lot of small programs for the
>> >> old QBasic for DOS and currently I'm planning to start learning
>> >> Nyquist in some near future.
>> >> FYI, I'm blind and that's why, when manipulating with the contents of
>> >> a sound file, I often combine listening to the sound and converting
>> >> the sample values to text, if I want to know more about some tiny
>> >> details (where most people would probably zoom in the waveform).
>> >>
>> >> I'm thinking of a possible new effect which might one day be
>> >> implemented in Audacity. Currently, I'm absolutely unsure whether this
>> >> kind of effect could be coded in Nyquist at all or whether the only
>> >> way is to write such complex stuff in C or whether there's yet another
>> >> way of doing it which I don't happen to know about. But I'd be
>> >> super-happy if I were told that this thing could indeed be coded in
>> >> Nyquist.
>> >> Therefore, I'll do my best to describe the effect, as some say, "in
>> >> prose", and hope my description is understandable for you all. In case
>> >> it isn't, I'm definitely open to clarification. I'll be very happy to
>> >> know your opinions about what might be the best way to code this.
>> >> I'd like to stress that I'm not intending this effect for real-time
>> >> performance at all, even though the description of the effect itself
>> >> might make you think I am. I'm not even suggesting something like a
>> >> "Preview" facility because I don't want the processing speed to be of
>> >> any importance here. In every case, I'm willing to sacrifice speed
>> >> over precision, even if the algorithm eventually turned out to be
>> >> super-slow.
>> >> Although I'd love to have such a thing working one day, I'm even ready
>> >> for the possibility that this effect might never be implemented, if I
>> >> realize it would be too difficult for me to code (honestly, I've never
>> >> coded in anything other than QBasic or briefly in Turbo Pascal, which
>> >> would probably require me to learn C all from scratch if C turned out
>> >> to be inevitable).
>> >>
>> >> - The core part of the algorithm is a frequency shifter [1]. Unlike a
>> >> pitch shifter, whose aim is to alter all the frequencies by a constant
>> >> ratio, a frequency shifter alters all the frequencies by a constant
>> >> difference.
>> >> - The corresponding dialog box would offer the following parameters:
>> >> 1) the amount by which the frequencies should be shifted, given in Hz,
>> >> which could be either positive or negative;
>> >> 2) two volume settings, namely for "dry" and "wet";
>> >> 3) the amount by which the wet signal is fed back into the input,
>> >> given as a value that is less than 100% and more than -100%.
>> >> 4) the amount by which the feedback is to be delayed, probably given
>> >> in ms, which should always be given as a positive number; this
>> >> parameter has no effect if feedback is set to 0.
>> >>
>> >> [1] The actual realization would go like this:
>> >> - A) We store two intermediate copies of our original signal, label
>> >> them "IP" and "Q", and modify them as described in [2],
>> >> - B) Each of the modified intermediate signals is separately
>> >> amplitude-modulated:
>> >> IP is multiplied by a cosine wave of the given frequency,
>> >> Q is multiplied by a sine wave of the same frequency,
>> >> - C) we sum the two products to get the frequency-shifted signal,
>> >> - D) this signal, multiplied by the "Wet" coefficient, is sent to the
>> >> output, together with the original signal multiplied by the "Dry"
>> >> coefficient,
>> >> - E) the same frequency-shifted signal, this time multiplied by the
>> >> "Feedback" coefficient and delayed by "Delay" ms, is sent back to the
>> >> input.
>> >>
>> >> [2] We make a filter that works like an inverted Hilbert transform,
>> >> for which reason I'll call it the IHT. The length of the filter will
>> >> probably be hard-coded and unknown to the user. The longer the filter,
>> >> the closer the approximation gets to a proper IHT.
>> >> - For a positive integer l, the filter length should be either l*4 or
>> >> l*4-1 samples. Practically, the two make no difference because every
>> >> other coefficient is equal to zero.
>> >> - Even though the filter is l*4 samples long, our sample position
>> >> indexes, instead of going from 0 to l*4-1, should go from -2*l to
>> >> +2*l-1. Let's call them k. Similarly, for a filter of length 4*l-1,
>> >> the sample position indexes k would go from -(2*n-1) to +2*n-1, i.e.
>> >> from -2*n + 1 to 2*n - 1.
>> >> The actual values of the filter coefficients meet the following rule:
>> >> - For all even numbers k, the coefficient c(k) is equal to zero.
>> >> - For all odd numbers k, the coefficient c(k) is equal to -2/)k*π).
>> >> - Next, we convolve our original signal with this filter and store the
>> >> result into an intermediate buffer, which may be called Q (as in
>> >> "quadrature").
>> >> - Then, depending on whether our filter length is even or odd, we
>> >> delay our original signal either by 2*n or by 2*n-1 samples and store
>> >> this delayed copy into another intermediate buffer, which we may call
>> >> IP (meaning "in phase").
>> >>
>> >> You may be wondering why I insist on using an IHT instead of a proper
>> >> HT or on multiplying IP by a cosine wave rather than a sine wave. The
>> >> answers are:
>> >> - If I choose the amount of frequency shifting to be zero and do it
>> >> the way I've described, the supposed frequency-shifted signal will
>> >> only be delayed by "Delay" ms but in all other aspects it will be
>> >> identical to the original sound -- i.e. there won't be any additional
>> >> phase shifts or delays. In contrast, if IP were multiplied by a sine
>> >> wave and Q were multiplied by a cosine wave, then the supposed
>> >> frequency-shifted signal (with a zero frequency shift) would
>> >> correspond to the original signal not just delayed but also
>> >> Hilbert-transformed. This doesn't seem like an issue if the feedback
>> >> is set to zero. However, once I set the feedback to a non-zero value,
>> >> this thing starts to matter significantly.
>> >> - When I use an IHT, then I can get the desired frequency shift by
>> >> adding the two amplitude-modulated signals. In contrast, if I used a
>> >> proper HT, adding them would give me the opposite frequency shift and
>> >> to get the desired one, I would have to subtract them.
>> >>
>> >> Okay, that's it. Sorry for such a long post but I didn't want to miss
>> >> any important details.
>> >>
>> >> Thanks for your comments or suggestions.
>> >>
>> >> Petr
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > El software de antivirus Avast ha analizado este correo electrónico en
>> > busca
>> > de virus.
>> > https://www.avast.com/antivirus
>> >
>>
>>
>> _______________________________________________
>> audacity-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
> _______________________________________________
> audacity-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>


_______________________________________________
audacity-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/audacity-devel