Hi,
any news or plans about 64-bit MAC versions of VI or VE? This topic has been around for many month/years now...
Cheers
-
64-Bit Vienna Instruments Release for Mac
-
Hi Vienna Team,
I would assume that your team must be getting real close (days) to releasing the Vienna Instrument and Vienna Ensemble 64-bit version for Mac. I was going thought my previous post and emails which are dated over a year ago where you advised that your team is working on it. Many VSL products have been released since that post and it puzzles me as to why over a year now, (which is eternity in software development), we the users are still waiting especially since when I purchased the original VI Solo Strings (July 10, 2006), the web site stated that 64-bit would be released soon. I know the word "soon" is subjective, but under a year is generally an acceptable assumption. I followed by purchasing every library instrument you have to offer (August 13, 2007 & everything else as it was released) and assuming that 64-bit would be available within weeks. And as always, you thanked me for my patience.
I think you probably understand by the tone of this post, that my patience is slowly but increasingly deteriorating. I've always felt that VSL was a great company and seemed to respond to the user's needs quickly. I've been a loyal VSL customer since the Horizon sample days. I am puzzled as to why we are still waiting? I'm aware of your company being blind-sided by the new Apple framework when the Mac Intel's were released but even that was over a year ago. I would have expected the 64-bit applications released by now.
Please advise with some good news!
-
Isn't Snow Leopard an integral part of this? Apple isn't going to release that until September of this year.
Anyway, I also own nearly everything that VSL makes. I've got it farmed out to a few computers, and I'm getting all my work done, no problem. I'm waiting to see what Snow Leopard brings before doing a complete update of my computer situation.
-
No Lee,
Based on a few post and emails, the 64-bit release is not dependent on Snow Leopard. It based on other dependencies of which I'm not sure what that means......
As far as a PC farm, well I spent all my money on the MacPro, large hard drives, back-up drives and monitors and Leopard thinking I was all set to go...... Surprise!!!
I previously came from the PC world with 64-bit Sonar and had a different vision and understanding of what 64-bit OS and apps really mean. One positive thing they keep telling me though -- I don't have to worry about viruses.
Kinda wish I kept my 64-bit PC instead of giving it to my daughter for college when I made the switch to Mac. Would have made a great slave....... Take care Lee, gotta get back to freezing some of my tracks....
-
Full 64-bit functionality indeed hinges not only on applications being 64-bit capable, but also the hardware and the OS. Apple's hardware has had certain 64-bit functionality for some time, but 10.4 and 10.5 haven't gone the distance in this regard, making it difficult (or impossible) for developers to write true 64-bit apps.
A couple of years ago, Apple decided that it would no longer support Carbon Frameworks which have been used on PPCs. This threw many developers for a loop as many developers had already worked on 64-bit Carbon Frameworks to no avail. These frameworks had to be rewritten with Cocoa Frameworks in mind in order to support 10.6.
What that means for developers is that all software has hit somewhat of a brick wall-- 64-bit processing within a 32-bit OS kernel. It's getting there, but Tiger and Leopard have been gradual steps to getting there.
Once Snow Leopard is released, we will see the transition accelerate. There WILL be some additional wait (however long or short) for DAWs to go all-Carbon and 64-bit capable. Then there are all of your favorite plugins and fx in addition to your favorite virtual instruments which will have to make the transition. Not all developers will be able to release their updates at the same time, but let's hope that the most important software we need will be released within a reasonable amount of time. It won't make sense to have Snow Leopard if half of your software (or PPC hardware) is not compatible. This is why, imho, OSX 10.6 will be a lot less expensive than other OSX updates/upgrades. Users will likely be hit with numerous upgrade fees, and this can be costly. Hopefully, some developers will be merciful by offering free updates or at least taking Apple's lead and keeping the prices low. Otherwise, there could be a lot of frustrated (and bankrupt) Apple users out there.
We may hear further news from developers during the summer trade shows, but I have a feeling that we will hear a lot more by Winter NAMM, 2010 (USA) and certainly by Musikmesse (EU) in March, 2010.
I probably won't "buy any green bananas" [;)] until 10.6.1 is released just to give developers and Apple a chance to iron out the initial wrinkles. Otherwise, I could be out of business if there are too many things which just don't work.
This article might help explain things a bit better (although some of the information about release dates was based on confirmed information from late 2008)
From:
When released to developers around spring and to end users a few months later, Snow Leopard will support using a 64-bit kernel on all Intel Macs with 64-bit CPU, such as the Core 2 Duo.
A 64-bit kernel requires all of its extensions to also be 64-bit. Kernel extensions or KEXTs include drivers for audio hardware, graphics adapters, networking, certain printing components, and other devices on the logic board or attached as peripherals. Until Apple delivers 64-bit versions of the nearly 300 extensions it ships with Mac OS X (not all of which will need to be supported on 64-bit Macs; many are legacy), it is limiting official 64-bit kernel support to a subset of Macs in prerelease builds of the new operating system.
The 32-bit kernel of Mac OS X
Snow Leopard will deliver the first 64-bit kernel for Mac OS X. Earlier versions of the operating system, including today's Leopard, can run 64-bit software but do so using a 32-bit kernel. More accurately, whether running on 32 and 64-bit CPUs, Mac OS X loads the same kernel image and run it as a 32-bit process, although when run on 64-bit hardware, the 32-bit kernel switches into "long mode compatibility mode."
Apple's current implementation allows the existing 32-bit kernel to run both 32-bit and 64-bit applications at once, as well as being able to handle 64-bit virtual memory allocations, giving 64-bit applications and background tasks the capacity to allocate memory spaces larger than 4GB when working with large data sets. In Tiger, 32-bit graphical apps could create a 64-bit process; under Leopard, Mac OS X can run full 64-bit graphical apps.
Leopard's 32-bit kernel has been fitted with enhancements that handle copying between 32 and 64-bit user address spaces, and its syscall and trap handlers are also 64-bit code. This hybrid design enabled Apple to deliver a kernel that could run 64-bit apps without needing to immediately deliver 64-bit kernel drivers for it, nor to require third parties to all ship 64-bit versions of their drivers.
As described in earlier coverage of Snow Leopard's 64-bit features, Mac OS X can also currently use various techniques to use more than 4GB of installed RAM, the limit imposed by 32-bit memory addressing, despite using a 32-bit kernel. Intel's hardware uses a method called PAE to enable certain Mac models to address as much as 32GB of installed RAM, despite Mac OS X's use of a 32-bit kernel.
-
Thanks JWL for the great summary of the OS 64-bit issue. Yes, I read this article before you posted it and was the main reason why I was questioning why VSL didn't provide an application that would exceed the 4.0 GB limit with Leopard. The article states the same info that the Apple techs have been telling me all along. If a developer wanted to code in Cocoa Framework, they could have provided an application that allowed a user to exceed the 4.0 GB limit.
I purchased the MacPro versus purchase for the same money 4 PCs. I made that decision based on the fact that the CPU power (8-cores) would approximate having four individual PCs and that the processors being 64 bit would allow access to the same amount of memory. Where things fells short, is that the application wasn't written in such a way to work with the hardware and current OS.
The point I was trying to make is that Leopard has been released now for over a year and we, the Apple users still do not have a VI application that allows us to load samples beyond (for VI, 3.0 GB if your lucky and 2.5 GB for VE). The article clearly states that it was possible to do so.... "Apple's current implement allows the existing 32-bit kernel to run both 32-bit and 64-bit applications at once, as well as being ahble to HANDLE 64-bit VIRTUAL MEMORY ALLOCATIONS, giving 64-bit applications and background task the CAPACITY TO ALLOCATE MEMORY SPACES LARGER THAN 4GB when working with large data sets.
Bottom line, the capability was there - provided by Apple, the desire by the software developers was not....
What absolutely upsets me is that when I purchased the entire VSL library, the web site stated 64-bit coming soon. Now it says under development. Soon to me was 1-2 months back in 2007 not late 2009....
-
what is really tiring me is when techs are chattering marketing speech ...
Apple's current implement allows the existing 32-bit kernel to run both 32-bit and 64-bit applications at once,
what basically means in clear text you should cripple a 64bit application to allow it running on a 32bit kernel - doesn't make too much sense to me, especially if everything will change again under snow-leo driving developers back into the code and review/rewrite everything one more time ...
for companies having too much developer resources this might be funny, in the real world it is not.
christian
and remember: only a CRAY can run an endless loop in just three seconds. -
Christian,
I agree that this whole dang thing has been a complete mess!!! That being said, will VSL have a 64-bit application for the Intel Macs available when Snow Leopard is released in September? Will we be able to access all our available memory through the VI engine? Will this problem finally go away?
-
there will actually be (or let me put it into words more cautiously: we shall expect) a minor version update (2.1, 3.1) breaking the 4 GB barrier on OS X, probably 10.5 only ...
VE PRO has to address even more issues and will require more testing than any former VSL software ever needed.
christian
and remember: only a CRAY can run an endless loop in just three seconds. -
Any day now I'm going to start getting the impression that Apple isn't cm's favorite company when it comes to cooperating with Viennese developers. :)
-
-
Hey Christian,
I just caught what you said.... You did mean 10.5.x correct? That would be great meaning we wouldn't have to jump right into Snow Leopard to get the additional memory allowing time for the dust to settle with Snow Leopard (i.e. drivers, etc.)
-
nick, it is not so much a question of beeing a favorite company or not - if 90 ore more percent of support is generated by a certain OS it's unlikely the user's or developer's fault ... looks more like inherited issues. just read through the postings here ...
christian
and remember: only a CRAY can run an endless loop in just three seconds. -
The critical part of it as far as 64-bit threading goes is not that the machine or "parts" of the OS are 64-bit capable. The key is that the Mac needs a 64-bit kernel instead of a 32-bit kernel choking on all that 64-bit processing. THATwill be the big difference (if all developers get on board with it handsomely).
But it's encouraging to have read that VSL among the front runners chomping at the bit for Snow Leopard and 64-bit.
-
-
Understand that JWL..... For me right now, on the Mac 8-core, CPU is not the constraint on the 32-bit kernel. I'm able to run all the audio plug-ins necessary without chocking the CPU. The issue right now is the inability to access the memory I have on board creating an inefficient workflow due to the necessity of purging unused samples.
I agree, until we have a full 64-bit kernel on the Mac and a true 64-bit application, the full benefits of what we paid for in the Mac 8-cores will not be realized, but for now, breaking the 4GB limit, as Christian has mentioned as an interim step would be a major Plus......
-
Since this is something that Kontakt invented which Vienna Ensemble also uses, I am wondering - why is it so bad to purge un-used samples? People keep saying they won't do this. So it is better to have unused articulations just sitting there on your computer for no reason? I am not trying to be a smartass, but asking seriously why this is considered bad, since it is so simple to do. Of course if you change your mind about a part then you have to click on "Learn" and wait about four seconds before entering the changed notes. But I do not understand what is so bad about the purge unused samples function. Since to me, using massive amounts of RAM to have hundreds or thousands of mbs of unused samples just sit in memory is grossly inefficient.
-
William,
The subject of purging is obviously personal preference. I like to work as efficient as possible and minimize the steps and time it takes to go from A-Z. Memory over the years has become relatively inexpensive to the point that to me, it's worth having the unused samples in memory versus taking the time to load, dump, reload, dump, reload, dump, etc. it.
Also, my workflow when composing is I look at a piece in sections and create all the tracks for a given section. I get it sounding pretty much the way I want it before moving to the next. It is the way I've always done it. I can hear the end in my mind but I only work one section at a time and therefore make many tweeks along the way.
I suppose if I was just plugging and chugging notes in the sequencer from a prewritten score one instrument at a time, then the purge things wouldn't be such a big deal. Input the whole instrument part, purge and on with the next. That's not the way I compose and therefore requires me to reload all samples back into every instrument for every part, for every section I work on. There's other technical issues I have had with the VSL VI purge in the past like the instrument purging samples that shouldn't have been purged after I had it learn and then requiring a reload and purge again. Just didn't want to have to deal with that.
I guess I've never thought of it much until you asked. Because of my preferred workflow, buying a big machine with lots for memory and speed so that all instruments are at my fingertips when I want them is very important. It is a left-right brain thing. When I'm composing I try to stay away from the tech stuff as much as possible because it begins to hinder the creativity..... I want to only think about the music and not the computer and software. It's time to move into the 21st century in how we use our computers. The Kontact Purge Things was great in the 386 days -- not so great today....
I feel like I just went to confession......
Hope this helps to understand my viewpoint.
Take care....
-
One other thing William,
Years ago when I first was getting into the Computer Science arena, I remember working with no more than 4KB where every bit had to be accounted for -- no wasting because it was very expensive and in many cases, additional just didn't exist. You had to build the code to work in the available space. I remember writing mini compilers in CS class at the University of Michigan and being graded on the efficiency of the source code and the time it took the complier to compile it into machine code not to say that the logic of the final product had to also be correct. Times have changed....
