When I use a random AU-Plugin with the OS X release (4.0):
I keeping the left mouse button clicked on a knob from a virtual guitar amp. If I now, while clicked, leave the plug-in window it does not recognize the mouse movement anymore.
It happens with all plug-ins. The Apple stock AU have a miserable performance and loose the clicked mouse button right after moving the cursor.
I made a short video which should explain it a little better.
This is a bug in the plugin’s GUI, but we can possibly fix it in Ardour. Too many plugin authors make sure their code works with Logic and then they stop, even though Logic does not obey the AU specification in full.
@paul: no its not. It’s a problem with GTK - I filed a bug a long while back. I have a workaround in my plugins, specifically for ardour - no other host has the problem.
I tried Bitwig, Ableton, Reaper, Tracktion and Logic - all working.
@sonnie: to be expected - mouse events are not passed to the plugin's GUI (NSView) when it is embedded in Ardour's GTK window once the mouse pointer moves outside the bounds of Ardour's window. There is nothing the plug-in can do about it. (other than to make sure the mouse pointer doesn't move outside the window - which is the hack I have to use - by asking OS X to temporarily decouple the pointer movement from the mouse events, but this is not a good user experience on some types of plugin, and in those cases I see no reason to degrade the user experience when used with other hosts, just so it works in Ardour).
@paul: There's good reason why developers test their AU plugins for compatibility primarily with Logic (it might be something to do with it being maintained by the company which actually invented the AU standard... and as demonstrated, *most* other applications seem to do a good job of supporting it too)
@linuxdsp,sonnie: the problem is that the plugin GUI fails to create an event grab of sufficiently broad scope. They assume that the host is using a toolkit that will do this for them. If the plugin GUI did this, then things would work as expected. That is why I noted that we could possibly fix it inside Ardour, by doing the grab for them.
Logic does not implement the AU standard. Try talking to people who implement VST<=>AU bridges for examples, and you’ll hear about a number of examples where Apple violate their own specifications. Symbiosis, for example, doesn’t follow the AU multi-bus specification because various version of Logic keep changing “what it means”. Over the years I’ve been on the core-audio list, I must have seen at least a dozen examples of plugin developers noting similar issues with Logic’s implementation of the AU spec. The result is that most other hosts also follow Logic’s behaviour, rather than the AU spec, in places where they differ.
The plugin can’t do anything about it - the events are not propogating from the hosts GTK window (the implication is that they don’t even get delivered to the host GTK window when the problem occurs, and if true, that is where the “scope” of the grab is insufficient, in which case its a bug in the host application). The plugin just creates a custom NSView and responds to events delivered to it, there is no concept within a plugin, of where this NSView resides in the hierarchy - neither should there be, and it shouldn’t be implementing all manner of custom event grabbing / processing outside of that window / view hierarchy without the potential of causing all manner of other problems). The fact that just about all other host applications seem to work, and ardour doesn’t, coupled with the fact that this affects Cocoa / objC UIs in many different plugins, using many different implementations / toolkits is an indicator of where the problem lies - in my opinion.
@linuxdsp: the plugin certainly can do something about this. The question is whether it should. The plugin GUI gets the mouse down and other events; it doesn’t initiate a global grab because it assumes that the toolkit will do this for it. If the plugin GUI NSView was known to the toolkit, the right thing would happen. But when the NSView is “foreign” to the toolkit used by the host, the grab isn’t created automatically. It works in other hosts because they propagate more Cocoa into their host code (even in Reaper/JUCE; but absolutely in the case of Logic), and so the correct grab takes place because the NSView is known to a higher layer in the host’s own GUI. In Ardour, there are no NSViews and (in many senses) no object that even corresponds to an NSView in any direct sense, because it doesn’t map precisely to any object in GTK2 (it is close to a GdkWindow, but not precisely equivalent; in GTK3 they are identical).
So when the mouse button down event is delivered to the plugin GUI, the grab either doesn’t happen or happens for a different NSView/NSWindow. With a host written using JUCE or Cocoa directly, the mouse button down event initiates a grab on the correct NSView, and as a result events continue to be delivered there. The Cocoa API makes it clear that NSView owners can and sometimes should initiate a grab, and there are some plugins that do this.
In addition, it is worse than this in the still remaining cases where the plugin GUI is implemented in Carbon (still quite a few of these around), in which case, as per Apple recommendations, the plugin GUI window isn’t even parented by a host application window but is placed on top of the host window and various silly games are played to make them appear as one. I would happily drop Carbon GUI support, and we likely will in a future release because it really doesn’t work any more on the most recent release(s) of OS X.
@paul: I understand all of the issues, from both the host and the plug-in side, but what it seems to me is that this can’t be fixed this properly (e.g. reliably) in the plug-in.
If NSViews are “foreign” to GTK2 then (and who knows what GTK2 really uses “under the lid” in that case - could well be Carbon…) that presents a problem with regard to making AUs which use Cocoa UIs work properly in a host application which uses GTK2 (e.g. Ardour). I don’t use GTK2 so that’s not my problem, and I think you are unlikely to persuade, what seems to be a significant number, of other plug-in developers to hack their code specifically to work in Ardour.
True there are some horrible hacks around using Carbon, generally, but that’s a distraction from this problem. Personally, I don’t really use Carbon in any of my plug-ins, other than a thin “wrapper” to provide 32Bit Mac VSTs, which will likely be extinct soon.
So irrespective of the rights or wrongs or any technical smoke and mirrors about whether the host application should or shouldn’t address the problem, I doubt if you’ll persuade other commercial developers to fix up their code, to address what seems to be an ardour specific issue. Which leaves the only remianing option that it be addressed in Ardour.
I know precisely what GTK uses under the hood, because I helped to write it. It uses Cocoa.
I write this stuff because I get sick and tired of, on the one hand, users complaining about plugin behaviour and on the other hand, plugin authors who say “I tested it in Logic and it works there”. I’m not saying that you’re doing that, but it is a very common attitude among AU developers.
@x42 You’re joking? - so instead of diverting time and resources into hacking custom work arounds into plug-ins for a corner case which only affects a DAW that not many people use on OS X (in comparison to e.g. Logic) - why don’t developers spend even more of their time and resources supporting yet another plugin standard (LV2), which is not supported by any other Win / Mac host applications (or ever likely to be), and also one for which the only application that actually does support it on those OS (Ardour), also supports (in theory) formats which all other host applications also use (AU, VST etc).
The technical case for LV2 on anything but linux is redundant, and its a bit shaky even on linux. Making a feature of the fact that it does exactly what any other host application / plugin format would be reasonably expected to do normally, and exactly what Ardour would do with AU plugins as well, if the developers were sufficiently minded to fix the bug in Ardour rather than blame everyone else (even the users), is not something that justifies the effort. I have no patience left for this. Don’t try to make this about LV2 vs VST, AU or anything else, this is about a problem with the way Ardour supports Audio Units, no more, no less, and it needs to be fixed in Ardour.
If this is a bug, it belongs on the bug tracker, not on the forum.
@linuxdsp: I was half-joking, but now that you brought it up…
As long as he has a choice, the developer who also wrote AU and VST support for Ardour 4.0 prefers to spend his time with LV2 because he thinks that LV2 is technically far superior on all platforms.
One example are proper unit declarations. eg. Ardour offers the user to specify samples, seconds or bars/beats etc when automating a LV2 effect that provides this info. …and there’s a lot more where this comes from: for example host-provided file selection (e.g. IR samples).
The main reason however is a software freedom - incl. the freedom of the user - and elegant standards suitable for the 21st century. FWIW, there are a few cross-platform hosts and also dedicated hardware running LV2 these days. The LV2 world’s not as black as you paint it.
PS. I have equally little patience left for this. I’d be entirely happy if Ardour would drop VST and AU support in the long run.
@x42: It is a bug, and I did file a bug report a while back. I don’t buy the fact that LV2 is de facto “superior”, none of the examples you’ve cited are things which you can’t do with existing formats, you just do them differently in other formats. I will conceed there is an issue around (GPL) licensing which LV2 addresses - but the number of GPL LV2 plug-ins which people (would) actually use on OS X is vanishingly small I would imagine. Often LV2 appears to be the ideal solution to a problem which it turns out has only arisen as a result of designing something for which LV2 would be the ideal solution. You need to consider whether that is what is really happening before deciding if it is inherently better.
I'd be entirely happy if Ardour would drop VST and AU support in the long run...
I’m sure Windows / OS X users will be equally delighted when this new version of Ardour arrives which doesn’t support any of the plug-ins they use…
If this is a bug, it belongs on the bug tracker, not on the forum.
I was not sure. Thats why I asked in my first post. It seem that noone is really sure about this.
It might be Ardour, it might be the Plug-in. As a non-dev user I don’t care. I want to use this plugin in a host to make music. If a host cannot handle my plugin, but others can, I really think twice the next time which DAW I’ll use.
All I can do is aking the devs about this. This is what I did here. Nothing more.
@sonnie: As far as I’m concerned It is a bug in Ardour, I filed a bug report about it previously, which is why I replied to the post / thread when I saw it mentioned (and paul’s repsonse). As a user you have every right to expect a host which claims to support AU to work correctly with AU plugins. I think this is where our opinions differ from the Ardour devs - for example:
..I get sick and tired of, on the one hand, users complaining about plugin behaviour...
As a plug-in developer, I want there to be a consistently (good) user experience across different host applications. That’s what I hoped it might be possible to resolve here, but unfortunately all we’ve managed to establish (as far as I can see) is:
Its apparently the user’s fault that the plugin doesn’t work (obviously, for naively expecting that it might work properly in Ardour in the first place…) or its the plugin developers fault for not hacking an Ardour specific work around into their plugin, and apparently the best solution is not to fix the problem but to adopt a completely new plugin format (LV2) which no other host application actually uses.
I have no idea why LinuxDSP feels the need to pollute the forums here with these periodic rants against Ardour, LV2, free software all of which are based on considerations that many people involved in the development of Ardour and LV2 and free software don’t prioritize very highly.
Nobody has denied that this is a bug. Nobody has said that it isn’t going to get fixed. Nobody has suggested that it is the user’s fault.
The entire existence of plugins is really deeply symptomatic of a major problem with all audio software. Every host development group, whether open source or not, struggles to deal with plugin compatibility in order to continue to make it possible to load arbitrary blobs of code from arbitrary third parties into already large and complex applications and hope that everything works right. No sane person would ever design a system like this, but it is what we have to deal with, largely as a legacy of proprietary software development. It drives some plugin developers a little crazy, and it drives all host developers nuts (lead developer of a major proprietary DAW: “oh god, plugins, they kill us over and over, every release”).
If we could avoid the prosletyzing about plugin formats and the suggestions that users are being blamed, there would a few extra minutes available to actually tackle bugs.
btw. paul:
,I have no idea why LinuxDSP feels the need to pollute the forums here with these periodic rants against Ardour, LV2, free software all of which are based on considerations that many people involved in the development of Ardour and LV2 and free software don’t prioritize very highly."
…by all due respect, I have no clue about programming, but this response is both childish and sickening.
@paul: I have to say I’m disappointed, I’ve been at pains to point out (and I believe politely) that there are concerns which affect users, and which could and should be addressed by the developers, in the interests of making things better. But in many cases (certainly recently) I’ve been met by an uncharacteristically unprofessional response. (For example, my thread about “the state of linux audio” was a genuine question, to people who actually use the software - in a way I’m saying “this is my experience when I use linux for audio, is this out of the ordinary” and I hoped that might inform decisions about the nature of my - and my company’s - future involvement. By implication, that perhaps I might be able to do something to improve matters, not necessariy abandon any involvement). I asked on the Ardour forum because that’s where the majority of linux audio users are. Unfortunately, that post was met by a “satirical” or “ironic” response - your words not mine. I’m not sure if that was intended to make you look ridiculous or me, personally I don’t care, but I did think it reflected badly. There were any one of a number of ways in which you could have censored that thread if you chose, which would have been more professional.
I got involved in linux audio about six years ago (publicly) as both a user and a developer, and I genuinely thought I could bring to it something which was missing, and which would improve matters. I believe I did that, and a number of users will agree, but, unfortunately (as has happened to others) I ran into developer intransigence, bad attitudes from developers, and a refusal to accept that someone who had worked in the industry for over 20 years, with one of the top pro-audio companies, might just know something about the subject. I particularly remember being told by one of your developers on IRC that he “couldn’t be bothered to debug code he couldn’t get the source code for” when I offered help to fix a problem, entirely of his making as it turned out, which was affecting some of my software.
I might have been able to offer the benefit of some valuable experience in this industry, and as a developer too, but with regret, I think the attitude of other linux audio / Ardour devs makes that impossible and / or a waste of time.