Trying to get started with symbiosis

[Robert Jonkman]

HI, I'm working on porting my AUDIO-MIDI VST to AU
(http://www.dsptrigger.com). I suspect I'm in for a bit of a
challenge especially as my plugin needs to generate MIDI events.

I'm decided to with wrapping alternative 5, and I've managed to get my
plugin to compile, but when I try to use auval, I get this:

aufx trig AFRO - Audiofront: DSP Trigger
[Symbiosis](0xa06b2540) AU kComponentOpenSelect
[Audiofront: DSP Trigger](0xa06b2540) Found my image
(/Library/Audio/Plug-Ins/Components/dspTrigger.component/Contents/MacOS/dspTrigger)
at 101 of 107
[Audiofront: DSP Trigger](0xa06b2540) No VST bundle or alias found in
resources, assuming fat AU bundle
[Audiofront: DSP Trigger](0xa06b2540) Bundle retain count before releasing: 4
[Audiofront: DSP Trigger](0xa06b2540) VST open
[Audiofront: DSP Trigger](0xa06b2540) VST audioMasterVersion
[Audiofront: DSP Trigger](0xa06b2540) Symbiosis component pointer is
null (cannot handle selector: 4)
[Audiofront: DSP Trigger](0xa06b2540) Caught Mac OS exception in
SymbiosisEntry: Mac OS error code -2147450878
[Audiofront: DSP Trigger](0xa06b2540) Caught exception in VST audio
master callback
Assertion failed: (0), function staticAudioMasterCallback, file
/Volumes/SHARED/again/source/Symbiosis.mm, line 1096.
/usr/bin/auval: line 11: 3074 Abort trap arch -i386 -ppc
/usr/bin/auvaltool "$@"

Any suggestions as to where I might start? My plugin contains many
extra methods for communicating with the editor and sending MIDI.
Will these need any special considerations? Also, how about
generating MIDI events--can this wrapper deal with that? Any
information you could offer me would be much appreciated.

[Robert]

To my utter amazement, by commenting...

return plugIn->myAudioMasterCallback(opcode, index, value, ptr, opt);

...from line 1093 of Symbiosis.mm my plugin loads. Although not quite
functional, the gui is there and quite a few things appear to work.
The Interface also seems to be communicating with plugin alright.

[Magnus Lidström]

First of all, if the sole point of your plug-in is to generate MIDI I
have some discouraging news. See this issue:
http://code.google.com/p/symbiosis-au-vst/issues/detail?id=12

In other words, there are means provided in the AU standard for
passing MIDI data from plug-in to host, but it is not supported by
either Logic or GarageBand. I've seen developers work around this by
implementing virtual MIDI ports using Core MIDI. I have no idea how
difficult it is to implement or how well that works, e.g. will the
host automatically detect new MIDI ports or will it add them on
startup only?

(If I get some time over one day, and enough people are interested, I
am considering checking into it this solution for an optional add-on
to Symbiosis.)

Dropping line 1093 from Symbiosis is not a very good idea. :) All
calls from your plug-in to the host go through this point, and
naturally removing this point will remove any problem associated with
a call from your plug-in, but it will also remove a lot of
functionality. So basically you had an itch and amputated your leg
instead of scratching it.

If you still think there is any point with creating an AU of your plug-
in (despite the lack of MIDI out), I think it would be a good idea to
put a breakpoint on the line 1096 assert and check the call-stack to
see what callback from your plug-in caused the exception. You could
also enable breaking on C++ exceptions and try to catch the error
where it is actually occurring. Could be something in Symbiosis.

[Robert]

Firstly, thanks for your reply. Much appreciated.

>I've seen developers work around this by
> implementing virtual MIDI ports using Core MIDI. I have no idea how
> difficult it is to implement or how well that works, e.g. will the
> host automatically detect new MIDI ports or will it add them on
> startup only?

I've starting going the Core MIDI route myself. I'm able to create
the Virtual MIDI port and I can confirm that Reaper will not see the
new port--not an issue as Reaper supports VSTs nicely. I also tested
in Live and it *does* see the virtual MIDI point. I don't have logic
or GB so I can't test in them. Once I'm actually able to figure out
how to send MIDI to my newly created port, I'll get someone to try it
out in logic.

> (If I get some time over one day, and enough people are interested, I
> am considering checking into it this solution for an optional add-on
> to Symbiosis.)

You certainly have me interested and I'd be willing to offer code once
I have something polished.

> Dropping line 1093 from Symbiosis is not a very good idea. :) All
> calls from your plug-in to the host go through this point, and
> naturally removing this point will remove any problem associated with
> a call from your plug-in, but it will also remove a lot of
> functionality. So basically you had an itch and amputated your leg
> instead of scratching it.

Desperate times call for desperate measures. :)

> If you still think there is any point with creating an AU of your plug-
> in (despite the lack of MIDI out), I think it would be a good idea to
> put a breakpoint on the line 1096 assert and check the call-stack to
> see what callback from your plug-in caused the exception. You could
> also enable breaking on C++ exceptions and try to catch the error
> where it is actually occurring. Could be something in Symbiosis.

I'll do that. Thanks for the advice.

Regards, Rob.

[Robert]

It's dying on the VSTPlugin::staticAudioMasterCallback:

The function that being called just before that is
AudioEffect::setParameterAutomated().

If I look into the staticAudioMasterCallback here are the things I
see:

opcode = 0
index = 7 //Referring to the parameter I'm setting
value = 0
ptr = 0x0
opt = 0.199999996 //Refering to the value of the paramter

Also, for the Locals, is says that plugin is 'out of scope'. Not sure
if this is normal or not. Anything jump to mind? From within my
setParameter method I occasionally call setParameterAutomated. Could
that be causing this issue?

[Robert]

The called to setParameterAutomated from within setParameter are
definitely responsible for my issues. I suppose I can set some flags
and have setParameter called from process instead. Is there any other
workaround you can think of?

[Robert]

I fixed the setParameter issue and all is good. I was also getting
some crashes when adjusting controls on my GUI. It was happening in
the beginEdit and endEdit as a result of parameters being of an index
out of the range of numParameters. I did another amputation hack by
adding some code to return from the function is the parameter was out
of range and everything seems to be working fine. Thank-you for your
help and thank-you for producing such a wonderful package.

Regards,
Rob.

[Magnus Lidström]

(Uh? Where did my reply to this go? I am 100% google groups said it
was posted.)

Again then. I am glad you are getting it working. Great! Although I am
curious why you would ever want to call setParameterAutomated from
setParameter. Seems backwards to me. I mean, setParameterAutomated
calls setParameter. Also, calling beginEdit and endEdit for parameters
outside numParameters? Is that a good idea?

I saw your update to the issue concerning MIDI out. Cool! I would be
interested in trying your virtual MIDI port solution once you have
something that can be tested. What about timing? Is there any way to
achieve accurate timing with this solution?