Version 1.3b

[Magnus Lidström]

Earlier today I committed Symbiosis version 1.3b to Google Code. This
will be the version I use for Bitspeek v1.02, which includes 64-bit
support and many minor bug-fixes. Once Bitspeek flies safely I'll drop
the 'b' and call it a stable Symbiosis 1.3.

Here are some of the more important fixes in 1.3b:

1) Although I already had solved the problem with multiple plug-ins in
the single Cocoa namespace, I realized the importance of guaranteeing
unique class names in case someone makes modifications to Symbiosis.
Otherwise, this could bring down other Symbiosis plug-ins as they
would reuse the code from any class definition with the same name. Why
XCode and / or GCC do not provide macros or configuration features to
generate unique prefixes is beyond my comprehension. In the end I
opted for a solution that will either require you to add a Run Script
Build Phase or manually define a unique prefix. See
http://code.google.com/p/symbiosis-au-vst/issues/detail?id=21 for
more.

2) Fixed a very old but severe bug that prevented AU Lab (and possibly
other hosts) from generating MIDI for Symbiosis wrapped plug-ins.
http://code.google.com/p/symbiosis-au-vst/issues/detail?id=11

3) SYFactoryPresets.txt and SYParameters.txt are no longer
automatically created in Release builds. This caused access violations
when the user was not running as administrator. These files should be
created once by the developer (using the Debug or Beta builds) and
then added to the project. http://code.google.com/p/symbiosis-au-vst/issues/detail?id=13

4) Fixed a crash bug (accessing freed memory) when closing the plug-in
GUI under certain conditions in certain hosts.
http://code.google.com/p/symbiosis-au-vst/issues/detail?id=17

... and some more minor stuff that I won't bother you about here.

Always, when you upgrade Symbiosis, take care to check for required
changes in the .plist and .r file by looking at the example files.

Cheers!

[Robert Jonkman]

Sorry to bother you again.  I'm now trying to get my MIDI synced properly.  Up to now I've just been send my MIDI without a timeStamp, and while this does work, it's little bit bizzare as I've not been able to properly time my note-off messages.

I played around with AudioGetCurrentHostTime(), but when I use that timestamp my MIDI ends up playing about 130 ms earlier than it should--I think I understand why this is happening and I think the solution is to work with the hostTime that contained in the AudioTimeStamp  that AU host passes in the render callback instead.

My problem is that I don't really know how to acesss it from my processReplace method.  Is it even accessible? 

On Sep 6, 2011 7:13 AM, "Magnus Lidström" <malst...@gmail.com> wrote:

[Robert Jonkman]

After doing an entire day's worth of research, I can't for the life of me figure out why on earth my MIDI is recording early.  The timestamp I'm getting from AudioGetCurrentHostTime() should be correct.  When I play in real time everything sounds great, but the recorded notes are all delayed.

Very disappointing.  I guess here ends my foray in the world of AU.  Thanks for all your help.

[Magnus Lidström]

Bummer. Sounds like some form of latency compensation to me. Is there a way to timestamp the MIDI so that Logic will ignore the timestamps? I.e. for real-time input, what would you use then?

Also, check Logic preferences, I remember a check-box for latency compensation on/off there. But I don't remember, could be concerning latency on plug-in output only and not on MIDI.

Cheers,
Magnus