On 07/01/25 23:29, Prof. Spock via groups.io wrote:
> The real step forward there is to provide a different type
> of echo one with feedback, possibly a multitap. *That*
> would open up new possibilities, but it has to have a new
> name.
Or it has the same name but with optional parameters like
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.
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 ] >
while, for "echos" one feedback path from the end to the start would be
feasible
to realize -er- something similar to the multitap but not the same,
which suggests
implementing a new one - "echom" or "multitap" - to realize a classic
multitap echo.
It's tempting to modify echo and echos to make them closer to what they
should be
but it may not be possible to both make them what they were and what
they should be.
"You can't make a racehorse out of a pig. You can, however, make an
awfully fast pig" :)
> > Provide a real phaser as "phaser"?
> As "phazer" or "resahp" or whatever. "spockify" if you
> want. People don't care - it's only SoX's effect
> namespace - and if spockify makes tongue-in-cheek
> sarcastic comments about phaser in its manual entry it
> might give them a laugh, you never know.
That's okay. My point was that a person expecting a real
phaser when using "SoX phaser" might be surprised.
But this could be handled in the documentation, e.g.:
»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.
The SoX "flanger" is by the great Rob Sykes so I have a lot more
confidence in it.
What a mess!
the wave form iterator in sox_i.h (lsx_generate_wave_table) has a
problem:
it cannot reproduce exact frequencies, because it keeps an
_array of samples_.
When the modulation signal wavelength does not exactly fit
into that raster, some roundoff error occurs, which
accumulates over time.
One can compensate that algorithmically (I did it in the
SoXPlugins) and admittedly the effect is absolutely tiny.
When subtracting a typical signal processed by the
SoXPlugins tremolo from one processed with the SoX tremolo
there is a tiny spike wandering in the spectrum at about
-130dB.
Right. Well, improving the frequency precision is desirable.
My only studio-quality piece, kickdirt
http://freaknet.org/martin/audio/csound/#kickdirt
has a phaser effect that must cycle exactly every 16 bars;
if it doesn't, the piece skews. Not that it was realized
with SoX but it could be important for someone.
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.
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.
M
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#39): https://groups.io/g/sox-ng/message/39
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]]
-=-=-=-=-=-=-=-=-=-=-=-
