Regarding ambiguity, I'd say a good rule of thumb is that one should be able to draw the patch on a sheet of paper without introducing any ambiguity. So things like inlet tool tips and cord shaking don't resolve ambiguity in the visual representation of the patch, though they may be useful in other ways. |
| On Fri, 18 Feb 2011 17:48:21 -0800 (PST) Jonathan Wilkes <jancsika@yahoo.com> wrote: > I guess I'm limiting it to unwanted ambiguities that > _cannot_ be resolved by looking at the patch. Maybe we could look at it in another way, and ask what information is hidden in a patch? Most we have mentioned so far: 1) Values of IEM GUIs 2) Creation order of cables 3) Differing implementations of objects 4) Creation order of objects In that scheme, obscured things like inlets behind wires would count. Using real fancy graphics in a modern interface maybe some use of transparency can be made. I always liked the VST hosts where you could "shake" cables. This made me think of a help to revealing (2). If an interface were to have hover-over tooltips, as has been discussed at times for outlets/inlets, then a cable could reveal its creation order on hover. It wouldn't obviate triggers, but would make a nice debugging feature. a. -- Andy Farnell <padawan12@obiwannabe.co.uk> |