Pretty sure I requested this about five years ago! Kineme made a tool to do this and many other things for QC and I and others used the right-click "Insert splitter" functionality A LOT. Vuo compositions tend to have less cables for any given task than QC compositions, but it's obviously still a time and frustration saver to implement this. Should be a trivial add like you say, Keith. (Note you could hack the Vuo XML code the same way we used to hack the QC file XML just for fun to manually do it, maybe even script it in a software editor to be automatic).

Mostly, in the use case where you'd have a bunch of noodles coming of an output port and you want to insert a patch between the port and all the noodles…say for example round a float type to an int type…the only only way to do it without rewire every receiving patch was to "insert splitter to the output port then wire the new patches to the output port and then to the splitter which would share then new code with the existing code.

keithlang True! But then again, you are de facto quantized in any digital application. I might have a strict definition of what a delay is (repetition of a previous event), but you can't delay anything that didn't exist in the first place at a place it isn't played back.

This means that if you in any application at a 30 Hz refresh rate delay something at for instance 0.95 seconds, it will visually play back after either 0.93 or 0.96 seconds.

From a UX perspective, a frame-independent presentation of a delay would certainly be neater, but I think you can still visually achieve the same results.

If the hypothetical action at 0.95 seconds were really really important to get right, there is also an option to subtract your delay from the source time for a duplicate node of what creates the control data. As far as I know, noise nodes in the same composition are for instance not random from each other, but will produce the same results given the same time/position input. This means you can visually achieve a delay-like effect with data that isn't present in the original flow.

jersmi yup, I think the enqueue node will enqueue channels of 512 samples each if i remember it right. I'm not sure if there exists a good solution for delaying audio yet either. I think the "easiest" approach would be to write the raw data to a data buffer of some sort, and then play it back from a set position in the buffer. Or make a feature request for audio delay :)