[MBTC]

Originally Posted by TweakHead

I was using Reaktor more as a metaphor, well aware of its limitations and that it doesn't qualify as a computer language, let alone a standard.

I'm not even remotely as educated as you are when it comes to computer languages. What I was trying to say - if it even makes any sense at all - is that I would like the differences between formats to be handled at the DAW level.

Why? So that developers wouldn't have to port their creations a couple of times.

In some ways my comparison of a synth-dev language versus a traditional down-to-the-metal language isn't completely ideal, or maybe difficult to put into context.

But believe it or not the challenges would be the same. For example, Java and the virtual machine technology created when Sun owned it was designed to do just that -- allow code to be written once that could run anywhere without a special port to every OS flavor. Write-once, run-anywhere was the promise. What it would require, however is what's called the JavaVM to be present on that OS. Microsoft has something similar that is known as the .Net Framework.

In the scenario you've described, each DAW would have to have something like the JavaVM or .Net Framework embedded in it, let's call it the CrossPlatformSynthHost or CPSH for purposes of this thread .. Anyway, someone would have to design, implement and own the rights to the CPSH implementation itself. Of course, nobody wants Steinberg, or Apple, or Cakewalk or Ableton or whoever to own the core technology, it would create a monopolistic scenario. This means they would need to start by forming a vendor-neutral committee (haha!! Now we are talking red tape, a big slow machine than gets very little done). Anyway each committee would need representatives. They would spend all their time in meetings every day, arguing about the way things should be done as each of them tried to sway the others in some way that is beneficial to their organization (at the end of the day, these organizations are there to make money, right? And that means staying competitive. They MUST compete, by definition).

Politics aside for a minute, and getting back to the cross-platform challenge. Java as a technology has been around for something like 20 years. Yet, most of us own very little software that's written in it. Why? Mostly because it performs badly compared to specialized languages that allow better optimizations. With a cross-platform language, you tend to end up with a least common denominator effect, where the language itself is limited by the fact that it cannot do device-specific things and take full advantage of the OS. There's a reason DAW software is not written in Java. The performance sucks. There is a saying in software engineering: "Portability is for canoes"... it just means whenever you make a technology portable across systems, there are going to be limits to that technology that are always begging to be broken through.

Then, back to corporate politics for example. Android devices are largely based on what's called the Android SDK, which is Java-based. It probably seemed like the logical language of choice at the time, what being cross-platform and all. Android is a highly fragmented OS with lots of devices that are incompatible, so a write-once language probably seemed appealing. Long-term, what happened, is that Oracle Corporation bought out Sun Micrososystems (the original creator of Java). They perceive Google (original creators of Android) as a hostile competitor, so once they owned the Java technology they decided to sue Google for using the technology that they *NOW* owned (operative word being NOW). Long-story short, big headache for Google, that choice to use Java.

So yes, this is well into the geek-speak arena and I hope that doesn't sound like I'm reaching out of scope to illustrate a point, because I truly believe it's all relevant to the cross-platform synth host idea. It's a good idea and would be great if truly viable but it would be plagued with performance problems and political problems by very definition. That's the reason it hasn't happened, is all I really wanted to say.

Originally Posted by TweakHead

I don't even know if such a thing would be possible or not. Why do I think this has to do with Access? Simply because - based on what users say - the performance changes when you switch platforms and the host software. And I imagine it's no easy to task to keep up with all the changes. I mean, Waves Audio and all the others had to put up some work for their plug-ins to be Lion compatible, right? Even though we're talking about the exact same format here which is "Audio Unit" (I think even the VST ones had to be updated to on the mac).

I could be wrong, but I think the performance differences people report are not really problematic due to the plugin standard used (VST, AU, etc) but are more due to the vast number of variable factors between the hardware and the plugin. Things like other devices sharing the same USB bus, creating latency challenges. Things like the ASIO driver and audio interface type... we didn't talk about ASIO but again its just a published standard like VST (although in the case of the Virus that's no excuse because they include their own audio interface!). Even something like the type of USB cable or whether the ports are directly on the motherboard versus a dedicated card can make a big difference.

The vast number of systems out there, running vast numbers of OS flavors, with vast number of combinations of other devices connected to them can add some real challenges to hardware testing. I'm certainly not going to make excuses for Access, because I think if they properly allocated development and QA resources to the project, proper integration could be achieved, no problem. The UltraNova is proof it can be done, I don't hear lots of complaints about the integration with the plug-in from anyone regardless of platform with that product. And the price point of the UltraNova proves that it's not some monumental task that's going to break their bank to simply develop and test their software properly.

In my opinion it simply reveals a management problem. Not enough resources of the right type being allocated to the right task. Its not a high enough priority for them if people are still willing to pay $3k for a synth that performs great as a live instrument but is poorly integrated.

So, technical solutions to a management problem almost always fail. There's only one way to solve the problem and in my opinion, new connectivity standards or plugin standards etc. are not the issue.

Originally Posted by TweakHead

I imagine that programming a synthesizer such as the Virus is no easy task and the integration could be easier if only things would look the same everywhere.

I do understand what you're saying, and to some extent consistency is great. I actually wish that all these vendors didn't have to republish their software in a gazillion different formats (VST, AU, RST etc) and the world would just accept one of them and that's that. But even with VST as the dominate standard, that standard evolves. Steinberg has the VST3 standard, yet most vendors still publish to the 2.4 standard, because theirs not really a revenue motive to implement special features of VST3 (I wish they did because hardware controllers work better with them among other things).

It's just that, as other vendors show that integration is perfectly viable and the technology is already there to do it properly, how do we convince Access to stop dawdling, acknowledge and fix the issues that exist, and do whatever it takes to man up, have some responsibility for delivering the Total Integration they promised and that many people paid for, and make things right? If Chris Kemper wants to go and play with his guitar amps for now I don't know what we can do to pull him back into the synth world to give the Virus product line proper attention unless he sees a direct negative impact to sales of the lackluster integration.

Wish I had the answer, but I don't. I have lots of opinions but no real solution to offer for that particular issue