My question is to christian then, answer me this if you will, given a level playing field, and no variables such as learning curve and so on, and given a scenario where you could choose either mac or PC as a development platform, as a tool, in terms of performance, what is the superior development platform - Cocoa (not carbon) or C++ under windows.?
Second, I remove myself from that monster statement, this is a strong discussion but I wouldn't even consider it a heated one - we can all have our opinions and within that educate each other where one or the other is either mis informed or ignorant of certain facts.
Herb you are quite right the development of 64bit OS X version is quite clear. For my own part, I simply entered this discussion more to press a button regarding the political leanings regarding windows development. For my part, I don't like windows, I think it is an inferior system by far, in any flavour compared to OS X or Linux and I say that with NO critisism of VSL or christians work - more a broader statement, I wish that windows did not hamper development of modern platforms.
I consider windows a legacy item at work and elsewhere, that the world now has to deal with because of it's legacy stranglehold on the world that was there by intention and design from the start (in my opinion). If it were not for that, and people were free to move to other systems that suited them, I think both OSX and various forms of linux (which would have much more innovative development if not for the windows stifling of innovation for many years and apples self created woes) would now be the dominant platform, with windows reserved for grandmas on Win98 using outlook for emails... he he. Seriously windows is not the great gamers platform by any means, it's only because it is the dominant platform and for other systems gaming comes last as a matter of necessity. Should linux and osx become and stronger market share, they would have the better gaming performance than windows by necessity.
This isn't about mac versus windows, it's about the stifling of innovation - so when somebody says windows is superior and mac costs more money to develop for "as though" it is inferior, I feel the need to say a few words. Apple is by no means a shining light but compared to windows, they have developed an operating system light years ahead of it. The legacy item here is windows... in my opinion. But I wait for christians opinion as well to my question at the top of the post...
By the way I am using safari which is why my posts are not formatted since safari has a bug with this forum.
Miklos.
-
All this arguing about Mac vs. Windows, no doubt, reflects all kinds of things regarding the state of the world, the sociol-economic factors that may have led to the dominance of Microsoft (not, originally, of Windows) in the corporate computing world, etc. etc., usw.
On the other hand, here on this forum, I am reminded of a story told to me by a couple who are my friends. For the sake of their privacy, I’ll refer to them as Jane and John.
One evening Jane and John found themselves in the midst of one of those heated, intractable arguments that couples sometimes get into. Each was certain of her or his own righteousness, possessed by a sense of cosmic injury and convinced of the utter impossibility of it all. So they decided to sleep in separate rooms. But Jane and John also had a dog, fortuitously named Puck (his real name), after the imp of English folklore and Shakespeare’s Midsummer Night’s Dream.
Long experience had taught Puck that it was a serious error for any reasonable dog to overestimate human intelligence. So, he decided to take action. He went to John’s room and barked, then to Jane’s room and barked some more. Both told him to be quiet, but he paid no heed to their commands and continued barking, more and more loudly at each of them in turn - - just as he had refused to remain silent when he was scolded for trying to advise them that they'd left a pot burning on the stove or, on another occasion, warn them that a bear was ransacking their car outside their cabin in the north woods. Eventually, as on those previous occasions, they caught on. Each began to laugh and heard the other’s laughter, got out of bed, met in the hallway, hugged, said they were sorry and went to sleep in the same bed. Puck wagged his tail, happy that his intervention had worked.
-
jerome, a tiny correction: i'm not one of the main developers, i'm only managing IT and some support. of course this often implies requests from and communication to the developers.
miklos, i'd like to give an answer to another question which is IMHO more to the point: i'm considering a framework to be not the ideal tool for developing applications having their main focus on performance. as some might have already read above: this applies to all platforms.
steve, your posts seem to be the real essence of this thread ;-)
christian
and remember: only a CRAY can run an endless loop in just three seconds. -
Read my last post again - I was not talking about the non-release of VE 64-bit on the same day than the Windows version. I was talking about the 32-bit Mac version which was *not* released on the same day than the Windows 32-bit version, and when it did, it was as a *beta*. J.@stevesong said:
The fact that a 64 bit version of VE was not available on the same day as the Windows version seems mostly - - or, no doubt, entirely - - the result of the fact that Apple discontinued the 64 bit version of Carbon about 3 months before the release of OS 10.5
-
@Jerome said:
Read my last post again - I was not talking about the non-release of VE 64-bit on the same day than the Windows version. I was talking about the 32-bit Mac version which was *not* released on the same day than the Windows 32-bit version, and when it did, it was as a *beta*. JI've read your post several times. The fact is that the delay was so short I don't remember it and that VE currently works well on Macs. May I suggest that you read the Ars Technica article I cited - - and the story of my friends' dog Puck.......
-
Activate the IAC driver in Audio MIDI Setup. Do this by double clicking on the IAC driver. A dialog box will appear. Make sure that "Device is online" is checked. Creat the requisite number of ports (each port is capable of 16 channels). Once you've done this, DP will see the IAC ports as another MIDI interface and you can choose them as MIDI outputs. Then you assign the IAC port and channel in VE so that it receives the MIDI data from VE.
I don't recommend SoundFlower as, every time I've tried it, I've gotten random artifacts (clicks and pops) during playback. If you have an interface such as those made by RME that has the requisite software, you can connect any input to any output and use it (the RME or equivalent audio interface) as the output device. If you have a interface such as the MOTU 2408 which does not currently have such software but does have 3 ADAT inputs and outputs, you can run a short fiber optic cable from Bank C's ADAT output to Bank B's ADAT input. Then assign each instance of VE's to output on a Bank C stereo pair (e.g. assign the first output to channels 17-18. etc.).Then create an AUX channel in DP, assign its Input to channels 9-10 and its outputs to channels 1-2. Thus the audio signal will be sent back into DP allowing you to use whatever signal processing is available within DP. I am currently using this setup without any problems. If your MOTU 2408's ADAT Inputs and Outputs are already occupied, you can purchase a 2408 I/O Expansion unit (the PCI 424 card allows for 4 I/O units).
-
Thanks, that's great information!
I use a MOTU 828 Mk2 which I gather will allow me to use lightpipe cable to route up to 4 stereo pairs out of and back into the mac, which assuming stereo outs would be enough for 4 instances of VE. The digital ins and outs are lying fallow now anyway.
Excellent!
--Chuck
-
-
Thanks Christian, you have answered my question, and that does make sense. I will do some more research into this when I have a moment, as I'm interested also. I suppose if a framework can give you more flexible options in as far as programming for hardware, it can potentially be more efficient performance wise. Thanks for being so up front, candid and honest here on the public forum, it's just another reason why VSL is such a superb company, and I apologise for any pressure however small - I admit do have an issue with windows, and it IS personal.... I put up with it every day at work, I get called in on my days off to deal with it all the time, sometimes more than once. I do not like it at all. If I could run only mac osx, then 99% of my IT problems would absolutely disappear. Currently I run everything on mac osx at work, with the exception of some windows apps that we need front of house, so you see, I'm in a somewhat opposite position to you - where windows is really the costly backwards pain in the butt legacy item and if not for those legacy apps that I cannot get re-written, I would never touch it again. I've come to understand IT and development concepts better than the average bear just by the virtue of the fact that I have had to troubleshoot so much at work over the years. If carbon offers more flexibility to programmers to access performance features of the hardware, then it would certainly be a mistake of apples to not push forward and do the hard work on turning it into a 64bit platform, however, perhaps it is a fair question to ask you - you have answered in a generalised form - can you say that your answer is true specifically of cocoa? I mean, apples frameworks are frameworks but, they are frameworks that are very thin and efficiently and tightly tied to the system and hardware are they not? at least for the most part - I would assume that the intention of such frameworks is simply to offer the developers a more simple environment to develop in while doing all the hard work of performance enhancements and efficiency for them (out of the box). Is that true of cocoa? Miklos.
-
miklos, i understand it would be nice to keep a process within only one platform - however this is not possible in many cases and one has to pay attention to specific behaviour (eg. character sets). too many proprietary features make it sometimes expensive to find the common denominator.
frameworks are basically a good idea to speed up development of applications - they provide a large range of prepared elements the programmer doesn't need to *re-invent* (simple examples are selectboxes, on-click events, menu trees, ect). however they are only of little use if it comes to individual elments and an existing codebase. and they are of no or almost no use if they don't allow to compile the application for all needed destination platforms.
as far as i know cocoa does not allow to compile win32/win64 applications and only a former version of visual studio allowed to compile mac versions (and i'd assume also not for leopard because of the same reason QT does not currently).
but all this goes much too far into speculation because the guys who have to sort the bytes know best what to use how and when, all that i know (and is commonly known) is, that currently it does not work and a few, but essencial, reasons for.
someone who is exclusively developing for mac might be well served by xcode/cocoa, someone developing exclusively for windows might choose visual studio - for the latter and the .NET framework i know it works well for web or more generic applications, but the result lacks performance when high performance client solutions are needed.
it's that simple, resp. it's not that simple ;-)
christian
and remember: only a CRAY can run an endless loop in just three seconds. -
News from one of those 'other' sample library companies: This was just posted on their forum: Some really good news regarding memory access with PLAY Some really good news for all PLAY product users, our software programmers have figured out how to open up the Mac 32-bit memory limit to use all of the installed ram you have IN YOUR HOST! PC users already have a 64-bit version that enables them to do the same thing, however this will be enhanced shortly with PC 64-bit VST support. For Mac users this FREE update will be available as soon as it passes QA and will enable users to load many more instruments, even without a 64-bit host. That means instead of waiting for Logic, Digital Performer, Cubase etc. to go 64-bit the major advantage of 64-bit computing will be available to you in a matter of weeks, and it's compatible with older versions of Mac OS X also. This was available in Logic 8 for EXS users, but it was not available to third party plug-ins ... until now. Others have opted for standalone hosts to solve this issue, but we think our solution is more elegant as you get all of the advantages of PLAY residing inside your host, plus accessing as much memory as you have installed. Now you will be able to use all those wonderful PLAY convolutions without them choking your system, and load many more instruments with more ram installed, and once all current conversions to PLAY are complete, have a huge selection of instruments and sounds that you can load from one browser, eliminating screen clutter. We are are rapidly reaching a point where memory limitations are a thing of the past. Ha!
-
1) The entire film post/production community around the globe is dominated by studios and production houses running MAC based DAWs.
2) The BEST sound-libraries available fror Orchestra are Vienna bar none...
3) The entire film post/production community starts buying PCs in order to run VSL smoothly
you guys are forcing our community into using PCs........it's not fair
SvK
-
SVK:
The folks at VSL say they are committed to release of an OSX compatible 64 bit version of VE. I have no reason to doubt them. They also have every motivation to come through on this as they know the facts you cite. I am sure they can figure out that all the professionals who use Logic or DP are simply not going to start learning equivalent Windows applications. Meanwhile, by making use of multiple instances of the standalone (possibly in combination with the plugin) one can achieve the same result - - one can exceed the 2.5GB limit imposed by 32 bit systems.
In my experience, on my dual 2.5 GHz G5, I run out of processing power long before I run out of the ability to load samples. (This is why I am looking forward to next generation of Mac Pro desktops equipped with Penryn processors and 8 processor cores.)
-
The description of how Play functions (offering 64-bit memory access while functioning as a normal AU within the sequencer) matches what I originally -- mistakenly -- assumed VE was designed to do. Needless to say I was simultaneously delighted by what VE could do, and disappointed to discover that the main issue remained tantalizingly out of grasp.
It's enlightening to see that EWQL have found a way to make it happen -- a sizeable competitive plus, with the exception that EWQL's libraries are much less huge and detailed and hence are less likely to hit your RAM limit regardless. The idea of VSL finding a way to allow VE surmount the obstacles the EWQL people have somehow conquered makes me salivate, which is bad for my keyboard.
--Chuck
-
VSL, as I understood, also uses memory space outside of the host, however, it must be implemented differently because I do hit a memory wall after a certain number of instances is reached (hosted by Digital Performer). I'm getting much better results using Vienna Ensemble Standalone alongside DP, so this suggests that VSL may not be using all of the memory space outside of the host app. It can't be, if I get better results and can load much more into VE Standalone.
-
Conversely, I run out of the ability to load samples much quicker than processing power on my 8-core.
-
I'm sure that VSL as any good company has a product strategy in place. What I do question is the marketing priorities within the strategy based on what the user base is asking for. It is very clear to me after reading several discussions on this issue that I am not alone in wanting an instrument that addresses ALL available memory on a single box. I would hope that the priority in the VSL company is to make the Vienna Instrument capable of addressing ALL available memory. I say Vienna Instrument because it is the reason why I purchased approx $17,000 US worth of VI modules. I love the playability of the instrument but it's short-coming in my opinion is the implementation of RAM management. I have never been happy about the fact that I have to play my score (or freeze the track) in order to then release the unused samples. This is a very time consuming process that hinders work-flow and in very large scores, I find myself doing that a lot. That being said, the advent of bigger machines such as the Mac Pro 8-core with more RAM and processing power moves us in the direction of minimizing this impact by being able to access ALL available RAM on a given machine thereby overcoming this RAM Management issue. Vienna Ensemble as I understand it was designed for those users who are using slave machines. For us single box users with large CPU processing capabilities, hard drives and memory, Vienna Ensemble does not solve the root issue. We should not have to add additional hardware or implement shareware (unstable at that) in order to route audio back to our sequencer. It is obvious to me that what the user base wants is an application that will incorporate seem less into any sequencer of their choice without the complex routing of audio, additional hardware, resulting in additional use of screen real estate. I understand the VSL is a small company but I would hope that the development team places a high priority on making the Vienna Instrument capable of using ALL available RAM regardless of machine, operating system or sequencer. Unlike using the Pro or Horizon samples where one could just use a different sampler that fits the bill, we are locked into using the VI engine -- an engine at this point that is missing the mark.
