Hi @brummer, that’s pretty awesome Thanks!
Keep in mind, that for DAW use, most soundcard vendor recommend a signal around -18dBFS (some even lower) for the input stage of the AD converter. -12dBFS corresponds to =+6dBu in an IEC calibrated system and is quite hot and not conservative at all.
I had a quick go at it. I suppose it could be even smaller – but then the 1/2" jacks won’t fit inside
I’ve tried a bit harder. the minute amp
Alas, it’s not great. The problem is that the jacks constrain the height - particularly for there stereo version; and the info/edit/delete buttons above a plugin define the minimum width. So one might as well use that space for a output-level display and a “bypass LED / control” and keep proper labels, too.
The source-code can be found at https://github.com/x42/tinyamp.lv2 and a pre-compiled binary can be pushed to the MOD on unix-like systems like:
curl http://robin.linuxaudio.org/tmp/tinygain.lv2.mod.tgz \ | base64 \ | curl -F 'package=@-' http://192.168.51.1/sdk/install
As usual feedback is welcome.
Very nice! I wonder if one could even integrate it into a cable (or have a very quick way to add it to a cable besides dragging it and connecting the jacks - more like a click-on-cable-select-add-gain action)… But the minute amp is pretty awesome, too: So Gain, Much Small, WOW
I can make the ‘(i)’ icon hidden if a certain property is present on the ttl, sounds useful for cases like this.
The height of the jacks will not change though, for consistency.
Now that’s a pretty cool idea. When a new plugin instance is dropped on a cable: insert it. Probably only works for 1in/1out (mono) FX, everything else will be hard to get right. Likewise remove (maybe shift+trash click) could keep the chain for N-in/N-out plugins.
heh. After some sleep and falkTX’s suggestion (no info-icon property), I’ve opted for the minuscule amp. The scaled box’ corners and shadow look a bit odd due to scaling, but that’s a nit to be picked later.
I really like this plugin. I placed it in certain places in the signal chain to troubleshoot where I was having clipping.
I’ve been experimenting with the scaling limiter (unstable plugin) and finding that it has a horrible clipping noise when hit too hard… which is kind of bad since the point of the plugin in to tame those transients to avoid clipping…
As per suggestion from @Bollie I’ve re-purposed the Enable LED/Control to be a “Mute” (bypass/enable is still click-free, but only available in the “Edit Window”).
New version is available from the same URL (http://robin.linuxaudio.org/tmp/tinygain.lv2.mod.tgz and src on github). I guess it won’t be long until this shows up in the MOD store, but it’s unlikely that it happens before the LAC.
PS. The background color of the DPM display now changes depending on the signal-level:
<-18dBFS: pale green <-3dBFS: green <-1dBFS: ocher < 0dBFS: orange >= 0dBFS: red.
That looks incredible @x42!
Is it possible to have a “transparent” knob that glows when activated?
That could save the led space.
@falkTX… Another idea to save space is to have an option to have “hard” plugs instead of cables.
Something like a right click popup option as “use solid plugs” or so.
Very nice topic.
MOD Rocks guys!!!
It’s also a bit worrying how fast we went from “inconsistent level response” to “practical solutions”.
I think it would be nice to have some official recommendations for MOD plugins – in particular new/future plugins!
I’ll second @fps original suggestions. (1) sounds good to me. (2)+(4) may be problematic with existing pedalboards, but I think it’s a good idea regardless (and better do it sooner than later). (3) is tricky. maybe not fix existing Plugins, but recommend it for all new plugins. Some plugin-authors may provide options for existing plugins like @brummer already did.
A wiki-page “best practices for DSP on the MOD” comes to mind. any takers?
Sure and you can have a pony, too
I like the idea of FX snapping together forming a hard-link. That might even be relatively simple : check if 2 FX are close to each other when one is dragged and if the port-count matches auto-position (snap) + change background image of the connector.
@x42 I guess the “fix” could be to just
Determine the current working range of a plugin
Wrap it in pre/post-gain (2 Multiplications, vectorizable (is that a word?)) to adjust it to appear at -18dBFS on the outside. Oh, since these are constants that are determined once, the compiler could even do constant folding in some cases.
While that is a bit of work per plugin (depending on the measurement setup I’d guess around a couple of minutes), afterwards it only needs to be done for new plugins.
I think -18dBFS is far to low. Therewith we reach a point were the noise-floor becomes a to high influence. That, is even more true for non-linear dsp’s, which may multiply the noise floor with produced harmonics. That is also the reason why most distortion/fuzz plugs in the digital domain filter out the high/low end of the spectrum. Mostly they filter against 200Hz - 5000Hz.
That wont be suitable for bass, for example, and, also wont make it for lead distortion.
In the digital domain, dBFS, means nothing. This becomes meaningful just when we enter/leave the barrier from/to digital/analog. So there is no reason not to use the full float range.
However, implement a selectable expected input level in the dsp/plugin structure is easy and already done for the GxPlugs, just, the implementation in the GUI is were I’m hang. I need a nice little 3-way-switch image to implement.
@brummer, sure you can select any reference point in the digital domain. I guess one motivation to use -18dBFS is that it allows quite a bit of “room for error” on the user’s side that prevents premature clipping on the DAC.
Also isn’t -18dBFS just 1/8 of 0dBFS? So in effect it’s just 3 bits in the exponent. This precision loss doesn’t really take us closer to the noise floor of the digital representation.
If you are talking about the noise of the ADC, then you could argue whether aiming for -12dBFS on the ADC (yellow LED blinks very occasionally) before digitally taking it to -18dBFS is too close to the (analog) noise floor. I found though that with -12dBFS as the general target I very occasionally do get peaks at around -4 to -3dBFS when really digging into the strings. So aiming for -12dBFS is almost too risky for my case, but since the ADC on the mod is quite noisy, I reckon it’s a good compromise.
Things will get a lot better there. It’s not the analog hardware nor the ADC that’s noisy.
It’s relationship between analog/digital most of which can be addressed by software/driver settings (the CODEC has configuration options which can be set in the driver). There’s work behind the scenes going on to improve this.
Then again 40dB signal/noise is already more than sufficient for pretty much all guitar playing and more.
that’s great to hear, @x42!
my usage is often in situations requiring very good S/N performance; in particular, i’ve had issues with the whine caused by the kernel buffering. i’ve sometimes found that the lower-pitched whine you get running at 256 frames is less objectionable. still, it’ll be great to get this solved!
I nearly fell off my chair laughing… (As someone who actually plays guitar), I’m going to have to call BS on that. 40dB S/N (if that were the case) would be absolutely awful. Please tell me it - has to be - much better than that…
I’m not involved with the MOD anymore and I don’t know nor do I care what the MOD’s current hardware does.
There used to be a power-supply issue related to frequency scaling.
The electric guitar here is about 70-80dB S/N at the source on a good day with not much EM-interference.
Still pretty much all music I’ve heard people to make with the MOD turned out to not be deeper than perhaps 5dB dynamic range and nobody cared for more.
I’d love to, but I can’t. I’ve just dusted off the MOD and measured it. After terminating the analog input, tne selecing “gain-stage: mid” (under “Volumes and Gains”), the noise-level is in the -50dBFS range. The main issue is still a DC offset or low-freq noise.
You can also record some audio (ssh into the mod, use
jack_capture --channels 2 --port system:capture*) and analyze that off-line.
In theory the analog circuit should be a lot less noisy.