juce_AU_Wrapper revised: Channels, Busses, Synth


#1

Hi Jules,

I revised the current version of the juce_AU_Wrapper to make it more flexible.
It shouldn’t break any existing code that is using the current version.
I additionally implemented:

  • arbitrary m to n channel configurations
  • multiple input and output busses for synths and effects
  • sidechain capabilities (using additional busses)
  • synths may have inputs/sidechains, too (for example for a vocoder)
  • a synth can be an effect at the same time
  • the channel names provided by the juce getI/OChannelName functions are used and shown
  • juce::Audioprocessor is informed when the number of channels provided by the host changes (getNumI/OChannel will always return the number that is actually provided by the host)
  • default, minimum and maximum parameter values are handled correctly. This avoids errors and warnings with auval if minimum and maximum of a juce parameter differ from 0 and 1. In that way dependancies between parameters are handled correctly.

That’s it for now. As already mentioned, the code should work with plugins that use the current juce_AU_Wrapper without further adjustments (at least for the test cases that came into my mind).

If you’re interested in putting some of that into the official juce tip, I can send you my code.


#2

Yes, thanks - I’d love to take a look at what you’ve done there!


#3

Check out:
http://mind-crafted-gear.com/juce_AU_Wrapper_Extended.zip

Let me know if something is unclear or doesn’t work as expected.


#4

Thanks, I’ll have a look asap!


#5

there is a discussion about this here:

http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?p=24311#24311

i also posted a similar type of zip (bottom post), with a help file and fully commented code.

i did it a bit different, its more minimal, becouse i didnt want update hell on my hands.
my wrapper hack can have as many busses and channels as you like (defaulting at 2 but if the host requests more it allows more), and also identifies as both synth and effect (that was easy).
having buss count writable, and the channel configs supports flexible setups {-1,-2}. i also saved some function calls at the render level and just iterated through the busses there.

might be nice to have those capabilities in a new wrapper :slight_smile:

nice going!


#6

Friscokid, I’m trying to get your code to work. I got rid of most of the errors (using Xcode 3.2.1 here) but the one that remains is

//Make sure that the juce channel configs are updated if the host connects new busses / channels
	ComponentResult	SetInputCallback(UInt32					inPropertyID,
									 AudioUnitElement 		inElement, 
									 ProcPtr				inProc,
									 void *					inRefCon)
	{
		ComponentResult result;
		result = JuceAUBaseClass::SetInputCallback(inPropertyID, inElement, inProc, inRefCon);
		!!!Invalid conversion from 'long int(*)()' to 'OSStatus(*)(void*,AudioUnitRenderActionFlags*,
                  const AudioTimeStamp*,UInt32,UInt32,AudioBufferList*)'!!!
		prepareToPlay();
		updateBusNames();
		
		return result;
	}

Do you have any idea what’s wrong here?


#7

Hi,
I didn’t get this error using Leo 10.5.8. Maybe something in the AU Framework has changed. Are you using Snow Leo?
If yes then maybe that’s the problem. I will update to Snow Leo in about three weeks, then I can check what is wrong.
If you are still using Leo, than it might be due to changes in one of the last juce tips (but I don’t think that’s the reason).
The last time I compiled my version of the wrapper was at least one month ago and since my MacBook is under repair at the moment I can’t check it myself.

Please let me know, which OS version, juce tip and xcode you’re using.


#8

Indeed, I use Snow Leopard, with the JUCE tip from four weeks ago (it says JUCE 1.51 in the debugger) and xcode 3.2.1.


#9

Can you check if there have been changes in the AU framework that could cause this error, compared to Leo 10.5.8.
I don’t think there have been changes to juce that could cause this.
Maybe there is a history file or something like this, to look for modifcations of apples framework.


#10

Couldn’t find anything relevant here: http://developer.apple.com/mac/library/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_6.html


#11

In the meantime everything’s up and running for some time already… the above error kind of evaporated. Now I’ve got an Audio Unit where the possible channel configs are {1,1},{2,2} and {4,2}. The number of input busses is 2 (the second one being used for possible sidechaining) and the number of output busses is 1. The sidechaining works flawlessly, also the “normal” stereo mode, but I’ve only now realized that the host (doesn’t matter which one) does not see the mono version anymore. Any idea how to get this straight?


#12

First: you should also offer a channel config {2,1}.
Second: check the isInputChannelStereoPair / isOutputChannelStereoPair functions of your AudioProcessor to return the appropriate values.
For me it’s working fine with mono versions of the plugin, too.


#13

Hi,

I am also working on custom plug-in wrappers based on Juce ones. Friscokid, the link you gave at the beginning of this topic is not working anymore. I would be very interested in having a look at what you’ve done!

My wrapper also allows to define custom parameters types (boolean, continuous, discrete, log, linear…) so that the AU generic view displays checkboxes, comboboxes, logarithmic sliders…
I’ve actually implemented an additionnal parameter’s interface used by the AudioProcessor so that every wrapper can access the parameter’s properties (name, code, type, string values, min, max, default, unit, precision, automatable, and even the parameter’s color that the corresponding component should use). Everything works great except the channel configuration in AU and it looks like you’ve done some great job here…

Thanks