I've got to second Toby's recommendations re virtual macros.
Virtual Macros could be great, but having to go back to the patch
creator to edit them is silly, and not showing visually that they are
virtual patches in the editor makes it very difficult to find/
understand them.
I see the copies-are-virtual-macros-by-default idea as being very
useful, and would alleviate a lot of troubles that QC beginners tend
to make (copy something a hundred times over, dutifully noodle them
up, and then get frustrated when one tiny thing has to change in all
of them). Virtual Macros aren't very obvious to the beginner because
they're hidden away only accessible via obscure menus that tend not to
get looked at. Is "Edit ..." really only available in the action menu
in the patch creator? How bonkers is that?
The editor could be more helpful in revealing what is virtual and
what's not. It's somewhat akin to the Finder's copy vs alias behaviour
- how about holding down cmd-alt to create a virtual copy of the
macro, and the resulting patch title would be in italics? Double-
clicking any virtual macro instantly opens the editor for the
original. The contextual menu would include a "Show original" option
for jumping to it.
Finally, it would be nice to have an option whereby some virtual
macros are _never_ stored in a separate .qtz file in a library
somewhere, and _only_ in the original qtz. This would probably have to
be on an individual basis, so I doubt a general preference would
suffice. In my work I frequently create a virtual macro that is
project-specific, and I have to name them with my client's name to
ensure they don't accidentally get used elsewhere, and hence cause an
error at commissioning because that qtz wasn't included as part of the
build. I'd much rather be able to keep my client's virtual macros away
from any kind of shared library altogether (regardless of whether it's
user or system level).
A quick list of my other most wanted UI improvements:
Pins: noodles can be pinned down so if they have to travel a long
distance you can tidy them up to keep them out the way of other things
Iterators: the tooltip inspectors show you every computed value
(within reasonable limits) instead of just the last value
Structures: the tooltip inspector is an interactive (and scrollable)
hierarchy. Perhaps only the top level is initially open but everything
below collapsed until you open each node if you want to.
Variables: yes, having to use noodles just to get a single top-level
value to hundreds of subpatches is bonkers. Spooky Send and Receive,
basically, but less crashprone. :-)
And instead of a pony, can I have a lorikeet instead?
Ade.
On 29 Apr 2010, at 02:07, li...@tobyz wrote:
Hello Chris (and congratulations!),
I'd like to see something within QC.app that allows you to just copy
a macro as another instance of that macro. Double click on any of
them, and you go in and edit them all. From my perspective, that
could even be the default, how qc works, and you could subsequently
think to break it away as a standalone macro if you need.
Having macros available across the system is nice and all, but
beyond having a number splitter preset to 0-1 and a few other
things, everything I use a virtual macro for is highly project
specific, ie. contained to one composition. Having to use a feature
that relies on an external filesystem, quitting and reloading QC.app
to pick up changes, that doesn't let me inspect the contents of the
macro... its just been designed backwards from how I find myself
using it.
Also, and in this I'm probably more alone, if you use virtual
patches held in the bundle of in a Cocoa+QCRenderer application, the
whole authoring system breaks and can only be fixed by judicious use
of sym-links.
I'd also like a pony. And for a thermo-nuclear device to be thrown
at QC's thinking about handling things in parallel (architecturally,
the iterator is just the tip of an iceberg; vvvv's spreads work so
efficiently because patches are coded to do things in parallel, and
the patch knows best). And for QC to run on iPhoneOS in some form.
Now where was the wish-list proper...
Toby
On 29 Apr 2010, at 01:37, Christopher Wright wrote:
Hi Toby, (long time no see :)
useability-wise, they are a barely supported kludge, however.
Can you be a bit more constructive on that? (I'm not calling you
out or anything -- I'm genuinely interested in some discussion on
things that are missing to make this feature more complete/useful).
It'd be handy to get some chatter on it with perspectives of users
"in the trenches" as it were, to know the largest/most-annoying
aspects :)
--
Christopher Wright
[email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected]
)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/adrian%40clayinteractive.co.uk
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com
This email sent to [email protected]
