Multiple views?


Was just trying the Juce demo plugin and there doesn’t seem to be AU mulitple view support. Opening two veiws and setting one to generic and then changing a control causes the host to quit.

Changing CreateEditorIfNeeded() to always create a new editor fixes this bug. Also if you set one of the views to generic and change any of the non-generic views, then its not updated until you switch back to non-generic view.


Wow - I never even realised AUs could have multiple views… What host are you running, Logic? If so, can you give me a hint about how to open more than one view - I find its UI completely incomprehensible!


“So he wrote his own.” :wink:

OT: Jules, if my memory serves me correctly, there was a full page RMS/Tracktion ad I saw ONCE in a music mag I can no longer remember the name of and no longer have. I seem to remember it feature your own coupon (face) prominantly.

I can’t recall the text exactly but it was like “Storer didn’t like the sequencers he saw. So he created his own”</hollywood trailer gravelly voice>

In fact I remember you seemed to have a rather smug look on yer coupon too! lol

Please tell me I didn’t imagine this! Do you have an image of it?

PS I see the first non-jules major T release is a bit of a bug-fest. Not tried it yet, but a lot of huffing and puffing on KVR.


Yes… I’d forgotten all about that… I seem to remember it was a picture that one of the mackoids took of me drunk at a party. Don’t think I’ve got a copy of it, thank god!


You can read here about multiple views, from the audio unit programming guide, towards the bottom of the page:

I have tested some commercial plug-ins and some allow for multiple views .

On a related but separate area, correct me if I am wrong, but the view can get a pointer to the controller through getOwnedFilter(). It can then use a lock to get/set things directly in the model. In the audio unit specification it states:

"You build a view to be logically separate from the audio unit executable code, yet packaged within the same bundle. To achieve this programmatic separation, Apple recommends that you develop your custom views so that they would work running in a separate address space, in a separate process, and on a separate machine from the audio unit executable code. For example, you pass data between the audio unit executable code and its view only by value, never by reference.

Without impinging on this formal separation, however, it’s often convenient to share a header file between an audio unit executable code and its view. You’ll see this done in the SDK’s FilterDemo project. A shared header file can provide, for example, data types and constants for custom properties that an audio unit’s executable code and its view can both use."

I have also been looking at DSSI, , where the messaging system between the view and the controller is done totally using OSC, which allows a view to be running on a different computer.
While it is impossible to future proof yourself against what the hosts may through up in the future, I do think that there is something like views running on different computers coming up fairly soon. I am still new to JUCE and Audio Unit programming so any view (pardon the pun) on this would be greatly appreciated!