Login

Developers publish nebula.xml file on your websites?

Officially Licensed 3rd Party Developer Libraries
Free 3rd Party Programs

Developers publish nebula.xml file on your websites?

Postby kylen » Sat Feb 08, 2014 11:55 pm

Is it reasonable or useful to ask Nebula 3rd party preset developers to publish the nebula.xml they used while listening/testing the final version of a preset?
It could be a bit of extra trouble for the devs to manage but it would allow me (possibly others) to do a sanity check on certain [relevant] settings after I buy a preset. I already have separate copies of nebula.dll and nebula.xml for each nebula developer so I can customize my <3rdpartydev>.dll and <3rdpartydev>.xml to what ever the dev recommends. Many 3rd party devs make recommendations in their manuals and many fine-tune the settings by posting in the forums. I feel like I might be missing something if I miss a forum post and simply viewing the .xml file after the product is considered ready would get me on the same page as to what the dev intended. Helpful or pain-in-the-butt idea?
kylen
Member
Member
 
Posts: 234
Joined: Sun May 08, 2011 7:43 am

Re: Developers publish nebula.xml file on your websites?

Postby enriquesilveti » Sun Feb 09, 2014 8:44 pm

kylen wrote:Is it reasonable or useful to ask Nebula 3rd party preset developers to publish the nebula.xml they used while listening/testing the final version of a preset?
It could be a bit of extra trouble for the devs to manage but it would allow me (possibly others) to do a sanity check on certain [relevant] settings after I buy a preset. I already have separate copies of nebula.dll and nebula.xml for each nebula developer so I can customize my <3rdpartydev>.dll and <3rdpartydev>.xml to what ever the dev recommends. Many 3rd party devs make recommendations in their manuals and many fine-tune the settings by posting in the forums. I feel like I might be missing something if I miss a forum post and simply viewing the .xml file after the product is considered ready would get me on the same page as to what the dev intended. Helpful or pain-in-the-butt idea?


Nebula MAST page settings is an Acustica Audio topic. You should read FAQ or ask support thru website form or support email.
Enrique Silveti.
Acustica Audio customer and technical support.

MBP 11.5 (i7-4870 | 16 GB | 512 SDD)
SP4 (i5-6300 | 8 GB | 256 SDD)
UFX | Lyra2 | USBPre2
VM U15 | VM Win10 | VM OSX 10.12
N4/NAT4 | SPX3 | RX5 | LN2C | Smaart8 | R5 | PT12 | PX10 | NIK5
User avatar
enriquesilveti
Expert
Expert
 
Posts: 2663
Joined: Sun Mar 28, 2010 9:00 pm
Location: Lodi | Madrid | Buenos Aires

Re: Developers publish nebula.xml file on your websites?

Postby jorismak » Sun Feb 09, 2014 11:16 pm

Another case where enrique means well but just doesn't answer (or understands) the question I guess :(.

In theory devs could post the complete XML file to use with their presets, but it's a pain for them to keep up2date. With every version of Nebula that comes out the defaults could change, or new settings could appear. So the 3rd party devs would need to keep a list of XML files up2date for multiple Nebula version.

And then (maybe more important), there are a lot of personal settings in there. Things like quality is for choice, DSP buffer depends on your audio hardware / DAW and latency requirements, GUI rate is a matter of personal taste. And stuff like which IPPS mode to use is machine dependent (imagine people using Cuda for example). And people with Nebula Server have IP settings in there I believe.
Things like SCANBOOT and BOOT are changed if people add lots of libraries or don't (startup optimization) and then you have of course the SKIN which is completely a user preference.

So in the end it's easier for devs to specify in their manuals / website to 'make sure certain settings are blablablabla' instead of giving complete XML files.
jorismak
Member
Member
 
Posts: 344
Joined: Fri Nov 16, 2012 4:49 am

Re: Developers publish nebula.xml file on your websites?

Postby enriquesilveti » Mon Feb 10, 2014 11:29 am

jorismak wrote:Another case where enrique means well but just doesn't answer (or understands) the question I guess :(.

In theory devs could post the complete XML file to use with their presets, but it's a pain for them to keep up2date. With every version of Nebula that comes out the defaults could change, or new settings could appear. So the 3rd party devs would need to keep a list of XML files up2date for multiple Nebula version.

And then (maybe more important), there are a lot of personal settings in there. Things like quality is for choice, DSP buffer depends on your audio hardware / DAW and latency requirements, GUI rate is a matter of personal taste. And stuff like which IPPS mode to use is machine dependent (imagine people using Cuda for example). And people with Nebula Server have IP settings in there I believe.
Things like SCANBOOT and BOOT are changed if people add lots of libraries or don't (startup optimization) and then you have of course the SKIN which is completely a user preference.

So in the end it's easier for devs to specify in their manuals / website to 'make sure certain settings are blablablabla' instead of giving complete XML files.


I understand your post. But after first setup you can backup file manually before upgrade/update. I'll show you ASAP. I handle normally here Nebula3FREE + Pro + Pro Server + all Acqua Effects updates in x86/x64 without problems. Now I lack of time but my method is simple but works from 2009 to now.
Enrique Silveti.
Acustica Audio customer and technical support.

MBP 11.5 (i7-4870 | 16 GB | 512 SDD)
SP4 (i5-6300 | 8 GB | 256 SDD)
UFX | Lyra2 | USBPre2
VM U15 | VM Win10 | VM OSX 10.12
N4/NAT4 | SPX3 | RX5 | LN2C | Smaart8 | R5 | PT12 | PX10 | NIK5
User avatar
enriquesilveti
Expert
Expert
 
Posts: 2663
Joined: Sun Mar 28, 2010 9:00 pm
Location: Lodi | Madrid | Buenos Aires

Re: Developers publish nebula.xml file on your websites?

Postby Cupwise » Mon Feb 10, 2014 11:36 am

i feel your pain here, kylen and jorismak. i feel it every time i release something where i have to put instructions on how to 'mod' the xml for something in my releases. especially for stuff like the maximum freqd/timed length possible, which i really don't even get why that is a parameter in the first place or why it's set low enough that by default it's going to trim the lengths of longer things like long reverbs.

maybe there is some reason, but i did some tests and it doesn't seem to affect CPU or anything else i could see, if i raised that setting well above it's default position and loaded programs that are using typical lengths like 50ms. it's a maximum allowed setting, so it isn't going to affect the length of samples in a program unless you set it LOWER than what those lengths are in the program. setting it higher doesn't change anything about that program, as far as i can tell.

so to me it doesn't make sense why those settings aren't 'maxed out' by default, to allow any length samples anyone could ever want to use. maybe there is a reason, or maybe there once was but nebula updates have since changed that, i don't know. but i do know it makes things confusing for users when i and other devs have to tell people to modify that xml just to do something that should be simple and painless such as load a reverb with 10 second tails.

in my opinion, this whole thing is just another reason why some on the outside may be hesitant about getting into nebula. there is a lot of confusion surrounding 'mods' and some people are paranoid about doing it, understandably. there's also the issue of one dev's mods possibly conflicting with another's. this whole thing is a mess basically. so i think it does need to be dealt with somehow, and i think the best possible thing would be if nebula were made so that the settings that devs might ever want or need control of (dspbuffer, timedl and freql, maxlookahead, etc), could actually be set PER PROGRAM. it might be tricky do it for some of those, like dspbuffer, but if this were pulled off, it would eliminate the need for any dev to ever ask anyone to change this or that setting. i think that would remove a great bit of the mist surrounding this thing.

jorismak wrote:
In theory devs could post the complete XML file to use with their presets, but it's a pain for them to keep up2date. With every version of Nebula that comes out the defaults could change, or new settings could appear. So the 3rd party devs would need to keep a list of XML files up2date for multiple Nebula version.
i'm not sure that i've seen any changes ever made to settings in that xml since i've had nebula, but i haven't looked super close. but i don't think it's like the xml is constantly getting changed. on the other hand, you still have a good point because something important in it COULD change in any update, so it is one reason why devs providing .xmls is a bad idea.
jorismak wrote:And then (maybe more important), there are a lot of personal settings in there. Things like quality is for choice, DSP buffer depends on your audio hardware / DAW and latency requirements, GUI rate is a matter of personal taste. And stuff like which IPPS mode to use is machine dependent (imagine people using Cuda for example). And people with Nebula Server have IP settings in there I believe.
Things like SCANBOOT and BOOT are changed if people add lots of libraries or don't (startup optimization) and then you have of course the SKIN which is completely a user preference.

another good reason. the datapath and alternatedatapath settings that tell where your libraries are, are other personal settings. about the quality one you mentioned, i think i've seen enrique/giancarlo say to leave that one alone, that increasing it doesn't really change any quality of anything, or something. so i'm not sure anyone should be changing that. but i could be wrong since i don't remember the specifics.
Cupwise
Expert
Expert
 
Posts: 773
Joined: Tue Nov 23, 2010 2:03 am

Re: Developers publish nebula.xml file on your websites?

Postby kels » Mon Feb 10, 2014 11:56 am

in my opinion, this whole thing is just another reason why some on the outside may be hesitant about getting into nebula. there is a lot of confusion surrounding 'mods' and some people are paranoid about doing it, understandably.


To me, there is one thing that add a lot of confusion, it is what Enrique said about the the <UP> tag that is used by one great dev. If I understand correctly, we loose AA support if we use it !

viewtopic.php?f=11&t=27627&p=62230&hilit=up+tag+support#p62230

Enrique, could you please clarify ?
thx
kels
User Level XI
User Level XI
 
Posts: 166
Joined: Fri Oct 11, 2013 8:43 am

Re: Developers publish nebula.xml file on your websites?

Postby kylen » Mon Feb 10, 2014 2:48 pm

Yes cupwise, that's it of course. I figured you would have some thoughts about this as I have read many of your posts on the topic of settings and wished...when you reach that "ah-ha" moment, "this is it", "finished"! I would love to have the nebula settings (that matter) so I can hear that also. Or if you ever find yourself giving settings to beta-testers those would be great to know also - what settings they used to proclaim "Eureka - you've done it again"! And it's true as jorismak says there are many settings in there that are personal (I called them 'non-relevant' for this discussion) or support an individual environment so posting an entire xml would create more confusion (too bad there aren't section tags to separate user configurable xml settings) and nebula versioning can come into play. So settings are best kept in the manual I suppose. Some devs do publish settings (Cupwise, Gemini, and AlexB have begun to on his new MFC) in their manuals. Exposing some 'confusing' internal nebula settings in an xml has thrown me off a bit for some time as an end user. I guess Nebula development are so used to having these exposed for their use that they don't see a need for a management screen for end users. Support says end users should stay out. But yes end users do need to get in there from time to time. I have had to change my datapath. Following a really useful lookahead post (cupwise again!) I went in to check my setting and it is set to 1376 or therabouts, not even 1500, I can't even get 2 seconds lookahead with that and some presets have 5 or 6 second lookahead sliders so I may change that one. I know that has the capability of affecting the sound, what others, that's all I'm asking. Per preset that a developer releases what were their settings that are offspec, that affect the sound and not their specific personal environment, and what nebula version did they use? :)
kylen
Member
Member
 
Posts: 234
Joined: Sun May 08, 2011 7:43 am

Re: Developers publish nebula.xml file on your websites?

Postby jorismak » Mon Feb 10, 2014 3:09 pm

Maybe a more short-term solution is let the programs have minimum / maximum values in them, and WARN when they're not met?

Like give a popup during loading, or flash a message in the LCD portion of the skin.

Giving a message that says "Warning, your LTIMED setting is xxxx, while this program advises a minimum of xxxxx".
That way people at least know they're loading something that might not work OK and don't have to go bug library-devs about it :).

The same thing goes for the resampling. Someone has to notice and then know that a flashing little arrow means the resampling is not done, and needs to raise a configuration value. I know this is listed on the FAQ somewhere, but a lot of people will not even notice that this is the case, and then complain about the sound.

I noticed it myself lately when I was working on my laptop and had a different interface for the time being, working on 44khz instead of 96khz. Reaper was working in 44khz mode, so when you open a Nebula program it loads / resamples into 44khz. While mixing, everything is fine.

But during rendering, my Reaper still had the project setting remembered to work in 96khz, so during offline render Reaper switches to 96khz mode... but Nebula doesn't see this since it's already loaded (makes sense) and stays to work in 44khz mode. Of course processing 96khz audio with 44khz libraries in this way (wrong resampling / no resampling) sounded like crap. And I couldn't figure out why my offline-renders where sounding so different to the previews.

A note in the Nebula instances that something is wrong in the samplerate would've helped... the same way a simple note that the RATECONV, DSPBUFFER, LTIMED or whatever is set too low can help.
jorismak
Member
Member
 
Posts: 344
Joined: Fri Nov 16, 2012 4:49 am

Re: Developers publish nebula.xml file on your websites?

Postby Tim Petherick » Mon Feb 10, 2014 5:55 pm

I think, the original poster is correct. Xml settings should be personal to a developer.

For instance some mods make my libraries sound worse if they are working in the background even if my presets are not taking advantage of the increased master page settings. So , using 'mods' should only really be used on specific libraries.

A example is experts saying that you if want to create a computer for music you should use it just for that! by not letting it do tasks in the background ,virus checking, internet tasks.Keep it clean!
You should avoid any unnecessary background process and I believe this would be the same for nebula! Now this something I've tried to advise before.....

So keeping a wide range in master settings might not be such a great idea.

The only way to decide for yourself is to take a regular library that would be used with regular settings and go between two different setups and see if you can hear a difference. I can hear small differences but then again our monitor setup is a set of ATC speakers.

By the way I'm not saying anything is wrong with doing mods but just warning that they will possible change the sound of other libraries even if the presets are not taking advantage of these mods..
User avatar
Tim Petherick
Expert
Expert
 
Posts: 1352
Joined: Sat Apr 17, 2010 4:07 pm
Location: Bath , Uk

Re: Developers publish nebula.xml file on your websites?

Postby Cupwise » Mon Feb 10, 2014 11:45 pm

could you give some specific examples? if this or that setting is causing problems it'd be good to bring that to light...

like i said, if acustica made it so that programs could over-ride the settings that are commonly being requested to be adjusted by devs, there wouldn't be any problem here. i think implementing a blinking light that tells you your program can't load properly because of the master settings not allowing something it needs, might be more complex of a thing to put in there, than just making it so that programs can over-ride those settings. if programs could do that, then there would only need to be one .dll and one .xml, with the exception of anyone wanting to keep libraries separate with the alternatdatapath settings.

but i have serious doubts that increasing LTIMED and/or LFREQD could negatively affect a program. i've done my own tests and found that renders with those settings set low, vs when they are set high, when nulled together give you the about the same amount of 'stuff' left over as any 2 nulls done even with the same exact settings used. i can't think of any specific thing about a program that would cause it to react to those settings differently and result in something bad. i could be wrong, but examples would be nice.
Cupwise
Expert
Expert
 
Posts: 773
Joined: Tue Nov 23, 2010 2:03 am

Next

Return to 3rd party libraries

Who is online

Users browsing this forum: No registered users and 8 guests