Hi Guillaume,
thank you for the info! One more thing I was posting above - since all the
binaries are the same, is it really enough to create a duplicate class on
runtime from it? It's just that if you load say AU first, then load VST,
the system creates classes from AU, so why should it be
On 06.09.2012, at 23:16, MeldaProduction i...@meldaproduction.com wrote:
Aaaah, ok ;) thanks. But now - will this actually help? I mean this
basically takes one class and creates another class from it realtime. But
if plugin A is created, then plugin B is created (which takes classes from
A
I'm afraid this is not possible. The executables must be the same. You must
understand that building 70 plugins is quite demanding and currently the 3
interfaces would need 3x more time and space (which means 1.2GB compressed
!! ) just because stupidity of Cocoa design, total no-go. There are 2
On Sep 7, 2012, at 4:19 PM, MeldaProduction i...@meldaproduction.com wrote:
I'm afraid this is not possible. The executables must be the same. You must
understand that building 70 plugins is quite demanding and currently the 3
interfaces would need 3x more time and space (which means 1.2GB
there are hosts that can use both AU and VST (and potentially VST3)
interfaces for plugins. But there's a big catch - crappy Cocoa design. My
plugins are obviously the same for all the interfaces and simply provide
all interface implementations, so the they can be both AU and VST, just
Create cocoa class at runtime
You can check how this is done in Juce, especially in the AU wrapper.
http://www.rawmaterialsoftware.com/juce/
HTH
Thanks. One trouble - I checked and I didn't find any runtime cocoa class
creation - they seem to have special Cocoa views for AU. But I'm
Aaaah, ok ;) thanks. But now - will this actually help? I mean this
basically takes one class and creates another class from it realtime. But
if plugin A is created, then plugin B is created (which takes classes from
A unfortunatelly), wouldn't it also create the new classes from the A
