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.
1 Like
I had a quick go at it. I suppose it could be even smaller – but then the 1/2" jacks won’t fit inside 
4 Likes
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.
5 Likes
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 
1 Like
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.
7 Likes
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.
2 Likes
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!!!
1 Like
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?
3 Likes
Sure and you can have a pony, too 
Well, it’s all HTML/CSS/Javascript + graphics design so it’s possible, but it’s not practical and a large amount of work which is probably better spent otherwise.
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.
4 Likes
@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.
Anyone?
regards
hermann
@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.
5 Likes
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…
1 Like
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.
1 Like
I’d have to look more closely at the measurements (I only have a very early MOD) but I think it must be better than 40dB S/N. If there is a DC offset, that’s a different matter - in and of itself that could mainly affect dynamic range etc instead - but without knowing the cause this is only speculation and I guess not very helpful. This whole discussion about gain levels seems very messy - having gain trims and twiddles everywhere is an engineers solution (and not a very good one) - its not a musicians solution (speaking as a musician rather than a developer this time - I just want to play - and it would be nice to leave some CPU for other effects too… ). I don’t know what the right answer is for everyone (or even if there is one) - the MOD is trying to be extremely flexible - and there are those who would want to use it in between guitar and amp - just like regular stomp boxes, or those who use it in an effects loop etc. The best solution (or least worst) is to design effects intelligently, with the idea that they have to accommodate a wide range of levels, and not get too hung up about it - (guitar players especially) have been abusing gain structure incompatibilities to great effect forever. For example, with the DT-1 distortion, I designed it primarily to work with ‘guitar’ levels, but, the gain goes from 0dB to 40dB and the output level can be set anywhere from -Inf to 0dB so it should be possible to find a setting that works (others may disagree - I won’t be changing it)
5 Likes