i'd say *shelved* expresses *put on a shelve but not ready to grab it* ...

you might be interested to read this announcement which affects the development

christian

 Christian:

So this means that release of a 64 bit version of VE is at least several months away? Reading the article you refer to I have some understanding of why this might be so and realize that it is a result of Apple's decision and not your fault or that of any other developer. However, I do hope that you do plan to release eventually a 64 bit Mac OS compatible version of VE...

Thnaks for the info,

Stephen 

well, the article is from june, but i couldn't find any updates so far ...

not that biggie for mac users, since OS X can already access more than 4 GB RAM

also i'm wondering about the status of *true* 64bit audio drivers, which i have to admit i haven't researched during the past months ...

besides that: isn't eg. logic also still 32bit? so who knows if this would even work from top to bottom at the current state

christian

 The version of EXS 24 that accompanies Logic 8 is supposedly (I haven't tested this) 64 bit - - and able to load a virtually unlimited number of samples under OS 10.5. So it seems possible that a 64 bit version of VE could work inside Logic 8. As soon as Leopard compatible MOTU drivers become available I will install Leopard (on a clone of my main startup drive) and try this out. 

If one uses multiple instances of the standalone version of VE one can load about 2.5GB in each instance and thus exceed the limits imposed by 32 bit software. However this means that one has to have a reliable way of routing the audio outputs back into the sequencer. One could do this by having multiple audio interfaces on one computer - - a rather expensive solution. However, there are some audio interfaces and their attendant software (e.g RME's FireFace 400 and FireFace 800) that apparently have a loopback capability - - so that one ca route any output to any input in software. Most audio interfaces and software do not seem to have this capability, so that one must use Soundflower or Jack OSX - - which may or may not work reliably.

Another stopgap for Mac users would be to run Windows XP Pro 64 using Bootcamp and use the Windows compatible 64 bit version of VE, but unless one were to also invest in a 64 bit Windows compatible sequencer (and invest the time in learning it) one would have to dedicate the machine to sample playback and use a sequencer on another machine.  However it does seem a shame to use such workarounds when, probably early next year, new 8 processor core (Penryn) Macs (with 32-64GB RAM capacities) will become available.So I truly hope that VSL will continue development of a 64 bit version of VE compatible with Mac OS 10.5.

Stephen

Dual 2.5 GHz G5

7GB RAM

MOTU 2408 mk.3

OS 10.4.11 

well, everything will be proven once the prerequisites arrive. and to anticipate any objections why not using Xcode: it would be hard to compile windows versions with it ;-)

christian

no need to assume - it is true.

on the WWDC 2006 64 Bit Carbon has been promised and confirmed, but one year later buried silently - so developers who need to write in C++ are lost because in fact they can't use Cocoa.

i noticed some comments mentioning *logic works internally 64bit* but on several places i also read that EXS crashes logic if one tries to load more than 4 GB samples, so either it is not 64 bit or other voices are right which point out that plugins can only use more than 4 Gb if they _don't_ use the standard AU implementation ... looks like another hick-up on the horizon ...

but don't let us discuss further about unlayed eggs - fortunately mac user _can_ access more than 4 GB and the development continues ....

christian

SvK - hasn't this question been asked already? anyway, here is the answer ...

@svonkampen said:

Dietz, Is 64bit OSX VI ensemble stalled due to Apple problems concerning QuickTime? thanx, SvK

confused now ... where is any context between QuickTime and VE - and why should Dietz know?

christian

sigh ... development happens basically in C++ and needs to be cross-platform.

since Cocoa is more a framework than a system API one would need to adapt everything according to the rules of such a framework.

in case you can limit yourself to objectiveC (and possibly a few lines of C++ code to be inserted) Cocoa would be great assumably.

in case you have an existing codebase and need to be cross platform i think every developer will confirm its not the first choice.

clearly a little company like VSL cannot maintain an application in for at least 8  tastes (XP, VISTA, 32 + 64 bit, PPC, intel 10.4 10,5, 32 and 64 bit) using 2 different IDEs (Integrated Development Environments)

christian

ps: i'd recommend to subscribe the newsletter, so you would be among the first to get infomed about availibility of a *true* 64bit version ;-)

well, this slipped through ... we currently don't have a macPro with 16 GB RAM to prove, but i received 2 requests mentioning that vslserver *vanishes* at 8 GB (which i do not understand at all ... if it passes the 4GB limit, why should it start troubling at 8?)

so we have to get the sticks and run some tests, possibly with debug versions (both for OS and VE) to see what's going on in detail. if it turns up to be reproducable we will try to fix it from our side if possible. means i can't comment clearly at the current state.

christian

steven, it is ridiculous to assume VSL would not care about the *apple side of life* it has simply not been neccessary so far to run a mac with 16 GB RAM.

in fact we do care much more about apple, OS X, logic ect as we would like to have to - based on the immanent lack of information we are regulary surprised with new features, releases, behaviour and bugs.

an example (my favorite one btw): imagine windows or application updates would regulary screw up permissions on your system - a worldwide outcry would be the consequence and computer magazines would be full of sneering articles about it.

opposed to this scenario mac users write to VSL support and post in the forum complaining about something *not working*.

now we _do_ care and provide a plethora of information and support how to overcome several issues which would in fact be far outside of our responsibility.

the background is IMO just a perceptional one: whereas the apple credo was and is that you don't need to care about your computer if it is a mac, this might be true and valid for the home user writing emails, purchasing music in iTunes or cutting holiday videos with iMovie, it is not true (and never has been) for the advanced user running highly complex setups on the edge of the technical possibilities.

whereas for windows systems it is considered to be *normal* one has to configure and maintain them carefully this is not so widely accepted for macs ... but it should ...

last point: looking back at the past years i'm estimating we spent twice the money on macs for half the number of machines and a significant part of them are no longer useable (most G4s, the aluminium powerbooks, the earlier imacs, actually the earlier G5s and the first macboook pro) whereas a 5 years old 1,9 GHz PC still runs fairly well and does what it is intended to do: compute ... of course this machines do no word-processing, emailing, surfing, and similar office-tasks ...

so please don't insist we would not care about macs, i just wish everybody else would too ...

christian