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

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