AudioFormat dynamic libraries


#1

Would it be possible to create a class that would exposes the AudioFormat class, and wraps is it in a way that it can be loaded in the AudioFormatManager, but in a dynamic/plugin kind of way.

New formats in new plugins, each plugin handles one file format, and the AudioFormatManager scans a directory for such plugins and registers found formats. This could help with some license issues i guess, and perhaps help for those who want mp3/mpc/aac format readers.

I’m asking for this cause i was using the AudioProcessor class to create my own “custom” plugin format and it worked, i can have Components in plugins witch is what i wanted (a plugin interface for my app). I thought that doing the same thing for audioformats might be a good idea.

just a thought.


#2

Good thought, though a bit fiddly to implement - it’d need lots of platform-specific messing about, and would mean a whole load more small projects to maintain, so not crazy about the idea of adding it to the core library.


#3

then perhaps add the AudioFormat methods to the AudioPlugin class (merge this somehow) so that AudioPlugins could serve as AudioFormat providers.


#4

Well, AudioPlugins are only a wrapper for 3rd-party plugin formats, so I don’t really see how that’d help?


#5

i needed a plugin api for my app.

i took AudioPluginInstance and wrote a sublcass of it, closed it in a DLL and create a createPluginFilter() method in it.

in my app i defined a AudioPluginFormat that searches only for my plugins, creating my own Plugin Type that can be loaded into my app using aonly juce (i’m not using any VST/RTAS/AU stuff, just JUCE calls). I need this to open an editor from the plugin in the host (witch works).

But i though since that works adding the methods from the AudioFormat to the AudioPluginInstance and allowing people to write such plugins to handle different formats, and then allowing Hosts loading them as filters for different file types, could be the answer.

or perhaps not :slight_smile: ? that was my idea.


#6

am i doing this the wrong way ? will this crash sooner or later ? or is this ok?


#7

The dodgy bit is that c++ isn’t very good at passing classes between DLLs. Unless both the DLL and app are built in precisely the same way, you’ll get all sorts of problems, and even if they are, there are memory allocation and other subtle dangers. You either have to use something like COM, or expose your API as a series of carefully designed functions rather than a class - both of which are a PITA to write.


#8

So what makes my idea different from all audio plugin implementations (VST, AU, RTAS) is there some special trick to make an api like that. Vst exposes classes, your plugin wrapper also exposes a class, that’s what i did, why is that PITA. Not that i dont believe you i do :slight_smile: if you say it is then it is, just i wanted to know why.


#9

Yes, they all use classes, but the objects don’t get passed between modules: you have a class on either end, and a big messy layer of c functions and structs that connect them across the module boundary. Sure, you can do it, but it’s not as easy as just creating a c++ class and passing it over!