It will be super cool to have a "Publish all inputs" from the selected (macro) patch function, side by side in the menu with the publish inputs and outputs ones....;)
kinemeCore 0.4 ?
Injecting stuff into that menu is going to be rather tricky (I'm not sure where it's generated/stored, so modifying it is difficult), but I agree, it would save a lot of time. :)
Or maybe, as a simpler alternative, just a menu-item in the Kineme Core menu to publish all inputs to the selected macro, and maybe the option to also publish splitters for all inputs to the selected macro (useful for people like me who make QC plugins for applications like VDMX, that require inputs to be published from Splitter patches).
I'd love all of those features, it'd save a ton of messing about.
One other (unrelated) thing I'd kill for: copy + paste with connections. Quite often i have a huge macro, with 20+ connections to it, and I want to duplicate it. Cue manually re-wiring everything.. No idea how that could be implemented though without some serious hacking :/
So, for the to-root functionality, do you want all ports published to root, or do you want that to be a per-port thing (like the existing publish port menu stuff)?
I'd love to see both, too. So I'd like to see a "Publish Input To Root" item in the right-click menu for every Macro/Patch, so I could choose an individual input to be published all the way up to the Root level.
An additional "Publish To Splitter At Root" item would also be handy for me, but I don't know if that would be of any use to anyone else out there.
The per-port stuff I think is ok (a bit tedious, but nothing impossible) for publishing to root.
Splitter at root, however, is a bit over the top. worst-case, you can just go to root yourself, and splitterize all inputs (still much, much faster than the built-in way of handling it).
you're right; that ideas is a bit OTT. Scrub that one.
Being able to publish an individual splitter to root WOULD definitely be handy though. There are lots of cases where you don't want to publish all the ports for a particular patch/macro.
With today's beta (still not quite released ...), I fixed a bug somewhat related to this:
Specifically, the Publish All __ functions ask per-port for a name. If you hit Esc, it doesn't publish it. This works for the publish to root as well (not yet -- I've got it working for me, but for y'all it'll act weird if you hit esc with Publish To Root).
So: is it enough of a compromise to just have this, and expect users to hit escape for ports they don't want to publish to root?
(I ask because I don't like huge menus, and this one's getting large already...)
As long as we are wishing for pie in the sky, I wish for the ability to be able to publish to root a group of inputs selectively! 12 out of 18 of them for example... and somehow choose which ones do or don't :o)
I thought exactly the same thing, but then I realised that doing it selectively isn't so important if you can do either a single port or all ports.
If you think about it, publishing 15 out of 20 ports on a patch all the way to the top level can be a real pain, but UNpublishing 5 all the way to the top is easy, you just unpublish on the patch and it sorts itself out. So if you could publish the lot, it would be pretty trivial to sort out what you didn't want.
Mr. Wright, is any of this even remotely possible, and even slightly on the cards? Or are we having another of those pointless "we want" discussions I'm sure you like so much? ;D
don't worry, I want this too -- however, I'm going to put some cards on the table:
It's actually apparently rather difficult for a plugin to find out what patch (or patches) the user currently has selected in the top-most editor. (This was researched for PerformanceInspector, and no feasible solution was found -- that said, PI has some crunchy time/cleanliness constraints that KinemeCore doesn't have to worry about, so maybe there are alternatives.)
Programmatically publishing a port isn't too difficult (assuming the patch/patches can be isloated, see above).
Modifying the menu the user sees when right-clicking a patch seems more difficult than figuring out which patch is selected -- the menu isn't in any nib, binary, or related file that I could find (in a quick recursive grep of the app and framework), and it's impossible to modify what you can't even find. Making a menu-item (and keyboard shortcut) out of it isn't a problem, but it's not a smooth workflow. -- smokris unraveled this.
We can modify menus via interception of events, but we have to know where to look (right click doesn't always mean "Make the publish menu", for example). If we could find the resource, we could watch where it gets used, and go from there. But since we can't find that, there's a lot of guessing necessary to track it down. (it's probably not all that hard actually, since the NSView subclasses likely handle this -- we just haven't looked at the editor views for much more than "turn transparent, to look cool!", which is stupidly simple.)
The actual graphics for it (rounded corner stuff) is part of AppKit or CoreFoundation or some such (not useful, since we're not actually modifying things that deeply :)
Of course, had I actually looked at the methods, I probably would have noticed something obvious like "MENU" in there... sigh thanks smokris! :)
(yes, poseAs is deprecated in leopard, and even our category tricks used currently don't work in Snow Leopard's 64bit runtime [smokris' eyes only: see commit logs for notes on that ;)]... Do I sense a cat & mouse game? ;)
So, to perform the publish thing, I decided to use the built-in publish code, and iterate over each input/output port (inputs only at the moment, since I was just doing some testing).
What happens is this (man, I wish I had some good screen capture software...):
You select "Publish All Inputs"
Then for each port, you get to edit the title as it's published. If you just press enter, it's the default. If you press escape, it aborts publishing. Thus, you can fully publish an N-input patch with N keystrokes (enter or esc), and selectively enable/disable each one.
Next up, outputs (same code, different enumeration), and then maybe publish to root (that's a bit trickier).
Please heap on some additional requests, to make 0.4 worthwhile :)
[And actually, the class we were interested in was GFNodeActor, not GFGraphView... a tiny bit in both, but GFNodeActor does all the heavy lifting]
I'm myself optimizing a (sigh*) HUGE patch atm. , and found that a performance inspector would be tremendously usefull. Esp. when you have nothing running on screen and the FPS is only around 40 ..... !
Written and released in mere hours! Amazing! Again! :D
I'd love to see the drag + drop to macro too btw. But.. I think for that to be really useful, it should keep the connections, otherwise it's only marginally more useful than cut + paste.
That's a bit more difficult, but I guess if you can determine which patch(es) are being dropped, you can determine their connections, and publish + connect the right ports. Possible?
I believe it's possible, but it's tricky. All of these tricks require re-implementing portions of QC's editor with additional hooks for our new features. This requires lots of book keeping (to make sure we're feeding everything what it expects to be fed), and lots of reverse engineering to see find where the data is that we need. For simply publishing/splitting inputs, we just need a single patch, which is conveniently handed to us. For Drag+Drop, there's a whole slew of methods (an Informal Protocol, in cocoa parlance) that we need to hook and reverse. Then, after that, we need to successfully traverse each port to get connection info (not too difficult), and connect things properly back up, publishing where necessary (publishing = easy, connection making is hopefully similarly easy, but it's never been done by us before...)
Just been trying out the latest Core beta.
The 'Splitter to all inputs' feature is BRILLIANT!! Thanks so much for that one- it will no doubt save me lots of time in the future.
I feel churlish mentioning it, but one little tweak that would make the function even cooler (and I don't know if this is possible): it would be great if the newly-created splitters weren't on top of each other. I know this is the standard behaviour when they're created one-by-one too, but I've always found it really annoying to have to move them all. Maybe they could appear in a vertical stack, with a little bit of space between them, vertically-centered on the center of the patch/macro they're attached to. Just a thought.
Researching how to programatically move patches around, to prevent that from happening (I noticed it too) -- moving stuff requires us to find out where our connect goes, patch-wise, and then modifying it. Both should be easy, but again, these parts are Deep in the belly of the QC Beast...
Well, I grew up listening to BBC Radio 4 (talk radio for intellectuals), so I imagine my vocabulary is nearer to the average middle-class, post-graduate-educated, middle-aged English person than most of my peers.
Catholic private school for me... my english teachers would abhor my constant bastardization of sentence structure and use of "...", "dunno", and other bad habits. I know better, I just no longer care! Yesterday I made a post to the quartz-developer list and used "a" instead of "an". I noticed this as I hit enter and felt an immediate pang in my heart, heheh. ( I am having sentence diagramming flashbacks.. noooooooooo!)
I think this is slick... I had gotten to where I was doing serious "speed editing" on stuff like this, but this does really save some time, and the way it sets you up to publish each port is extremely handy.
...and it skipped over the noodles! Thanks for that.
Separately, but on the subject of port publishing; is it currently possible to change the published ports listing order without republishing all the ports? Seems like that capability ought to be available in QC somewhere, but I've never found it. It's quite inconvenient to have made a simple port name modification and then to have had that port drop to the very bottom of the listing of all the published ports.
This is actually rather exciting -- I'm glad it's helpful so far.
I'm working on publishing to root -- it's a bit trickier than it sounds (for example, when publishing, we get prompted for the name -- by extending this, you'd get prompted for the name at every level, which would suck), but I'm making progress.
As a side effect, I've worked out how to publish ports without asking for a name -- would a Publish Without Asking option be useful too?
i think the menu is going to get too long. the obvious way would be to just ask for it once (the first time) and then go with it. that would save the most clicks (time) and make the option work as it sounds (click once, get to root).
So, if you select publish all, it would work as current. However, if you selected publish to root, it would work almost as current, except bumping you to the top level, where it asks just once?
I like that! But I do kinda like both options. Is one extra option going to make the menu too long? :o(
no level bumping -- that would be disorienting to the user ("Where am I!?"), and we've not mastered how to correctly change levels programatically anyway (I've got some leads, but there are lots of things changing at that point, and testing them all is somewhat time consuming).
Remember that these options will come in pairs: one for inputs, one for outputs.
current beta actually already handles publish to root -- it prompts at the current level, and then reuses the name all the way up to root. I figured that was easiest, code-wise, and made the most sense.
the current betas are more advanced (they're marked with their long build number/date, 20090128), and the release they're working towards (0.4) -- hence, 20090128 (0.4). It's a mouthful, but it provides information on several things: when it was last built, which release will outdo it, and which beta is newest (20090128 is newer than 20090127, etc. bigger numbers = newer).
If you plan on using publish to root functionality, I highly recommend trying the latest -- it's a new, experimental feature, and it needs some real-world testing to really prove it as workable. otherwise, it's just small tweaks that may or may not matter.
Good point, I was thinking that before I posted but figured I would chime in with that anyway :o)
.. but after I posted, I realized that idea what would probably be the best twist on that would be a "publish all open ports"; as in, publish all ports that aren't connected to "noodles".
oh, I like the "noodles" addendum -- good idea (and possible, if I recall correctly :) -- as in, we can ask ports if they're connected, and Do The Right Thing (all previously mentioned Really Hard StuffTM is still Really Hard)
i always wished for a way to drop things into macro patches. like, you would select all the patches you want to put in a 3d transform for example, drag them (maybe hold down some key) and let go of the mouse over the macro patch. this would put all the stuff in and preserve the connections to stuff thats outside by publishing the needed ports. The opposite would be to select all the stuff you want to move one level up and chose a 'move one level up' from the menu.
im sure this is out of the the scope for the kineme core because of:
"It's actually apparently rather difficult for a plugin to find out what patch (or patches) the user currently has selected in the top-most editor."
but i thought id throw it out there just in case this changes :). it would be just too cool to have.
this would be great too! (I want this as well, though I never thought about it till you brought it up :)
finding the selected patches can be difficult (smokris might have found a way to discover if just one is selected), but looking up a patch by coordinate is easy (we can feed the editor a point, and it'll tell us which patch is there, if any). I think drag/drop events will also contain which patch/patches are selected, making that part not too impossible as well.
Only hang-ups: overriding drag&drop can be tricky, and handling noodles. Ideally, noodles would get auto-published and re-connected both inside and outside when necessary. That's a lot of bookkeeping, but not outside the realm of possible :)
(I wonder if apple's lurking on this thread, silently adding stuff to snow leopard? :)
Discovered how to capture exactly which patches are selected in the editor (it's sorta ugly -- you have to iterate over all of them), so I'm now focusing on adding support for that to PerformanceInspector (after a quick drive across town to take care of some paperwork)
...but if they aren't even sure what something as simple as TUIO is, would they even understand what we are talking about? (oooh, I am bad bad bad.... HALF joking here)
Troy wasn't sure what it was, but Alessandro was, so Apple's divided, as far as stats go. From the looks of it, Alessandro's the more artistic one (i.e. uses QC for art, makes graphics (see the tiny .xX signature on the QC icon sometime)), while Troy appears to be more of the developer type.
To be honest, I had no idea what TUIO is (and I still don't, really), and I EVEN DID THE INITIAL LEOPARD PORT OF IT (QC-wise, I didn't actually touch TUIO at all)! :)
Earlier, there was a UI Job posting to QC on Apple's website, so, depending on if they got a talented engineer or not, things could be rather smooth in Snow Leopard. (I know that stuff looks fairly different)
Lol, I know I was being unfair with that, but I can't help myself sometimes :o) I guess if it was me, I would friggin' look the thing up, rather than hit a response to the whole world that is "well I guess I could look it up, but I'm not going to..."....then responding with 0% useful commentary. (yes, this is somewhat of a "flame" and it is juvenile in a sense, sorry... but I can also step out of "my" shoes and just as easily see Troy's point).
I noticed that listing actually... there have been a couple/few qc related listings in the past couple of months.
I understand the POINT of TUIO when used with an actual table top, but I feel like an ass using an emulator on a laptop (seems ultra pointless to have an emulator besides for testing)... after about 5 seconds I'm going "why isn't this just hooked up to a mouse or trackball"?
I thought that it was weird when I was looking through online posts that someone referred to the "kineme tuio" patch, and that there wasn't one here. I have a TUIO patch, but here I was assuming it was standard API because of the way that it is listed as a "plug-in" (though I know that doesn't have to be the case!).
yeah, you're right (I came across this in testing once, and didn't think twice about it...) -- I'll make that change.
(also, another bug: publish all to root, then hit esc on some of the inputs -- it still tries to publish ports, but it ends up picking the wrong ones... I've just fixed that as well).
On a different note (but while we're discussing cool impossible features), how does everyone feel about single-step rendering?
As in: instead of setting the framerate in the preferences, you also are able to have the viewer just render a single frame, and wait indefinitely (so you can inspect the state of all patches on a per-frame basis).
I've just come across a weird composition where this would be invaluable for debugging (some patch is providing output a single frame too late, but it's difficult to track down which one, and even at 10fps it's too fast to catch the culprit).
A work around is to attach everything's output to a billboard and render in QuartzCrystal or something, but that's lame.
This sounds invaluable!!! I like QC realtime stuff, but I also think it is valid to use it for stuff that is strictly offline bound... where the renderer is skipping from 1fps to 6fps, to 30fps, and you aren't really seeing every part of the motion that reliably. It sounds like that would be a much better way of inspecting compositions that have really variable fps. You are talking about using it to slow something down, but it seems like it could be used for these scenarios as well from what you describe. I'm pretty floored by that possibility actually... it really opens up many doors.
For example, lately I've been doing some fun stuff with feedback + video, and trying to record a video of it with crystal. Problem is, the video plays at a fixed 30fps, and the composition as a whole might play at 15fps in places. Feedback is a per-frame effect, so what tends to happen is that the effect plays 2x faster in crystal while the video stays the same. It'd be useful if the video could advance in a per-frame way too.
On a side note, I have a case where I need something like value historian (but a lot simpler) that can capture at a very high frame rate (i.e. it might capture 200 samples per frame from mouse/tablet input, and output say a structure of 4 samples per frame). I'll write a plugin to do it, but just wondering if there's a need for such a thing in general?
recording more than one sample per frame would be exceptionally handy -- not really possible for mouse/keyboard events (since they're delivered on a per-frame basis to the composition, unfortunately), but for patches that get data from other sources, this could be an extremely handy feature.
basically, it'll pause (not stop!) the top-most viewer window. Then, you can step in 1/60th second increments. And, of course, you can unpause when you're done. The editor's ports are all left in the state that the composition's in while paused/stepping.
Helped track down the culprit -- apparently the Pulse patch sometimes takes an extra frame to catch trailing edges.
I'll probably make another beta in a day or two, unless y'all want me to get this out Right Now ... 4 betas in 4 days is a bit insane :)
You are really cooking. Interesting note about the pulse patch. I'm just really surprised that this has ended up covering so much ground. These updates have been fairly enormous.
I don't know what happened -- the perfect mix of time, feedback, and luck combined to smile upon kineme this week I guess :) (and behind the scenes, I finished PerformanceInspector). A very productive week :)
Thanks everyone for their support, feedback, and great ideas.
(sorry about the drag+drop macro stuff.. that's a difficult thing to do, but it's still on my hit list eventually :)
cwright wrote: ... (and behind the scenes, I finished PerformanceInspector) ...
I haven't found any official place to comment about PerformanceInspector yet, so I thought I'd offer some appreciation for that feature at this juncture.
I mostly just muck about and try various combinations of patches with the sole goal of achieving visual interest and, in all honesty, I would never have been able to sort out patch efficiency factors on my own. Additionally, PerformaceInspector provides an insightful compositional overview that is not always readily apparent from merely observing the composition in its default context. In that regard, it seems creatively useful because it can encourage the consideration of alternative patch options and placements. Thanks so much. PerformaceInspector is a wonderful tool.
This sounds super useful. Being able to step through frames sounds super-useful for some of the JavaScript stuff I'm doing - debuging in QC can be a nightmare.
Could you elaborate on the Pulse bug a little? I think I may have run into that in the past.
When the interpolation time goes from duration-tiny_amount to 0 (reset), the output drops to zero, but the pulse patch doesn't register the drop from almost_x to 0 until the frame after ... I'm not sure if that's accurate at all, but that's what it looked like in a 10-second inspection.
This would explain a few problems I've had in the past, when trying to trigger things with pulses (usually with some kind of feedback loop). All kinds of strange behavior tends to happen, so I gave up and wrote some javascript to do the same job. I always wondered why it didn't work :)
this one to long for me to read the whole thing right now but, i think publish all is great option, at least for the particular patch selected. also publish all out would be good as well for patches that have constraints on them like iterate. would be nice to actually get the result returned back to the upper level.
I've seen this comment before... and I'm really ignorant of the way that other node based programs that are similar to QC work- is this a standard option? If you find yourself needing a value from something that is inside the iterator, can't you just have that part actually be outside of the iterator, and publish the input ports of the chain that remains inside the iterator...then make necessary attachments, etc? You can even just copy whatever part of the chain that you are wanting values/images from and plop it on the level you need that is outside of the iterator if you don't feel like going through cutting part of the chain/placing it outside of iterator/publishing inputs from chain inside iterator... and then having whatever outputs you needed available. Does doing that miss some kind of options that are in other programs?
Let's say you have 15 patches with 1 output each, and you want to publish all the outputs. This currently requires 15 clicks, even with the publish all inputs function, because those only work on 1 patch at a time.
I've worked out how to address all selected patches, so, if anyone's interested, I could modify the publish-all options to actually publish all from the currently selected patches. I'm likely going to do this anyway, for my own use, but if there's some interest out there, I can try a bit harder at getting it released :)
psonice wrote: One other (unrelated) thing I'd kill for: copy + paste with connections. Quite often i have a huge macro, with 20+ connections to it, and I want to duplicate it. Cue manually re-wiring everything.. No idea how that could be implemented though without some serious hacking :/
Here and other threads this has been asked for and from memory cwright said quite tricky... option dragging for duplicate with input noodles duplicated would be another implementation of same that would be great.
Anyway, spooky patch delivers one nice workaround i discovered (for those who don't do this already). V good for when you need to change a macro/iterator internals and then delete all previous copies and make (say 10) duplicates. With spooky you don't have to rewire every duplicate every time you edit inside. Save a bunch of re-wiring.
So glad for the publish-to-root, insert-splitters and so forth, that stuff was a pain without KinemeCore. Option-Drag duplicate would be icing on the cake!
I did my best to read through this, and researched the site. I am trying to get an input splitter that is two macros down to be published on the top (root?). That's what "publish all inputs" is meant to do right? If it is, is there a way to implement this that I missed? If I'm way off base, how do I get my published input splitters from deep in macros to show up (in VDMX)?
Injecting stuff into that menu is going to be rather tricky (I'm not sure where it's generated/stored, so modifying it is difficult), but I agree, it would save a lot of time. :)
I vote for this!!
Or maybe, as a simpler alternative, just a menu-item in the Kineme Core menu to publish all inputs to the selected macro, and maybe the option to also publish splitters for all inputs to the selected macro (useful for people like me who make QC plugins for applications like VDMX, that require inputs to be published from Splitter patches).
a|x
Yes in the KinemeCore menu ! Yes publish all inputs to root ! ;)
and publish to root level? please....
I'd love all of those features, it'd save a ton of messing about.
One other (unrelated) thing I'd kill for: copy + paste with connections. Quite often i have a huge macro, with 20+ connections to it, and I want to duplicate it. Cue manually re-wiring everything.. No idea how that could be implemented though without some serious hacking :/
publish to root !
So, for the to-root functionality, do you want all ports published to root, or do you want that to be a per-port thing (like the existing publish port menu stuff)?
both?
So there would be a "publish all inputs to root", and "publish to root -> [each port]"? that's possible.
I'd love to see both, too. So I'd like to see a "Publish Input To Root" item in the right-click menu for every Macro/Patch, so I could choose an individual input to be published all the way up to the Root level.
An additional "Publish To Splitter At Root" item would also be handy for me, but I don't know if that would be of any use to anyone else out there.
Great work!
a|x
The per-port stuff I think is ok (a bit tedious, but nothing impossible) for publishing to root.
Splitter at root, however, is a bit over the top. worst-case, you can just go to root yourself, and splitterize all inputs (still much, much faster than the built-in way of handling it).
you're right; that ideas is a bit OTT. Scrub that one. Being able to publish an individual splitter to root WOULD definitely be handy though. There are lots of cases where you don't want to publish all the ports for a particular patch/macro.
a|x
I agree :) (it's in the works :)
With today's beta
(still not quite released ...), I fixed a bug somewhat related to this:Specifically, the Publish All __ functions ask per-port for a name. If you hit Esc, it doesn't publish it. This works for the publish to root as well
(not yet -- I've got it working for me, but for y'all it'll act weird if you hit esc with Publish To Root).So: is it enough of a compromise to just have this, and expect users to hit escape for ports they don't want to publish to root?
(I ask because I don't like huge menus, and this one's getting large already...)
For me, yes indeed. That seems like an excellent functionality.
like a good solution to me, too.
a|x
Yeperooni. Great idea... best way to implement it.
As long as we are wishing for pie in the sky, I wish for the ability to be able to publish to root a group of inputs selectively! 12 out of 18 of them for example... and somehow choose which ones do or don't :o)
I thought exactly the same thing, but then I realised that doing it selectively isn't so important if you can do either a single port or all ports.
If you think about it, publishing 15 out of 20 ports on a patch all the way to the top level can be a real pain, but UNpublishing 5 all the way to the top is easy, you just unpublish on the patch and it sorts itself out. So if you could publish the lot, it would be pretty trivial to sort out what you didn't want.
Mr. Wright, is any of this even remotely possible, and even slightly on the cards? Or are we having another of those pointless "we want" discussions I'm sure you like so much? ;D
don't worry, I want this too -- however, I'm going to put some cards on the table:
It's actually apparently rather difficult for a plugin to find out what patch (or patches) the user currently has selected in the top-most editor. (This was researched for PerformanceInspector, and no feasible solution was found -- that said, PI has some crunchy time/cleanliness constraints that KinemeCore doesn't have to worry about, so maybe there are alternatives.)
Programmatically publishing a port isn't too difficult (assuming the patch/patches can be isloated, see above).
Modifying the menu the user sees when right-clicking a patch seems more difficult than figuring out which patch is selected -- the menu isn't in any nib, binary, or related file that I could find (in a quick recursive grep of the app and framework), and it's impossible to modify what you can't even find. Making a menu-item (and keyboard shortcut) out of it isn't a problem, but it's not a smooth workflow.-- smokris unraveled this.That's my story, and I'm sticking to it :)
That was my first thought... I was thinking "how the hell could you modify the right click menu anyway?"
Keyboard shortcut ... "command-PU" .....as in peeeeyeeewww what a "skanky" idea.
My totally wrong guess (probably) theory is that the bubble is part of Finder :o)
We can modify menus via interception of events, but we have to know where to look (right click doesn't always mean "Make the publish menu", for example). If we could find the resource, we could watch where it gets used, and go from there. But since we can't find that, there's a lot of guessing necessary to track it down. (it's probably not all that hard actually, since the NSView subclasses likely handle this -- we just haven't looked at the editor views for much more than "turn transparent, to look cool!", which is stupidly simple.)
The actual graphics for it (rounded corner stuff) is part of AppKit or CoreFoundation or some such (not useful, since we're not actually modifying things that deeply :)
This works for me:
(However I know poseAsClass is deprecated.. you probably know of a better way to do this. hopefully this will help you on your journey.)
... this is very reminiscent of an older thread from around here!
http://kineme.net/Discussion/ProgrammingQuartzComposerPatches/Howdrawyou...
Of course, had I actually looked at the methods, I probably would have noticed something obvious like "MENU" in there... sigh thanks smokris! :)
(yes, poseAs is deprecated in leopard, and even our category tricks used currently don't work in Snow Leopard's 64bit runtime [smokris' eyes only: see commit logs for notes on that ;)]... Do I sense a cat & mouse game? ;)
Ok (I'm so excited, I'm all jittery :)
So, to perform the publish thing, I decided to use the built-in publish code, and iterate over each input/output port (inputs only at the moment, since I was just doing some testing).
What happens is this (man, I wish I had some good screen capture software...):
You select "Publish All Inputs" Then for each port, you get to edit the title as it's published. If you just press enter, it's the default. If you press escape, it aborts publishing. Thus, you can fully publish an N-input patch with N keystrokes (enter or esc), and selectively enable/disable each one.
Next up, outputs (same code, different enumeration), and then maybe publish to root (that's a bit trickier).
Please heap on some additional requests, to make 0.4 worthwhile :)
[And actually, the class we were interested in was GFNodeActor, not GFGraphView... a tiny bit in both, but GFNodeActor does all the heavy lifting]
As I said before, duplicate patch with connections. I know it's only practical for input ports, but it'd save a ton of time :)
Also, performance inspector.. I just came to optimising something, and realised how much it's needed!
I'm myself optimizing a (sigh*) HUGE patch atm. , and found that a performance inspector would be tremendously usefull. Esp. when you have nothing running on screen and the FPS is only around 40 ..... !
Here's a quick Screenie (all new options are functional -- a beta release is in the pipe, awaiting a drupal bug fix...)
[typo, of course, is corrected in the beta ;)]
THX chris and Smokris ! this is enormously cool.... What a future time saver feature ! I love kineme !
Written and released in mere hours! Amazing! Again! :D
I'd love to see the drag + drop to macro too btw. But.. I think for that to be really useful, it should keep the connections, otherwise it's only marginally more useful than cut + paste.
That's a bit more difficult, but I guess if you can determine which patch(es) are being dropped, you can determine their connections, and publish + connect the right ports. Possible?
I believe it's possible, but it's tricky. All of these tricks require re-implementing portions of QC's editor with additional hooks for our new features. This requires lots of book keeping (to make sure we're feeding everything what it expects to be fed), and lots of reverse engineering to see find where the data is that we need. For simply publishing/splitting inputs, we just need a single patch, which is conveniently handed to us. For Drag+Drop, there's a whole slew of methods (an Informal Protocol, in cocoa parlance) that we need to hook and reverse. Then, after that, we need to successfully traverse each port to get connection info (not too difficult), and connect things properly back up, publishing where necessary (publishing = easy, connection making is hopefully similarly easy, but it's never been done by us before...)
Just been trying out the latest Core beta. The 'Splitter to all inputs' feature is BRILLIANT!! Thanks so much for that one- it will no doubt save me lots of time in the future.
I feel churlish mentioning it, but one little tweak that would make the function even cooler (and I don't know if this is possible): it would be great if the newly-created splitters weren't on top of each other. I know this is the standard behaviour when they're created one-by-one too, but I've always found it really annoying to have to move them all. Maybe they could appear in a vertical stack, with a little bit of space between them, vertically-centered on the center of the patch/macro they're attached to. Just a thought.
Great work, though!
a|x
I love English vocab :)
Researching how to programatically move patches around, to prevent that from happening (I noticed it too) -- moving stuff requires us to find out where our connect goes, patch-wise, and then modifying it. Both should be easy, but again, these parts are Deep in the belly of the QC Beast...
Well, I grew up listening to BBC Radio 4 (talk radio for intellectuals), so I imagine my vocabulary is nearer to the average middle-class, post-graduate-educated, middle-aged English person than most of my peers.
a|x
Catholic private school for me... my english teachers would abhor my constant bastardization of sentence structure and use of "...", "dunno", and other bad habits. I know better, I just no longer care! Yesterday I made a post to the quartz-developer list and used "a" instead of "an". I noticed this as I hit enter and felt an immediate pang in my heart, heheh. ( I am having sentence diagramming flashbacks.. noooooooooo!)
I think this is slick... I had gotten to where I was doing serious "speed editing" on stuff like this, but this does really save some time, and the way it sets you up to publish each port is extremely handy.
...and it skipped over the noodles! Thanks for that.
it was a good idea you had, and pretty easy to implement too, while I was at it :)
Thanks so much. This is a really helpful tool.
Separately, but on the subject of port publishing; is it currently possible to change the published ports listing order without republishing all the ports? Seems like that capability ought to be available in QC somewhere, but I've never found it. It's quite inconvenient to have made a simple port name modification and then to have had that port drop to the very bottom of the listing of all the published ports.
cmd-I on the patch in question. cmd-3 in the inspector panel. (this should bring up published inputs/outputs).
You can re-order them from that window by dragging and dropping (I think you can also re-name them too, without disconnecting noodles)
Excellent! Thank you.
big step Thanks.... Daniele
This is actually rather exciting -- I'm glad it's helpful so far.
I'm working on publishing to root -- it's a bit trickier than it sounds (for example, when publishing, we get prompted for the name -- by extending this, you'd get prompted for the name at every level, which would suck), but I'm making progress.
As a side effect, I've worked out how to publish ports without asking for a name -- would a Publish Without Asking option be useful too?
i think the menu is going to get too long. the obvious way would be to just ask for it once (the first time) and then go with it. that would save the most clicks (time) and make the option work as it sounds (click once, get to root).
So, if you select publish all, it would work as current. However, if you selected publish to root, it would work almost as current, except bumping you to the top level, where it asks just once?
I like that! But I do kinda like both options. Is one extra option going to make the menu too long? :o(
no level bumping -- that would be disorienting to the user ("Where am I!?"), and we've not mastered how to correctly change levels programatically anyway (I've got some leads, but there are lots of things changing at that point, and testing them all is somewhat time consuming).
Remember that these options will come in pairs: one for inputs, one for outputs.
current beta actually already handles publish to root -- it prompts at the current level, and then reuses the name all the way up to root. I figured that was easiest, code-wise, and made the most sense.
Which is the most current right now(advanced, feature wise), the release or the beta? I am losing track!
I think it's awesome as is actually.
the current betas are more advanced (they're marked with their long build number/date, 20090128), and the release they're working towards (0.4) -- hence, 20090128 (0.4). It's a mouthful, but it provides information on several things: when it was last built, which release will outdo it, and which beta is newest (20090128 is newer than 20090127, etc. bigger numbers = newer).
If you plan on using publish to root functionality, I highly recommend trying the latest -- it's a new, experimental feature, and it needs some real-world testing to really prove it as workable. otherwise, it's just small tweaks that may or may not matter.
Good point, I was thinking that before I posted but figured I would chime in with that anyway :o)
.. but after I posted, I realized that idea what would probably be the best twist on that would be a "publish all open ports"; as in, publish all ports that aren't connected to "noodles".
oh, I like the "noodles" addendum -- good idea (and possible, if I recall correctly :) -- as in, we can ask ports if they're connected, and Do The Right Thing (all previously mentioned Really Hard StuffTM is still Really Hard)
...Spike Lee might sue you :o) At least you didn't put your ™ on "Do The Right Thing", 'cause that's a Spike Lee joint if I recall correctly.
Super extra cool! This is a good one...
i always wished for a way to drop things into macro patches. like, you would select all the patches you want to put in a 3d transform for example, drag them (maybe hold down some key) and let go of the mouse over the macro patch. this would put all the stuff in and preserve the connections to stuff thats outside by publishing the needed ports. The opposite would be to select all the stuff you want to move one level up and chose a 'move one level up' from the menu.
im sure this is out of the the scope for the kineme core because of:
"It's actually apparently rather difficult for a plugin to find out what patch (or patches) the user currently has selected in the top-most editor."
but i thought id throw it out there just in case this changes :). it would be just too cool to have.
this would be great too! (I want this as well, though I never thought about it till you brought it up :)
finding the selected patches can be difficult (smokris might have found a way to discover if just one is selected), but looking up a patch by coordinate is easy (we can feed the editor a point, and it'll tell us which patch is there, if any). I think drag/drop events will also contain which patch/patches are selected, making that part not too impossible as well.
Only hang-ups: overriding drag&drop can be tricky, and handling noodles. Ideally, noodles would get auto-published and re-connected both inside and outside when necessary. That's a lot of bookkeeping, but not outside the realm of possible :)
(I wonder if apple's lurking on this thread, silently adding stuff to snow leopard? :)
Drag and Drop into macros would be great. I've often wondered why this wasn't a normal behavior in QC.
Discovered how to capture exactly which patches are selected in the editor (it's sorta ugly -- you have to iterate over all of them), so I'm now focusing on adding support for that to PerformanceInspector (after a quick drive across town to take care of some paperwork)
You and your darn iterators! It amazes me the stuff you have pulled off with iterators.
...but if they aren't even sure what something as simple as TUIO is, would they even understand what we are talking about? (oooh, I am bad bad bad.... HALF joking here)
Troy wasn't sure what it was, but Alessandro was, so Apple's divided, as far as stats go. From the looks of it, Alessandro's the more artistic one (i.e. uses QC for art, makes graphics (see the tiny .xX signature on the QC icon sometime)), while Troy appears to be more of the developer type.
To be honest, I had no idea what TUIO is (and I still don't, really), and I EVEN DID THE INITIAL LEOPARD PORT OF IT (QC-wise, I didn't actually touch TUIO at all)! :)
Earlier, there was a UI Job posting to QC on Apple's website, so, depending on if they got a talented engineer or not, things could be rather smooth in Snow Leopard. (I know that stuff looks fairly different)
Lol, I know I was being unfair with that, but I can't help myself sometimes :o) I guess if it was me, I would friggin' look the thing up, rather than hit a response to the whole world that is "well I guess I could look it up, but I'm not going to..."....then responding with 0% useful commentary. (yes, this is somewhat of a "flame" and it is juvenile in a sense, sorry... but I can also step out of "my" shoes and just as easily see Troy's point).
I noticed that listing actually... there have been a couple/few qc related listings in the past couple of months.
I understand the POINT of TUIO when used with an actual table top, but I feel like an ass using an emulator on a laptop (seems ultra pointless to have an emulator besides for testing)... after about 5 seconds I'm going "why isn't this just hooked up to a mouse or trackball"?
I thought that it was weird when I was looking through online posts that someone referred to the "kineme tuio" patch, and that there wasn't one here. I have a TUIO patch, but here I was assuming it was standard API because of the way that it is listed as a "plug-in" (though I know that doesn't have to be the case!).
if a patch is in a consumer macro, the publish output options should be grayed out. it causes an error if you try to publish them.
yeah, you're right (I came across this in testing once, and didn't think twice about it...) -- I'll make that change.
(also, another bug: publish all to root, then hit esc on some of the inputs -- it still tries to publish ports, but it ends up picking the wrong ones... I've just fixed that as well).
On a different note (but while we're discussing cool impossible features), how does everyone feel about single-step rendering?
As in: instead of setting the framerate in the preferences, you also are able to have the viewer just render a single frame, and wait indefinitely (so you can inspect the state of all patches on a per-frame basis).
I've just come across a weird composition where this would be invaluable for debugging (some patch is providing output a single frame too late, but it's difficult to track down which one, and even at 10fps it's too fast to catch the culprit).
A work around is to attach everything's output to a billboard and render in QuartzCrystal or something, but that's lame.
This sounds invaluable!!! I like QC realtime stuff, but I also think it is valid to use it for stuff that is strictly offline bound... where the renderer is skipping from 1fps to 6fps, to 30fps, and you aren't really seeing every part of the motion that reliably. It sounds like that would be a much better way of inspecting compositions that have really variable fps. You are talking about using it to slow something down, but it seems like it could be used for these scenarios as well from what you describe. I'm pretty floored by that possibility actually... it really opens up many doors.
Yep, I'd find this very useful too.
For example, lately I've been doing some fun stuff with feedback + video, and trying to record a video of it with crystal. Problem is, the video plays at a fixed 30fps, and the composition as a whole might play at 15fps in places. Feedback is a per-frame effect, so what tends to happen is that the effect plays 2x faster in crystal while the video stays the same. It'd be useful if the video could advance in a per-frame way too.
On a side note, I have a case where I need something like value historian (but a lot simpler) that can capture at a very high frame rate (i.e. it might capture 200 samples per frame from mouse/tablet input, and output say a structure of 4 samples per frame). I'll write a plugin to do it, but just wondering if there's a need for such a thing in general?
recording more than one sample per frame would be exceptionally handy -- not really possible for mouse/keyboard events (since they're delivered on a per-frame basis to the composition, unfortunately), but for patches that get data from other sources, this could be an extremely handy feature.
I'm find the one-frame render thing handy, I'm sure. Great idea!
a|x
This will certainly make isoRaytrace animations a more streamlined process. :o)
Ok, just implemented this.
basically, it'll pause (not stop!) the top-most viewer window. Then, you can step in 1/60th second increments. And, of course, you can unpause when you're done. The editor's ports are all left in the state that the composition's in while paused/stepping.
Helped track down the culprit -- apparently the Pulse patch sometimes takes an extra frame to catch trailing edges.
I'll probably make another beta in a day or two, unless y'all want me to get this out Right Now ... 4 betas in 4 days is a bit insane :)
You are really cooking. Interesting note about the pulse patch. I'm just really surprised that this has ended up covering so much ground. These updates have been fairly enormous.
I don't know what happened -- the perfect mix of time, feedback, and luck combined to smile upon kineme this week I guess :) (and behind the scenes, I finished PerformanceInspector). A very productive week :)
Thanks everyone for their support, feedback, and great ideas.
(sorry about the drag+drop macro stuff.. that's a difficult thing to do, but it's still on my hit list eventually :)
I haven't found any official place to comment about PerformanceInspector yet, so I thought I'd offer some appreciation for that feature at this juncture.
I mostly just muck about and try various combinations of patches with the sole goal of achieving visual interest and, in all honesty, I would never have been able to sort out patch efficiency factors on my own. Additionally, PerformaceInspector provides an insightful compositional overview that is not always readily apparent from merely observing the composition in its default context. In that regard, it seems creatively useful because it can encourage the consideration of alternative patch options and placements. Thanks so much. PerformaceInspector is a wonderful tool.
Now.. Can you make it step backwards?
:^P
Not to bring US politics into kineme, but "Yes We Can."
State stuff might not be sane (as in, frame counters won't count backwards), but stepping backwards in time should be easily possible.
This sounds super useful. Being able to step through frames sounds super-useful for some of the JavaScript stuff I'm doing - debuging in QC can be a nightmare.
Could you elaborate on the Pulse bug a little? I think I may have run into that in the past.
I'm not entirely sure of the circumstances, but the setup was something like this:
Interpolation 0-x -> Pulse (trailing edge) -> enable
When the interpolation time goes from duration-tiny_amount to 0 (reset), the output drops to zero, but the pulse patch doesn't register the drop from almost_x to 0 until the frame after ... I'm not sure if that's accurate at all, but that's what it looked like in a 10-second inspection.
This would explain a few problems I've had in the past, when trying to trigger things with pulses (usually with some kind of feedback loop). All kinds of strange behavior tends to happen, so I gave up and wrote some javascript to do the same job. I always wondered why it didn't work :)
this one to long for me to read the whole thing right now but, i think publish all is great option, at least for the particular patch selected. also publish all out would be good as well for patches that have constraints on them like iterate. would be nice to actually get the result returned back to the upper level.
I've seen this comment before... and I'm really ignorant of the way that other node based programs that are similar to QC work- is this a standard option? If you find yourself needing a value from something that is inside the iterator, can't you just have that part actually be outside of the iterator, and publish the input ports of the chain that remains inside the iterator...then make necessary attachments, etc? You can even just copy whatever part of the chain that you are wanting values/images from and plop it on the level you need that is outside of the iterator if you don't feel like going through cutting part of the chain/placing it outside of iterator/publishing inputs from chain inside iterator... and then having whatever outputs you needed available. Does doing that miss some kind of options that are in other programs?
I've found another case of minor annoyance:
Let's say you have 15 patches with 1 output each, and you want to publish all the outputs. This currently requires 15 clicks, even with the publish all inputs function, because those only work on 1 patch at a time.
I've worked out how to address all selected patches, so, if anyone's interested, I could modify the publish-all options to actually publish all from the currently selected patches. I'm likely going to do this anyway, for my own use, but if there's some interest out there, I can try a bit harder at getting it released :)
Actually I ran into this tonight working on my composition. I was thinking "gee wouldn't it be nice if..."
So yes, I think this would be swell.
please go into this... one of my nightmares...
I would use it.
It seems really useful, i'm interested !
Yes please, I could of really used such a feature last weekend when building a dodgy sequencer with 3D UI.
That would be great.
Here and other threads this has been asked for and from memory cwright said quite tricky... option dragging for duplicate with input noodles duplicated would be another implementation of same that would be great.
Anyway, spooky patch delivers one nice workaround i discovered (for those who don't do this already). V good for when you need to change a macro/iterator internals and then delete all previous copies and make (say 10) duplicates. With spooky you don't have to rewire every duplicate every time you edit inside. Save a bunch of re-wiring.
So glad for the publish-to-root, insert-splitters and so forth, that stuff was a pain without KinemeCore. Option-Drag duplicate would be icing on the cake!
I did my best to read through this, and researched the site. I am trying to get an input splitter that is two macros down to be published on the top (root?). That's what "publish all inputs" is meant to do right? If it is, is there a way to implement this that I missed? If I'm way off base, how do I get my published input splitters from deep in macros to show up (in VDMX)?
Next item in the Menu down is "Publish all Inputs to Root". Use that one. Return to confirm, escape to not publish as you work through the inputs.