WANTED: Java VSTi host

[DoctorEternal]

I'm looking to use a VSTi (or DXi) instument in a Java app (load the instrument and play it from inside a Java GUI). Thus, I need a Java library or host app that can load them. I've seen the open source project for creating VSTs and VSTi's in Java, but not an actual Java VSTi host. Anyone?

Cheers,
Dr.E

[VitaminD]

wow.. I dont think there is one really..

at least I've never heard of a pure java-made music/audio host

closest I've come across was storm, but only a chunk of it (iirc) was made in java.. I could be wrong with even that part too.

[Mo Verdigast]

wow.. I dont think there is one really..

at least I've never heard of a pure java-made music/audio host

closest I've come across was storm, but only a chunk of it (iirc) was made in java.. I could be wrong with even that part too.

Arturia Storm definitely uses Java! I stupidly ran some kind of Windows cleanup on my machine and a few days later I went to run Storm and it wouldn't load. I couldn't figure out why, and then I remembered reading some discussion somewhere that said that Storm used Java (and that was why it was so slow and ... uh, wobbly). So I installed Java (from the Sun site) and Storm worked perfectly.

Storm is really cool, but it does have some quirks. And Java. Unfortunately I don't know of any Java hosts, but it would be cool if there were such things.

[pljones]

Weird, I was just thinking this morning that wrapping both plug-in and host interfaces for VST might be a fun thing to do once I've finished reading up on Java... and ASIO...

[Ixox]

A real-time application in Java ??????

[pljones]

Mmm, so there's no realtime support in Java? That could be a drawback...

[vbfischer]

Mmm, so there's no realtime support in Java? That could be a drawback...

Sure, there's plenty of "realtime support" in Java, whatever that means... I have personally developed realtime Java apps...

[Z3R0T0N1N]

I think what Ix was thinking of is that Java is going to be significantly slower than c++ or assembly(of course) or delphi for that matter. Still, I think it is quite possible, and that a good programmer could make it fast enough to function nicely. But you aren't after a full on sequencing package like cubarse or something are you? you are looking for a minihost type of thing that can be integrated into a java app? or did I misunderstand.
Anyway, there is something like that if I am not mistaken. Let me just check on something and I will post back.

[fizbin]

Curious - me having a little programming knowledge, but just enough to be dangerous. How is it possible for a Java application to wrap or call a Windows dll (as in VST)?

fizbin

[Alouf]

I just asked a programmer friend.

Curious - me having a little programming knowledge, but just enough to be dangerous. How is it possible for a Java application to wrap or call a Windows dll (as in VST)?

It is called JNI or Java Native Interface. And he said that most certainly Java could be used for realtime applications, and that Java has some kind of low level sound "API" now. ( what the hell API means, do not ask me )

[Ixox]

I've never seen any real time application in Java.
I cannot imagine a Java App displaying (display is realy a java weakness) many wavs, midi informations at the same time as reading the hard-drive and dealing with a 5ms buffer that it would have to send through all the JNI wrapped VST dll before feeding the soundcard !!

8 years ago everybody imagined Java as the perfect language for client side application, today Java is mostly used for application server (which is my every day Job ).

What would it use for the GUI ? Swing ? Does anybody know a good responsive fast swing application ? I don't.

I'm ready (and would love) to change my mind if someone prove me i'm wrong.

I would also love to know why you want a Host in Java ?

[Warmonger]

How about Eclipse? It's all Java, the GUI uses the system look-and-feel, and it's definitely fast. Java can't be any slower than any other language for GUI responsiveness, because Windows is doing all the actual work.

Maybe using a Java look-and-feel would be a different story, but why would you want to use that ugly thing anyway?

[fishbowl.tucson.az]

What would it use for the GUI ? Swing ? Does anybody know a good responsive fast swing application ? I don't.

Swing, SWT, and other GUI object libs of that type all have a weakness, a tradeoff of their being general-purpose, cross-platform libs.

Nothing stops you from making JNI hooks to a more efficient, platform-optimized GUI subsystem, created specifically for your application. If you can do this, and also eliminate the bytecode interpretation at runtime (either with JIT or by compiling the bytecode), your Java app can be just as efficient as a compiled C++ app.

Unfortunately, by doing this you would throw away many of the attractive merits of Java. But if you look into the GUI libs, you'll see a disgusting amount of object creation and message passing and reflection, all sorts of things that you'd want to avoid if you're going for raw performance. JNI hooks into Win32 (or Xlib) primitives would be better.

I don't personally agree that the graphic nature of audio software is really the way to go. To my mind, the best audio system would be controlled with faders and shuttle controls, with maybe a well thought-out LCD, like a piece of audio gear.

[fishbowl.tucson.az]

How about Eclipse? It's all Java, the GUI uses the system look-and-feel, and it's definitely fast. Java can't be any slower than any other language for GUI responsiveness, because Windows is doing all the actual work.

Maybe using a Java look-and-feel would be a different story, but why would you want to use that ugly thing anyway?

Eclipse is not "fast". It's acceptable, once all the widget objects are loaded by the classloader. It's a file/resource manager and a text editor and a front end to a compiler, that's not really a tall order for "real-time" performance. Eclipse uses SWT instead of SWING, which is a great deal more efficient than SWING or AWT can be.

You say "because Windows is doing the actual work." that's not entirely accurate. SWT is a set of JNI classes that call OS primitives for IO. In that sense, the library is programmed in the native idiom of the OS, so SWT implementation internals look like Win32 on the win version, and they look like GTK code on the GTK version, etc.

But the application still has to do a lot of work (layout managment, geometry, etc.) before it even gets to that layer, and all that happens in Java, and performance depends on how tight your java is, and on how efficient your runtime is.

SWT goes to great lenghts to make sure the API is cross-platform, while the implementation has a one-to-one correspondence with the OS primitives. Why? Because if the java behaves any differently from the equivalent C code, you introduce all kinds of hidden performance problems, buffer alloc issues, and other ugliness.

People seem reluctant to use SWT, and I suppose it's because it takes you a big step away from 100% platform independence. It does buy you in return, near-native GUI performance.

There is nothing that says an equivalent layer for ASIO (or JACK?) interface would not be feasible for audio apps.

You could create a JVM that is optimized for timing-critical applications, to give realtime threads; I'd be surprised if there weren't already something like that.

[Ixox]

Thanks fishbowl, you wrote very interesting stuffs.

--

JNI for low level audio, JNI for every graphical access and JNI for VST dll as well as a specified real-time optimized JVM seem to be the solution. Who wants to code it ?

Java is a very powerfull and "elegant" language.
But i think it's a better idea to use it for what it can do...