The more I use QC, the more time I spend making sure my patches align so that curved noodles aren't significant. Combining this with KinemeCore's linear noodles has made me produce work that is cleaner and easier to understand, and quicker to render in the Editor :-)
It does make me wonder whether QC would majorly benefit from rethinking the curved noodle approach. For example, I often find I'll have a single number that has to get to a selection of patches, perhaps having some math applied along the way in some cases. A lot of my patches are structured around a central JS controller too, so those values may need to be diverted into that in addition to the outputs coming back for further use. In these cases, I'll try to align all patches that take the same value horizontally horizontally, so that the multiple curves of the noodles get flattened into a single line. When a patch needs to "tap" this line, I use Splitters to pull the value off - usually using a second one to form a nice 90° bend. I also set the Splitter's name to " " (a single space), reducing visual clutter. This reminds me much of having a common logic line on a circuit board that runs across the entire diagram. http://dl.dropbox.com/u/8004068/QC-NoodleAlignment.png vs http://dl.dropbox.com/u/8004068/QC-NoodleAlignmentNoSplitters.png I'm convinced this is a sensible layout approach. No amount of careful alignment would make the second case more readable. I was initially allergic to Splitters because they were so bulk visually. QC4's slimline Splitters are better but I would ideally like an even more minimal approach, perhaps a pin? Or just a tiny control handle type circle? Anyway, I had filed this as rdar://problem/5877176 and http://www.openradar.me/radar?id=524403 which was closed by Apple when QC4 introduced patch alignment, but the 'pinning' idea was lost. Linear noodles! Please free my ageing GPU from the shackles of rendering hundreds of bezier curves! Ade. On 28 Jul 2010, at 19:26, vade wrote: > While we are on it. > > Can we get a: > > Align vertically to patcher 'box' boundaries, so you can snap to grid > (like you can with output port alignment) so that patches are vertically > aligned nicely? This is just nice and orderly, and we all know thats > important to remove visual noise when parsing visual environments. > > On that not, can we please fix the curved drawing of the patch cords / > noodles so they draw consistent curves from the middle of the distance > between two connected output ports? The current curved method really gets > annoying as it causes lots of overdraw, and LOTS of noise to the scene/graph. > Looking at other environments like Plogue Bidule, XSI ICE, Flame, etc, all > have much much more consistently 'curved' , 'spaced' and drawn patch cords, > which means parsing the tree is easier, and organization becomes less of a > nuisance, and is quicker. > > A really lame, quick example: > > http://imgur.com/52z6f.png vs http://imgur.com/W0JNP.png Compare the > XYZ inputs and patch cords drawn. Fixing drawing so that having them be > vertically aligned but equally spaced like the second image would be ideal. > Having 2 patch cords curve across one another is very common, even though one > is originates from a higher vertical port, and goes to a higher input port. > Thats bad! > > Consistent port ordering across patches. Many patches have similar > patch inputs, such as image, with, height, color, etc. Having a standard > ordering across all patches would be amazingly helpful for patch clarity and > general "it is good" vibe. This also means less cris-cross (makes you jump) > patch cords. Which makes baby jesus smile, and barf rainbows. Also, it wont > break anything, just how things are drawn, right? :) > > I am very happy to file detailed bugs about all of these issues, assuming > there is some consensus as to how things should work. Sorry to gripe, little > things make life so much nicer when working day in and out in these > environments. Thanks. Sorry Chris to distracted you, you know you're loved! > :) > > On Jul 28, 2010, at 2:03 PM, vade wrote: > >> Community thoughts on these ideas? >> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/quartzcomposer-dev/adrian%40clayinteractive.co.uk > > This email sent to adr...@clayinteractive.co.uk
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com