Hello SoX_ng,
you wrote:
> > [providing some sort of feedback mechanism for 'real'
> > echos]
> > echo gain-in gain-out [ -f feedback ] { delay decay }
> That's a good idea. as long as, without -f, it does the
> same as before.
When the default feedback is zero, then there should be no
problem.
> I notice that the multitap echo in Effects Explained has
> one feedback path, not one for each delay, though "echo"
> puts the delays in parallel, not series, which suggests
> echo gain-in gain-out <delay decay [ -f feedback ] >
Now you've lost me. If we want a single and collective
feedback path, why specify one for each tap?
You might recall my diagram from issue 276 in git:
x gain ___
+---------------------------------------------->| |
| ___ | | x gainOut
| | | x feedback | + |-----+
iBuff ->o->| + |<-----------------------------------o-->| | |
|___| ^ |___| v
| +===============================+ | oBuff
| | ECHO | |
| +===============================+ |
| | ________ ___ | |
| | | | x decay1 | | | |
+-->o-+->| delay1 |--------->| | | |
| | |________| | | | |
| | ________ | | | |
| | | | x decay2 | | | |
| +->| delay2 |--------->| | | |
| | |________| | + |->o--+
| | ... | | |
| | ________ | | |
| | | | x decayM | | |
| +->| delayM |--------->| | |
| |________| |___| |
| |
+-------------------------------+
which provides exactly one such path, i.e. a collective
feedback.
> while, for "echos" one feedback path from the end to the
> start would be feasible
Either individual or a collective feedback could be helpful.
But it soon gets very complicated to understand what really
happens and even some avalanche feedback effects might
occur, if you are not careful.
But algorithmically everything is doable. You could even
combine the idea into the following command line.
echo/echos gain-in gain-out [-f collective-feedback]
<delay decay [-f tap-feedback]>
Easy to parse and to implement and downward compatible.
> [multitap echo could be a new effect "echom"]
Why not reuse the original effects (although I am still
struggling with the results of the echos effect...)?
> "You can't make a racehorse out of a pig. You can,
> however, make an awfully fast pig" :)
You're well on the way to achieving this.
> > [talking about real phasers]
> > »phaser uses delay lines and hence does a harmonic comb
> > filtering.«
> Or "phaser is not a phaser; ir's a flanger." For a real
> phaser see fazer" and explain the difference between
> phaser and flanger's flangers.
Whatever you deem appropriate.
> The SoX "flanger" is by the great Rob Sykes so I have a
> lot more confidence in it. What a mess!
Well, SoX seems to me to be an effort to provide
command-line versions of prominent audio effects in a widely
distributed team with people of different backgrounds. I
have no problem when a geodesy Ph.D. candidate provides some
solution. Even though it might be improvable, it is better
that nothing and it is a good basis for rework.
And it is not sacrosanct.
Rob Sykes's code looks very professional. I have no problem
with that at first sight, but I will deeper look into the
flanger later.
What I could offer is provide a fazer.c implementation (or
whatever you like to call it, 'phaser_ng'?) if you like.
This will take some time, but it should not be too
complicated and we can check how some of my proposed ideas
prove themselves in practice...
> > ["absolutely exact" waveforms]
> Right. Well, improving the frequency precision is desirable.
> [...]
> Wouldn't that mean keeping the cycling offset as a float
> instead of an int and interpolating between sine/tri wave
> values, with a (slight) performance penalty, or
> calculating the sines for every sample with a much bigger
> one? Though normal computers are hundreds of times faster
> than when this was written, it would impact people running
> it on 200MHz ARMs.
Exactly.
The implementation in SoXPlugins
(https://github.com/prof-spock/SoX-Plugins/blob/master/src/Audio/WaveForm.cpp#L99)
does the following:
- It uses a single reference table for sines and triangles
(with 10000 support points for a sine and 4 for a
triangle).
- Each wavetable stores its real-valued length and
real-valued increment for each step in the sample rate
and an integer step count plus a pointer to the
reference table. Then it finds the real-valued position
in the reference table and does a linear interpolation
between the function point before and after.
I am not too keen on doing a higher-order interpolation for
a sine wave with 10000 base points.
And yes, this is slower than just using an integer index
into some precomputed table, but it is some float
operations, some to-int-conversions. Not too complicated
for todays standards. But, of course, if your machine has
no floating point hardware this can be costly.
We could even do a conditional compilation with
HAS_FLOATING_POINT. This should be limited to a few
code locations.
> > Long story short: in my opinion the algorithms may be
> > renovated and improved as long as the change is hardly
> > noticeable.
> Agree, always making the changes as small as is feasible
> to achieve the goal. Improving the precision, lowering
> the noise floor or whatever could be considered bug fixes
> and can probably go out in mid-February. New effects or
> new flags would be for the next minor release in May.
That looks like a plan.
Best regards,
Prof. Spock
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#40): https://groups.io/g/sox-ng/message/40
Mute This Topic: https://groups.io/mt/110480565/21656
Group Owner: [email protected]
Unsubscribe: https://groups.io/g/sox-ng/leave/13602885/21656/313486934/xyzzy
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
