The Future of "Patch" Programming

Now there's an alley-oop, cwright, all yours! :~?

Many of us would like to see QC extended from a QC composition authoring and OpenGL pro-typing tool to a full functioning application IDE. Probably wont ever happen at Apple though :/ (guessing obviously as I have no inside info).

Shame, so much potential for a tool that would inspire new and seasoned programmers with a little more rounding out from it's specific use cases in the context of Cocoa/Xcode. Would be great if certain QC comps could be compiled into a native QC patches for example. To be write the QC framework just using QC tools.

Need's a lot more text and slick input handling/binding to make a really interesting App IDE though. The kinds of frameworks that are already in Cocoa like Quartz framework. NI has some nice RTF text tools which would be good as stock patches, hint hint AAPL.

I'd also like other parts of the OS to offer comprehensive QC support too, like Keynote in particular which teases but doesn't deliver. If Keynote had really tight QC integration (like ability to share global values and QC could receive UI Events etc) the combination of the two would make a Hypercard worthy of the 21st Century. In tandem, Keynote could provide the WYSIWYG/drag-drop style layout side of things while QC did all the computational/control logic/visual processing end. Could be a very powerful combination if the hard yards of getting them together could be sold to the powers that be.

See this thread for my ideas for using QC as a system wide 3D scene inspector palette for wrapping 3D in other applications with a bit of processing magic.

I can dig getting the QC comps into other programs easier quite a bit.

I think everyone realizes how great making graphics is this way, and I am sure Apple realizes this as well. They could really mix it up if they would take advantage of the simplicity more.

They have the assets, so why not offer a patch version of Xcode?

-Would it alienate more traditional programmers with "too easy/not flexible enough" of a time? -Any competitor (Say Google with Android) would attract many more developers if there was a easier IDE (Much easier in this case) -Perhaps the level of innovation is already above most, so they do not feel the need to push new things as hard as we would like

Just spit balling...

Can't wait for there to be a day when you need a program, and you can just enumerate the parameters by moving your hands and speaking.... Bam, a program is born.

There's a fairly large corpus of research into purely visual programming paradigms; I suggest checking out some of the literature. Basically, it's mostly impractical for wide-scale use. There are many aspects of development that do fit the directed graph model that QC uses, but the push/pull model often fails (most programming is oriented around pushes, and QC's purely pull). There's also a fairly large number of operations that aren't nicely representable in graph form -- sorting for example (discarding sorting networks, perhaps).

I really don't think speaking is useful for programming. speech interfaces are still quite raw, and speaking is a linear thing while programing (textual) is often non-linear. programming via graphs is also non-linear. Mapping the two for non-trivial cases is probably too difficult to be worth it.

I don't know that attracting developers is a significant problem for OS X, iOS, android, or WM7. The problem is attracting talented developers. That's a pretty much universal problem, and more abstractions don't always make for more talent (and often less).

In many ways, this kind of argument almost boils down to the "poor craftsman blames his tools" line of thought, where someone says "I'd make something great, if only there were better tools". Tools definitely help, but enterprising people have been making great things without them for thousands of years. Make something great that is clearly QC-domain only, and this topic might be worth revisiting.

thats funny we had a silicon valley talk on campus with some old computer people. one was this lady whom helped design the first lap-top in outer space or something. there where a couple questioned asked of her.

one was how did she feel being a computer engineer / programmer and being a women. that didn't bother her as linda lovelace the worlds first computer programer was a women. this is something i think more girls should know as the computer science department on my campus i think has a total of three girls.

i asked what type of programming she liked to do and she said the lowest level possible. i asked if she had ever used a visual high level programing language like quartz composer and she said in the 80's people started doing what was called icon o'graphic programming for databases and atm machines etc... she said big companies where able to develop applications very quickly with a higher level icon view of the code as opposed to the assembly languages she preferred to use.

i to thought that it would be a good idea to have a qc export to gl function code stub sort of thing as well. at least that way you could prototype out your app save the code then use that to port to other systems. to me that seems the first step. there are however applications that do this type of thing all ready for android, ios etc... http://radicalbreeze.com/

as per using patches for programming applications for the mac quartz is made for this. apple can not make it any easier if you ask me. as it is right now you can build an app entirely in qc and then just and drag and drop it onto your xib file in xcode and build your executable app. plus you can fully bind and or integrate your patches into most core frameworks making it the most versatile visual programming tool xcode has next to interface builder. its like if your trying to build apps without writing code this is pretty much possible right now in xcode. i would highly recommend learning obj-c though as it will help developing your own custom patches as well.

honestly seeing qc is dev tool i don't see apple anytime soon going ok we need to get this running on a windows box. i bet we will see qc on the iphone way before we will ever see it running on a windows machine but hey i could be wrong.

Quote:
In many ways, this kind of argument almost boils down to the "poor craftsman blames his tools" line of thought, where someone says "I'd make something great, if only there were better tools".

@chris thats a good way to put it.

i like to say "its not the tool but how you use that matters".

I enjoy that quote quite a bit

It will be interesting to see how it plays out.

I feel the easier it is, the more people will be able to use the tools. However, those with a more detailed understanding can enact more exact/specific commands.

I would love a patch interface for making a simple app to track bids on a item in my Art Show... However a major airline company may not use these "patches" to track all of the packages it is transporting.

So it may just boil down to the right tool for the job

that quote might have sounded maybe harsh. most of the time i'm wrong when trying to re-iterated something chris says. maybe he is more or less saying the old.

Quote:
if it isn't broken don't fix it"

meaning people have been using x-code for years with textual based code, why would apple change all that for all patches ? i don't know maybe that is what chris is saying ?

i like to say its not the tool but how you use it and or is it interesting.

i just say that all the time on other tech forums because people are always what is the best gear / tech to get etc... what synth is going to make me sound good etc... for a long time i used to be ok i need this piece of gear or that piece of gear or technology. so then you finally get that tool or what ever you need then you find you need another one etc.... at some point you have to say, i'm going to use the tools i have and try to the best i can do with those tools and learn them before i move to another piece of technology.

what your saying nails it though.

Quote:
it may just boil down to the right tool for the job

obviously a power tool may do the job faster but that doesn't mean a screw driver doesn't work.

dust wrote:
that quote might have sounded maybe harsh. most of the time i'm wrong when trying to re-iterated something chris says. maybe he is more or less saying the old.

Quote:
if it isn't broken don't fix it"

meaning people have been using x-code for years with textual based code, why would apple change all that for all patches ? i don't know maybe that is what chris is saying ?

Not quite. I'm saying that there are paradigms that are incompatible in [QC's] patch-based programming. It's not Turing Complete, concepts like recursion aren't there (meaning entire classes of algorithms aren't possible -- anything tree based, for example, which is pretty important). There aren't many wins for patch-based other than simplicity.

dust wrote:

Quote:
it may just boil down to the right tool for the job

obviously a power tool may do the job faster but that doesn't mean a screw driver doesn't work.

And even more importantly (and closer to what I was saying): There are tools that simply aren't useful for what you're doing. If you need to cook a chicken, a pocket watch isn't going to help. That doesn't mean chickens can't be cooked, or that watches are useless, they're just different classes of problems with different tools to accomplish them.

Let the above sink in for a moment: There are classes of algorithms that cannot be expressed with patches in QC's model. That means all problems that depend upon such algorithms cannot be usefully solved in QC's model. That means applications that aim to solve those classes of problems cannot be usefully created in QC's model.

That's entirely different from saying something's cumbersome to implement, or inconvenient. Lots of things are inconvenient in C, but very few things are impossible to express in it. QC has lots of things that are impossible to solve in it, and that's a pretty severe problem.

As you begin to develop non-trivial applications, it becomes clear that almost all development runs into one or more of these algorithms, and that's when using QC to build apps starts to just break down. Unlike C or C++ or Java, where things become uncomfortable, it just becomes impossible.

Hrm. My understanding is different classes of patching languages are or are not turing complete. PD, for example, claims to be turing complete:

http://lists.puredata.info/pipermail/pd-list/2006-09/042618.html

So I dont know if you can say all patching/dataflow languages are not turing complete.

edit: And actually, Chris brings up a great point. The main reason I switched from Max/MSP/Jitter to Quartz Composer was not that Jitter lacked for visualization/effects tools, (in fact, in many ways, Jitter is far superior to QC in that regard); but rather the fact that QC, inherently by design, concedes that Data-flow languages are not the end-all-be-all, and implicitly allows in its design an API for text based syntactical access to data-flow resources, namely the Obj-C interface of QCRenderer and friends.

This is why Quartz Composer is, in my opinion, a great tool. Embed-ability within the larger context of an Application. Handle logic in programmable text based languages. Handle data flow, video pipelines and the things that are best suited to flow based metaphors in a Data-flow system.

Strictly speaking, Quartz Composer has a lot of catching up to do in the realm of Data-flow languages (Pure Data, Max, and friends have it (in my opinion) beat on pure data-flow features and metaphors/integration and workflow (by miles), but the integration as an API into Obj-C is where QC trumps all. And its why I am sticking to it, issues, nuances, incompleteness and oddities all.

Turing complete or not, QC appears to me to be like a giant roll of duct tape for OS X graphics. You can lash together some HID input, file access, audio streams, network messaging, system calls... with all the goodness of Core Image, OpenGL and Core Video, and you can make things that fly across your vision and melt audience faces.

It is easy to be mesmerized by the possibilities of this tool, but I suspect that it's place in the Apple universe is going to continue to be for prototyping and exploring -- whether from an artistic or engineering perspective. Even as a plugin development tool for commercial applications such as FC, CS, iMovie it may be most relevant for quick prototyping. When the exciting pixel pushing is embedded either in the Apple api's or an OpenGL shader, it is straightforward to use xcode to bake it into a more standard language. And add the kinds of logic that are awkward to impossible in QC itself.

I say this fondly; we all know that duct tape is one of the prime forces that hold the universe together. It is indispensable, but not omnipotent.

vade wrote:
Hrm. My understanding is different classes of patching languages are or are not turing complete. PD, for example, claims to be turing complete:

http://lists.puredata.info/pipermail/pd-list/2006-09/042618.html

So I dont know if you can say all patching/dataflow languages are not turing complete.

I was trying to be careful and not disqualify all visual languages -- QC in particular is not turing complete, and many metaphors are clunky or impossible in it. Other environments have grappled with similar problems, and some have overcome them.

You have my complete agreement with data-flow oriented used (and using it as a pipeline inside an application that isn't purely qc-created), but sadly numbers don't say that's nearly as common as we'd all like. In my comments above, I was largely trying to dissuade people from clamoring to have QC be "the environment" for application development, because that's silly. It's a great aspiration, but there's a lot to be done before it can come anywhere close. I'm not trying to drive people away from QC, just from trying to use it as a universal hammer. :)

Well, we make commercial plugins driven by QC at http://noiseindustries.com. I wont say QC is not lacking features, and isn't full of duct tape itself, but when you know its strengths and weaknesses, it can, I think, be a potent tool.

(edit, urg, Kineme new post/reply thing makes following threads difficult, this is in response to @harrisonpault

"Make something great that is clearly QC-domain only, and this topic might be worth revisiting."

Red-herring.

Who cares?

The thought of this is specious... what about Xcode, OS X, heck even Apple? Show me something great that could be done only by using those. I cannot think of a single thing, unless we're going to tag "and it was done on an Apple", or "and it made use of this Apple tech", as qualifying statements on the "something great".

More relevant: "make something great that wouldn't have been made without 'patch' programming, because of time, cost, or some mix of the two". It is somewhat meaningless if something can be done without QC, or without graph programming; an affirmative answer doesn't negate positive benefits.

The importance of Turing completeness is more philosophical... I'm not downing on it, and I think it's extremely conceptually appealing, I just don't think it matters at all to most people.

If the toolset exists to setup a graph, define the traversal of the graph, etc., it really doesn't matter if it's Turing complete; one just makes a patch that can then interact with the rest of the stuff in the graph.

Also, I think the recursion argument is a bit of a hollow argument as well. It could be argued that feedback is a type of recursion; but in the greater sense that you mean, it's not as if it's strictly impossible to represent (I know you're not necessarily suggesting it is impossible to represent...just saying it's not in QC now- which is like going "I didn't teach my kid to read... damn that kid, he can't read". Sorta unfair.)

In a larger sense, I agree with your qualms and concerns.

On the programming/layman thing that's a subtext of the starter post, I can't find quite the right words for it, but basically, when a technology is well developed (maybe even valid) we can then expect to see it democratized. Programming isn't there yet - not graph ("patch") programming, but programming itself.

I can go into a convenient store and buy some crayons. Not a nascent technology at all, and it's totally democratized. In the 70's-2000's recording became "democratized" to a large extent. Photo editing, layout, still and motion photography, etc., have become democratized. Sure, it doesn't mean that what people produce is any better, but this is largely irrelevant from the perspective of a business that wishes to make money by selling said tool, or people who wish to achieve a goal in a more time and cost effective way.

In a culture, there are trendsetters and followers. Apple computers have traditionally appealed to those in design, art, production, etc., and in that, have also appealed to many trendsetters. That slice of the pie may seem small, and unimportant. However, it's not a slice of a pie at all. It's the mortar the company is built on.

There used to be this thing called the walkman... and now there's not. Apple should take a big hint. Toys come and go. I haven't touched my hotwheels cars in years. Granted, every so often I do actually see Sony stores, and like one or two people in them, but they're usually the sales people. How do those places stay open anyway?

If a time comes when Apple makes stuff so absolutely simpy and vapid that it is totally distasteful to anyone who wants to do something cutting edge, that's exactly what the Apple stores are going to look like too. It won't be an immediate thing... people will just feel like a-holes for wasting their money on something overpriced and underpowered that doesn't even mitigate those potential issues by having good software loaded on it. I'm not saying this is the current scenario, just that every so often with "big" Apple changes, it sure seems to be going that way. I don't think people at Apple have a very good understanding about why Apple actually appeals to the core demographic (and by core demographic, I do not mean people buying frigging iPhone 4's that will turn around and buy whatever the next cool toy is. That kind of consumer is fickle.)

gtoledo3 wrote:
"Make something great that is clearly QC-domain only, and this topic might be worth revisiting."

Red-herring.

Who cares?

The thought of this is specious... what about Xcode, OS X, heck even Apple? Show me something great that could be done only by using those. I cannot think of a single thing, unless we're going to tag "and it was done on an Apple", or "and it made use of this Apple tech", as qualifying statements on the "something great".

great is definitely subjective. So let's play a game. I have a web browser open essentially 100% of the time (be it firefox or safari). Can you write an entire web browser in a patch language? You probably could. Would it save you time, or make it more robust? presently, no. Parts could be trivial, but others would be crazy.

I have Mail open at least 95% of the time. Can you write an entire Mail client in a patch language? Certainly. Why doesn't anyone?

I have Terminal.app open 100% of the time. Same rules apply.

I have iStats Menus running constantly. Same rules.

I have the XNU kernel (3 flavors!) running continually. I have all the system services. I have firmware on my harddrive servicing every request. I have "firmware" (actually software, but WD's crazy) on my NAS running all the time, my router's OS (via linksys). My home stereo/dvd/bluray player thing has an OS. My Wii does too. So does my projector (limited as it may be).

My microwave, my washing machine, my stove, my refrigerator, and my dish washer all have firmwares too.

Oh, and my digital cameras, and my iPods.

Those aren't necessarily great. They may not even be useful (for anything other than demonstrating that holy crap I have a lot of crap...). But they're all commodity products. If the producer could save a penny per unit, they'd do it. Would patch programming help them do that? some pieces, definitely. entire stacks? no way.

For a bit more context: My "entirely QC domain" bit was in reply to "Make a patch version of Xcode!". There's absolutely no reason to make such a thing at this point in time. What does it even mean? What's the learning curve? What are the benefits of writing applications in it vs. more traditional methods?

gtoledo3 wrote:
More relevant: "make something great that wouldn't have been made without 'patch' programming, because of time, cost, or some mix of the two". It is somewhat meaningless if something can be done without QC, or without graph programming; an affirmative answer doesn't negate positive benefits.

And we enter a long-running game you and I have been playing :) My position is that graph-based programming is getting over-hyped in this thread. @vade (#LoL #wtftwitterofftwitter) has essentially nailed it: QC's great for data flow problems, but most logic is better handled elsewhere. Are there other huge benefits? If so, nobody out of all the people who work on GTK, KDE, Gnome, PD, Max, Processing, Apple, Google, the entire body of University researchers into "the future of computing", and no body on this forum has found any of them. That's pretty damning. That's like saying that zero studies out of all medical literature links high cholesterol to heart disease but many link heart disease to high blood sugar, and then continuing to fight a crusade against cholesterol and saturated fats. Opinions are getting too hopped up with no backing data, or too hopped up in spite of ambiguous-at-best data.

gtoledo3 wrote:
The importance of Turing completeness is more philosophical... I'm not downing on it, and I think it's extremely conceptually appealing, I just don't think it matters at all to most people.

so where are the cool products?

gtoledo3 wrote:
If the toolset exists to setup a graph, define the traversal of the graph, etc., it really doesn't matter if it's Turing complete; one just makes a patch that can then interact with the rest of the stuff in the graph.

Totally true, but also meaningless. environments that do what you say have existed for decades. more than 20 years. I've seen awesome audio processing graphs using this technology. I've seen maybe 4 applications that benefited from it to a large degree. Turing complete or not, patching is terribly niche, or it's so awesome no one knows about it?

gtoledo3 wrote:
Also, I think the recursion argument is a bit of a hollow argument as well. It could be argued that feedback is a type of recursion; but in the greater sense that you mean, it's not as if it's strictly impossible to represent (I know you're not necessarily suggesting it is impossible to represent...just saying it's not in QC now- which is like going "I didn't teach my kid to read... damn that kid, he can't read". Sorta unfair.)

see above. Other patch languages have probably addressed this, but in QC saying feedback == recursion is perhaps technically true, but worthless. I can search a tree of 4 billion elements with just 32 checks using recursion. in QC running 32 passes mean 32 frames = half a second just to pick out an element? I guess an iterator could be used to hide it, but it's still silly.

gtoledo3 wrote:
On the programming/layman thing that's a subtext of the starter post, I can't find quite the right words for it, but basically, when a technology is well developed (maybe even valid) we can then expect to see it democratized. Programming isn't there yet - not graph ("patch") programming, but programming itself.

I guess I take a slightly different view: the barrier to entry to make a new CPU or a cell phone or an ipod or a harddrive or a graphics card or a bicycle is extremely high. The barrier to entry to invent a programming language is not (this is done all the time for research purposes, and there are toolkits like LLVM that make it even easier). The barrier to entry to invent a patch-based environment is also not high (I mean, QC and PixelShox before it were written largely by 1 guy. lots more have touched QC since then, including myself, but the core thing was a 1 man job).

So, the barrier's low (only risk is time, not financial/VC), and everyone's saying the reward is high (patch xcode! patch applications!)... why isn't this a financial success? Why aren't psychics winning the lottery?

sorry for not replying to the other stuff -- there are some other bits that I may get to later. I believe that we agree on premise, but we have different viewpoints on the problem. truth probably lies somewhere in the middle.

The future of patch programming ?; well I can definitely think of a Visio type diagramming application to Cocoa code module QC like approach working, the thing with QC is that it is very patch dependent from start to finish.

It's great for what one can get it to do well and it does some other things rather ungainly and unreliably, but if you accept to work within the limits of what it can process, it makes for a great graphics development environment, most definitely capable of doing more than VJing visualizations alone [which it does a pretty stand up job of].

Data Flow wise there are some really effective alternatives where QC runs a very poor second. QC just does what QC does. For myself, I'm still figuring our just what QC can also do. It's great for drafting prototypes with, up to a point.

I still find I fall to using pen and paper and code print outs from time to time.

I also find xCode to be pretty modular and user friendly already once the full document set is installed.

I do think that some form of join the dots and noodling approach could track the diagramming used in doing a DFD for an application

Quote:
You have my complete agreement with data-flow oriented used (and using it as a pipeline inside an application that isn't purely qc-created), but sadly numbers don't say that's nearly as common as we'd all like. In my comments above, I was largely trying to dissuade people from clamoring to have QC be "the environment" for application development, because that's silly. It's a great aspiration, but there's a lot to be done before it can come anywhere close. I'm not trying to drive people away from QC, just from trying to use it as a universal hammer. :)

I think, part of the issue with QC not being used as often as people might expect, is really because of developer education/familiarity. Quartz Composer has a sort of odd image and place in the Apple API family tree, and due it its patching approach, I think can be alien and off putting to a lot of developers who would benefit most from it; those just with little graphics programming experience, who want to add some shine to their app. Learning the nuances of Core Animation, Core Image and, dear god, OpenGL, compared to making a simple composition? Yet, somehow, I think those people tend to (try) go down that path, rather than use QC, because QC is not always an obvious solution.

Basically I think (sadly) that the demographic for usage itself, its pretty odd and small.

Quote:
why isn't this a financial success? Why aren't psychics winning the lottery?"

It is for me, and many projects wouldn't have come to fruition or have been considered to start with, had there not been an ability to setup graphs quickly.

Is there a need to work with pieces of code as separate "pieces" or can it be an all in one? I think the answer to both is "yes", and that they aren't mutually exclusive. Validity of one approach doesn't take away from validity of the other.

I personally enjoy having the ability to hook a preamp to a compressor to an eq, or to be able to unplug the stuff, and chain it up as preamp to eq to compressor. If I was able to wave a magic wand and have two eq's appear, I'd be thrilled. This doesn't necessarily have to be expressed as boxes and noodles in audio software, because there's already the paradigm of the mixing console, but what's happening is identical. A channel strip is essentially like a chain of QC patches.

If I had to open up the box, unsolder stuff, shift it around, and solder, every time I wanted to shift the order, it would really suck. Pretty soon, one would start going "how can I make this modular"?

I think the demographic may be small, because the right steps haven't been taken, and maybe it's a damn nerd factory in Cupertino. In past lives, I've been in charge of producing marketing materials for accounts with budgets of hundreds of millions of dollars, and we spent much of it on print materials. I am certain that if the department had some kind of templates that would allow to make a basic interactive kind of representation of typical print materials, money would shift to being spent on that because it's modern and "cutting edge". Granted, I do recognize that my argument is very "build it and they will come", and also betrays my feeling that even more abstraction would lead to a larger audience. I don't see QC-Minutia Programmer Wet Dream version as being a really big winner. I see QC-Motion Photoshop as a big winner.

Here's my humble point of view. Before switching to mac, I had never dreamed of being able to program. Tried the usual books on c or whatever to no avail.. I'm an artist, you see, as in went to art school and majored in figurative drawing. I can't think in code. But I find myself being able to think in Quartz Composer. I have two programs on my desktop. A small pixel art editor and a generative music thing in the vein of Bloom on the iPhone.

The point is, there is no manual for QC. Would I release these programs on the app store?Heck no. Do they do exactly what I need them to do? You bet. And I made them, you see? You have no idea how empowering this feels for someone like me, who is used to pencil and paper. It's an entirely new creative world to explore and has opened so many possibilities. Imagine if we could use QC to send small programs to the iPhone and iPad.

I'm not entirely sure the people at Apple know what some of us use this for. I am no vj, I produce mostly static images. There is no built in patch to export static images like the one in the developer examples, and that only does .png by default...png! You see what I mean? The audio patch has a stereo setting that doesn't even work! Why would anyone release it in that state? And think of all the stuff that is only possible because someone else made a patch for it.

I love QC. I get things done in it and I wish I could make more music or Audio Units in it as well. I have sold images made entirely in QC. But I don't understand why there is no patch reference or manual for noobs. Why is it hidden? Children could learn in QC, if I was able to. You could use it in schools. You could do so much with it. It's like Automator, it's genius! So easy, so fast, so logical, I can make a program in 1 minute with no plan that transforms a batch of images to a different format. It's such a big deal! But do you realise how big of a deal it is?

Oh, I know exactly how you feel. Visual environments like QC / Max is really what got me started taking "programming" seriously. Empowering indeed.

"new post/reply thing… "

You can set for threaded or flat and for full and collapsed just under OP of topic. Yucky UI (I've been meaning to make some cleaner looking buttons to send to Kineme ;-]) but that's how you return to your normal programming.

I kind of agree with your last sentences, George. From an engineers POV cwight and Vade are spot on. Yet I think they forget what it's like to hit a technological barrier and say, 'no I don't have the time or left-brain resource to learn Obj-C to extend this easy tool I like using'.

As vade has previously said (and I've previously quoted ;-] ) text-based languages bring with them greater abstraction and therefore greater problem solving power. Add to that the pull nature of graphs that cwright spoke to and there is no argument where a programmer is going invest her time: in the tool that suits the task while staying compatible with the other tools required.

There is a small class of users, to paraphrase Vade from another thread, who want to dick around with 3D and so on. (People wanting to dick around with numbers in VisiCalc lead to a pretty big industry) We're called multimedia artists/developers amongst other things. If we could code Obj-C for a living no doubt we'd be doing it and earning good money, but we're too interested in other right-brain stuff (to use what's maybe a deteriorating meme) like art and design to be bothered with the effort and probably wouldn't be so great at serious OSX programming anyway — that side of my brain seems to be in permeant decline, I was a best in year maths and comp-sci student around 14yo but now I'm a newb!

Big generalisations there (and I know you have learnt some Cocoa/Obj-C in recent times George but I include you in this group of artist-first-coder-second users).

It's the people for whom patch programming is a joy (mostly) and learning bash/NIB/Xcode is a painful (mostly) unintuitive learning curve. For such users a combination of something like Keynote (but more extensible via scripting) and some kind of patch programming suite would make a great platform/IDE for the kinds of content George mentioned. Not Applications!! widgets inside presentations, special effects that didn't come (cum) in the can and can be integrated into a presentation or movie style flier and so on (i think the web has cornered much of this space). I appreciated this probably seems marginal and trivial to genuine OSX/iOS programmers in the way a scooter or tricycle seems trivial and useless to a champion mountain bike rider. Consider this cwright, for little people, a scooter or trike is still magic (read: very useful and desirable).

So much good meat in this conversation. I think, perhaps I can offer a somewhat unique perspective on this discussion.

I use QC in an enterprise environment, for a large retailer in the United States ( with very little investigation you could probably figure it out). One day as I was walking through the building that I work in I noticed that every employee would manually write their productivity numbers on a white board on their repair line. I realized that not only was this a waste of their time, it could be automated and turned into a central point of discussion about the business (helping drive their metrics, reporting company news, even acting as a guide in an evacuation scenario). So within a weeks time I quickly fleshed out a prototype of a digital signage application that would pull data from many different disparate systems to create a live infographic. Could this have been done in any other programming environment? Most definitely. But QC allowed me to rapidly build something that most typical programmers would ( we have quite a few in the building ) not have thought of. It allows for a much lower barrier of entry to a world that people like myself can dream very quickly in. It also allows me to communicate ideas and metrics to people that normally just don't care in a very effective way. So much so that not only do we have over 30 displays in the building, with another 20 slated for deployment, and several others for our Corporate office.

So I look at QC sort of like Excel. Excel can just be a spreadsheet program. Every day people can use it. But if you spend a little time with it, you can create something that almost seems to grow outside of it's original intent. It's organic, and powerful, flexible in some ways, and a cruel mistress in others (Cwright can attest to my head scratching about memory leaks).

I think instead of focusing on what QC isn't, we should focus on what it is, and the creative ways it can be bent. I think the limitations or strangeness of QC could in fact be a great creative driving force in application creation.

superflea wrote:
Here's my humble point of view. Before switching to mac, I had never dreamed of being able to program. Tried the usual books on c or whatever to no avail.. I'm an artist, you see, as in went to art school and majored in figurative drawing. I can't think in code. But I find myself being able to think in Quartz Composer. I have two programs on my desktop. A small pixel art editor and a generative music thing in the vein of Bloom on the iPhone.

I've really, really, enjoyed your post.

Quote:
The point is, there is no manual for QC.

There isn't a manual, but there really are a bunch of "learning quartz" papers located at Apple's website. Just a head's up on that, if you've never seen them. They are seemingly simplistic, but I think that their info is usually well represented.

Quote:
Children could learn in QC, if I was able to. You could use it in schools. You could do so much with it. It's like Automator, it's genius! So easy, so fast, so logical, I can make a program in 1 minute with no plan that transforms a batch of images to a different format. It's such a big deal! But do you realise how big of a deal it is?

Here's a novella:

I don't think people at Apple have a clue what a big deal it is. At least it's a big deal to me...

I've been a musician/songwriter, and visual artist for years. At the same time, I've always been technology and computer oriented and used to love to do some playful hacking - and when I say "hacking" it was just changing programs in school computer lab to do little jokes that I thought were funny at age 6 or 7, like saying "you suck, nerd" when you scored too well on typing tests. Silly stuff, but it did set a tone for always poking around. Also, my uncle has been a lifetime programmer, while my father was an artist and designer.

Anyway, this is where I'm going with it...

When I was like, 12, I was going out and playing side guitar in the studio and on stage with tons of at least moderately well known artists, if you listened to 60's/70's rock back in the day. I've played with Iron Butterfly, Spencer Davis Group, Rare Earth, Sugarloaf, blah blah...

I had a stint learning audio engineering and production from Steve Gursky (http://www.allmusic.com/artist/steve-gursky-p82955/credits ... this is super incomplete, I don't even see him listed for producing the Andy Gibb record, or his BeeGees stuff, or Ringo, etc.)

Anyway, that guy was total genius, and was one of the best experiences of my life. He had learned from Tom Dowd (http://en.wikipedia.org/wiki/Tom_Dowd ... look at the part about the Manhattan Project if you want to be tripped out. That was REAL.), another amazing producer engineer, and being able to go through that whole "apprentice" type of thing, and learn tons of stuff that I've never read in an audio engineering/production book EVER was amazing. It was like learning from a genius that had learned from a guy that was almost god-like to me (Tom Dowd). Suffice it to say, I feel that I do have a good grasp of signal flow, regardless of who I learned from really. I was doing my own recording and engineering for years before that experience.

Enter super personal zone:

At some point it was very obvious my grandmother had very bad Alzheimer's disease, and my father was physically impaired, so I really had to pick up the slack. I moved back to my home town, and took care of my grandmother. I took up a job in a print shop; I had been the office manager for a ship supply company directly before this (and still work with that company on occasion actually), but it was in another city, and having to move back to my home town sort of made that ineffective.

After awhile, the print shop got bought up by a national company; in the past, I had run my family ship supply business for a good long time, and had scored some pretty heavy contracts with international conglomerates. It became obvious that I should be the contact person for the rollout of their super-duper print tracking software, for their first national contract. My job turned into doing bug testing for the software, going to client's desks to vet problems (I was a 3rd party, who had my own office inside of various architecture/engineering firms), getting together marketing materials, doing document conformance and updates, document distributions, etc. Super artsy stuff!

All while doing this, I was playing in two bands, and doing my own solo music.

Every day in my job, I was using InDesign, Illustrator, Photoshop, and about every Autodesk product ever made.

One day, I wanted to add in a rising sun to a music video thing I was making. I didn't have Adobe Creative Suite loaded on my personal machine. I felt weird about going back to my office and loading my company's version on my machine, as they were particularly anal about everything and anything. I felt too cheap to go out and buy it! Or rather, I just felt like "I use this everyday, it's not that damn special, something else must do this".

Now, at the time, I was experimenting with writing Java applets that would take video stream, and do image processing effects. I'd written dozens, if not hundreds of these by this time. Very simple - cam feed, effect, render. I was using really early Processing versions too. I had also used Pixelshox in the past, but didn't really think it was anything special - not being able to have the editor and viewer open at the same time was a small aesthetic choice that totally turned me off, and pretty much totally neglect it.

So, I realized "ohhh, I can just do this with that Quartz Composer thing". It finished within minutes, and was totally satisfied in every way. I thought "geez, I really like this thing!". Weirdly, I believe I ran into cwright's blog while searching for something completely different around the same time, and I became aware of what he and smokris had been up to, and they totally seemed like birds of a feather.

I think I probably whined about something I didn't like about QC to cwright, just in a chatty way, and he was like "dude, I can totally do that, and think you're right". (paraphrasing). I had (and continue to have) tons of really enjoyable back and forths with cwright, and later smokris, have had nice collaborations on projects both together, and with other parties.

It's funny - I can think about having back and forths about cwright about "what would the most Apple-like way be to do this?". It's totally awesome that now he's working AT apple. I think of the level of thought and scrutiny that went into various things...it pleases greatly, especially in retrospect!

At some point, I just started having idea after idea of stuff that could be done in QC that people weren't doing, and had, and still have, a really strong drive to show exactly what CAN be done with the tech.

I don't usually go down this conversational route in public, but at some point, right before a Thanksgiving, my father slipped, fell (he was in his early 60's, and really not in horrible health, besides some physical impairment related to a minor accident. He could walk, it just hurt badly for him after some amount of time.) Anyway, what was simple turned really bad and he ended up passing away the next April after months in the hospital. I guess he actually died of MRSA, which is real mind blower- a friggin' staph infection. Anyway...

While I was going through all of this, I was plowing away at QC, and got some really interesting contacts to do some gigs; my constant posting of video clips and code probably didn't hurt.

Some fell through, but then I got into some very awesome opportunities. I soon found myself doing some interactive graphics for the Beastie Boys (I rarely talk about this kind of stuff on forum, but I feel it's pertinent to my larger point). To have gone through all of the stuff I had gone through, all of the different career paths, the hardships, and to find myself working with what was probably, out of ALL modern bands, one that my father respected the most, and that we both listened to together many a time was not only an amazing opportunity, but just... special in so many ways. The fact that they are truly very, very, good people made it even more special. Those men are very thoughtful, and just decent people. I worked my butt off! (These are pretty emotional appeals - this is not in defense of QC, just giving context).

This led to a variety of other, what are to me, very major gigs/events (j. mayer, deadmau5, grammies, and others...). Since then, I have seen and/or been part of very major productions where QC is absolutely integral. To me, this isn't a trivial thing. When an entire stadium of people come to see an event, and QC is not only generating, but processing, rendering, loading other external data or sources, etc., it's not trivial. Niche, maybe, but I point this out for a variety of reasons:

-Substantial apps can be made using QC as the main driving force.

-Substantial apps can be made by taking advantage of QC as part of the puzzle.

-GUI can be done, people just don't generally take time time to do this.

-In a production environment where things have to happen quickly, having pre-established chunks of working code, and editing stuff on the fly, is still often slower than having working "patches" that can be strung together. Sure, I may have the code mocked up for a multiplexer, but I really don't want to have to integrate it into a Xcode project, and go through all of the steps of updating my project sometimes. (random example here... maybe not the best).

-Code syntax very often describes things that can be drawn out on a napkin. We may have to employ Venn diagrams, or boxes with a bunch of numbers with no order defined (like an un-ordered list), but just because that stuff isn't in QC, doesn't meant that one can't Google for 3 minutes and usually find a pretty solid visual representation of almost any computing principle. It more likely indicates a general lack of direction or vision, though I hesitate to say that, because it's only speculation - also, I'm not referring to cwright.

I totally "get" why Apple seems so aimless with QC. They don't really have anyone internally who has used it for projects that would lead it into the future. I wonder if internal departments even implement it correctly sometimes considering weird crashes that happens every so often.

Pierre is gone, so the guy who made it isn't there. Again, no veiled remark at cwright- I have the highest respect, and I am so thankful to know him; I would be it's one of the best hires Apple has made in their history; maybe not really awesome for QC though. What I mean is that, sometimes ideas need to be bounced around, and a team needs to consist of the right people to make something happen. It can't be all on one person's shoulders, or even a few, it's it's not the right mix on the team.

If we look at what Cwright put out for QC while not at Apple, vs. what Lion is looking like... it saddens me. (not crying, it's just wasted opportunity, in my opinion.)

In synopsis -musician and artist, with some moderate programming skills, and an extremely advanced concept of signal flow, morphed into a much stronger programming ability that I wouldn't have ever gotten into without QC.

Maybe I'm really skewed, but something like QC, which democratizes so many activities feels like a definite news story. It's language, "programmery" instead of something more like In Design, but for generative graphics signal flow. It's weird to see stuff like the iLife package from some months ago pushed so heavily, when something like QC exits.

mattgolsen wrote:

I think instead of focusing on what QC isn't, we should focus on what it is, and the creative ways it can be bent. I think the limitations or strangeness of QC could in fact be a great creative driving force in application creation.

I think you've summed up just what makes QC so compelling to so many of us in so many different ways. Like the Excel to QC analogy :-) .

gtoledo wrote:

"It's weird to see stuff like the iLife package from some months ago pushed so heavily, when something like QC exits."

Freudian slip? I guess you meant "exists", but my deep fear is that the giant ship of Apple will allow QC to "exit". As cwright says, it was essentially a one-man creation. Does it's percolation within Apple into more mainstream applications such as Keynote, Photobooth, Final Cut, Imovie, Itunes (and the PR of video walls at WWDC's) give it the legs to keep standing?

This concern is amplified when things happen like the qtz developer list going dark for weeks on end: how much management attention does a little niche patch language get? And, how likely that it could end up as collateral damage in bigger wars such as iOS vs Android; DirectX vs OpenGL?

harrisonpault wrote:
gtoledo wrote:

"It's weird to see stuff like the iLife package from some months ago pushed so heavily, when something like QC exits."

Freudian slip? I guess you meant "exists",

Yes! Exists...

... and I also meant to type "bet" that cwright has been one of Apple's best hires. Whoops.

cybero wrote:
Like the Excel to QC analogy :-) .

I liked the Excel analogy too and kind of what I was getting at when I said 'People wanting to dick around with numbers in VisiCalc [preceded] a pretty big industry' (Excel based 'apps' for data processing)*.

Excel is everywhere and as Matt said often goes beyond 'what it's designed for'. How many times do I read somebody say 'that's not what [app XYZ] is designed for', usually in ignorance of what it actually can do with some persuasion.

With computing constantly growing in complexity in terms of what's within reach, easier ways to do otherwise very complex things are King (or magic as sjobs calls it). That's why nodal systems are loved by visual-bias creative types as generative systems. (Grasshopper, Max, QC, Conduit, Shake(RIP)).

In order for QC to have extended reach beyond it's core competency of video plumbing, it needs better integration into some other Apple applications before it needs to become a fully fledged IDE (as cwright keeps attesting that's problematic).

* It was kind of a delayed reply to something Vade said in another thread about my naive ideas for extending 3D object/scene/presentation system wide in OS X Apps possibly using QC as a wrapper framework to offer plugin stylings (via QC comps) that can be heavily customised with input sliders.

vade wrote:
I think, part of the issue with QC not being used as often as people might expect, is really because of developer education/familiarity.

I used to agree, but I think I've outgrown the "The Solution is Better Education" philosophy. There are a number of things people are "educated" about that they fail to do (for example, everyone knows they should floss. precious few actually do. everyone knows extreme obesity is bad. yet that doesn't stop them.)

The "education" for IOSurfaceRef is almost entirely absent. The "education" for GCD exists, but is perhaps a bit terse (less fleshed out than QC's documentation is, and with fewer places like kineme.net to extoll the virtues of it). Yet I'm pretty sure there are more apps that use GCD than there are QC. I'm not so sure that holds for IOSurface, because it solves a rather niche problem. But those that need that problem solved all manage to come across IOSurface in spite of the fact that there's no documentation.

Wanted to express my respect and appreciation here for this community and all that is being discussed. Testify, as it were.

I operate in the visual arts / video art / performance world. MFA in painting, no programming background. From my perspective, at the risk of stating the obvious, the sea change introduced with QC, Jitter, Processing, et al., is clear: video in real time. In my world, tools not supporting these exciting possibilities are getting shelved. I've made a lot of work with After Effects and Final Cut. Now After Effects, Motion, Flash and to some degree Final Cut are all feeling obsolete. How does Apple frame this new frontier? Does Apple see it only as a small frame around a small groups of users? Is there a bridge to iOS? What's in it for Apple?

Though Quartz Composer has its limits, I see it as a tool that represents the thrust towards new interactive methods and practices, for the little guy. Quartz Composer performs. My work has never looked better. The doors I am opening with real time performance / interaction are getting more interesting every day. It's a very exciting phenomenon and I feel like I'm just getting started.

Quote:

It's a very exciting phenomenon and I feel like I'm just getting started.