OK, so I’ve been spending a couple of weeks working with Vuo. And I appreciate the efficiency that deciding exactly what should fire when, achieves. The cost, of course, is that during debugging a composition, you need to manage all that stuff yourself, or Re-run the composition when you change some values. Or hack in some periodic fires and then change out later if you don’t forget blah blah blah.
I find waiting for the Preview after Shift-Command-R window to come up to be like waiting for a compile ! Firing all these events is something I do hundreds of times per day. If you’ve ever used an audio editor, or video editor, it feels like you want to quickly jump back to the beginning of the track very, very fast. Like, hit SPACEBAR fast. *
And yes, I know spacebar is currently mapped to , but you could probably just remap the event unless the user clicks with mouse, or moves mouse in that time, etc. Oh, and a toolbar button would rock.
I know it’s tempting to want to give this functionality some nice command+blah solution. But this is a CORE idea of the app, and I think it needs a shortcut which is hierarchically appropriate. AKA
[There’s another discussion about augmenting Fetch Image with some built-in, on-by-default, Fire node, since surely it’s used 95% of the time to load an image on launch]
‘Why don’t you use the Command+T?’ shortcut? Good question. It only works if I’ve gone through the Fire event flow once before. Only for one node/port. And Command+T isn’t as slam-it-down-fast as spacebar.
Do you know how many years it took to convince Kosada that spacebar for panning the graph was worthwhile and that dozens if not hundreds of other apps use that paradigm, so maybe it’s useful even if it’s “modal” to some extent?
Still waiting for spacebar + command for zoom in and spacebar + command + for zoom out like dozens of other apps I’ve used.
I’d be happy with one of the other modifiers to me used. What’s the worst thing that can come of firing all fire at start nodes? Performance issues mainly I think? Control key hood be fine by me. Or dual assign the spacebar to pan and fire or let users assign a fire key in preferences. Team Vuo don’t seem keen to add many preferences to Vuo thoihhh. It has very few for a coding app.
Note, here’s been quite a few feature requests around the problematics of firing events during testing or updating shared values and mode unit values. Maybe search through FR for some of them.
Fire node on manual/user changes to any input value is one I made. I think it’s now included? I don’t use Vuo much these days but about to get back into it and see if I can ween myself off QC which I find much easier to conceptualise and be creative with as InStyle think in that language not so much in Vuo even though i do try from time to time.
@bodysoulspirit hmm, I didn’t see that one, thanks. That would help—but doesn’t necessarily help with the ‘first launch’ experience. For example, it’s not common to change some patches (like Fetch Image) etc that are usually wired up to a Fire on Start node, which then kick off a chain of events down the line.
That wouldn’t still help when your create protocol compositions where you usually don’t use fire on start, but rather Allow First Event connected to a time port (or it would need to re-fire those too).
But already when “automatically re-fire manually changed ports” is implemented, if I only have to refire when I add nodes, I won’t bother so much. Or relaunch and recompile won’t bother me really either when the composition window will relaunch at the same size and position (most work is to reposition it next to the editor window).
Yes the relocating composition runtime window is the most frustrating thing about relaunching composition (and the time delay second I guess).
Of course we can set the window start position and size but I do find that I move things around as I work, often having other apps for creating the artwork open at the same time.
Is there an existing FR for save all last window positions?
Thanks @jmcc, as always!
I missed that thread, so I’ll move over there. There are some differences, which I’ll add.
I’m proposing more than just Fire on Start, because there’s often other timing aspects which assume things all begin at once. For this matter, it might be nice if ‘Allow First Event’ was reset as well.
I’m proposing Space. To me, it really is that important
A nice toolbar button, to make it easy for new users to see that the function exists
! Firing all these events is something I do hundreds of times per day. If you’ve ever used an audio editor, or video editor, it feels like you want to quickly jump back to the beginning of the track 
very, very fast. Like, hit SPACEBAR fast. *
, but you could probably just remap the event unless the user clicks with mouse, or moves mouse in that time, etc. Oh, and a toolbar button would rock.
and that dozens if not hundreds of other apps use that paradigm, so maybe it’s useful even if it’s “modal” to some extent?