|
|
Chart Tools Congratulations on another shipping product smokris, et al. When I hooked up a structure to file patch to take a peak at the the Chart Tools: Chart Data: Pie patch I got a stretched canvas (rendering destination dims not observed) and an exception 0x94a616a8: -[QCContext renderPatch:time:arguments:] 0x94a6148c: -[QCGraphicsContext renderPatch:time:arguments:] 0x94a60580: -[QCOpenGLContext renderPatch:time:arguments:] 0x0000db2c 0x94ad678c: -[QCView render:arguments:] 0x94b1f6c8: _TimerCallback 0x96e3481c: CFRunLoopRunSpecific 0x95c2eb18: RunCurrentEventLoopInMode 0x95c2e93c: ReceiveNextEventCommon 0x95c2e77c: BlockUntilNextEventMatchingListInMode 0x954a3248: _DPSNextEvent 0x954a2c00: -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 0x9549c8a0: -[NSApplication run] 0x00003f84
|
That's pretty much because the output you're plugging into a structure isn't actually a structure -- that cannot work, and will thus throw an exception.
When I first looked at your 'problem' case, I was worried that it meant JSON string structures weren't being accepted, but then I realised were your example was asking for the impossible. [Just realised that your post was a rework of the included compositions :-0]
With these new Chart Tools installed, it is entirely possible to create Chart Tools data sets with JSON string structures & your post [sans inappropriate noodling] thus works really well to demonstrate the use of JSON structures.
GRDatasets aren't well documented, except in developer blogs, but they really won't dance with any other form of input than those provided by GraphKit Framework.
(double edit... guess there isn't a talk page...)
Haven't looked at it, but small suggestion; lose the question marks (?).
What causes this error (btw, I notice this happening ALL the time with stock patches like image downloader...)....
[07:52:19.885] QCProvider_CoreGraphics: Unable to extract native pixel format from CGImage (bitmap info = 0x00002001 | bits per pixel = 32)
That sort of error occurs even when the graphic required is available, but has still to be loaded and procesed. Once the necessary resource has been loaded that cause ceases and the error also stops.
However, this sort of error crops up repeatedly with frame by frame images and can also occur even when some of the images are being processed and some dropped.
Then again, it can also be associated IMETD with a composition that flakes out after the request for a graphic has been queued .
In short, it s what it says it is, but it isn't always so significant.
If Quartz Composer always rendered in a fashion that was based on only request graphic if and only if the pixel format were already available we probably wouldn't see this sort of pipeline message.
Given the different ways in which several image streams can be concurrently requested in a composition that would be pretty difficult to achieve.
Yeah, it's a message that there is some sort of image conversion going on, but I'm wondering why, as in, how do some patches avoid this, and, is it any benefit to do so (?). It always happens when native pixel format is null, seemingly...
I don't know if this is possible but it would be awesome if we could input a glyph for points (and have it work with the little drop shadow).
The smoothness of the lines is pretty nice! I love the smooth anti-aliased look.
If you have something like the LFO example, is it possible to color fill the area below where the line is drawn?
Referencing Rendering Destination Dimensions winds up with the image being a little bit short pixels in width as well as height (like in the LFO example).
You can get pretty close with setting the Renderer to Tile Horizontal and the Chart Data to column with a fairly thick line width.
All due respect... not close at all. That just makes the line look frigging gigantic.
By the way - SinCos and the cpu monitor one both error out in Finder for me, and crashed it after switching the folder they were in to Cover Flow mode. Given the sheer amount of Finder/quartz composer related crashes that happen, I don't necessarily fault this patch, but it may be worth looking into. Finder/quicklook stalled out on making the preview icon when it crashed.
Despite my nitpicks, this patch is really cool, and has some applications that extend way beyond charts... I was expecting something more like Grapher, but this is really cool.
Ok - barely close then ;-)
Layout Errors both in CoverFlow for SinCos & CPU Monitor, though they work in QuickLook mode, but also give Layout Error in the Info box
not really any issues yet for me. great way to make a fast spectrum graph and to find some hot bands for use with visualizations.
been trying to parse some xml structures with attributes but chart tools doesn't seem to like attribute formatting so i guess i will have to see about converting to a json string or something.
So, width and height on the LFO qtz sample cover the full rendering destination on your system? Perhaps you're saying that isn't an issue for you.
Do you mean like this reworked version of LFO Nonsense ?
Hmm, I don't know, I'm just looking at the sample (your pic shows the wave with a bigger left hand border than I get when using the LFO qtz and turning off the display stuff). I'd rather stick to analyzing the provided compositions in trying to figure out if stuff works like I'm expecting.
The wave in the LFO qtz renders shy of the borders even if I turn off all things that would seem to effect borders (like the X axis display). I have to oversize just a little bit. Not really a big deal, but it's unclear exactly how much, though I can estimate by eye.
not sure about specifically the lfo sample. actually they all use the same patches so if you are getting an render dimensions issue then it will be an issue with any chart. I did find setting let's say the x on a bar graph to - .5 will help any overlaid chart to not get cut off on the left side. using a structure count for the x max will make sure your whole structure will be visualized. ideally using the tile feature feature helps with automatically adjusting the graph to your data. honestly i have not really tried going full screen on to see what happens yet. I'm at the doctors office right now. when i get back I will see if i can replicate the issue. is there any sample file of the dimensions issues you guys are talking about ?
A quick screen grab of a bit of noodling between Kineme's Chart Tools and _1024's Wave Generator and audio taken from the _1024 Tone Player.
See attached :-)
Yes. GraphKit adds a 10-pixel border around each side of the plot by default.
If I change the margin to zero (not currently exposed in the QC patch's interface), and disable both axes, the title, and the legend, the plot goes right up to the edges of the rendered image.
Should I disable the margins by default, or leave them as-is and add another input(s?) to control them?
Yes --- see attached screenshot. The currently exposed interface doesn't allow this, but if we can come up with a decent interface, I can add it. The trouble is that it's useful to have a predefined list of marker glyphs (since they're relatively hard to find on the Unicode chart), but having a predefined list doesn't allow custom entries.
If the attached image is what you mean, then, yes. Just change the plot type to
Area, and add anRGB Colorfeeding into theData Colorsinput.I vote for an additional input :-)
Any chance of adding Scatter Plotting too [please] ?
Oh, nice!
My thought was that either the top or bottom choice in the marker glyph menu could be something like "Input", "User Input", or "Custom Marker", and that the port below Marker Glyph or Size could be an image input (Custom Marker?) that only becomes active when the marker glyph menu is set on the user Input mode.
... and yes! That's exactly what I meant by the color fill. Thanks smokris!
Cool.
For me, now that I know what the pixel difference is, it's sort of trivial whether it's modded in any way.
I see little point in actually having the border (well, it does make sure a graph fits within bounds nicely), especially as the default mode for the patch to load in; I would think that one would probably want to always have it off when doing image processing (maybe not?). An input or setting to control it wouldn't be a bad thing I suppose.
Again, really nice. It's great to see a QC patch aimed at doing this kind of thing. QC needs more patches like this that are solidly useful and utilitarian (and I don't mean utilitarian in a bad way).
Can I also vote for an additional layout option "Grid" for the Chart Renderer; e.g. four pie charts could be displayed as two rows of two charts.
Yes Unicode support being uneven across typefaces and applications often is the downside of Unicode's expanded capacity for typographic range.
(Sidenote: I'm always coming across websites for which I cannot find an encoding that matches and that doesn't give me funny glyphs that obviously are not meant to be there — like the old question mark knocked out of a black diamond.) ☃
Unicode being what it is and all perhaps you could add a structure feed to the Chart Data: XY patch that takes a structure of unicode numbers (or 1 char strings or one long string or whatever seems 'best' from your pov and folds the glyph info in with the data elements).
So for each data item as well as having it's numeric value (always shown on "Y" axis I gather) you have a glyph — either as Unicode# or whatever else. If the input is just a single item structure (or a number instead of a structure) it just repeats the glyph for all items in the data feed.
I was asking about an actual image input.
Yep, 2d scatterplots are possible with GraphKit, I believe. @mattgolsen also requested this. I'll investigate.
I'll add a Custom Marker text input, but, as far as I can tell, GraphKit doesn't allow raw image markers, nor does it allow one to specify separate marker glyphs per datapoint.
Unfortunately GraphKit doesn't support grid layouts --- we're currently exposing all the layout options it provides.
That's fine, I've made my own fonts/glyphs before (I'm guessing if we load a new ttf file into our system, our images would show up?).
Yes, it uses the system font renderer, so in theory you should be able to use any font that'll handle. I'll add a
Marker Glyph Fontinput, too (since you probably won't want to use the same font for labels).To which question marks do you refer?
Idea of cycling glyphs and just throwing different glyphs all over the place had me excited. Could still cycle the one glyph to go whoop whoop whoop like a marker on a map in a James Bond movie.
What app do you use for font creation, gt? I have tried a few but I'm uncomfortable using them to say the least.
You know, I feel less vigilant about this than I did this morning, because variety is the spice of life, and this is a really nice patch, but what I'm referring to are the question marks on the Chart Renderer on any input that uses the phrase "Show".
I guess the best way I can express why I think this is aberrant is that Enable on a renderer isn't Enable? nor are similar boolean inputs, such as anything that is "Reset" for instance, instead of Reset?. Also, an input port that is phrased as a question would seem to call for Yes/No, instead of True/False as port values. Did I explain that in a way that makes sense? I know it's splitting hairs; it's of little importance.
I was totally going to say that ("ditch the ?'s") during my brief perusal of the plugin (I did report some tooltip errors), but opted not to. They do feel totally out of place (regardless of whether or not they're more clear -- Boolean inputs get ?'s could be interesting, but has no precedent).
I knew I was getting a sub-conscious kick in gut from somewhere with those but it didn't register on a conscious level. I have to agree (but wouldn't have brought it up even if I did notice b/c, even though gt is correct, I would have felt it was a bit rude to comment, but it is a commercial product, so fair call actually)
Touché, @gtoledo3, @cwright, and @usefuldesign.au. I'll remove them.
Since we're splitting hairs... questionmarks-in-portnames appear several places in CVTools. (I swear I'd seen that convention in other plugins, too, but I'm not finding them now so I think I'm misremembering.)
I've also been informally using them in compositions I develop. Since boolean ports are used in QC to represent both 1. boolean states and 2. event triggers, I've gotten into the habit of differentiating these two intentions. I append questionmarks to boolean-state ports (1.), and exclamation marks (in a sort of homage to Max/MSP) to boolean-event ports (2.). So a boolean port that's labeled "Show Legend?" toggles whether the legend will be displayed for the current frame being processed; whereas a boolean port that's labeled "Show Legend!", when triggered (with, say, a one-frame-pulse), will cause the legend to show from then on (or until a "Hide Legend!" event is received).
I think this is a completely valid intent (which is why I initially didn't voice my opinion; you'd expressed this before [on CVTools?], so I knew what your motive was) -- It's an interesting thing. QC needs this kind of expression, but I don't know if it (or its community?) is mature enough to be ready for it just yet (note all the complaints). I don't know if I like ? and ! as indicators, since it's not very clear, but something should represent if it's an edge trigger or a level trigger.
Perhaps this could go along with string-port-combo-boxes as something the patch renderer could indicate, but the patch expresses (see also: safe mode, interaction ports).
The analogy of a ShowLegend! then HideLegend! event either requires two one shot ports that respond to a change in value - a ShowLegend! port, and a HideLegend! port that receive pulses (or bangs for the sake of argument), or alternately, one port that holds boolean state and works in line with how QC works now.... or a third option- one port that receives pulses, only flashes true when it receives the pulse, but where false can represent either on or off, deterministic on sequence of bang/pulse.
I don't think it's a matter of maturity of audience, I think it's that the concept of !/bang in QC has little real meaning or advantage...no event really gets pushed through from the front, or pushes along the graph (and I don't mean visual graph, I mean evaluation).
So it's not like "mouse down"=bang=evaluate/draw as long as mouse is down and not otherwise, for a mouse driven qtz.
Also, in QC model, it becomes odd to have something that makes a pulse, goes from false to true to false, and connects to an input port that outputs say, an explosion or not an explosion.
For example; the patch that triggers the event's output goes from false to true to false (a pulse) and triggers an explosion that continues until the second time the port receives a pulse/bang, it which point it turns the explosion off (a pulse/event model with a single input port as opposed to current QC standard of an off always being off and on always being on)... input ports start to not convey a 100% picture of what the current state of a composition is. If you stop and restart a composition in a session, does it restart from scratch, or do values persist from the last start (like in Interaction?). If you have two ports that each receive pulses... that seems of little advantage. So I guess, I'm dubious about the concept of something with a ! being appropriate or meaningful in a QC context as is.
good fun !
If you thought that was fun, check this out, OT BTW.
More Tone Player & mixing dynamic and static meshes.
I disagree -- there's a strong notion of "runonce" in programmer parlance; you want some thing to happen once and only once. In Photobooth, you want exactly 1 output picture saved per "take picture" button click (no more, no less); right now, in QC, that's accomplished with a bunch of hackery to ensure that something lasts for a single frame (and no more).
The fact that this functionality 1) isn't requested and 2) is dismissed shows some immaturity on the community (and I mean this in the absolutely highest of senses -- You're dead on in saying that QC doesn't offer much advantage for this, which isn't entirely true, but the corner cases where it is useful are definitely few and far between.) If you're making a UI, and you have a button-like thing, you want it to initiate an action Exactly Once when clicked -- it's edge triggered, rather than level triggered. This poses another problem: if a leading edge is required, it's impossible to trigger at framerate -- the best you can do is framerate/2 (thanks, Nyquist!). You can do leading/falling edge triggering to get full framerate pulses, but then you need additional glue -- those sorts of implementation details shouldn't be Your Problem, but to date it's mostly unexplored territory.
Additional ways of illustrating the immaturity problem (man, that sounds so harsh, I apologize!) is that no one has suggested structures being deprecated, and replaced with Real Arrays and Real Dictionaries -- can you imagine how many problems that would solve? The barrel of structure gripes is overflowing with complaints, but the model still stands with people asking for documentation -- docs to fix an oversimplification? yikes.
(I'm not at all trying to express anything less than the highest respect and awe at the things QC users have accomplished -- it's been beyond my wildest dreams, truly. when I make reference to immaturity, I mean there's a larger visionary component that isn't there, or has been silenced with "Not Possibles" or something.).
Well, the notion of a QC button as an example of pushing stuff through or singleframe events (we've talked about this before). Taking a frame of an image, etc., as a one shot event makes sense. I was simply stating that there aren't really any boolean ports that tend to work like this now (that I can think of?), and few ports in existence now that would benefit from it.
smokris mentioned something about a scenario where you send something a pulse and it initiates one state - then you send it another pulse and it initiates the opposite state. That is somewhat different from a single shot even like a camera button, because it would require a external driven patch that "kept" it's on value until the next time it hit (so again, what state does a composition open/save in... the state that it was when it was last externally driven, or from scratch, or options for both? If it was just a pulse that all of a sudden flashes something into an "on" state, while the pulse maker returns to false... then you have something on, with a connected input port that's false.
An event like taking a picture is a one shot, and makes sense as you describe, because both the button and the corresponding input would be expected to return to false.
Graph evaluation in both directions hasn't been formally requested yet (eg., mouse drives evaluation for mouse driven compositions)? No one has requested Real Arrays or Dictionaries (I really thought I had seen that requested on list)? People may ask for documentation because they might think there's a way to coax the expected behavior in QC, so I don't view that as a "yikes" behavior, especially since anyone would typically think that something with keys is a Dictionary and Indexes, an Array.
Damnit, I'm doctor cwright, I'm not a magician.
Also, all of these question marks are bound to cause problems when I try to run QC on Win7.
Maybe in QC there should be a QCMemory object to mitigate something like the QCButton theory...
For instance, a memory object could have a persistent or non-persistent state input port (this is a bit different than sample and hold functionality), but also ability to hold across saves/apps opening and closing (or not). If you hooked a QCButton to the memory object, and it was in persistent mode, a first button event would trigger something on, and the next would trigger it off... basically the dif between catching rising signals, or rising and falling.
If it was in non persistent mode, it would be a one shot, because it would catch the rise and fall of the button pulse. This model makes sense, because in persistent mode, a QCButton output could be false after it's been pushed, the input of the memory object would be false, but the output could be true - and this behavior would be logical because it would be defined by the persistence port being set to true (or rise/fall behavior port... whichever way is best to express it). The input on the memory object from the QCButton would be an Operand, there would be typical math operations for that Operand including a reset/none, and an Initial Value port that could define the starting value. This would allow for front driven counters or buttons that hold across saves (or not), without it necessarily being hooked to a consumer.
Not that I'm aware of -- requests on the list are equivalent to requests in the trash can; they don't count.
That's possible. It just feels more fragile than a solid "this design is broken!" complaint though :)
I think when you say immaturity, you mean immaturity from a programmer's perspective. (Correct me if I'm wrong). Programmers who use QC have access to all the procedural and text based object-oriented tools of X-Code and are probably not looking for the same set of tools in QC — which is surely why it exists. To do complex, often pixel based operations, with simpler tools than having to actual iterate through bitmaps with code. I wasn't complaining about the ?/! notation, just noting the ugliness and inconstancy (CVTools excepted) of that specific implementation. Smokris explained the thinking behind it, but to me that's more like a rule an individual would use in naming variables inside there own code (looks right to them). If it's going to happen that QC has a new object type (event_trigger) it needs to be done at the framework level and really thought through right across the board by Apple. If it gets that far, then it will be welcomed bby QC community I'm sure.
Vade made the point a while back that as programming notions become increasingly abstract and complicated, strength lies with text style code (that can accommodate high level abstraction) over graph based programming (which needs to presuppose quite a bit of what you want to do already in the form of patches). Which I guess is why QC, it's plugins, CI and GSLS are all written in text based code. (Some development environments are actually written in there own language but can't think of an example I've used except Pick which you'll never have heard of). The fact that QC hasn't covered all the bases of programmatic logic doesn't really reflect the immaturity of it's user base necessarily (although I agree for my part ;) ) but more the use scenarios it is put to, mostly in conjunction with text based programming in X-Code.
QC definitely isn't set up to handle event based logic as directly as tools like Director, Flash, etc etc which were purpose built for interactive animation. It took me fifteen minutes to extend the keyboard patch so it will behave as we are used to a key event behaving (outside of games), having an immediate single event trigger followed by a delay followed by a repeated set of triggers at a given pulse rate. In X-Code that isn't necessary, just make a field or window and the OS handles most of everything the keyboard can do. I love that in QC you can actually make that utility if you bother but it's time consuming to have to constantly be micro-managing pulse events and logic gates in QC to get the simplest of things done. That's the immaturity of the tool, btw — not the user.
If QC had a huge non-programmer base like Director and Flash initially did (and now a huge scripter/programmer base for Flash/Air etc) QC would have probably developed in a faster and different way to meet a different set of demands. The fact that QC is a sub-set of Quartz framework and X-Code is both a limitation and a strength and kind of defines it's user base to a large extent, I think. That has a big influence on where it's going to go (it's not a commercial product seeking an ever bigger user base and audience after all).
As for Arrays and Dictionaries as separate Objects, vote 1 is from me. QC auto-casts from type to type when it can anyway so why not (what's the big deal?), do it Apple. It's taken me tens if not a hundred hours to sus out the subtitles of when a structure is going to behave as a dictionary and when it is going to behave as an array depending on who's receiving it and longer to develop tools to work around that. Like baking the ordered output of a Structure Sort patch into the array item "keys" so the order gets respected by other patches (I'm think of specifically of JS patch here).
I think the user vision is there for QC to move towards being a more all-purpose media tool but it's not even in Apples list of top 100 things to do next year or next decade so who's going to bother pushing that barrow?
I haven't heard back from Apple on the bug I logged that the Keyboard patch gets stuck (kind of limiting!) when used with key modifiers (which are only available thru the Kineme Freeboard patch!) so why would I expect Apple to develop a stronger suite of Keyboard patches/tools for example. Obviously a programmer would being using X-Code and/or NIB to handle UI_Events but that doesn't mean the vision isn't there on my part to want that kind of robust and directly bound functionality right inside QC.
Nope, I mean from a class-of-problems-to-be-tackled perspective (which is more general engineering, and not necessarily programmer specific, though I'd be lying if I didn't admit to having "programmer-goggles" as my main perspective). There's a huge class of things out there to make/do, and the QC community at large has been pretty quiet about what it wants to do. That, to me, suggests immaturity -- they don't know what they want to do, where they want to go. Some uncertainty is definitely fine (and even expected), but this is like year 3 of me sinking nearly every waking hour into the tool, and with the exception of just a very tiny set of people, requests are all generally the same: "I want shadows that don't suck", "I want faster iterators", "I want something like a structure, but with images".
These are great, don't get me wrong. But no one has really proposed "game changing" models. Fundamental departures from where QC has been. There are certainly places where it doesn't belong, but there's an even larger set of places for it to go that no one seems to be interested in.
I'm sorry, but I think you've misplaced some confidence. Expecting Apple to embrace a paradigm means you're locked to Apple's release cycle (which is pretty slow) -- if something cool happens a week after 10.6.0 is released, you're stuck waiting ... and waiting... and waiting. There was a proverbial ton of innovation at kineme that actually did end up driving some aspects of QC. There's no reason why kineme couldn't release a new paradigm-altering plugin, and have people embrace it, entirely without Apple being involved. Whether it's Apple, Kineme, NI, or anyone, I think there's much more exploring to be done in general in lots of diverse ways.
I also feel like having Apple sanction something doesn't mean it's welcomed by the community. How many people honestly welcomed the idle-state stuff with 10.6? OpenCL? Meshes? Interaction? People are still buying Kineme3D!
I won't deny that there's power in abstraction and text-based code, but I am also a strong proponent of visual expression. I do not feel like "it's there yet", however. The final test would be to make QC in QC or something, but that's not even remotely possible today.
And my assertion of immaturity is that there aren't a lot of people really pushing QC into those areas where it's not a use scenario. Cocoa didn't become awesome because people accepted it as it is. Computers in general didn't become what they are by people accepting them as Mainframes and text-based spreadsheet machines. Was doing more with a PC difficult at the time? definitely. But that passion that drove people to create beyond the limits is what moved it. There just isn't as much passion in the QC community at times, I feel sometimes (that's doing a majorly huge, offensive disservice to all the great and wonderful things that people are doing, so don't take that as a blanket statement of truth).
Putting it another way, no one has said (that I'm aware of) "This sort of problem is totally doable by QC, except for this one thing -- that should be a feature", and then filed a radar for it. There are radars for bugs, and inconvenient things, and totally off-the-wall crazy stuff ("make QC into shake + flash + photoshop!"), but none that thoughtfully map out where QC can go "in the future". (granted, that's my job now, but this was something near to my heart even before my westward sojourn).
I won't for a moment deny that the tool's immature (I stare at that problem in the face every day for 9.5 hours in my office, and then for another 6 when I'm out of the office). But expecting a mature tool to create great works, or even chart great direction, is getting it all backwards. It's akin to waiting for the saw to be invented before using lumber as a building material. without using lumber, there's no need for the saw, and thus the saw never gets invented.
QC is in no way a subset of Quartz and Xcode -- those two techs are written by totally different teams that never talk to us (well, we have lunch with Quartz, but that's for historic reasons ;). I don't buy the "not seeking a bigger user base" argument for a moment -- the same could be made for Obj-C -- why was Garbage Collection added, or Properties? How do you know QC isn't seeking a bigger user base/audience?
And yet it's never been requested. (I'm totally not blaming you -- I feel like I'm ripping you up on this, and that's totally not my intent -- my terseness comes from talking to machines all day, I assure you :). People are completely free to say "Hey, this one thing in QC, it's stupid. I hate hate hate it, and it's wrong -- it needs to be more like this...". That's what drove QC4 -- lots of internal people shouting stuff like that, and very very few people on the outside saying anything at all (myself included -- I was too busy pointing out simple bugs to see the bigger picture).
/me raises hand? It's a symbiotic relationship: if someone does something cool with a tool (despite obvious tool suckage, for sure), it shows a glimpse of that vision. Where's it getting shown presently? Who's pushing the envelope? And I don't mean using more shaders, or bigger CL kernels, or larger textures. I don't mean more complex meshes, or higher framerates. It's something more.
That bug is assigned to me -- I'm responsible for it, personally. (As well as lots and lots of others). The fix, unfortunately, is much more difficult than it first seems -- modifiers have different effects with different input locales, and writing a function that maps the transform that takes place when a modifier is enabled is non-trivial (as in, unicode is a cruel mistress non-trivial). I was initially chomping at the bit to tackle this problem, but backed off when the scope of it dawned on me. Please don't take that as me not seeing it as important -- Please don't take the lack of hearing about it as it's not being discussed/worked on, because that's not the case. I think there's also a subtle AppKit bug, where NSEvent's "ignoring modifiers" method still honours shift (necessitating the manual modifier translation) -- that's been present in AppKit for so long that it's almost certain to not get fixed simply because it risks breaking lots of other stuff that also works around it. (meaning the fix is a lot of work on my end :/)
[P.S. that could be an unusual extension of the forums -- radar chat. interesting...]
[P.S.S. don't take this as "I'm out of ideas!" -- far from it, in fact I've got more than enough mapped out in my brain that it'll take ages to dump it all out into code. However, thinking that what I've got planned is better than an idea someone else could have is laughable -- I'd love to hear what people envision for the tool]
wow this was a good rant. not really sure even where to start commenting. i guess i can go from the top.
i'm not entirely sure about the whole persistent button pulse conversation as that went a bit over my head, although smorkis's use of notations to delimitate boolean states seems like a very semantical connotation that i do not think is outside the realm of a immature understanding.
however the problems with notative delimitation's is that a universal standard is really needed and not proprietarily unique to the individual programmer. meaning if i use #1 to denote a boolean state and smorkis uses !! it get confusing.
the freedom to arbitrarily declare primitive and generic delimitation is very powerful but a specification of some commonly used or needed marks would need to be set as a specification by the community as a whole in order for 1 immature users to grasp and 2 for qc to mature as a language.
all it will take is someone like smorkis to start using ? and then someone else utilizing the same notation in their plugin to catch on but adversely all it would take is for someone to go no he uses that i'm using ∞ to denote the same action to muck everything up. right now i don't see it as an issue as there are not that many people making plugins so all one would do is have to learn vade's way or the 1024's way etc...
what i am saying is that a structure sort uses ! to denote the order of a sort which is totally different than smorkis's purpose which may cause obstructions when an immature user is trying to learn the qc language. as much as i hate to say this some sort of uniformity or conformity is needed. which qc does address with its particular protocols etc..
the whole using an NSArray or NSDictionary thing as a QCStructure baffles me sometimes ? i'm pretty sure a QCStructure is a NSDictionary under the obscurification of qc data types. where as mesh vert structure is NSCFAarray wrapped in a QCStream which may be a dictionary as well i have no idea.
so i'm there with you on dictionary style structures and what not. at least that will solve the most asked question on kineme and the qc dev list of all time.
!¬how do i sort or smooth a structure ?
dictionary have some good built in sorting options.
some things i think would push qc into the future are but not limited to this which list....
!¬openGL ES 2.0 safe patch mode so a qc view can be used with iOS.
!¬in viewer transformation tools. (rotate, scale, move) for all or any consumer patches with interactions.
!¬dynamics or physics (rigid and soft body colliders etc..)
!¬fbx or and or dae baked animation support
!¬suite of non text shader and CL patches
!¬basic audio synthesis, generation, and saving capabilities.
!¬all of kineme's free plugin's as stock.
!¬hi res offline render non realtime mode
!¬mac-pc application bundle export
!¬code generating
i could go on and on about tools i think would be cool from calendars to maps etc..
I just wanted to chime in again... after a little bit more using it, I have to say that the color fill function is really nice. This really makes a number of functions very straightforward.
There's something inherently interesting about being able to do something like take an audio spectrum, graph it, and output an image to Billboard, versus a traditional QC alternative, like taking the structure, feeding some sprites, and iterating. It's fascinating for all of the structure processing and conversion to image to be happening via this plugin and outputting a high quality image like this.
Thought I'd have another go at this cwright. I appreciate your insights :)
Does Apple know the QC user demographic? I know the Kineme community isn't necessarily representative but you've cited hundreds of lurkers. Outside of developers, it seems like hobbists (like me), a handful of professional artists like Franz and George, and developer backgrounded enthusiasts like Cybero who can fathom the technical stuff I find glaze-over–interesting because I can't understand it. (Sorry if that sounded like a pigeon-holing exercise, just generalising grossly)
I still think the audience for QC content and QC's place in the Apple stable are a primary issue here. Early Flash/Director artists and developers weren't just showing their stuff to each other, they had paying clients keen as mustard to have a cutting edge online presence or a wizz bang CD-ROM (gez time flys). That generates demand and efforts by artists to skill up fast. If you can't find a way to do something in QC as a hobbist, you move on (ideas are cheap)… as a professional you hammer Apple/Adobe/Macromedia for the tools if you just can't make do without (or go to a 3rd party provider ;) for a plugin). Flash was so central to Macromedia's profitability they listened hard and responded quickly from what I heard. Adobe is more incremental, conservative but knows what users want because there are just so many of them out there — and at one time the was competition with their products (eg: Quark, Freehand).
Yeah, all true enough. My feeling is that while Flash and Director put making interactive visual content within the reach of the anyone for the first time in many ways (non dev-educated people) (and had a more broad-based viewing audience) QC is still very technical and low-level by comparison. (Obviously I find it powerful and elegant too hence this discussion.) This and the lack of app style interfacing elements is holding it back from more mainstream use in my view. At the moment QC's sweet spot is still being the glue between outside data (be it audio, RSS, 3D models, whatever) and realtime visual representation.
To broaden the tool I'd like to see a set of Renderers what emulate what NIB does for XCode. So menu bar, rollovers, dialogue boxes all that (I've read there's an interaction patch in SL which is a start in the right direction). To start with in the Apple OS X look or whatever then eventually customisable skins. This would help admirably with Kiosk style apps for those of us who can't do X-Code.
I'd like an extensive symbolic object architecture that lets you pass 2D and 3D shapes as maths defined objects from generator to modifier to renderer patches. Some of these objects might be stock eg: 2D n-point star polygon patch or stroked round-rectangle or user generated eg: 2D shape from glyph or eg: equation y=sin(x) based that send (read: reference) the point and bezier data to patches that implicitly understand the format of the data (so user doesn't need to get their hands dirty to modify it eg: skew transform patch or eg: blend from object a to b or eg: iterate object 10 times and transform from here to there or eg: extrude 2D shape to 3D shape on this rail curve). Then the data could be ported to a renderer. Would be v cool if it could be used in other renderers like as a particle in particle tools or iterator or whatever. Plugins or virtual QC patches that output shape definition data could pre-define new complex shapes (with inputs for size etc) that you just drop into your comp for a new shape or mesh.
I'd recommend anyone look at Grasshopper (Visual Programming tool) for Rhino (3d NURBS modeling app) for one approach to these kinds of tasks. Coming to OS X soon apparently. Same GH software scheduled to run inside OSX ver of Rhino.
There are two intoductory you-tube videos, PDF introduction tutorial etc here
more videos with this one: Obviously this is leveraging the sophisticated NURBS tools in Rhino but it interesting to see another visual programming 3D tool implementation. Looks like GH could do with a macro patch judging by some of the graphs in those videos;)
"Necessity is the mother of invention" was a favoured quote by modernist Architects. QC is yet to make killer app status in a crowded market. A stand-alone hi-quality realtime media kiosk turn-key app generator could be one way to do it? Imagine if a non-developer could pump out something almost as good as what toby did here. I imagine you've done as much as anybody outside Apple for pushing QC forward, cwright. That's been reflected in your appointment to the first XI.Wasn't having a go! Just that in Australia, Apple is not a company you hear about people interacting with unless they get the rare call over to the states or attend WWDC type events ($$ from aus). The local people are kind of sales/marketing from my very limited experience and don't reflect the qualities that have made Apple what it is, they just seem to ride on the (at times capricious) coat tails of the real Apple. I actually had a conversation with Troy about better integration of Keynote and QC when I was working on Keynote stuff and couldn't use QC because of basic limitation's in Keynote. Safe_Patching Keynote hasn't helped either. I sent a few pages of discussion points to the Keynote team via an Australian public speaking and Keynote 'user/evangelist' who was invited to address the Keynote Dev team. Never heard back from anybody. Troy pointed out it was really KN team that would need to run with it not QC team.
Further to that I think the ability to do the equivalent of 'compile to binary' or in some other way secure Quartz Compositions for distribution without allowing the source to be edited/stolen is a must if QC is to mature in a non-developer environment. We have discussed elsewhere — whether or not it's technically possible from within the QC citadel as opposed to outside I leave to your good judgement. I'm not necessarily talking 'military grade secure' just polite thievery, as cybero(?) put it, from say a product competitor. I thought of some awesome Keynote Theme products but basic Keynote glytching and lack of simple I/O along with the open-sourcing issue make it a no go for me at present. I have a feeling, Apple don't want keynote users getting ahead of Steve's keynotes so it's kind of hobbled. Smokris even mentioned a Keynote undocumented API (sound familiar!) — if Keynote got opened up to QC goodness especially bound to Build Actions we could do all kinds of cool and marketable stuff.
Side note the leading developer of KN themes was approached to do the Stock Powerpoint themes for the next release and apparently MS is getting it's product up to scratch (they claim) with features that might even make KN squirm (it already has scripting).
Sorry, b/c this sidesteps a ton of what you said, but one comment at the end reminds me of a thought I've had a few times...
-Feature Request - Invisible Patch that you can't see on the editor, or some kind of boolean in the meta data that we can set, that flashes DEMO (or some other string) really big across the Viewer at a proscribed time. ;-)
Lol!
This ones for you, gt. Would look a heap better if the cubes at min size just switch themselves off IMHO.
I was beta testing on that but lost track/interest...