Help

[Steve Schow]

Just trying out some tests with symbiosos.  So far I have been unable to get it to work using the prebuilt wrappers.  I get the following error, any suggestions?:

[Symbiosis](0x7fff7ea04000) AU kComponentOpenSelect

[MLVST: PG-8X](0x7fff7ea04000) Found my image (/Library/Audio/Plug-Ins/Components/PG-8X.component/Contents/MacOS/Symbiosis) at 147 of 187

[MLVST: PG-8X](0x7fff7ea04000) Found VST bundle or alias at /Library/Audio/Plug-Ins/Components/PG-8X.component/Contents/Resources/PG-8X.vst

[MLVST: PG-8X](0x7fff7ea04000) Resolved alias to /Library/Audio/Plug-Ins/Components/PG-8X.component/Contents/Resources/PG-8X.vst

[MLVST: PG-8X](0x7fff7ea04000) Bundle retain count before releasing: 3

[MLVST: PG-8X](0x7fff7ea04000) VST open

[MLVST: PG-8X](0x7fff7ea04000) VST audioMasterUpdateDisplay

[MLVST: PG-8X](0x7fff7ea04000) VST getCurrentProgramName

[MLVST: PG-8X](0x7fff7ea04000) Updated current preset to user preset named  INIT 

[MLVST: PG-8X](0x7fff7ea04000) VST audioMasterUpdateDisplay

[MLVST: PG-8X](0x7fff7ea04000) VST getCurrentProgramName

[MLVST: PG-8X](0x7fff7ea04000) Symbiosis component pointer is null (cannot handle selector: 4)

[MLVST: PG-8X](0x7fff7ea04000) Caught Mac OS exception in SymbiosisEntry: Mac OS error code -2147450878

[MLVST: PG-8X](0x7fff7ea04000) Caught exception in VST audio master callback

Assertion failed: (0), function staticAudioMasterCallback, file /Users/magnus/projects/symbiosis-au-vst/Symbiosis.mm, line 1094.

/usr/bin/auval: line 11:  2028 Abort trap: 6           arch -x86_64 /usr/bin/auvaltool "$@"

[Bernie Maier]

Steve Schow:

> Just trying out some tests with symbiosos. So far I have been unable to
> get it to work using the prebuilt wrappers. I get the following error, any
> suggestions?:
>
> [Symbiosis](0x7fff7ea04000) AU kComponentOpenSelect

[...]

> > [MLVST: PG-8X](0x7fff7ea04000) Symbiosis component pointer is null (cannot
> > handle selector: 4)

I'm about to head out to day job, but I think this is the root cause. I'd need
to look up which AU function is invoked by selector #4. You may try
investigating yourself by looking at the values for the constants in the big
switch statements in the component entry function near the bottom of the
Symbiosis.mm source file. Sorry I can't be more precise; I'm not at my dev
machine right now.

Cheers,

Bernie

[malström]

It's been a while since I worked on the Symbiosis code but ending up with a null pointer for the Symbiosis component is bad. The selector itself is expected ("kAudioUnitGetPropertySelect"). My first guess is that something went wrong just at the end of the VST initialization (but I am surprised I don't see any exception being caught there). "VST getCurrentProgramName" should be one of the last calls during initialization (as part of "updateCurrentAUPreset"). It looks to me like something unexpected is happening in between these two lines of code:

SymbiosisComponent* symbiosisComponent = new SymbiosisComponent(auComponentInstance);

::SetComponentInstanceStorage(auComponentInstance, reinterpret_cast< ::Handle >(symbiosisComponent));

If the last line is never executed you would end up with a log that looks like yours. But the only way that could happen is if the "SymbiosisComponent" constructor throws, and in that case you should have a log-line about the exception in between these lines:

[MLVST: PG-8X](0x7fff7ea04000) VST getCurrentProgramName

[MLVST: PG-8X](0x7fff7ea04000) Symbiosis component pointer is null (cannot handle selector: 4)

Do you only have a 64-bit version? Have you tried validating in 32-bit mode?

/ Magnus

[Bernie Maier]

Very good to hear from Magnus on this list. He made some very interesting
observations and I've had a bit of a further look.

> It looks to me like something unexpected is
> happening in between these two lines of code:
>
> SymbiosisComponent* symbiosisComponent = new
> SymbiosisComponent(auComponentInstance);
>
> ::SetComponentInstanceStorage(auComponentInstance, reinterpret_cast<
> ::Handle >(symbiosisComponent));

I now believe that Steve's original log *may* have a hint of the unexpected
thing that is happening:

> [MLVST: PG-8X](0x7fff7ea04000) VST open
> [MLVST: PG-8X](0x7fff7ea04000) VST audioMasterUpdateDisplay
> [MLVST: PG-8X](0x7fff7ea04000) VST getCurrentProgramName
> [MLVST: PG-8X](0x7fff7ea04000) Updated current preset to user preset named
> INIT
> [MLVST: PG-8X](0x7fff7ea04000) VST audioMasterUpdateDisplay
> [MLVST: PG-8X](0x7fff7ea04000) VST getCurrentProgramName

Before SymbiosisComponent has finished constructing (and thus before the
instance pointer is saved in the component instance storage), the VST makes
*two* calls to updateDisplay() via audioMasterUpdateDisplay. The first of
these is likely to result in the component emitting a
kAudioUnitEvent_PropertyChange event.

Now I don't see how any AU event listeners could have established themselves
this early in proceedings, but given that Magnus identified the failing
selector as kAudioUnitGetPropertySelect I am wondering if there is a listener
querying the value of a property notified as changed before the component has
had a chance to finish initialising itself. And I'm certainly no expert in AU
event listeners, but this does appear to explain what we see in the log.

I'd recommend at least temporarily disabling the plugin from calling
updateDisplay(). Alternatively, it's a bit premature for me to mention this,
but I've been working on a fork of Symbiosis AU VST and somewhat belatedly
adding version 2 Audio Units support (yes, I know Apple is already up to
version 3). I gather that most developers now may have moved on to other
frameworks that provide this support already, but if anyone is interested you
could check out the develop branch at:

<https://github.com/blurkk/symbiosis-au-vst-2>

The reason I mention this here is that one key aspect of v2 Audio Units is
that they do not use Carbon's Component Manager, and thus cannot save the
instance pointer in component instance storage. I use a class static map
instead. So if you use this fork and set things up to use the v2 AU entry
point instead of the old component entry, then you may avoid the problem of
the SymbiosisComponent pointer being null when retrieving that first property.
But those early updateDisplay() calls may still cause other problems, and none
of my v2 AU code has yet been widely field tested, so this may or may not help.

Cheers,

Bernie

P.S. It may also help to run this crashing code in a debugger with breakpoints
set on C++ exception throw, and capture the stack backtrace of the crashing
thread. Then we'll see for sure whether ComponentEntry is being called again
before the SymbiosisComponent constructor has returned.

[malström]

Excellent detective work! I believe you may be right Bernie. I missed that updateCurrentAUPreset() is also called via 

updateDisplay(). Strange though that, according to the log, the error occurs after the *second* "VST getCurrentProgramName" and not directly after the first (which would be the one issuing the property-changed notification). (The observer pattern is an arch-enemy of mine. It's the goto equivalent in object-oriented programming :) )

As a general rule I have found it a bad idea to call updateDisplay() in VSTs except as a direct response to some user-initiated action. Hosts do all kinds of weird things with updateDisplay(). E.g. Ableton Live suspends parameter automation for the plug-in (I believe they assume that updateDisplay() means that the user has loaded a new preset from the plug-in GUI).

Regardless I should have blocked all callbacks during construction in Symbiosis to be on the safe side. Might do that if I ever update the "official Symbiosis branch". Speaking of which, the only reason I never bothered moving from Google Code to GitHub (or something) is that I simply haven't needed a new version of Symbiosis myself. Everything still just works for me with the Symbiosis code from 2013. Despite that Apple has deprecated the Component Manager and warned about this countless times they *do* still support it, even in OS X 10.12 (or whatever they call it now).

Really happy to see that work continues on Symbiosis without me though! I fully support that.

(Btw, Symbiosis has always been for AudioUnit version 2 which was released way back in 2002 or something. I don't even know, and probably don't want to know, what AU version 1 was. :) But Apple has been extremely sloppy with numbering their AU versions until version 3. They made huge changes to version 2 in early 2000's without bothering to send out any prior information or maintaining any official update history. Every update to Logic or OS X meant breaking 50% of 3rd party software back then. Times *are* better now. :) )

[Bernie Maier]

> Excellent detective work! I believe you may be right Bernie. I missed that
> updateCurrentAUPreset() is also called via
>
> updateDisplay(). Strange though that, according to the log, the error
> occurs after the *second* "VST getCurrentProgramName" and not directly
> after the first (which would be the one issuing the property-changed
> notification).

I agree. I glossed over that fact, but yes I did notice there were two
callbacks and only the first should emit the property-changed notification.
Without a stack trace or a more detailed attempt to reproduce this situation
myself, I don't really know if some kind of race condition is involved that
would delay the "system" requesting the the property details.

> (The observer pattern is an arch-enemy of mine. It's the
> goto equivalent in object-oriented programming :) )

I had never thought of it in those terms, but yes I find in both Cocoa and
Cocoa touch all these different types of observer patterns (KVO, notifications
etc.) do hinder attempts to comprehend the cause of particular classes of bug.
Sure, these techniques aret very useful for blasting updates around the app
without having to explicitly pass objects or delegates around, but I miss the
days of being able to trace logic flows more linearly.

> Speaking of which, the only reason I never
> bothered moving from Google Code to GitHub (or something) is that I simply
> haven't needed a new version of Symbiosis myself.

Indeed the main reason I have made any changes is that the VST 2.x spec is
ambiguous, and the plugins I work on seem to interpret just a couple of things
a bit differently. But also, precisely because Symbiosis *is* so stable, I am
making further changes in my own branch that remove much of its generality
because I want to bypass the limitations of VST 2.x and allow AU to talk more
directly to my internal framework, e.g. directly access a richer parameter
definitions framework.

> Really happy to see that work continues on Symbiosis without me though! I
> fully support that.

At this point I'd like to publicly say thanks for creating it the first place.
It's taken me years (admittedly part time) to get to this level of
understanding, and that's because I could just use Symbiosis and build and
publish.

> (Btw, Symbiosis has always been for AudioUnit version 2 which was released
> way back in 2002 or something. I don't even know, and probably don't want
> to know, what AU version 1 was. :)

Aha, right. I'm just going by the terminology Apple introduced with the OS X
Lion updates that removed the need to use the Component Manager and resource
files. I'm sure there were multiple unidentified Audio Unit spec revisions
prior to that. As you described...

Cheers,

Bernie