Currently use QC to make custom layers for Bonix TV - a vision mixing kind of application for OS X with a kind of QC stack of layers, each layer being a composition with published ports and some protocols for data types. Also generate sports graphics and twitter feeds and so on for video score boards at large sporting venues.
Spent a few years learning Quartz Composer as my way back into coding from a decade away doing design related work. Film, graphics, studied Architecture for a few years and got involved in publishing then film. Now moving into front side web development. Hope to get into app dev with Vuo and rapid app prototyping.
Hi Jaymie when I simply replicate a vuo file the same as yours (Make Color Layer patch only) I don't get the bug.
But when I'm working on sub compositions used in my own Vuo files I consistently have this problem. See screenshot. Attached a sub-composition for you to examine. Try creating an output called acceleration. Not possible for me, Vuo will always append the lowest number not used by another output port already. Even if I delete all the output ports first.
adeveloper Can you provide some examples of why that's needed and how that would work using a preference based system please? I'm not sure I understand the need or solution well enough to agree or disagree.
Without getting into a bike shed type argument about it, having strict datatypes as Vuo does makes it more functional than object oriented I think. I'm not sure if it has lazy evaluational the way QC does for example, another characteristic of a functional language. One of the problems though is the types aren't expansive enough as they stand (no lists of lists for e.g.) and users can only extend types by writing C code.
Any functional language thrives or dies on compositional expressiveness and the ability to create higher level functions from lower level functions. To me sub compositions are not really doing that yet in Vuo, it's too hard to manufacture higher level functions from lower level ones. With QC type Macros as an intermediary step for development I feel like it will engender more of that kind of coding. I agree having too many nodes on the canvas is a deterrent to major work in Vuo.
I'm not smart enough or skilled enough to know if Lambda's in Vuo could be implemented successfully or not. I'm just teaching myself Haskell after a 3 day training course for professional coders run by Lab61 in Australia — I was quickly out of my depth but am totally hooked on the concept of pure functional programming as the coding method of the future.
Create a sub-composition with some published ports
Erase one of the published ports (input or output)
Create a new published port with the same name and place as the erased port (input if erased one was input, output if erased port was output)
Result is the digit "2" appended to the port title.
Rename port to erase the "2" and it becomes a "3"
Have you found a workaround?:
It means that when reworking a sub composition you can break wires coming out of it in the parent compositions because it forces a port title change on you which, which obviously breaks the link to other nodes in the parent compositions. Forced to rewire them, and an annoying port name too.