Hi, I'm interested in this thread about large-scale QC projects. I'm fairly new to Quartz Composer, cocoa programming and javascript, but am embarking on a project that would ultimately be a pretty complicated game-like program with OSC inputs and outputs for communication with audio hardware. As I'm currently conceiving it, it would involve a lot of array manipulation, and I'm wondering whether it would be better to program that in javascript or to use QCPlugIns (thinking that maybe QCPlugIns would perform better?)
Adrian, are your arrays being handled all with standard QC patches, or are you using javascripts or QCPlugIns to manipulate them? But generally I'm just interested in how people are programming large projects in QC. Is it all running on a single machine, or is the work divided among machines? I'd also like to know more about how the top level JS patch that Adrian describes works... best, Phil On Wed, Dec 8, 2010 at 9:18 AM, Alex Drinkwater <[email protected]>wrote: > This is fascinating... I wasn't aware that anyone was using QC for such > large-scale projects. An eye-opener. > > a|x > > I'm certain there have been a few. :) -GT > > > On 8 Dec 2010, at 12:55, Adrian Ward wrote: > > > I'm not sure QC could ever fully satisfy strict MVC design requirements due > to the inherent nature of it (execution is driven by consumer/rendering > patches, for a start), so I think the Controller/Viewer blur is a common > difficulty that may be inevitable. > > That said, I'm convinced MVC can certainly help structure big Quartz > Composer projects. I don't consider there to be one perfect methodology, and > we've spent years experimenting with different approaches. > > Currently in our projects we tend to have lots of discrete 'scenes' that > > are either shown or not shown. We tend to encapsulate those as separate QTZ > files (which helps the team to work on them concurrently) and then have a > top-level QTZ with an all-in-one controller JS patch that is responsible for > logic and storyboard flow, triggering those scenes, etc. Data is loaded and > processed by a separate section (again, usually in an external QTZ) and > currently I'm favouring bundling all data, settings and values in a single > Structure that gets passed along to whatever needs it, like a poor-man's > global object. > > There are downsides to this of course. For example, our recent installation > at Imperial War Museum in London (did I mention we have a big QC powered > exhibit in the new Lord Ashcroft Gallery there?) passes about 4000-6000 > values and objects (even images) in a single nested Structure object. Kind > of mad but it works efficiently and massively reduced our noodle usage. So > yes, it got difficult keeping track of what was *actually in* that > Structure, especially as it's a royal pain to inspect them at runtime, but > it made it very easy to separate model, view and controller into individual > parts. > > Best, > > > A. > > > > > On 8 Dec 2010, at 12:20, Alastair Leith wrote: > > "Also consider > > > > > that this technique could help encourage a MVC paradigm > within Quartz Composer." > > It's apt that you mention that^ because MVC is *exactly* the reason I made > this JS patch suggestion. Currently I'm trying to model a prototype a MVC > set-up in a QC comp or even perhaps 2 or 3 comps (one for each part). (Happy > to share it when I get somewhere I'm modelling that Simon musical > button game for a case study). In QC it's a special challenge to do this as > it's a functional environment with no resources specifically devoted to MVC > like *Cocoa* has. > > Say one has 3 JavaScript patches for each of *Model*, *Controller* and * > Viewer*, does one pass messages between the JS patches with codified > constants (eg: var k_play_an_A_ON = new Number(); k_play_an_A_ON =1; > result.Message_to_Viewer = k_play_A_ON; ) to get parsed whenever the other > Module is ready to do so. Or could one have live 'State' booleans that > determine if, say, the *Viewer* module should be accepting Inputs and live > Structures that are immediately interpreted to, say, display particular > Output states. > > I've been reading a fantastic book of interviews with well known > programmers (Coders at Work) and one take-away I got was not to over > generalise my code, only bite off what I need to do — don't over-engineer > for expansion/more function than required; leave that for later. I'd like to > have a go at MCV inside QC because I have made an Application in QC that > drives other .qtz compositions. I'll probably use *Quartz Builder* to > distribute the App, at this stage. > > My Javascript patch for parsing the 28+ on screen button inputs is becoming > a bit unwieldy in terms of adding functionality without breaking existing > functionality — it's *Viewer* and *Controller* all in one, and then I have > another JS patch (hooked to tons of structure patch noodling) for the * > Model* which is not talking to any other JS patches yet just responding to > manual inputs. > > The idea of separating into MVC seemed like a good organising principle as > much as a code beautifying / rationalising one. Communication between the > MVC parts / modules is what I am probing / flailing around with at present. > Any advice welcome. > > Best to all > Alastair > Useful Design > > > > > On 08/12/2010, at 9:51 PM, Adrian Ward wrote: > > > Hear hear. > > rdar://8743194 > http://openradar.appspot.com/radar?id=953401 > > > > On 8 Dec 2010, at 06:14, Alastair Leith wrote: > > Would it be possible to implement composition/application wide globals for > the Javascript patches in a future QC revision? > > > I know graph evaluation and free global variables could create a headache > if used unwisely, but it would be kind of neat at times to have a > composition-wide layer to read/write get/set to. Couldn't it just operate on > an ad-hoc basis read to whenever (whatever JS patch is being evaluated) > write whenever (same). > > > > _______________________________________________ > 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/the_voder%40yahoo.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/gtoledo3%40gmail.com > > 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]
