Questions re Additional Java Files

[honki-bobo]

Hi Andrew,

yes, file system access does indeed block audio processing. If you really have to access the file system you would have to do it in a dedicated thread that runs independently of the audio processing. That is what I have done in my VM Recorder module.

What I have also done is, I have created my own library of functions that I need more or less regularly. I have written a VoltageModuleAdapter class that takes the original VoltageModule as a parameter in the constructor so I can access it whenever I need to. In VMD I do the layout and design of the module and pass every VoltageComponent to my adapter class. The adapter class also implements all methods of the VoltageModule and those methods get called in the VoltageModule in VMD with all parameters passed to the adapter class accordingly. I have basically written a template module in VMD that I load first thing VMD opens, then I save it as new module and start my development. The adapter class' Java file gets added to VMD as external Java file, my library as external Jar file. The main development of the module is then done in Eclipse, where I have proper syntax highlighting, auto-indent, auto-completion and all the nice stuff that Eclipse has to offer. The only drawback is that I have to re-load the Java file in VMD every time I want to compile and test it, but I can totally live with that.

Hope this helps.

Best regards and stay safe,
Martin

[AndyMac]

Thanks Martin, and your approach seems like a really well thought out and constructed model.

[honki-bobo]

Thanks. It is, I suppose

[andro]

Then I would suggest using the Java logging API. The only reason to use VoltageModule.Log() would be to write to the one single file.

[andro]

Hi @honki-bobo, really good architectural approach. Hopefully we can see more in depth posts like that on these forums (which seem to me strangely deserted).

I think the biggest shortcoming of MD is the code editor from 1987 or so. Really, it's dreadful. I am just commencing to hook up Netbeans, for the reason you mention. But it would be great if Cherry Audio could integrate some contemporary IDE.

Brilliant.

[AndyMac]

Then I would suggest using the Java logging API. The only reason to use VoltageModule.Log() would be to write to the one single file.

The reason I was using their logging API was so that it also shows up in the debug window when testing, and so it can be switched on or off through VM settings.

I'm going to setup a return object for these so that I can pick up errors and log them in the main code. A bit of a simplistic workaround, and the 'scaffolding' in the main code is a bit more, but not too much, but means that the more complex shared code is still separated properly.

It's a pity that Java (or this editor) doesn't have a direct equivalent to C/C++'s #include for these sorts of situations.

And agreed, good to have some in depth conversations on this forum.

[josephbottinger]

I just wish MD was a "standard java project." The module designer has some REALLY nice features for the domain, but as an actual coding environment, it's brutal. For me, at least.

[terrymcg]

I just wish MD was a "standard java project." The module designer has some REALLY nice features for the domain, but as an actual coding environment, it's brutal. For me, at least.

While it's a bit awkward, you can use Eclipse (or some other IDE of your choice) to do at least some of your coding via the "Additional JAR files" project property in VMD. It's a workflow I only just recently adopted myself, after reading this thread

You need to remove and re-add your external jar to the VMD project each time you export it from the external IDE, but it does work. There are some other complications as well... debugging code in the external jar can be a pain for instance, but these are outweighed by the advantages imo.

You get all of the IDE goodness of Eclipse/your favorite IDE, and your external jar is just 'regular' Java, so you have access to the whole scope of the language (vs working inside a single class with VMD). It's been an eye-opener for me

Cheers,
--
Terry McG

[honki-bobo]

I have adjusted my workflow a bit. I still use my library as an external Jar file, but I don't change it very often so there's usually no need to re-import it.
The actual module code is written in a separate class that I import as Java file. When I make changes to that file in Eclipse I simply copy and paste the code over to the file in VMD and I can compile and run it there without having to re-import the Java file.

And I agree, debugging code in the external Jar is a real pain.

[josephbottinger]

So what your process is, then, is that you design the panel in VMD, then copy the Java file to a standard-old-java project with the voltage.jar in the classpath? Do the development there, then export from the project back to VMD for testing, etc?