Login

Changing XML file for high quality sound and rendering?

Tips & tricks, working results, technical support

Re: Changing XML file for high quality sound and rendering?

Postby superhero81 » Fri Aug 30, 2013 10:11 pm

Soooo much info on this topic it's unreal. It's going to take me a looong time to comprehend this. I want to stick with a setting to start with. So should I used Timed Kernels? Split Mode?
Im not into tweaking nebula, I grasped the concept of changing the 10000 to 100000 and moving the arrows to Clean and Even Time Kernels. What's the deal with the Split Mode?
superhero81
User Level III
User Level III
 
Posts: 30
Joined: Tue Aug 27, 2013 11:53 pm

Re: Changing XML file for high quality sound and rendering?

Postby RJHollins » Fri Aug 30, 2013 11:17 pm

Then, start with the standard, default engine and you'll be
Absolutely fine!

This will allow u to run many more Nebula instances.

Later, you'll have time to experiment if wanted.

Meantime u have excellent tools to get the sound
And shape u want. First get the workflow down.

My suggestion
;)
i7-5820k, MSI X99A Plus, 16 GIG Ram, Noctua NH-D14, Win-7 Pro [64-bit], Reaper-64

NVC [Nebula Virtual Controllers]
RJHollins
Expert
Expert
 
Posts: 2633
Joined: Sun Mar 28, 2010 5:53 pm

Re: Changing XML file for high quality sound and rendering?

Postby brp » Fri Aug 30, 2013 11:53 pm

you should use the programs as you baught them!

then listen carefully and ask yourself if the results satisfy you?!
if yes, go makeing music instead of asking questions which only lead to other questions till you understand exactly that whats already written here (depending on your brainpower and your background, this can be the hardest thing you ever did in your live).

if you are not satisfied, first of all, you re probably an audio-junkie like most of us. but that also mean that you'll getting criminal just for a little bit of improofement on soundquality by harming your brain at getting the nebula-knowledge, harming your wallet by getting expensive quality computer hardware, do some more harm to your brain by geting the knowledge on how to massively overclock these expensive hardware and finally find out, that you STILL have to harm your workflow to get along with your personal frankenstein-nebula. BUT your feeling of the NEED of highest fidelity will be releaved! as you'd have to do all this to get youre next dose of heroin and finally get it ;-)
brp
User Level IX
User Level IX
 
Posts: 99
Joined: Tue Mar 30, 2010 1:02 pm

Re: Changing XML file for high quality sound and rendering?

Postby Cupwise » Sat Aug 31, 2013 2:46 pm

the problem with split mode is that if you use it you dont get to also use a kernel for smoothing. that's usually important for anything with dynamics. i'm like 99% positive that i've emailed G about split mode asking if it was only intended for equalizers (which are typically non-dynamic) and he said yes. since they (almost always) are not dynamic and are static, they don't need a smoothing kernel, so split mode then becomes a good compromise between freqd and timed modes. so as far as my understanding goes, split mode may not be good for anything with dynamics, which may need cubic or some degree of smooth2 (liquidity is smooth1) smoothing.

and again i just want to say that regardless of anything i've said, i'm not suggesting anyone should feel the need to go messing around with any of this stuff. the libraries out there already sound good and already won people over. all i ever really meant to get across was my feeling that yes, there is still room for improvement (in various ways, and probably some which nobody has even thought of yet). but the 'trueness' of that fact would also necessarily imply that existing programs are less than perfect. to me that's what i mean when i used the word hype. and i'm not even necessarily talking about any devs hyping their stuff. but the idea in general that programs perfectly emulate things, which exists to some degree. the stuff out there is still great, but it's not perfect. truthfully it never will be. there is almost always room for improvement as with anything. but you can get pretty close, and yeah a lot of the elements are already there and have been for years. but the transient thing is probably just one example of something where i think i've shown that it's simply not there even though it has been claimed to be, but my main point was to say that it's becoming practical with current cpus to use more of nebs potential that was already there and finally get that piece that was missing. but i think that's more on devs than users to accomplish.
Cupwise
Expert
Expert
 
Posts: 773
Joined: Tue Nov 23, 2010 2:03 am

Re: Changing XML file for high quality sound and rendering?

Postby Cupwise » Sat Aug 31, 2013 3:27 pm

another thing is that i don't even know if there's any way to improve any kind of quality by doing anything to the actual nebula setup xml. i think i saw somewhere in the thread about the 'exportquality' tag in there, and i may be mistaken but i think i've seen it mentioned by someone here in the forums (search could maybe bring it up), and g said to leave that alone and keep it at 1 or whatever it's set at by default.

only thing i, as a dev, have ever recommended any of my customers to modify in there is the lookahead and timed entries which impose limits that to me seem arbitrary and needlessly small to the point of being almost useless. maybe there is some reason they are like that but i don't know it. like i think look-ahead is limited to 1.5ms by default? to me that's pretty weird. it's barely enough to do anything. in fact i remember always wondering why look ahead seemed to do absolutely nothing all the times i used it before i became a dev and realized that 1.5ms is basically useless almost always, depending on the program. a few comps can get some use out of that, but it's so much more useful if you can have more. same thing with the default limit of timed mode being at 10ms. i dont get why there even needs to be a limit for these things. i've said this multiple times, but the reason is because i don't like having to ask customers to change anything at all in that xml. i really don't see why there would be some limit imposed in the master settings, instead of just allowing devs to say how much they want of look ahead/timed as their program requires. it's beyond me.

the only thing i could think of that might affect quality would be the buffer settings but i doubt theyd affect sound quality so much as cpu use or something. i really just don't think there's some secret hidden parameter in there that will improve nebula.
Cupwise
Expert
Expert
 
Posts: 773
Joined: Tue Nov 23, 2010 2:03 am

Re: Changing XML file for high quality sound and rendering?

Postby botus99 » Sat Aug 31, 2013 6:17 pm

Whoa, this topic is AWESOME! Thanks everyone for putting in some effort and information. I'm really going to have to go back and seriously re-read these comments to get a better understanding. That's all for now :D
Win10 Pro 64 / i7 6700K / 16gb RAM / Reaper | Allen&Heath ZED-R16 / Echo AudiofirePre8
Nebula Ultimate - Ochre, Red, Charly, Tan, Orange, Blue, Navy, Purple, Amethyst, Lime, Sand, Pink, 2412, 7236, Titanium, Aquamarine, Coral
User avatar
botus99
Expert
Expert
 
Posts: 529
Joined: Wed Mar 31, 2010 7:59 pm

Re: Changing XML file for high quality sound and rendering?

Postby brp » Sun Sep 01, 2013 12:51 pm

hi cupwise

you have a point. i see things allmost similar to you, actually. there is not really a button to improof nebula, i agree. regarding the xml file of nebula, there are just parameters which can be changed to better fit your specific needs. there is no buffersize for example which will be perfect for everyone. or if you'd like to load some special programs which provides more than 30ms of timed kernels, you'd have to change this value in the xml because on the mast page you cant enter values biger than 30ms. if you'd leave this allone, these timed kernels would be truncated at 30ms! the list goes on..

btw. i didnt know about this thing with the splitmode and the smooth kernel. i find the smooth kernel compromising soundquality or maybe its stone (rate s). as i once discovered or kind of realized, was that there is rate s to adjust the prograte: this must be something similar to timestretching, because its something that you have to switch on for being able to alter prograte in the first place. this implies that there is something like a natural or say original prograte which would be set if you switch off rate s. and here comes the big trick, the smooth kernel is only needed for rate s. if you switch off rate s, the smooth kernel (i guess) is deactivated automaticaly and kernels somehow will just fit perfectly after each other!! and the best news for you obviously is that you can use splitmode without the need of the smoothkernel ;-)

the only drawback would be a prograte which is probably a thiny bit too slow. but devs meybe are able to influence this by sampling shorter kernelsizes. the natural prograte allways will be fastest in timed mode, slower in freqd mode and slowest in split mode. try it yourself and check out if your program run fast enough in "natural split mode"...

here we see exactly what i mean by possible usertweaks. the tweaks which will alter the quality of nebula are not in the xml but in the program settings. the real point is however, each customer has a different system and different preferences regarding theyr workflow. whats good for you is worse for another one and vice versa." so its allways a trade off between quality and cpu as we found out earlier. as time passes, computer gets faster and these trade offs shifts towars perfect programs. this means that modern programs maybe good as they are adjusted by the dev while old programs have a huge potential for improofing!
brp
User Level IX
User Level IX
 
Posts: 99
Joined: Tue Mar 30, 2010 1:02 pm

Re: Changing XML file for high quality sound and rendering?

Postby Cupwise » Mon Sep 02, 2013 9:24 am

brp wrote: i find the smooth kernel compromising soundquality or maybe its stone (rate s). as i once discovered or kind of realized, was that there is rate s to adjust the prograte: this must be something similar to timestretching, because its something that you have to switch on for being able to alter prograte in the first place. this implies that there is something like a natural or say original prograte which would be set if you switch off rate s. and here comes the big trick, the smooth kernel is only needed for rate s. if you switch off rate s, the smooth kernel (i guess) is deactivated automaticaly and kernels somehow will just fit perfectly after each other!! and the best news for you obviously is that you can use splitmode without the need of the smoothkernel ;-)


rate s is just a switch that allows you to over-ride the program rate and set it yourself. programs will load with a program rate dictated by the length of their kerns/samples and whether it's using timed/freqd/split. it automatically picks the fastest prog rate that you can have with that combination of factors. if you want to set it yourself you have to first turn 'rate s' to ON, and all that does is over-ride the default prog rate setting and allow you to change it. all you can do is increase it though, from the default setting that you get with 'rate s' set to OFF, unless you trim the length of the kerns down to be able to get a faster setting, or switch to timed, for example. but i wouldn't call the default rate a 'natural rate', it's just the maximum rate possible with the combination of length, mode, and buffer, that nebula can provide.

switching 'rate s' on or off doesn't affect whether or not you can use smooth2. the only thing that does that is if you use split, in which case you can't use smooth2, because they both use that same extra kernel. this is why sometimes 10k programs actually say 11k, because they have 10kernels and then an extra one for smooth2. split adds an extra one also, one for each freqd and timed. what i said about smooth2 still stands. if a program has dynamics and you turn smooth2 off (which switching to split does), you can get artifacts. it depends on the program a bit, and also on the prog rate. slower prog rates can get away without using smoothing, which is why reverbs don't use it. but for a preamp or something like that you can get artifacts if you switch smooth2 off. maybe not every time, but you'd have to actually do tests and stuff to see. and i don't think a simple glance at vstanalyser always gives you the full picture either, because it's just showing you what's happening with a fixed level tone going in.

split is really more of a compromise between timed and freqd mode anyway, so i don't think it makes sense to sacrifice the smooth2 kernel to use split for dynamic programs. all split does is let the first few ms of the samples use timed and the rest use freqd, so its a compromise and you lose smooth2. why not just use all kerns on freqd with smooth2 kept at cubic or whatever it loads at (unless you've done some test to see if turning it off or lowering it doesn't introduce artifacts, and you'd have to do a fair amount of tests and it would be different for each program), and then before you render just switch h1 to timed?

and this is all besides the point that ngarjuna brought up which is- how much does timed mode actually sound better than freqd in the first place? to me the biggest advantage of timed is that it can allow you to get faster program rates, but to get that ability all kerns need to use timed, and this increases the risk of artifacts which means even more testing is needed and probably only devs are going to have time to do that so nobody else should really worry about it. but besides that, the idea that timed mode itself sounds better than freqd, that may or may not be the case. i don't know because personally i haven't directly compared them a whole lot. like i said you would have to make sure the prog rates were the same before you compared. but i think the comparison should be done a few times before you decide if you even need timed at all, or split (which just lets SOME of the kern use timed, and again sacrifices smooth2 to do that).
Cupwise
Expert
Expert
 
Posts: 773
Joined: Tue Nov 23, 2010 2:03 am

Re: Changing XML file for high quality sound and rendering?

Postby brp » Mon Sep 02, 2013 6:40 pm

ok i see, i'll have to do some more experiments. i just tried this with compressors. prograte usually is 0.104ms with timed kernels of 13.5ms. in splitmode i got something with 5ms for prograte. i never heard any artefacts!! maybe this is true for slower progrates. but are you sure it's not your cpu makeing the artefacts?

i get artefacts for progrates faster than 3ms with rate s and smooth kernel enabled. the smooth kernel kind of modulates the signal and with these speeds it starts to generate an audible waveform! i tryed out everything at 96k and the gemini xml tweak for comps.

timed kernels sounds mich better than freqd. this is an audible fact and its logic as well. but surely, you need good monitors to be able to hear this! i monitor with beyerdynamics 880 pro headphones and a very good headphone amp which is needed with this 250ohm headphone. trust me, its like cristal clear wather vs. dirty mudd!!
brp
User Level IX
User Level IX
 
Posts: 99
Joined: Tue Mar 30, 2010 1:02 pm

Re: Changing XML file for high quality sound and rendering?

Postby Cupwise » Tue Sep 03, 2013 8:21 am

brp wrote:ok i see, i'll have to do some more experiments. i just tried this with compressors. prograte usually is 0.104ms with timed kernels of 13.5ms. in splitmode i got something with 5ms for prograte. i never heard any artefacts!! maybe this is true for slower progrates. but are you sure it's not your cpu makeing the artefacts?
i'm not trying to speak for giancarlo because i'm not him, but again i'm almost positive that i asked him about split mode before and the answer i got was that it was for equalizers (which are undynamic). the reason i asked is because the NAT sampling templates for equalizers have them set to use split. i don't think anything else uses split in those templates. and if you look at your collection of eqs, they are most likely all using split just like the templates that were used to make them.

on the other hand anything dynamic does not use split in the templates, nor do most of the programs as you get them. there's a reason for this. it's because giancarlo thought split was best for eqs which don't need smoothing because they are undynamic. so they can use split which gives you a taste of timed mode by using it for the first couple ms of the samples. obviously he thought dynamic programs will usually need smooth2 or the template for them wouldn't be set to use it. it's a pretty clear distinction. the templates are set up that way, and most of the programs as you get them are set up that way.

obviously it would probably be best if you could get away without ever using smooth2, and some dynamic programs may not generate artifacts without it. but lots will. that's why they are set to use it. it wouldn't exist if there wasn't a reason for it. even if you don't hear the artifacts they are very possibly there at lower levels just being masked by the audio and turning off smooth may increase them by many dbs.
brp wrote:i get artefacts for progrates faster than 3ms with rate s and smooth kernel enabled. the smooth kernel kind of modulates the signal and with these speeds it starts to generate an audible waveform! i tryed out everything at 96k and the gemini xml tweak for comps.
it's true that sometimes different smooth2 types actually increase artifacts instead of reducing them, but it depends on a combination of things, like prog rate. really fast prog rates are prone to generate artifacts.
Cupwise
Expert
Expert
 
Posts: 773
Joined: Tue Nov 23, 2010 2:03 am

PreviousNext

Return to Working with Nebula

Who is online

Users browsing this forum: No registered users and 4 guests