Modular design? Any ideas on how to handle modules?

Guys, after a loooong period of inactivity, I´m back. So my next project will be a synth that allows open-source modular elements, like envelopes, filters, etc … I was hoping that each module would be a Juce Plugin, and polyphony would be handle by the number of audio ports or something like that. So, could I handle this with Juce? Any ideas on this? Just asking, since it doesn´t hurt, and I need all the help I can get. :wink:

The whole project will be done with Juce, closed-source, BUT, the Modules will all be open-source. What kind of license I need to attach to those modules, stating that they can be re-used to make new modules, but not re-used for commercial apps?

Best Regards, WilliamK

So far I´m thinking on just using each module as a synth-plugin (vst?). But I was wondering on using modules like DLL files, but I wonder about cross-platforms in the future, that´s why VST (or whatever) seems like a better idea, thanks to Juce cross-platform plugin scheme.

The problem is polyphonic parameters. For example, a filter could have multiple parameters per voice. So, maybe I will need to do this in some other way. Any ideas?

Wk

this are too many questions in one. it seems you have to make some conceptual work first.

  • one plugin instance per voice? (so they can me monophonic)

well if they use juce, they have to use licenses which juce provide (but even GPL doesn’t prevent commercial use)

Thanks, yes, I will try to describe the idea better.

Using one instance per voice would take too much resources, specially when using low-buffers. Imagine 16 calls to the plugin process, and having 8 modules been called. Its just too much calls. So the idea is to call it once, and the process will handle each voice in a stereo output, which is fast and easy to handle.

The following call can help getting a pointer to a data structure to be used to send voice-based modulation parameters in a faster way.
File juce_AudioPluginInstance -> virtual void* getPlatformSpecificData()

There´s still a lot to be done, so I´m just trying to think a few things before I spend days and weeks working on something that wouldn´t work. :oops:

Wk

[quote]Using one instance per voice would take too much resources, specially when using low-buffers. Imagine 16 calls to the plugin process, and having 8 modules been called. Its just too much calls. So the idea is to call it once, and the process will handle each voice in a stereo output, which is fast and easy to handle.
[/quote]
well you mentioned

[quote] “The problem is polyphonic parameters.” [/quote] Thats why i give you this answer and

Did you measure it? In proportion what an additional audio-output costs, an additional callback is nothing
And how do you handle the polyphony, in the end you have to call different methods too, so i can see here no downside.

it looks you want to make things more complicated, but i only can give you an advise, try to simplify.
Also to me it looks not sensible, to use a existing standard (like VST) , and then modify it…

Good points, thanks bud, I will simplify things up. :oops:

http://www.synthedit.com/ and http://www.synthedit.com/software-development-kit/

?

Yes, I know SE, but my idea is to make something different, but I will take a look at their SDK, good idea, thanks.

Ok, using a single VST instance per voice does make sense, specially since it would simply the code a lot and make things easier indeed. Plus, adding more voices would just mean allocate more instances, and not have to redo a complete module. :oops:

The VSTs would be GUIless, as things will be handle by the main host via XML configurations along the VST file.

Here´s most of what´s going on in terms of projects: http://www.kvraudio.com/forum/viewtopic.php?p=5390860

Now, since I plan on just using the VST format, I wonder if there´s a way to make VSTs that can´t be scanned by Hosts, or gets ignored somehow, but that I could load from my code. On Windows I can rename the .dll files to something else like .wmod, but what about MAC and Linux? I will investigate a bit more, but any advice would be appreciated, before I paint myself into a corner. :mrgreen:

Ok, creating my own VST file that gets a different name structure wasn´t so hard.

modulesLoaderPlugDesc.pluginFormatName = "vst"; modulesLoaderErrorMessage = String::empty; modulesLoader = new AudioPluginFormatManager(); wk4000Format = new wusik4000Module(); modulesLoader->addFormat(wk4000Format);

[code]class wusik4000Module : public VSTPluginFormat
{
bool fileMightContainThisPluginType(const String& fileOrIdentifier)
{
const File f(fileOrIdentifier);

#if JUCE_MAC
if (f.isDirectory() && f.hasFileExtension(".w4kmodule"))
return true;

#if JUCE_PPC
FSRef fileRef;
if (makeFSRefFromPath(&fileRef, f.getFullPathName()))
{
const short resFileId = FSOpenResFile(&fileRef, fsRdPerm);

		if (resFileId != -1)
		{
			const int numEffects = Count1Resources('aEff');
			CloseResFile(resFileId);

			if (numEffects > 0)
				return true;
		}
	}

#endif

	return false;

#elif JUCE_WINDOWS
return f.existsAsFile() && f.hasFileExtension(".w4kmodule");
#elif JUCE_LINUX
return f.existsAsFile() && f.hasFileExtension(".w4kmodule");
#endif
}
};[/code]

One question, will I be able to name my MAC VST w4kmodule instead of vst? (I don´t have much experience with MAC files)