trummerschlunk / master_me Goto Github PK
View Code? Open in Web Editor NEWautomatic mastering plugin for live streaming, podcasts and internet radio.
License: GNU General Public License v3.0
automatic mastering plugin for live streaming, podcasts and internet radio.
License: GNU General Public License v3.0
In the installer and as plugin manufacturer please write 'Klaus Scheuermann' instead of '4ohm'
opening a ticket to generate a discussion around this.
currently the plugin is quite heavy, ideas for optimizing its cpu usage would be quite welcome.
we could try a few compiler optimization flags and see what works best.
also reducing the gui-oriented calls on the dsp side, as mentioned in other tickets.
this can be a blocker for some people doing live-streams, as the capturing + recording takes a significant amount of cpu. if audio processing does too, the system might not be that much responsive when all parts are on.
I did a few listening tests, and the confirmed this by measurement. The LR4 cross-over network used by the mscomp adds a 180 deg phase-shift where bands overlap:
A multiband compressor is commonly implemented:
I've whipped up some FAUST code for this which should be straight forward to integrate here.
https://gist.github.com/eeb2aa9f9cc4a9083fb2cf2d86645c9a
@magnetophon Since you have significantly contributed to FAUST's compressor lib, you may be interested in this as well.
(moved to low-prio, as not critical for first release)
These are the texts for 'Easy' page:
Hi there,
master_me is a free and open source automatic mastering plugin for live streamers, podcasters and internet radio stations.
You are currently in “Easy” mode.
Select a preset from the bottom and forget about it.
Choose “Expert” mode to see and tweak what's under the hood.
Happy streaming!
And on the right side:
master_me
A plugin by Klaus Scheuermann.
With contributions from falkTX, jkbd, magnetophon, x42 and others.
Made with Faust and DPF.
Supported by the Prototype Fund / German Federal Ministry of Education and Research.
there are two kinds of presets:
todo on dsp/faust side:
todo on gui side:
IMHO, anybody who can handle the "expert" interface, will welcome being able to tweak the crossover frequencies.
crossoverFreqs = vslider("v:soundsgood/t:expert/h:[5]mscomp/h:[1]low band/[1]mscomp low freq", 60, 20, 20000, 1),vslider("v:soundsgood/t:expert/h:[5]mscomp/h:[2]high band/[1]mscomp high freq", 8000, 20, 20000, 1):LogArray(Nr_crossoverFreqs);
There is commented code around the compressor gain reduction naming part:
//meter(i) = _<:(_, (ba.linear2db:max(-40):min(0):vbargraph("v:soundsgood/t:expert/h:[6]mscomp_meter/[%i][unit:dB]%i[tooltip: gain reduction in dB]", -3, 0))):attach;
meter(i) = _<:(_, (ba.linear2db:max(-40):min(0):vbargraph("v:soundsgood/t:expert/h:[6]mscomp_meter/[%i][unit:dB][tooltip: gain reduction in dB]", -3, 0))):attach;
From what I could understand, these are dynamic stereo controls, so giving a name makes it appear duplicate.
I guess it is commented out until a solution is found.
This ticket can serve as a reminder, as we need this for the plugin version too.
I implemented a 'side eq'.
desired function: boost on the side signal in an area (width) around a center frequency (eq side freq) by an amount in dB (eq side gain)
It's done with a bandpass filter added to the source signal.
I am having trouble calculating the loudness of the bandpass so it feels like a parametric eq. (0 adds nothing, +x adds x db)
My from width to low and high frequency of the bandpass is messy and broken in low frequencies.
Help needed...
please make mb-ms-comp meters range -6dB
(done in dsp file)
I am not 100% sure, but I guess it's a problem wit ma.EPSILON..?
Does the -double option make the code more cpu-heavy?
With the need for '-double' I can't use the faustide.grame.fr which I find quite comfortable.
Which IDEs do you guys use? I went for ATOM and Faustlive. Not too slick...
something seems wrong with the new gate meter.
it has a proper value where there is sound input, but cut the input and gate meter value gets lower and lower and lower... eventually stopping at -758.6 dB.
This seems like a bug..
make presets safe 'easy' or 'expert' state
In the best case, this software runs everywhere and shines with all the platform dependent details. Sure, beauty is our business.
But what is the most important niche, where it has to run properly as soon as possible? That is:
As previously discussed.
Ticket serves as reminder and to check on progress on the task. Which as of now is still TODO.
What's your favorite place and format of documentation for a plugin like this?
Wiki? Markup document?
Preferably here on the repo, right?
Am am not seeing it... why are parameters displayed in wrong order?
sc_compressor =
(
(ms_enc,ms_enc):
(((RMS_compression_gain_N_chan_db(strength,thresh,att,rel,knee,0,link,N)),si.bus(N) )
: ro.interleave(N,2) : par(i,N,(meter : post_gain : ba.db2linear*(1-bypass)+bypass)*_))
: ms_dec)
with {
N = 2;
bypass = checkbox("v:soundsgood/t:expert/h:[5]kneecomp/[symbol:kneecomp_bypass][1]kneecomp bypass"):si.smoo;
strength = vslider("v:soundsgood/t:expert/h:[5]kneecomp/[symbol:kneecomp_strength][2]kneecomp strength", 0.1, 0, 1, 0.1);
thresh = target + vslider("v:soundsgood/t:expert/h:[5]kneecomp/[symbol:kneecomp_threshold][unit:dB][3]kneecomp threshold",init_kneecomp_thresh,-12,6,1);
att = vslider("v:soundsgood/t:expert/h:[5]kneecomp/[symbol:kneecomp_attack][unit:ms][4]kneecomp attack",40,1,100,1)*0.001;
rel = vslider("v:soundsgood/t:expert/h:[5]kneecomp/[symbol:kneecomp_release][unit:ms][5]kneecomp release",200,1,1000,1)*0.001;
knee = vslider("v:soundsgood/t:expert/h:[5]kneecomp/[symbol:kneecomp_knee][6]kneecomp knee",6,0,30,1);
link = vslider("v:soundsgood/t:expert/h:[5]kneecomp/[symbol:kneecomp_link][7]kneecomp link", 0.6, 0, 1, 0.1);
meter = _<: _,( vbargraph("v:soundsgood/t:expert/h:[5]kneecomp/[unit:dB]",-6,0)) : attach;
// dev version of faust has this in the libs, TODO, use co.RMS_compression_gain_N_chan_db
RMS_compression_gain_N_chan_db(strength,thresh,att,rel,knee,prePost,link,1) =
RMS_compression_gain_mono_db(strength,thresh,att,rel,knee,prePost);
RMS_compression_gain_N_chan_db(strength,thresh,att,rel,knee,prePost,link,N) =
par(i,N,RMS_compression_gain_mono_db(strength,thresh,att,rel,knee,prePost))
<: (si.bus(N),(ba.parallelMin(N) <: si.bus(N))) : ro.interleave(N,2) : par(i,N,(it.interpolate_linear(link)));
RMS_compression_gain_mono_db(strength,thresh,att,rel,knee,prePost) =
RMS(rel) : ba.bypass1(prePost,si.onePoleSwitching(att,0)) : ba.linear2db : gain_computer(strength,thresh,knee) : ba.bypass1((prePost!=1),si.onePoleSwitching(0,att))
with {
gain_computer(strength,thresh,knee,level) =
select3((level>(thresh-(knee/2)))+(level>(thresh+(knee/2))),
0,
((level-thresh+(knee/2)) : pow(2)/(2*max(ma.EPSILON,knee))),
(level-thresh))
: max(0)*-strength;
RMS(time) = ba.slidingRMS(s) with {
s = ba.sec2samp(time):int:max(1);
};
};
//post_gain
post_gain =
_+
(vslider("v:soundsgood/t:expert/h:[5]kneecomp/[symbol:kneecomp_makeup][unit:dB][8]kneecomp makeup", init_kneecomp_postgain,-10,+10,0.5) :si.smoo);
};
Either something wrong in faust, or the way the meters are defined.
The "init" or default value for the level meters (and maybe others, not sure) is 0dB instead of the expected matching minimum.
This makes it so that, under a few hosts, the UI starts with the meters at 0dB and trigger the falloff on start.
Would be nice if the init/default values for level meters would be set as its minimum (as if there was no audio) instead of 0dB as it is now.
GUI: remove numbers from bands in mb-ms-comp
One usually uses a factor or 0.5 when converting left/right to mid/side and then just sums for the inverse
mid = 0.5 * (left + right)
side = 0.5 * (left - right)
and then
left = mid + side
right = mid -side
As opposed to the sqrt() approach, this also ensure that the mid value will not exceed 1.0, if both source values are below 1.0.
Note multiply by 0.5, which is faster than diving by two (although some compilers change this with fast-math)
A few parameters do not have units, this ticket serves to track down these and possibly make a decision on them.
Switches (including bypass) do not need them.
But others should have them, if possible.
(Personally I find 0-100% more readable than 0.0-1.0 raw values)
Current parameters without unit:
There is one problematic situation with the new feedback concept of the leveler
(which works so nicely now):
If target
is higher than possible with the settings of limiter
and brickwall
, they will fight against each other resulting in maximum gain
of the leveler
.
I think it cannot be avoided, but with limiting certain ranges.
An 'expert' will not set these settings.
What are your ideas on that?
global bypass
leveler: try expander instead of gate for silence detection
leveler: fix wrong calculation
side-eq: try different shelf eqs
kneecomp: drywet control (after makeup)
kneecomp: feedforward/feedback control
limiter: try different limiters available in faust
I am making a DPF-based plugin version for soundsgood, with faustpp for the templating stuff, which nicely gets us a C++ class with some filled in values based on a template.
Check the dpf
branch for current progress, there are builds via github actions too.
Also see #23 for the GUI sketches, where discussion on the layout and other high level concepts should happen.
This ticket is only about the implementation, and mostly so others can easily follow current progress.
We can assume I will do all these things, anything that requires intervention I will open as separate tickets.
Current TODO for plugin/dsp side:
Current TODO for UI appearance:
Current TODO for UI widgets:
Current TODO for UI layout:
Current TODO for UI features:
Can be left for later or v1.1:
Unclear at the moment:
A ticket to discuss the double-click text input topic in particular.
Few things to do:
after those are done, we will need testing.
More like a question, not sure if this is intentional or not but currently seems all meters are mono.
Is this on purpose?
will renaming the repository to 'master_me' cause any problems?
just wondering if there is a need or preference for translations.
germans typically like to see things in german 🇩🇪
but maybe audio production terms go with english? tbh I am not sure how german producers handle this.
just asking, setting up a switch for english | german mode is quite doable with the current code.
Subject says it all.
First making the signal mono and then inverting polarity of one channel will void mono compatibility.
this is an issue as a form of question, because I dont know faust enough to understand how this is typically done.
we want to have level meters on the gui, but in order to make these meters actually useful the dsp level-meter side needs to keep going until notified by the ui that it has read the meter values.
the amateur approach is typically to calculate RMS and other values within a process cycle, every cycle, and set the passive / output meter value to that.
this is not a good approach, as the meter values would then be block-size dependent. also there could be several meter values calculated and reset before the GUI even shows a single one..
in short, level meters should run as commanded by the UI.
the flow is typically:
There are possible deviations to this, we can keep level metering active with a fixed time (in ms) if we want for example lv2 control outputs to have useful values even while UI is not open.
now my question is... how do we deal with this with faust?
can we specify a time-window for the metering? can it run "forever" (not bound to time) and wait for a signal to reset its internal values?
The brickwall limiter, when enabled, adds a a latency of 480 samples (@ 48kHz).
it's really limiter_lad_lookahead = 0.01;
* ma.SR
When bypassing the limiter (or the whole effect), either the latency has to be reset to 0, or ideally a crossfade happens with a signal that is delayed by latency.
The value is for display only. With a custom GUI it's preferable to have the GUI call it.
Currently FAUST compiles this into the inner loop and calls log10()
for each sample!
Since it's for display only, accuracy is not required you might want to investigate a fast_log implementation
https://www.flipcode.com/archives/Fast_log_Function.shtml
I think, lp1p(cf)
is identical to si.smooth(ba.tau2pole(foo))
with foo = 1/(2*ma.PI*cf)
.
I looked at the C++-Code generated from
process = _ <: lp1p(cf), si.smooth(ba.tau2pole(1/(2*ma.PI*cf)))
with {
cf = ma.E;
};
which yields
for (int i0 = 0; i0 < count; i0 = i0 + 1) {
float fTemp0 = fConst1 * float(input0[i0]);
fRec0[0] = fConst0 * fRec0[1] + fTemp0;
output0[i0] = FAUSTFLOAT(fRec0[0]);
fRec1[0] = fTemp0 + fConst0 * fRec1[1]; // summands swapped
output1[i0] = FAUSTFLOAT(fRec1[0]);
fRec0[1] = fRec0[0];
fRec1[1] = fRec1[0];
}
I would prefer using the standard library. At first, lp1p(cf)
made me think, "oh, super-elaborated ballistics going on".
target slider is still moving faster than the mouse
a double click option for entering the value would be nice
As the silence detection function s not a gate anymore, but an expander which puts a 'brake' on 'speed', it needs renaming.
leveler_gate meter -> leveler_brake meter
leveler_gate_threshold -> leveler_brake_threshold
symbols and labels
Reaper by default does not give plugin UIs keyboard focus, which makes it super easy to press backspace and have it delete the plugin 😡
It is the same issue as dealt in DISTRHO/Cardinal#304
We need the same hacks here too, likely best pushed as direct DPF functionality.
preset buttons need to go black again after loading, or changing a parameter
I think, the LUFS filter is only correct for a samplerate of 48kHz.
Should this be doing EBU-R128 prefiltering? Like the ITU filter in Loudness Measurement according to EBU-R128 (page 13)? If yes, I have some code in my sleeve.
I understand that the main goal is to make more or less subtle corrections to the audio based on presets.
At the same we want to expose te expert interface as well.
It would be nice if that one allows to do heavy corrections or creative sound design.
Finally, I think the plugin would become more intuitive to work with if all similar parameters and displays have the same range.
With a consistent mapping between the visual position of a fader (or meter) and it's meaning you can get used to them quicker and focus on the sound more.
Therefore, I propose the following ranges:
The leveler gate meter has % unit, but range of 0 to 1.
Plus minimum value only seems to ever each 0.143, which is weird
Currently looks wrong on the gui too, as it does not behave like all the other meters.
For this one we want the meter to go from left to right, correct? (ie, from 0 to 100%..?)
Getting this error on macOS 11, for the CI automated build:
ERROR : path '/soundsgood/expert/mscomp_meter/1' is already used
any hints?
issue does not happen on macOS 12 or on Linux, so perhaps a faust side issue?
Dear all,
I have been wrapping my head around this for quite some time now.
I kind of like 'soundsgood' as the name for a tool you throw at the master and hopefully then it 'soundsgood'.
I also like master_me as the project from which this one came...
So. If you have any other ideas for naming this beast, please share - thank you!
I think, the bypass of correlate_correct_bp
(line 251)might cause audible clicks, because it uses select2
for the audio signal.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.