Windows Support with JUCE 5.4.7

[DBraun]

Addressing https://github.com/fedden/RenderMan/issues/12

First of all, thanks for this amazing project. I was really happy to see your Medium post on deep learning synth presets a while back and am even happier to see IRCAM researchers use Renderman on their https://github.com/acids-ircam/flow_synthesizer.

This commit adds Windows support. I wanted to avoid changing the version of JUCE, but somehow the JuceLibraryCode/modules kept getting overwritten, and I had to give in. Unfortunately 5.4.x introduced many issues:

The return signature for pluginFormatManager.createPluginInstance seems to have changed from a simple pointer to a unique_ptr. These made me change the way RenderEngine gets deallocated. if (plugin) { plugin->releaseResources(); plugin.release(); } I also had to create boilerplate for copying RenderEngineWrapper. RenderEngineWrapper(const RenderEngineWrapper&) {}

My Visual Studio 2019 projucer properties include a lot of "hard-coded" paths: C:/tools/boost_1_71_0 C:/tools/VST3_SDK C:/Python37 C:/Python37renderman

Originally I tried using environment variables in the Projucer. My Windows environment variable for RENDERMAN_PYTHON_PATH might be C:\Python37 and so my header search paths would be $(RENDERMAN_PYTHON_PATH)\include but Visual Studio didn't seem to recognize those vars. So I gave up and just hard-coded the paths.

But I can use Renderman on Windows!

If you want to try this yourself but attempt NOT updating JUCE, here's my advice: Install C:/tools/boost_1_71_0, C:/Python37, and C:/Python37renderman as suggested in the updated README.

Create a new property sheet for Visual Studio 2019 in the Projucer. Extra Linker Flags: -DBOOST_PYTHON_STATIC_LIB

Header Search Paths: C:\tools\boost_1_71_0; C:\Python37\include

Extra Library Search Paths: C:\tools\boost_1_71_0\lib64-msvc-14.2; C:\Python37\libs

Post-build Command: md C:\\Python37renderman\\DLLs; move "x64\\Release\\Dynamic Library\\librenderman.dll" "C:\\Python37renderman\\DLLs\\librenderman.pyd"; copy /B C:\\tools\\boost_1_71_0\\lib64-msvc-14.2\\boost_python* "C:\\Python37renderman\\DLLs\\"

C:\Python37renderman\Scripts\activate.bat, then, python and import librenderman as rm

[fedden]

Hey @DBraun, thanks so much for the PR.

I'll admit this was a univesity project that needs a bit of love, and I've really had no time to look into it. This appears to break the (only) test I have, so until that passes I can't really accept it.

I must admit though, getting this up to date with the latest version of JUCE would make a lot of sense.

[DBraun]

Yea no worries. The drop of VST2 is such a nuisance. https://forum.juce.com/t/can-t-get-juce-to-build-vst-plugin-only-after-update/30618/2 https://forum.juce.com/t/plugininterfaces-vst2-x-vstfxstore-h-not-found/30301/2 I thought that a preprocessor definition of JUCE_VST3_CAN_REPLACE_VST2=0 would make it so that the VST2 folder doesn't need to exist. It failed the CI test. Same thing for JUCE_VST3_CAN_REPLACE_VST2=1

[DBraun]

I got pretty close. The linux test works and mac fails. I'm not sure if I should specify the VST3 SDK Folder for the Mac builds.

[fedden]

Hey @DBraun thanks for the PR. I'm unable to support this project in a professional capacity, so I am wondering if you would like to become a collaborator to get this project in a state that is hopefully usable for yourself and others?

[DBraun]

@fedden That would be an honor. I could try again to get mac working with my windows update. I would also eventually like to remove Maximillian and several non-essential features from Renderman. I think other libraries do FFT, file-writing etc sufficiently well and they don't need to be in something that should focus purely on VSTs. What are your thoughts on that plan?

[fedden]

Hi @DBraun apologies for the late response. This repository has not been at the top of my priorities and I've let it go a bit. Sorry about that. What you suggest sounds good to me provided features aren't removed. I've send you an invite to be a collaborator and trust your instincts for this project.

[DBraun]

Hi @fedden, thanks for doing that. In the time since our last exchange I've been working on a framework that extends RenderMan. https://github.com/DBraun/DawDreamer/ It has numerous advantages over RenderMan but these are some weaknesses:

• No one has tested Linux (OSX and Windows are fine)
• It doesn't use the "override"-specific-parameters paradigm that you designed
• FFT stuff has been removed

Earlier I mentioned removing Maximillian, but I haven't removed it, and it's likely to stay as an alternative to JUCE when appropriate.

It has some strengths too:

• Easy to build, thanks to pybind11 and no Boost.
• Support for dlls and vst3
• Support for instruments, effects, and effects with multiple inputs (e.g., sidechain compression)
• Parameter automation
• Audio playback
• Can build audio processor graphs
• Loading MIDI files

I intend to maintain it and develop it for a while. In a separate project, I'm running some experiments with TF-agents and a custom environment that uses all CPU cores to render audio.

Regarding RenderMan, if you're ok with it, I would ask you to mention DawDreamer in the README so that others can find it. Then you could non-destructively archive this repo so that no one can create issues or PRs etc. Over time people will post on DawDreamer, and I'll do my best to take care of the issues. I think I've already handled most of the suggestions and requests that exist for RenderMan. If you have a suggestion about how to cite you in the repo I'd be happy to accommodate. Thanks!

[DBraun]

Closing because RenderMan's main branch now supports Windows.