Site navigation

Getting module (library) path

Audio Plugins
#1

Hi Jules.

I’m developing a plugin (actually porting it from some old win32/vst code) from VST to JUCE because we want built OSX (AU, and RTAS if possible) versions.

This plugin has a bitmaps based GUI wich user could modify, and the old version just had the bitmaps (bmp) and data files along the dll, distributed like this:

Main library module (dll):

VstPluginsInstallPath/…/Company_Name/VASynth/VASynth.dll

Bitmap files:

VstPluginsInstallPath/…/Company_Name/VASynth/Skin/main.bmp
VstPluginsInstallPath/…/Company_Name/VASynth/Skin/knobs.bmp

Data files:

VstPluginsInstallPath/…/Company_Name/VASynth/Data/presets.dat
VstPluginsInstallPath/…/Company_Name/VASynth/Data/config.dat

The question is simple: looking at SystemStats members, it looks that I can get the main exe path, temp path, user directory path and application data path.

I know I should use the later (app data path) in order to store the data, but I would like to do the mostly unobstrubsive package for users, avoiding put data out of the folder where the main binary file is set.

Using Win32 is just a GetModulePath call iirc, but it could be possible to get the library pathin a “Juicy” way. and the most important question, there’s anythings in the AU version to be considered if I want to distribute the data in the same style.

If there’re problems I guess I’ll better have to use the app data path way.

What you recommend in any case?.

Thanks for your amazing library.

Regards,

Argu.

#2

For a plugin, the app path that is returned by SystemStats is actually your plugin’s DLL file - for doing exactly the sort of thing that you’re doing…

#3

Well, actually:

getCurrentExecutableFileName -> gives the host exe path (ie: “C:/Program Files/Image Line/FL6.exe”).

and getUserApplicationDataDirectory()

gives user data folder as:

“C:/Documents And Settings/UserName/Application Data”

What systemstats function you refer?.

#4

Ah yes, you’re right. In fact I’ve been updating all those methods for the next version, so will get it fixed. In the meantime, you can use PlatformUtilities::getCurrentModuleInstanceHandle() to get the handle of the DLL, and use that to get the filename. That’s what it’s supposed to be doing internally, but it looks like it’s using 0 instead, sorry!

#5