Modular design? Any ideas on how to handle modules?

#1

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

#2

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

#3

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)

#4

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

#5

[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…

#6

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

#7

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

?

#8

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

#9

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.

#10

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:

#11

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]

#12

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