-
Notifications
You must be signed in to change notification settings - Fork 25
Micro Blog
Saturday, June 20, 2009 by mhroth
JVstPersistence.saveBank() has now been implemented, allowing entire banks to be saved to file (nominally with the fxb extension). I have yet to implement loadBank, but this will come in due time.
Friday, May 08, 2009 by mhroth
JVstHost development has admittedly slowed down since the beginning. The library successfully loads most effects on all supported platforms. But it isn’t perfect. Now that 90% of the work has been done, we can start with the other 90% :-) One especially annoying missing feature (to me at least) is the inability to openEditor in OS X, even though it works in Windows.
There are two basic approaches (that I can think of) to supplying the VST with a pointer to a window that is needs when calling effEditOpen. The first is to create a new thread in Java, then create a native window in native code in that thread, and make that thread be the event thread for that window. The other approach is to create the window in Java, then pass a native window handle to the VST by using JNI AWT. The former approach is currently being used in Windows. I would love the use the same approach in OS X as well, however I am thwarted.
After much trouble and plenty of swearing about compiling and linking Objective-C and C++ code, learning about NSAutoreleasePool, Carbon and Cocoa, and figuring out how manage windows in OS X, everything worked except for ShowWindow. Any call to ShowWindow would crash the application.
Right now, I don’t know why this is happening. I will try the latter method by using JNI AWT. This is tricky problem.
Tuesday, April 14, 2009 by mhroth
Until now, JVstHost2.setParameter has checked the given parameter value and thrown an exception if it was not within [0,1]. While this conforms exactly to the VST 2 standard, not all VSTs choose to follow this convention. For example, the TAL Vintager encodes its discrete parameters (such as LFO destination) as integers. For this reason, setParameter will now allow any value, but will print a statement to standard error (System.err) informing the programmer that a potentially illegal valid is being passed to the plugin.
Tuesday, February 17, 2009 by mhroth
The topEditor method has been added to JVstHost2 which forces the native editor window, if open, to the top of the z-order (i.e., to the top of all other windows). As with all other editor methods, this one is also currently supported only for Windows.
Monday, February 16, 2009 by mhroth
Two methods, getInputProperties(int inputIndex) and getOutputProperties(int outputIndex), each returning a VstPinProperties object, have been introduced in order to query the plugin regarding the properties of its inputs and outputs. Not all plugins support this feature. Be sure to check that the output isValid. Currently the most useful methods are:
-
isValid: Indicates if theVstPinPropertiesobject valid data about an input or output -
isActive: Indicates if the pin is being used -
getIoIndex: Returns the index of the input or output which this -
getLabel: Returns a textual description of the pin -
isFirstInStereoPair:trueif this pin is the first of a stereo pair. If so, them the next pin is the alternate channel.falseif this is a mono channel, or part of a multi-channel group.
Saturday, February 7, 2009 by mhroth
The previously referenced closeEditor bug has now been fixed. This was due to a Java threading issue wherein the JVstHost2 object would be garbage collected before the native editor thread returned. The latter would then try to set a field in the former, which didn’t exist anymore. The issue has been resolved with appropriate synchronisation. Note that closeEditor blocks until the native editor thread has successfully returned.
Saturday, January 31, 2009 by mhroth
The signature of openEditor has been updated to openEditor(String frameTitle). This will allow the host to specify a custom frame title for the native editor window. This is especially helpful if multiple instances of the same plugin are open simultaneously.
closeEditor is now working for Windows. There is a known bug which causes some plugins to crash when the window closes, but it isn’t clear what the cause of this is at the moment.
A bitmask for audioMasterProcessEvents has been fixed. This should stop an InvalidMidiDataException from being thrown in such cases.
Thursday, January 29, 2009 by mhroth
Well…! I haven’t felt this ill since I was forced to the use the Java native keyword to write Javascript in GWT! I have uploaded a first attempt at loading the native editor for Windows plugins. I was sweating blood as I didn’t know anything about Windows programming before I started. And frankly, now I wish that I knew much less. Has anyone ever seen more abstract variable names with ill-defined structures pointing off to nowhere!??? Maybe the worst is already over, but the the fight is not yet done, not by a long shot.
The native editor can be very easily opened with vst.openEditor(). If you register a JVstHostListener with vst.addJVstHostListener() then relevant callbacks will be made. These are most often comprised of onAudioMasterAutomate, informing you which parameter has changed to what value, and also onAudioMasterBeginEdit and onAudioMasterEndEdit, telling you that a particular parameter is being edited (usually the cause of the user holding the mouse button down and twiddling the knob). These callbacks can be passed on any other sink, such as the provided StringGui. See the GuiMiniHost for an example.
The current version of the code does not work for most plugins, but does work for some. For those that work, it seems to function perfectly. Use the feature at your own risk. I have also identified a bug which crashes the JVM when the plugin is unloaded. Or there are no more editors. Or something. I am still tracking it down.
I would appreciate any feedback regarding how well the native editor works for you. I will of course continue working on the feature, with hopefully more stable results!
Thursday, January 22, 2009 by mhroth
3 The FileNotFoundException is now also thrown by JVstHost2.newInstance. This changes the instantiation idiom to,
JVstHost2 vst;
try {
vst = JVstHost2.newInstance(vstFile, SAMPLE_RATE, BLOCK_SIZE);
} catch (FileNotFoundException fnfe) {
fnfe.printStackTrace(System.err);
} catch (JVstLoadException jvle) {
jvle.printStackTrace(System.err);
}
The reason for this change is that a FileNotFoundException has meaning to an end-user and can be acted upon. This is in contrast to a JVstHostException which contains information for the programmer, but has no meaning to the end-user, except for the fact that the plugin cannot be loaded.
Previously the former exception was encapsulated in the latter, which forced a generic error to be shown to the end-user in the form of, for example, “The plugin cannot be loaded.”, even though the situation could be rectified if the only problem was that the file could not be found. Perhaps the filename was simply entered incorrectly.
Monday, January 12, 2009 by mhroth
I have tenuously uploaded a major new revision today. There have been many changes, but the most critical are as follows. I have made space in the source tree for a tentative VST3 host implementation. For this reason, there is now a class JVstHost2 which is the focus of the library. This class manages VST2s. Also for this reason, the name of the native library has been changed to jvsthost2. Furthermore, the idiom to instantiate a JVstHost object in code has slightly changed. Please see the README. Other than that, all of the basics are still there.
The Windows version continues to vex me. Some of my test synths now produce sounds (whereas before they did not), while others that used to work now crash the JVM :( Also, I recognise that changing programs using the GuiMiniHost just doesn’t work. So much for the cross platform compatibility of Java ;)
Sunday, January 11, 2009 by mhroth
I am nearly complete with a significant refactoring of the code now. It is meant to add more elegant support for different VST 2.x versions on the Java side. It also adds a great deal of parameter error checking in order to prevent VST misuse and JVM crashes, the ability to manually unload the native component (though you can still be lazy if you want to), an improved interface to Java GUIs representing the VST on the host side, and better separation between the Java and C++ code. Under the circumstances, and because I never made any promise to the contrary, despite good software design principles, the current JVstHost API is broken (and hopefully improved!) in several places. Everything seems to be working on OS X and Linux. I still need to do Windows testing and then the new update will be made public.
After that, I will work on supporting opening and closing native editors in Windows.