giancarlo wrote:compiled core4 for mac osx too. Apparently everything is running flawlessly. We'll start betatesting soon, I'll try to compile all versions tomorrow and to prepare new installers around the end of this week.
as first step we'll release a vst64 to nebula server users. This vst64 should be good enough for a wrapped usage, ie using jbridge. If it will work correctly we'll release vst64 to nebula3 pro users.
We are still working on au side. Steinberg wasted 2 years on that, we are wasting a similar amount of time (we started late, in the middle of 2011, because we are a small company). As stated correctly by arne (steinberg),
We are now at the same point we were 2 years ago before Apple dropped 64 bit HIToolbox. So nothing really won from a users point of view. Internally it was a good thing to re-factor our UI code and gave us the opportunity to fix some bugs and streamline our native implementations.
in our specific case we introduced tons of bugs too.
some years ago i asked you why you are not going with juce..
and i still can not see anything positive with the way you go. it just looks like you're sado masochistic going such a painful way. i myself are a bloody beginner with programming and still was able to make some useful tools for my studio!! i know, you'd had a lot to rewrite with juce. but if i see things right, you have the nebula engine as c++ code with lots of assembler lines, which should compile with juce as it is. you mainly had to rewrite the gui which is really not more difficult and timeconsuming as you would build a gui from lego
i'd bet such a smart guy like you would have no longer than four weeks to port nebula to juce. sure, the gui probably would look different. but who cares!! i'd really like to see you working on the engine rather porting nebula to each pluginformat separately!!! and i think you'd like too, not?
have you ever tryed juce? you can just try everything for free as long as you want! you're even allowed to make freeware for free with it. if you want use it commercially you'd have to buy a license for about 700$.
go to the juce homepage to learn more about it. it's really worth at least learning to work with it. there is so much beautiful code in there, that nearly every programmer would find some inspiration to improof his own code!!
but dont get me wrong, i'm with you whatever your way will be. i follow you g-sus
we cant adopt juce unless we rewrite completely the skinnng engine both for nebula and acqua products and believe me, its an huge work.If you want to wait other 4 years... nebula needs a lot of things, ie loading png from memory and other nasty things
i know that these things are nasty as hell. and that's my point, with juce you'll get some awsom classes which allready suport skinning and loading png's from memory!! you'll kind of just put some of these classes together and define them if they should compile with a png integrated with them or with a specified path where the png lies. it even offers you a program called the jucer where you can define youre gui classes through graphical interface!!
farther you could offer a juce class instead or additional to aqua. devs then were able to develop bether guis, customised meters or even a plugin which is able to load more than just one nebula program. that really could bring some awsome eq plugins to us!! or in therms of compressors devs also could make plugins which loads two instances of nebula, a fast one with 1.kernel and another slow one with the harmonics possibilities are endless as you see. so please thake yourself half a day to install juce and make some beginners tutorial. you'll get the idea very soon how to build up a gui with juce, so that you'll see after a few hours allready if it would be a good idea to go with juce or not.. and btw jules (the guy who makes juce) is kind of an inspiring genius like you are. so even in that sense of sprit juce would fit acustica-audio very well
changing the gui engine requires the rewriting of a lot of code, which is not strategic at all for us. Better if we spend our time on something else, like the engine, supporting 3rd party developers, creting new technologies. Acqua is a skinning language based on xml parsing, so a lot easier than juce for our developers (c++ skills are an high requirement for a library developer, who should be focused on music production, hardware tuning, sampling). Moving the engine to a different library takes a lot of time, so we'll not move to juce. I guess never (unless we hire someone who could spend his time on that, at the moment we can't afford it)
ok i see, we totally agree that you want spend as less time as possible on everything but the engine.
but there is my point, with juce you would save time, especially in the long therm. you'd allways have to just write one code for vst, au, tdm, x86, x64 for both mac and win. i don't know how it stands with aax, but if it's there, you'd get it with no extra work!! and believe me, if nebula had a more streamlined gui and worked with protools, you'd sell so much licenses that you'd become a rich man over night imageing nebula would be presented at pensado's place, the whole pro marked would buy nebula on the next day!! but therefor it must be aax or at least tdm. all these advantages makes juce the first choice framework for a lot of plugin manufacturers.
juce also has a lot of xml stuff, so there's maybe a elegant way to integrate your acqua skinning language...
but i stop now with my marketing show. if you tryed allready juce and came to the conclusion that it's not worth, then fine, you're probably right.
i just have serious problems with believing that you allready gave juce a real chance when i read your counter arguments. so did you? and the jucer? dont you find it easy to create gui's with it?
btw. nat can also be written with juce and compiled for win, mac, x86, x64 and iphone/ipad. so you could run it on your ipad while you're at a rented studio
I'll go straight. Juce would delay us till next century, too much code was written, and adapting things to a new framework changing mutex, queues, methods and network code would be an incredible waste of time. Is it ok now? we could adopt juce only if someone else would do it for us... maybe someone paid... I think juce is a good framework but it was delivered too late for us.... we are able to pay someone, but he should be good and fast, because we have around 80000 lines of souce code without comments and spaces, something in the 200000 ball park of human spaced code. Nebula is an huge project
Btw I know juce. I analyzed the source code for sidechain, au and tdm...