OK, so I want to implement a separate dll for each type of program (one for pres, one for eqs, one for reverbs, etc), trying to optimise the MAST configuration for each type. My goal when possible/reasonable is to maximise audio quality and minimise latency, at the expense of cpu usage and loading times.
The process of creating the separate dlls is well described elsewhere and I have no problems with it. What I want to understand better is the MAST parameters relevant to this kind of "user optimisation". Of course I won't touch anything if I don't know what I'm doing, but I want to know what I'm doing so I can touch stuff
I've gathered info from different posts, manuals, documentation, etc scattered all around, and I've compared the MAST page for the "Nebula" and "NebulaReverb" versions. What I've come up with is 3 MAST parameters that are sensibly different for Nebula and NebulaReverb: GHOSTMODE, LFREQD and DSPBUFFER. I think I understand what they do, but I'm looking for their "optimal" values for each type of program:
- GHOSTMODE Apparently this minimises dropouts for long kernels, and it's 0 for Nebula and 1 for NebulaReverb. Should this be 0 for everything except reverbs, which have kernel lengths of seconds? Or would, say, a 186ms kernel length for an EQ be considered a long kernel and thus benefit from GHOSTMODE=1?
- LFREQD This seems to be the maximum kernel length, and it's 0.020s for Nebula and 2.000s for NebulaReverb. I've noticed that each program has a FREQD value per kernel in the KERN page, which seems to be the actual length of the kernel... so for a specific type of program, wouldn't it be optimal to look for the highest FREQD value for any kernel of any program in the type, and set LFREQD slightly higher than that? For example, if within all my EQ programs the highest FREQD value for a single kernel of a single program is 186ms, I'd configure LFREQD in the MAST page of the eq-dedicated dll to 200ms. Is that correct?
- DSPBUFFER This one is the size of the internal buffer and seems to correlate directly with the latency and inversely with the CPU load, being 128 for Nebula and 8192 for NebulaReverb. My question is: does this affect audio quality? I mean, could I set it to, say, 4096 or lower for reverbs if I'm ok with the increased cpu load? Is 128 a good value for anything but reverbs if I'm OK with the cpu load?
Then there's also RATE CNV:
- RATE CNV This is the conversion rate for programs with a different sampling rate than the project, and seems to impact on audio quality and loading time. AlexB recomends setting it to 3200 or higher for his pre/console programs. If I don't mind the increased loading time, is 3200 a safe setting for any program to get maximum quality? Could reverbs or any other stuff require even higher values?
And finally there's the WORKBUFFER parameter in the xml:
- WORKBUFFER This one is wildly different for Nebula (32768) and NebulaReverb (131072). I don't think it's available in the MAST page and I simply don't know what it does. So my question is: what does it do? I don't want to modify this one, but I want to select the correct value for each type of program... is the lowest value (32768) good for anything but reverbs?
I think that's it... any and every bit of info on this issue will be very much appreciated.
Yeah i know that page, I learned what each parameter does there... so i already know more or less what does what, and I was looking for more specific info on behaviors and values for the parameters I mentioned, specially from betatesters and/or library developers... but thanks anyway!
workbuffer should be a power of 2, and it limits the maximum kernel size is some way. Kernels are splitted in DSPBUFFER pieces. A DSPBUFFER should be contained several times, in order to prevent buffer underruns. It affects memory usage. Don't change it, nebula is not tested for "strange" values.
scottkane wrote:What about the 3200? should it be a standart latency? like 64 128 256 384 512 768 1024 1280 1536 1792 2048 3072 4096 Standart divisions or doesnt matters ?
The 3200 is RATE CNV, which is indicated in miliseconds, not samples... nothing to do with latency. The standard Nebula3 and Nebula3 Reverb versions both use 25ms, so nothing to do with powers of 2 either.
I came up with the 3200 from some AlexB manuals where he recommends a value of 3200ms or higher to avoid conversion issues when the sampling rate of the library doesn't match the project's. I've applied that value to all types of libraries just to be on the safe side, as this parameter seems to affect loading times only, and I'm not much concerned about that...
Interesting to see how you have setup. I split up my dll's according to the sample rate used. Since most 3rd party presets I got are at 96 kHz and my project sample rate is the same, I have set RATE CNV at 0 for my normal Nebula(reverb)and have made an extra dll for presets that need sample rate conversion. I've also made a dll for long tail reverbs/delays, so I've created two extra dll's in total:
Nebula (reverb) Nebula (reverb LONG TAIL) Nebula (reverb RATE)
So I am using the 'standard' reverb LFREQD for everything but the long tail. Why are you using different LFREQD settings if I may ask?
Mplay wrote:So I am using the 'standard' reverb LFREQD for everything but the long tail. Why are you using different LFREQD settings if I may ask?
Well, as I understand LFREQD is just the upper limit, programs will use the FREQD specified by the developer unless it's higher than LFREQD... so rather conservatively I specified the highest LFREQD for all reverbs to make sure that they all play the whole tail.
And for the other types of effects I just verified the FREQD for some of the programs in each type and chose a safe LFREQD of around 2x the highest FREQD I encountered, rounding to either 100ms or 300ms for simplicity.
I chose RATECNV=3200 for everything for simplicity as well, because I don't want to guess if a particular program matches my project sample rate every time, and I don't care about increased loading times (up to a point anyway).
The bad news are that all of this is documented rather poorly and info is scattered in a million places... the good news is the wide flexibility that Nebula offers to tailor every setup to the specific needs of the user (provided that you know more or less what you are doing)