Just echoing Julian's concerns about compatibility issues with Logic 7.2 - I'm wondering whether the initially released standalone version will work with Logic 7.2 and if it is the AU version that is currently not compatible. Also would like to get an approximate idea of the time frame for release of a Logic 7.2 compatible version. Finally, does the standalone version have a capacity to accept AU plugins? I'd be most appreciative of any information on these subjects. Thanks.

just stepping in ... it's not a question of 7.2, it's a question of intelMac or PowerPC ... AU version on PPC runs very smooth already (independantl from the used host application) ... as far as i've heard 260+ voices.
martins answer was implying the question was about 7.2 on intelMacs
christian

how can an independant version run fine standalone as an AU?

i thought AUs ran inside Logic ?

maybe i'm mistaken

hmmm, maybe it was me who misinterpreted the sequence of postings ... the stand-alone version was already finished and can be found on the install CD (you should check for updates in the user area though ...)
the AU version initially had some performance problems (don't know the details ...) but this is fixed for the PPC platform now.

also not sure now if one could say *ViennaInstruments as AU is running _inside_ logic*, it is of course an extra application (which needs to be installed) but can be used as a plugin _from_ inside logic.
(my english might be too poor to describe it correctly)

christian

Due to problems with different hosts - seems that everbody is brewing their own
soup - we ended up with an AU Server. Think of it similiar to ReWire - only faster and without additional rewiring.
Thus opening an AU Vienna Instrument audio is routed from the VI AU Server to AU Host ( such as Logic )
The only drawback is that GUI appears in an extra window.
This anticipates some directions we may take in the future ...

Thanks

chrisT

Yes, the Vienna Instrument uses its own memory block apart from the sequencer. Several Vienna Instruments use the same memory block, though. We're still testing the RAM limits, optimizing its usage.[/quote]

Martin,

Does this still apply when VI's are opened as an AU within Logic or is it back to the single app limit.

Thanks

Julian

"Does this still apply when VI's are opened as an AU within Logic or is it back to the single app limit."

I'd like to know this too. Also, is it possible to open VI on the same Mac both as a plug-in within Logic and a stand-alone (hoping to gain more sample memory)?

I appreciate the updates on your testing and read them eagerly.

@golem said:

we ended up with an AU Server.

Precisely. A few years ago, my partner in TrueSpec Systems and I met with Martin as he reviewed with us VSL and its direction. At that time, Bruce and I saw that what was needed was a basic server solution. Right now with your own proprietary software for the Vienna Instruments you have the freedom to move in that direction, and you should.

Although no one really talks about it in these terms, what everyone is looking for is a desktop mainframe solution for music production.

Computer A is the sequencing machine. It can be Mac or PC. Computer B is the VSL server using a special edition of FX Teleport and connecting via one (1) LAN cable.

Computer A contains X-number of VI instruments, Computer B holds the rest.

Computer C - a Vienna laptop with a sketch set of VI so the composer can work remotely. See this picture of Max of FX Teleport as a perfect example:
http://soniccontrol.com/features/article.php?ID=17

You're a stone's throw from making this happen. But wait... one point more...

You license the player to the other orchestral libraries so that everyone can work on the same system. Total number of phone calls: 5.

And then...

You have MIR as part of the server solution. Works with everyone since everyone is working with the VI software. System integration issues - solved.

For your computer marketing reading, I suggest: Who Says Elephants Can't Dance, by Lou Gerstner, past president of IBM.

And I'll help you bring it to market.

PA

@Plowman said:

"Does this still apply when VI's are opened as an AU within Logic or is it back to the single app limit."

I'd like to know this too. Also, is it possible to open VI on the same Mac both as a plug-in within Logic and a stand-alone (hoping to gain more sample memory)?

I appreciate the updates on your testing and read them eagerly.

As pointed out in previous posting, VI AU uses an AU Server App.
This is: 1 Application for all AUs
But: indeed you can open standalone in parallel. In this case audio is _not_ routed back.
You even can make a copy of standalone and run 2 standalones (and AU host)
If this is an issue we will add virtual MIDI ports.
Pls note: this has _not_ been tested.

The Sphinx presumes: VSL might work on an integrated multicomputer platform.
(shh, don't tell anybody)

thanks

chrisT (development)

so the VI au cannot run directly in logic ... Apples own software .. that is the main standard for au ?


mmmm...


sounds messy

@Plowman said:

"Does this still apply when VI's are opened as an AU within Logic or is it back to the single app limit."

I'd like to know this too. Also, is it possible to open VI on the same Mac both as a plug-in within Logic and a stand-alone (hoping to gain more sample memory)?

I appreciate the updates on your testing and read them eagerly.

As pointed out in previous posting, VI AU uses an AU Server App.
This is: 1 Application for all AUs
But: indeed you can open standalone in parallel. In this case audio is _not_ routed back.
You even can make a copy of standalone and run 2 standalones (and AU host)
If this is an issue we will add virtual MIDI ports.
Pls note: this has _not_ been tested.

The Sphinx presumes: VSL might work on an integrated multicomputer platform.
(shh, don't tell anybody)

thanks

chrisT (development)

For those of us not as knowledgable as you are about AU's and how they work, I think seeing screen shots of this is implemented would be very helpful.

BTW, the "Sphinx" presumes nothing. Presume is a synonym for assume which means, at least in marketing circles, ass/u/me.

Marketing issues DO drive product development. VSL users sequence on both Mac and PC platforms, and VSL has developed its Vienna Instrument to work on both platforms. The "giant" customer wish from customers is to do everything on a single computer.

Unless the "Sphinx" has missed something, VI is on both platforms. But! Possibly there could be a third platform, and this third option would eliminate the constant update issues found with both Apple and Wintel systems - Linux. Since you're using the Vienna Keys for copy protection, is it possible for them to be programmed to be used on Linux?

If the answer is yes, then there's one possible server solution. And, there are already sequencing/digital audio programs in Linux from smaller companies. So the opportunity to have a front end could be a licensing step away.

Every time the OS updates, you have to update. That's money spent on development that might be avoided with an alternate approach. Every time the OS updates, at some point, the customers have to update and for working professionals, that means down time and lost income, along with all the other stuff that goes into updating.

If you had a consistently stable OS, that means development goes into the developing the product, and not just adapting it to the newest OS changes, as we've already seen mentioned with those asking about Logic 7.2 compatibility on the new Apple systems.

Anyway, these are but ideas and insights. But I think it's appropriate for the Sphinx to quote former British Prime Minister Benjamin Disraeli who said, "The art of statesmanship is to foresee the inevitable and to expedite its occurance."

@Another User said:

As pointed out in previous posting, VI AU uses an AU Server App.
This is: 1 Application for all AUs
But: indeed you can open standalone in parallel. In this case audio is _not_ routed back.
You even can make a copy of standalone and run 2 standalones (and AU host)
If this is an issue we will add virtual MIDI ports.
Pls note: this has _not_ been tested.

Hm. So how would you route the audio from the stand-alone/server progam to your digital audio sequencer in this set-up, Golem?

And I'm a little unclear - as a practical matter, does this mean you can approach 8GB (or 16 in a quad)? You can open both AU and stand-alone Kontakt 2s, for example, but it's not a practical solution due to the excessive CPU load.

@Nick Batzdorf said:

Hm. So how would you route the audio from the stand-alone/server progam to your digital audio sequencer in this set-up, Golem?

The question was if app limits can be pushed further. And multiple
VI AU's use 1 serverApp. Audiostream is handled by host as usual.
This is only a technical issue and should not concern the user.

Standalones are different insofar that audiostreams cannot be routed other than to audio drivers. But you can run them in parallel, tho.

So: VI AU is just an AU !

thanks

chrisT

@Another User said:

As pointed out in previous posting, VI AU uses an AU Server App.
This is: 1 Application for all AUs
But: indeed you can open standalone in parallel. In this case audio is _not_ routed back.
You even can make a copy of standalone and run 2 standalones (and AU host)
If this is an issue we will add virtual MIDI ports.
Pls note: this has _not_ been tested.

Hm. So how would you route the audio from the stand-alone/server progam to your digital audio sequencer in this set-up, Golem?

Some audio cards have the ability to route into sequencers (e.g. RME Multiface using Total Mix). I've never tried it, but I believe that it can be done, so this might be what you're looking for. However I would imagine that the number of inputs would only be as many as the physical ones on the soundcard.

DG

will all of the VI products be available this month? I remeber some product will be released on April, but now I cannot find that message.

thanks

The first 5 Collections will be available this month: Solo Strings, Chamber Strings, Orchestral Strings I, Orchestral Strings II, Woodwinds I.
Cheers, Martin