On 04-28, david wrote: > Well, I like multiple windows. I can arrange them on the screen in a way > that makes sense to me, then leave them there for additional manipulation. This point has been pointed out in the past and it is a pretty typical trade-off of single window designs. In my opinion most of this is mitigated by the vastly reduced navigation overhead. With the existing UI, the distance between different views might involve transitioning between 8-10 different windows. From my own experience this typically means that you're digging through a bunch of windows piled on top of each other in order to navigate and as such you *want* to have some arrangement which doesn't change because changing it is painful. With the mockups related views are normally 1-2 clicks away with the maximum distance being around 5-6 clicks. That navigation difference may end up converting a few people to the new paradigm, but for the remaining ones, it's possible to exploit the technology powering the UI. So, the UI is an out-of-process one which connects to the zyn core and the zyn core is designed to behave correctly with *multiple* *simultaneous* interfaces. It might be buggy in implementation currently, but the design permits running multiple copies of the user interface. So, if you really wanted to it should eventually be possible to a different instance of the GUI running on multiple screens or multiple portions of the screen. > Upgrade your laptop. Most laptops these days come with touchscreens. And > Linux supports them pretty well. ;) I had expected some of the data to show that, but most of the touchscreen size responses were 7 or 10 inch displays. While not idea I could see a UI this expansive working in the context of a 10 inch display though a normal laptop/desktop sized monitor would definitely offer some noteworthy advantages. > >>Is it intended for live work (a possible other use case) > >To a lesser degree, yes. > >This is where I see the simplified navigation, single window UI, easy > >MIDI learn, and realtime param automation combine to make some live work > >practical. > >In those cases the job of the UI would be make setup easy, let the > >musician bind parameters to their (likely) physical interface, and get > >out of the way. > > A thought: Give users an option to specify their desired UI. Call one > "Musician" or "Performer" or something like that. Call the other "Sound > Designer". So there is essentially no chance that I'm doing this for one key reason: Maintenance. The current UI provides a 'Simple' and 'Advanced' UI. I know that some bugs have sat unfixed in the simple UI for ages because it doesn't receive enough testing from users which would typically report bugs and none of the devs have *any* reason for using that interface. This breakdown has historically meant that you have one view which is confusing, user unfriendly, and the only reasonable way to use the program and another view which is overly restrictive, doesn't provide a model for the data that it's manipulating, underdocumented, and buggy. With a large very active team with a lot of QA this could be mitigated, but even then I don't think it would be a good idea. > I use a panorama program called Hugin. They offer 3 UI choices: Simple, > Advanced, Expert. I have my choice set at Expert, because that's what I do > with the program. But if I was doing realtime image work with it, I might > switch it to simple. So for audio applications, I'd argue that Hugin's simple UI corresponds to the case of no UI within a plugin host. From there the user can get an instance of an application, load basic patches, and manipulate the output in their own familiar environment. Advanced->Expert on the other hand are more of a spectrum and a learning curve for the real UI. Starting out I'd expect a user to want to explore patches, perhaps play with an oscillator, expand to a LFO, then an envelope, etc. Ideally it's an experience which let's the user slowly grow their comfort zone. The current mockups might do a poor job at that, but I don't think it's practical at this time to come up with something between the plugin host's builtin controls and the full UI. > Or get really ambitious and give users the ability to customize the UI as > desired. For instance, maybe for BANKS I only want to see Organ and Piano. > But for individual patches, I want to see and tweak everything about them. > So I can tell Zyn: List these banks on the Banks screen, and Show expert > settings for individual patches? Heck, you want to code your own window/view, then I (eventually) won't have a problem with that. I'm not (currently) going to provide the tools within the UI to do so, but if you have a text editor the code to generate the UI isn't that horrifying (though the layout code takes a good bit of getting used to). For example the Add Synth global parameter window is mostly defined by: http://fundamental-code.com/tmp/ZynCenter.txt I'm not going to recommend breaking out the editors quite yet, but the dynamic nature of the UI might eventually make sense for a reduced view relevant to a *single* user. This side of things is mostly beyond the scope of the 3.0.0 release though. --Mark
Attachment:
pgpZcRdzp0mEZ.pgp
Description: PGP signature
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
