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 ...

@Another User said:

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

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

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. :)

Sounds promising....  Hope it all comes together.....

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.)

yes 10.5, indicating that probably it will not be possible (or supported) for 10.4 ...

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

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.

I understand, cm. You aren't wont to shoot from the hip.

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....

Chuck, That makes perfect sense.  Also, there are issues with optimizing alternate samples occasionally.  Someone asked in another thread if there is a "reset" in order to start over on a cycle of alternate samples (or up/down bows, etc.).  There isn't one, and so if you do not start in the same place you will get different alternations that are no longer present in the optimized group of samples. 

Understand William -- like a round-robin reset via CC control.

Herb posted a solution by using a phantom note (if there are 2 alternations)  so each time a sequence played the same note would sound - this would work when VI's are optimised as the phantom note sample and the respective alternation note would remain in memory.

Julian

I am not understanding this -  usually a sample wll not alternate unless it is the same note.  Unless the programming is different on these and ANY note causes a switch to the alternate set of notes?  Is that it?   Otherwise how could it be "phantom"?  It would have to be within the keyswitched section, and on the same note, and therefore it would sound an irrelevant note.  Please explain that again because I did not see that thread.

Link:

http://community.vsl.co.at/forums/t/21887.aspx

Julian