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