AU plugins not being validated by Logic until OSX High sierra is restarted
Hi, we are experiencing quite some issues with the newest OSX and Logic Pro - when our AudioUnits are installed, Logic cannot validate them (usually actually showing "validated successfuly", but doesn't really let the user use them). After the system is restarted (or perhaps logout + login) it all starts working fine. We are installing the components manually using a custom installer, so I wonder, is this a bug in Logic, or is there some specific step needed to "finalize" a component or something? Cheers! Vojtech www.meldaproduction.com Facebook <https://www.facebook.com/MeldaProduction>, Twitter <http://twitter.com/meldaproduction>, Youtube <http://www.youtube.com/user/meldaproduction> ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Deleting files extremely slow since OSX High sierra
Interesting! Cheers! Vojtech www.meldaproduction.com Facebook <https://www.facebook.com/MeldaProduction>, Twitter <http://twitter.com/meldaproduction>, Youtube <http://www.youtube.com/user/meldaproduction> 2018-04-27 19:34 GMT+02:00 Jens Alfke : > > > On Apr 27, 2018, at 6:29 AM, Andreas Falkenhahn > wrote: > > No big deal... just have Cocoa convert your string to precomposed > or decomposed UTF-8. > > > Just use NSString.fileSystemRepresentation, and -[NSString > initWithFileSystemRepresentation:] to go the other way. They are > guaranteed to do the proper encoding/decoding. (There are CF equivalents > too.) > > —Jens > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Deleting files extremely slow since OSX High sierra
Unfortunately unicode could be quite a problem with that I think. Cheers! Vojtech www.meldaproduction.com Facebook <https://www.facebook.com/MeldaProduction>, Twitter <http://twitter.com/meldaproduction>, Youtube <http://www.youtube.com/user/meldaproduction> 2018-04-27 15:01 GMT+02:00 Andreas Falkenhahn : > On 25.04.2018 at 21:58 Sean McBride wrote: > > > On Mon, 23 Apr 2018 07:36:26 -0400, Mike Throckmorton said: > > >>Try replacing FSDeleteObject with [[NSFileManager defaultManager] > >>removeItemAtPath: pth error: &erro]; > > > Don't do that, it's sorta-deprecated too. :) You want > removeItemAtURL:error:. > > Good times. So what can we learn from that? Avoid Apple APIs at all costs > if there is a POSIX equivalent: remove() is your best friend :) > > -- > Best regards, > Andreas Falkenhahnmailto: > andr...@falkenhahn.com > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/ > meldaproduction%40gmail.com > > This email sent to meldaproduct...@gmail.com > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Deleting files extremely slow since OSX High sierra
I don't think this is applicable here. If you have a function to "delete a file", it will still be a function to delete a file, there's no improvement! Apple is simply covering badly designed APIs, which do work, they are far from ideal, but they work. If they replace an API, they need to provide full backwards compatibility. Look at Windows, it's backwards compatible without problems for like 20 years now (yes I made some hardcore projects 20 years ago and they still work). So apparently it is possible. Whenever MS designs something new, the old version still works, may not be ideal, but let's face it, several times slower file delete because of backwards compatibility? That's a joke... Cheers! Vojtech www.meldaproduction.com Facebook <https://www.facebook.com/MeldaProduction>, Twitter <http://twitter.com/meldaproduction>, Youtube <http://www.youtube.com/user/meldaproduction> 2018-04-25 16:25 GMT+02:00 Dave : > > > On 25 Apr 2018, at 14:43, Steve Mills wrote: > > > > On Apr 25, 2018, at 08:32:14, Vojtěch Meluzín > wrote: > >> > >> Thanks Mike, i'll probably try. I am reluctant to do that, because api > is > >> api and apple forcing devs to change stuff all the time (wasting our > time) > >> is just sad. Plus i just cannot imagine how it could cause things to be > >> that bad. And finally people here seem to report general problems... > Well > >> apple... Anyways i'll try. > > > > That's called progress - replacing antiquated APIs and data structures > with new and better ones. By all means, keep driving a coal-powered steam > car and see how easy it is to buy fuel when every station sells gasoline. > > Well if you consider the use of “gasoline” as an “update” on steam power, > I’d say the same is true. Gasoline which seemed like “progress” at the time > has caused more damage to the environment then almost any other man made > “device”. Which if you turn this back into operating system speak would > also be true, I mean look how much damage the software version of > “gasoline” has caused! > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/ > meldaproduction%40gmail.com > > This email sent to meldaproduct...@gmail.com > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
setWantsBestResolutionOpenGLSurface and flickering with multiple overlaying windows on retina
Hi, I'm using setWantsBestResolutionOpenGLSurface to enjoy the high DPI on retina. Everything works now except that if I have multiple windows overlaying each other (these are AU plugins), the drawing in the partially plugins randomly draws over the foreground windows causing a severe flickering. It does NOT do that when setWantsBestResolutionOpenGLSurface is not used, yet the code is pretty much exactly the same. Regards, Vojtech ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSOpenGLContext destroying textures of another context
(sorry for double post, forgot the subject) Hi, I'm using NSOpenGLContext to optimize drawing AU plugins. There are multiple plugins and each can have multiple instances. So each plugin creates a global NSOpenGLContext and attach particular NSView contexts to it, so that the textures do not need do be duplicated. Problem: When I open one plugin, it's ok. I open a different on, it's ok. Now I release the first one, it destroys all resources => the second one looses its textures! I checked that both context are different, sharing is different, they both use makeCurrentContext in both lockFocus and drawRect. Any ideas what is wrong here? Btw.I got the same thing working using AGL and WGL (on Windows), both without problems, so it is just Cocoa as usual. Cheers! Vojtech ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSOpenGLContext destroying textures of another context
Hi, I'm using NSOpenGLContext to optimize drawing in AU plugins. There are multiple plugins and each can have multiple instances. So each plugin creates a global NSOpenGLContext and attach particular NSView contexts to it, so that the textures do not need do be duplicated. Problem: When I open one plugin, it's ok. I open a different on, it's ok. Now I release the first one, it destroys all resources => the second one looses its textures! I checked that both context are different, sharing is different, they both use makeCurrentContext in both lockFocus and drawRect. Any ideas what is wrong here? Btw.I got the same thing working using AGL and WGL (on Windows), both without problems, so it is just Cocoa as usual. Cheers! Vojtech ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Collision between Cocoa classes for AU and VST plugins
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 duplicating the classes from VST? I'd normally assume Mac OS X would be as dumb as in the first case. Cheers! Vojtech <http://www.meldaproduction.com/> 2012/9/17 Blue Cat Audio Dev > Hi Vojt?ch, > > The only way to handle this issue in your case seems to be using the > objective c runtime APIs to dynamically create your objective C classes at > runtime. > > This way you can give a unique name to the classes (either based on the > address space or anything else), and it avoids clashes. It is also a good > way to avoid clashes between different versions of the same plug-in (it may > happen too). > > That's what we do for all our plug-ins and never had any problem. > > Regards, > > Guillaume > Blue Cat Audio > www.bluecataudio.com > > > Quoting Vojt?ch Meluzín : > > Hi, >> >> 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 >> depending on where you put it and what extension you give to the bundle. >> BUT when you then use e.g. Ableton Live and open the same plugin first >> using VST and then using AU, boom you have a crash, because when VST has >> been open, system checked for Cocoa GUI classes in the VST version and >> then >> when you open the AU plugin it uses the GUI class from the VST version, >> because they have the same name! So it starts using resources from the VST >> version etc... lots of bad stuff can happen. How to solve it? For >> different >> plugins it is solved by adding some postfix to the class names, which is >> just sad, but at least it solved the issue. But here I don't see a way >> without providing different executables for VST and AU, which is a no go. >> Any ideas? >> >> Thanks! >> Vojtech >> >> > > > > __**_ > Do not post admin requests to the list. They will be ignored. > Coreaudio-api mailing list (coreaudio-...@lists.apple.com**) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/**mailman/options/coreaudio-api/** > meldaproduction%40gmail.com<https://lists.apple.com/mailman/options/coreaudio-api/meldaproduction%40gmail.com> > > This email sent to meldaproduct...@gmail.com > -- ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Collision between Cocoa classes for AU and VST plugins
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 more interfaces to be available... No way. Also with frameworks it is not possible for technical reasons as well. I just need a way to create normal objects, never though such primitive thing would be a problem... welcome to Apple... I'll try the runtime creating I guess. Vojtech 2012/9/7 Uli Kusterer > > On 06.09.2012, at 23:16, MeldaProduction 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 unfortunatelly), wouldn't it also create the new classes from the A > > superclasses? Because I see no reason why it should do it a different > way. > > I can think of two options: > > 1) Name the classes differently. You can e.g. do so by adding a > -DBUILDING_AU resp. -DBUILDING_VST flag to the compiler options, and then > doing > > #if BUILDING_AU > #define TheClassName TheClassNameAU > #else > #define TheClassName TheClassNameVST > #endif > > Of course that is problematic if the duplicate classes are referenced in > XIB files, because there you have to use the actual name (i.e. with the AU > or VST suffix). > > 2) Share the classes using a framework used by both plug-ins. The OS will > notice that the framework is already loaded, and will simply reference the > classes in it. Of course, this means you will have to find another way to > switch between AU and VST interfaces, like using the Builder pattern to > have the base class return the proper AU or VST subclass depending on a > parameter passed in, while leaving the rest of the code identical. > > Cheers, > -- Uli Kusterer > "The Witnesses of TeachText are everywhere..." > http://www.zathras.de > > > > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Collision between Cocoa classes for AU and VST plugins
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 superclasses? Because I see no reason why it should do it a different way. Vojtech 2012/9/6 Olivier Tristan > check the git version. > This has changed recently. > > > http://juce.git.sourceforge.net/git/gitweb.cgi?p=juce/juce;a=blob_plain;f=modules/juce_core/native/juce_osx_ObjCHelpers.h;h=6f643705923e6a0319ddcb7b4dd616a303500df7;hb=refs/heads/master > > > On Thu, Sep 6, 2012 at 10:58 PM, MeldaProduction > wrote: > >> 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 >>> worried about this, because even if I'd create special classes for all >>> interfaces (which is sick, but ok...) by subclassing my default view class, >>> what is the odds that the god damn system will use the class from the first >>> loaded module anyway, they will be there too obviously. Any ideas? >>> Or can you point me out into Juce, where the thing is supposed to be? >>> >>> Vojtech >>> >>> >>> check juce_osx_ObjCHelpers.h, ObjCClass class and its use >>> >> >> Thanks, but I must be missing something. I'm looking at Juce 2.0 and I >> found nothing that would even closely remind runtime cocoa class creation. >> juce_osx_ObjCHelpers.h only contains some postfix creation, similar to what >> I use in my plugins to ensure plugin A won't take classes from B. But I >> meant a different problem - in my case plugin A is actually the same as B, >> same binary, same resource, everything... But one is used as VST plugin, >> the other as AU plugin. Then the names of the classes are obviously the >> same, so I just need to ensure binary A will take classes from A despite >> they are also in B. >> >> Vojtech >> >> > > > -- > [image: UVI] <http://www.uvi.net/> > Olivier Tristan | Research & Development > o.tris...@uvi.net > > [image: Facebook] <http://www.facebook.com/UVI.Official> [image: > Twitter]<http://twitter.com/UVIofficial> > [image: Youtube] <http://www.youtube.com/user/UVIofficial> [image: > SoundCloud] <http://soundcloud.com/uvi-official> [image: Blog > UVI]<http://blog.uvi.net/> > > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Collision between Cocoa classes for AU and VST plugins
> > 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 worried > about this, because even if I'd create special classes for all interfaces > (which is sick, but ok...) by subclassing my default view class, what is > the odds that the god damn system will use the class from the first loaded > module anyway, they will be there too obviously. Any ideas? > Or can you point me out into Juce, where the thing is supposed to be? > > Vojtech > > > check juce_osx_ObjCHelpers.h, ObjCClass class and its use > Thanks, but I must be missing something. I'm looking at Juce 2.0 and I found nothing that would even closely remind runtime cocoa class creation. juce_osx_ObjCHelpers.h only contains some postfix creation, similar to what I use in my plugins to ensure plugin A won't take classes from B. But I meant a different problem - in my case plugin A is actually the same as B, same binary, same resource, everything... But one is used as VST plugin, the other as AU plugin. Then the names of the classes are obviously the same, so I just need to ensure binary A will take classes from A despite they are also in B. Vojtech ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Collision between Cocoa classes for AU and VST plugins
> > 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 > depending on where you put it and what extension you give to the bundle. > BUT when you then use e.g. Ableton Live and open the same plugin first > using VST and then using AU, boom you have a crash, because when VST has > been open, system checked for Cocoa GUI classes in the VST version and then > when you open the AU plugin it uses the GUI class from the VST version, > because they have the same name! So it starts using resources from the VST > version etc... lots of bad stuff can happen. How to solve it? For different > plugins it is solved by adding some postfix to the class names, which is > just sad, but at least it solved the issue. But here I don't see a way > without providing different executables for VST and AU, which is a no go. > Any ideas? > > > 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 worried about this, because even if I'd create special classes for all interfaces (which is sick, but ok...) by subclassing my default view class, what is the odds that the god damn system will use the class from the first loaded module anyway, they will be there too obviously. Any ideas? Or can you point me out into Juce, where the thing is supposed to be? Vojtech ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: the first mouseDown message of NSWindow
I'm no expert here, but I think I had the opposite problem - I have a single custom NSView and it was really hard to get rid of the first mouse down message sometimes :). Maybe try the views. Vojtech 2011/12/14 Torsten Curdt > I have a custom window that where I receive mouseDown messages. Now > the first mouseDown is always lost because it just activates the > window. > Here is the relevant code: > > https://gist.github.com/0b3b010ad675a349ce72 > > So I was digging through the docs but I don't see a way around this. > > > http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/WinPanel/Concepts/ChangingMainKeyWindow.html > > But I've seen this working in other applications so I must be missing > something. > Anyone that could give me some pointers? > > cheers, > Torsten > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > > http://lists.apple.com/mailman/options/cocoa-dev/meldaproduction%40gmail.com > > This email sent to meldaproduct...@gmail.com > -- ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
