<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 29, 2016 at 12:18 PM, Will Godfrey <span dir="ltr"><<a href="mailto:willgodfrey@musically.me.uk" target="_blank">willgodfrey@musically.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, 29 Apr 2016 11:37:25 -0400<br>
Paul Davis <<a href="mailto:paul@linuxaudiosystems.com">paul@linuxaudiosystems.com</a>> wrote:<br>
<br>
> From Apple's "Optimizing Audio Unit User Experience in Logic Studio"<br>
><br>
> "For even better user interface integration, custom Audio Unit Views should<br>
> refrain from using overlay windows and from opening sheets or auxiliary<br>
> windows other than for file browsing. All user interface elements should be<br>
> presented inside the root Audio Unit View by laying out its content<br>
> dynamically and resizing as necessary. The host window listens to size<br>
> change notifications and will adapt automatically."<br>
<br>
</span>Well now, I had intended to stay out of this discussion - not my business - but<br>
I can't let this go without comment.<br>
<br>
I don't use any Apple, nor any Microsoft kit, so don't feel obliged to adhere<br>
to their diktats. Indeed I *specifically* want to get away from other people<br>
telling me what I should do; how I should 'experience' the computer.<br></blockquote><div><br></div><div>This is Apple telling *DEVELOPERS* what to do or not to do if the *DEVELOPERS* want their plugins to interact smoothly with an Apple program. <br><br></div><div>If the *DEVELOPERS* don't follow Apple's descriptions, then things may still work, but the user experience may be worse than it otherwise would be.<br><br></div><div>You are free to (a) not use this particular Apple program (b) not use Apple products at all.<br><br></div><div>However, I cited the stuff from Apple because a lot of people forget just how batshit crazy plugin hosting really is, and that for it work well, the plugin (developer) <br></div><div>needs to be aware of certain basic guidelines. This is as true for the GUI side of the plugin as it is for the DSP side.<br><br></div><div>I wasn't suggesting that Zyn or anything else needs to pay any attention to the details of Apple's guidelines, but I was noting that there are guidelines and I was implicitly<br></div><div>noting that Ardour (at least) tends to work the same way.<br><br></div><div>Which means : if a plugin developer thinks that they can just pop up new windows whenever they feel like it, and everything will just work right: no, they cannot.<br><br></div><div>Hence, this is an argument, in the plugin context at least, for a single window design. <br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Since the days of the Acorn Archimedes, everything I use has had independent<br>
windows that can be placed where *I* want them, and instantly rolled up to just<br>
the title bar.</blockquote><div><br></div><div>The Acorn Archimedes did not feature multithreaded, multi-window realtime audio applications using gobs of memory and hundreds or thousands of their own on-screen controls loading arbitrary bundles of code written by parties unknown, and then running bits of that code both inside the DSP and GUI aspects of the program.<br><br></div><div>The idea that the plugin developer can just do whatever they feel like and expect stuff to just work (in every host) is, to say the least, misguided.<br><br></div><div>Your DAW/host is the *application* and it can do whatever it wants with windows (single/multi/whatever).<br><br></div><div>Plugins are *not* applications and they need to follow some guidelines if things are going to work well (if at all). <br></div><div> <br></div></div></div></div>