[LAU] ZynAddSubFX Usability Survey

[Paul Davis]

On Fri, Apr 29, 2016 at 12:18 PM, Will Godfrey <willgodfrey at musically.me.uk>
wrote:

> On Fri, 29 Apr 2016 11:37:25 -0400
> Paul Davis <paul at linuxaudiosystems.com> wrote:
>
> > From Apple's "Optimizing Audio Unit User Experience in Logic Studio"
> >
> > "For even better user interface integration, custom Audio Unit Views
> should
> > refrain from using overlay windows and from opening sheets or auxiliary
> > windows other than for file browsing. All user interface elements should
> be
> > presented inside the root Audio Unit View by laying out its content
> > dynamically and resizing as necessary. The host window listens to size
> > change notifications and will adapt automatically."
>
> Well now, I had intended to stay out of this discussion - not my business
> - but
> I can't let this go without comment.
>
> I don't use any Apple, nor any Microsoft kit, so don't feel obliged to
> adhere
> to their diktats. Indeed I *specifically* want to get away from other
> people
> telling me what I should do; how I should 'experience' the computer.
>

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.

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.

You are free to (a) not use this particular Apple program (b) not use Apple
products at all.

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)
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.

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
noting that Ardour (at least) tends to work the same way.

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.

Hence, this is an argument, in the plugin context at least, for a single
window design.



>
> Since the days of the Acorn Archimedes, everything I use has had
> independent
> windows that can be placed where *I* want them, and instantly rolled up to
> just
> the title bar.


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.

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.

Your DAW/host is the *application* and it can do whatever it wants with
windows (single/multi/whatever).

Plugins are *not* applications and they need to follow some guidelines if
things are going to work well (if at all).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20160429/72cbd414/attachment.html>