A bit of both worlds. We used a QCPlugIn to traverse a data source and build the nested Structure output (ie. an NSDictionary), which was then rendered using JS and built-in patches.
In one project, there were occasional points where we need to modify/insert items into such a structure. We did this using a JS patch that re-builds it (structure inputs in JS are immutable), inserting the correct keys/values where needed and then spitting it back out again. This doesn't happen very often so I'm not worried about execution speed, the important thing was that we could do this conveniently from within the QC environment, instead of going back to the QCPlugIn. In another project, I had 4000 records in a single structure, each one with an X/Y coordinate. I had to do some trigonometry with each coordinate, and sort the structure by this result, and I had to do this on every frame. In this instance, using QC structures alone wouldn't have cut the mustard - way too slow. Turns out even an NSArray purely within a single QCPlugIn wasn't quick enough. In this instance, we dropped down to low-level C arrays with an efficient sort routine, did pretty much everything in C, converting back to an NSArray for output/rendering only after all the processing was done. Here the priority was to keep QC's handling of data to an absolute minimum. And just quickly to answer your question about multiple machines - depends on the project. Sometimes we use multiple machines that synchronise states using UDP Broadcast messages (easy!). Another thing we're doing at the moment is provisioning multiple screens from a single computer, but with each screen running in it's own independent process - this is pretty efficient and I like the way each screen has some isolation/protection from other screens. bfn A. On 12 Dec 2010, at 22:45, Philip Curtis wrote: > 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/adrian%40clayinteractive.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/archive%40mail-archive.com This email sent to [email protected]
