giancarlo wrote:first version to be released: you will be able to load acqua plugins. No further things are allowed.
What to expect from first release:
- harmonized commercial libraries - new skinning engine also for developers (and several libraries skinned, or they will be skinned soon) - acqua plugins and nebula libraries are the same thing (I'm not sure acqua presets will retain values if you change them using the preset browser) - you will be able to edit basic features in acqua plugins, because you can open acqua plugins using the standard nebula3 interface. For example you could modify the speedness of compressors editing the GLOB page of a particular instance
since nebula4 is very basic we are working now to - a new preset browser, with search capabilities - vst3 support (not sure it will be ready for the launch) - stupid thing: midi channel support
This is exactly what to expect immediatly, we'll be more accurate as soon as we have new details. Obviously things will improve further during next months I want to be straight on several points:
- we'll not suggest you to move to nebula4 immediatly - almost all new features starting from the release date will be implemented in nebula4 - during next months advantages will be more and more visible. We can do things which are not possible today
I know that you want "this", "that" or "these" things. But nebula4 basically solves a conceptual issue, which is the difference between libraries, skinned libraries, acqua plugins. Starting from that point 3rd party developers could start releasing acqua plugins, we'll know more about it on next months. We'll sort even a training session both for sampling and library developement.
From the practical point of view: libraries with basic skins will be as much cheap as today. Nebula4 will load nebula3 libraries. Obvously a library like "amethyst" will be a bit more expensive, because it requires hard work. Everybody (also 3rd party developers) will learn that.
Last but not least: we are not here for solving a "nyrv agent" problem. There are things which nyrv agent cannot solve and things which nebula4 cannot solve alone in its first release. You can use nyrv, or bidule, or bluecat or whatever for nebula4 in the case. Anyway sooner or later we'll support routing and other things, like multi-channel and surround. Reason is simple: they are already implemented in nebula4, but not exposed outside, so it is a matter of time.
I hope this post answers ALL your questions
Hi Giancarlo, I see you say that the first release will only load Acqua plugins. You also say that Acqua plugins and Nebula libraries are the same thing. Does this mean that the first release will load older Nebula third party libraries? Thanks
I see you say that the first release will only load Acqua plugins. You also say that Acqua plugins and Nebula libraries are the same thing. Does this mean that the first release will load older Nebula third party libraries?
Yes, N4 will load existing Nebula 3rd party libraries.
tumburu wrote:It could simply move to the nearest available value to the one written.
yes and not, but we could try a workaround in the future but I cannot promise a solution, and I don't see a solution now.
What you see is calculated using the vectorial engine, and it is a consequence of a complex function (or an high number of complex functions). Your slider is an input for this complex function. Now: this function is not simply "invertible" for all possible cases. It could be even a program. This is an automation problem, and you need to build a feedback for minimizing the difference. The system could also be not stable.
Let's make an example. You have a function which doubles the value expressed by a slider. Now you move the slider to position 4 and you get "8" in the display. If you want to write simply "8" and you expect we move the slider accordingly, nebula should DIVIDE that value by 2. This case is simple, but sometimes there is NO solution to the problem. Now: value expressed are COMPLEX functions. It is not easy to go back to the slider position, unless the function is strictly monotonic, in such case we can solve it using newton. And no, a "close" value is not a solution. "Close" sometimes is not close enough. Infact your host is storing the slider position as "parameter", and it is everything which counts. If the slider value is not perfectly synchronized you will load a different display value when your host reloads, or automation is used. Which translates to what you describe as "bugs bugs bugs"! So what we are doing is simply avoiding a nightmare of bugs, bad plug-in reloads, changing presets, instable sessions.
Hope you understand now why the feature was requested so many times and we answered "no".
the planned release date is around april. Anyway I can't exclude a small delay on it. The engine itself will be completed this month, but we need to sort libraries and skins, and at the moment we are busy bugfixing also acqua plug-ins.