Hey hey,
I'm working on some Python code. The idea is to have a kind of MIDI sequencer
with a built-in metronome that plays the clicks using simple .wav files.
Here's the code, my question follows:
https://www.dropbox.com/scl/fi/5t2z0qtpj3ejyhevqdy9s/clock_test.zip?rlkey=w…
Currently, I am using pygame.mixer.Sound to play the .wav files, but compared
to the MIDI messages sent, the clicks lag. I tried lowering the buffer size,
as you can see in the Metronome class on line 110:
pygame.mixer.init(buffer=32)
No good.
Is there a better, hopefully simple, way to play these clicks?
On my system I'm running jackd with a samplerate of 48kHz and
-n 3 -p 256
This usually serves me well in recording audio and MIDI.
If someone could make suggestions, I'd appreciate it very much.
Best wishes,
Jeanette
--
* Website: http://juliencoder.de - for summer is a state of sound
* Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g
* Audiobombs: https://www.audiobombs.com/users/jeanette_c
* GitHub: https://github.com/jeanette-c
What's practical is logical. What the hell, who cares?
All I know is I'm so happy when you're dancing there. <3
(Britney Spears)
Guitarix.vst is the full blown guitarix stack as VST3 plugin for Linux,
using Juce to wrap the guitarix engine into a VST3 plugin.
It allow to load/save your presets, download presets from online and
load external LV2 plugs and IR Files, like the guitarix stand-alone version.
But all that as a VST3 plugin in your DAW. All parameters been exposed
to the DAW, so accessible for automation.
Other than the stand-alone, the VST3 version allows to switch the input
to a real stereo input, so it may match better your channel strip in the
DAW.
For Hdpi users, the GUI is full scalable.
New in this release:
 - Add support for Parallel Processing (process second mono chain in
parallel when stereo is selected)
 - Fix downloading online presets
 - Update included Juce modules to v7.0.12
 - Hide disabled controllers in main amp when no-tube is selected
 - Update included guitarix engine to latest git head
Project Page:
https://github.com/brummer10/guitarix.vst
Release Page:
https://github.com/brummer10/guitarix.vst/releases/tag/v0.4
regards
hermann
On Thu, Oct 17, 2024 at 12:27:30AM +0200, yoann.le.borgne(a)free.fr wrote:
> Regarding your approach of white box reverse engineering, have you had a
> look at Jatin Chowdhury's work on the subject?
> (https://github.com/jatinchowdhury18/AnalogTapeModel).
> He went quite far simulating the full chain and his plugin has acquired
> quite a reputation.
Yes, I know of his work. But reading the paper, I don't think
his physical model is correct.
Unless I'm missing something, the algorithm he uses amounts to
- upsampling, giving S(t)
- adding the bias signal B(t)
- evaluating the hysteresis loop on S(t) + B(t), giving M(t)
- downsampling, which filters out the HF bias.
But that NOT how things work in reality.
Imagine following a small fragment of tape (corresponding to
one sample in the upsampled domain), as it moves past the
recording head and away for it.
The magnetic field of the record head extends well beyond
the head gap, decreasing in strength as you move away from
it.
So the small tape fragment will go through to many
cycles of the bias + signal waveform with decreasing
amplitude. The resulting magnetisation is not just
the 'average' of M(t).
For an example, see
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/magnetisation.png>
X-axis is time in microseconds, bias frequency is 100 kHz,
bias amplitude is 1.0, signal (assumed constant during the
short time shown) = 0.5.
The green trace shows the magnetic field as seen by a small
tape fragment as it moves past the recording head.
The red trace is the resulting magnetisation, taking the
hysteresis effects into account. The constant value it
converges to is the signal that remains on the tape.
This is what I simulate, and it is way more complex than
what is described in Chowdhury's paper - that would just
be the average value of the red trace while it is still
at full amplitude.
If the signal is HF, it can't be assumed constant during
the time the field decay takes, it may well go through a
complete cycle or more. This is what causes the 'self
erasure' at higher frequencies which Chowdhury doesn't
take into account at all (AFAICS).
Ciao,
--
FA
Hello all,
The purpose of this post is to gather some opinions on the
use of 'tape distortion' plugins.
The way an analog magnetic tape recorder distorts the signal
is quite complicated. The non-linear response is mainly due
to the hysteresis of the magnetisation process, and how this
interacts with the HF bias added to the recorded signal.
Simplifying things a bit, as the tape moves past the recording
head and away from it, it goes through several cycles of an
hysteresis loop with decreasing amplitude, and it finally
converges to some value more or less proportional to the signal.
The bias signal itself does not remain on the tape, or at most
at a very low level.
The same process but with just a very high level HF bias is
used to erase the tape.
Simulating this accurately is quite complicated, and very CPU
intensive. The sample rate must be at least twice the bias
frequency (around 100 kHz for 'pro' equipment) and for each
sample you need to evaluate the hysteresis loop up to a hundred
times (depending on tape speed) to simulate the convergence.
Over the past few months I've written the code to do this,
with the aim to present a useful 'tape emulation' plugin
at the next LAC. It uses a somewhat simplified form of the
Preisach algorithm for the hysteresis.
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/preisach-model.pdf>
But the first results are somewhat sobering.
Have a look at
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/tapesaturation.png>
This shows the tranfer function (recorded magnetic signal as
a function of the input) for three values of the HF bias.
The blue line is what you get without bias. It result in a
very smooth saturation for high level signals, but a low
amplitude signal will be severly distorted due to the flat
region around zero.
As bias level is increased, this effect is reduced and the
low level gain increases up to some maximum. This is shown
by the orange curve.
The recommended way to set the correct bias level is to
further increase it until the small signal gain is reduced
by a few dB (typically 1 or 2 dB, depending on tape type).
This is shown by the green curve.
The central part of this is very linear (less than 1% THD).
But now the smooth saturation is almost transformed into
hard clipping. The sharp bend in the curve occurs when the
signal amplitude is higher than the bias amplitude.
The only effect that remains in a complete simulation is
the result of the EQ applied to the signal to be recorded.
Higher frequencies have a 'self erasure' effect (which is
nicely reproduced by the simulation) and so need to be
amplified. The net result is that they will saturate at
a lower input level.
How much EQ is required depends mainly on tape speed, higher
speeds need less. At the most popular 'pro' speed (381 mm/s)
this would be something around 10 dB at 10 kHz. At the higher
(762 mm/s) speed typically used for 'master tapes' it's just
a few dB.
So what does effectively remain of the 'smooth saturation
and compression' that is claimed to give tape recording its
magical 'warm' character ? Is it just a myth ?
I also simulated the green curve directly without going
through the complicated full simulation, and honestly,
to me that sounds just the same. And unless you really
use very high levels (much more than would actually be
used) the net effect is marginal. Maybe the hard clipping
can be useful when applied to individual tracks (e.g.
drums or bass), but then there are much simpler ways
to do this than 'tape emulation'.
Comments invited !!
On Wed, Oct 16, 2024 at 05:57:33AM -1000, robertlazarski wrote:
> When talking about the tape bias levels, the EchoFix is around 50hz and is
> annoying enough that I high pass filter it out.
You may have the wrong idea about what 'bias' is in this context.
The bias used in analog tape recording is typically in the 100 kHz
range, and even for 'consumer' level equipment at least 50 kHz.
Ciao,
--
FA
Fluida is a LV2 wrapper around Fluidsynth for Linux and Windows
allowing to load and control Fluidsynth as LV2 plugin.
This release of Fluida add support for Fluidsynth SoundFont Modulators
Envelope and Filter with the following MIDI bindings:
-Â Â Â MIDI CC 73 Soundfont modulator Envelope Attack Time
-Â Â Â MIDI CC 72 Soundfont modulator Envelope Release Time
-Â Â Â MIDI CC 74 Soundfont modulator Filter Cutoff
-Â Â Â MIDI CC 71 Soundfont modulator Filter Resonance
Project Page (Source Code):
https://github.com/brummer10/Fluida.lv2
Release Page (Binaries):
https://github.com/brummer10/Fluida.lv2/releases/tag/v0.9.3
