Publish all inputs function

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 ?

cwright's picture
tricky

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. :)

toneburst's picture
Yes, Yes...

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

yanomano's picture
Yes !

Yes in the KinemeCore menu ! Yes publish all inputs to root ! ;)

DanieleCiabba's picture
and publish to root level?

and publish to root level? please....

psonice's picture
Sign me up!

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 :/

franz's picture
+ 1

publish to root !

cwright's picture
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)?

fsk's picture
if i had to chose one of

both?

cwright's picture
so 2 items then

So there would be a "publish all inputs to root", and "publish to root -> [each port]"? that's possible.

toneburst's picture
Both

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

cwright's picture
menus

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).

toneburst's picture
Yeah..

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

cwright's picture
agrees

I agree :) (it's in the works :)

cwright's picture
skippage

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...)

leegrosbauer's picture
enough, and generous too

cwright wrote:
... 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? ...

For me, yes indeed. That seems like an excellent functionality.

toneburst's picture
Sounds

like a good solution to me, too.

a|x

gtoledo3's picture
Yeperooni. Great idea...

Yeperooni. Great idea... best way to implement it.

gtoledo3's picture
As long as we are wishing

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)

psonice's picture
Nice, but maybe not necessary

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

cwright's picture
_I_ want

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 :)

gtoledo3's picture
duuuude...

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)

cwright's picture
interception

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 :)

smokris's picture
GFGraphView _menuForNode:

This works for me:

@interface KinemeLocalNodeActor : GFGraphView
- (id)_menuForNode:(id)fp8;
@end
 
@implementation KinemeLocalNodeActor
- (id)_menuForNode:(id)fp8
{
   NSMenu *m = [super _menuForNode:fp8];
   [m addItemWithTitle:@"New Menu Item" action:nil keyEquivalent:@""];
   return m;
}
@end
 
...
[KinemeLocalNodeActor poseAsClass:[GFGraphView class]];

(However I know poseAsClass is deprecated.. you probably know of a better way to do this. hopefully this will help you on your journey.)

PreviewAttachmentSize
GFGraphView-menuForNode.png
GFGraphView-menuForNode.png18.11 KB

gtoledo3's picture
pose as...

... this is very reminiscent of an older thread from around here!

http://kineme.net/Discussion/ProgrammingQuartzComposerPatches/Howdrawyou...

cwright's picture
ah ha!

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? ;)

cwright's picture
ZOMG !

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]

psonice's picture
0.4 request

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!

franz's picture
+ 1 perf. inspector

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 ..... !

cwright's picture
Status Update

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 ;)]

PreviewAttachmentSize
MenuAdditions.png
MenuAdditions.png43.89 KB

yanomano's picture
:) so bad you're already married ;)

THX chris and Smokris ! this is enormously cool.... What a future time saver feature ! I love kineme !

psonice's picture
<3

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?

cwright's picture
prossibly

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...)

toneburst's picture
Publish All Inputs

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

cwright's picture
churlish ;)

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...

toneburst's picture
Vocab

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

gtoledo3's picture
Catholic private school for

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!)

gtoledo3's picture
I think this is slick... I

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.

cwright's picture
*tips his hat*

it was a good idea you had, and pretty easy to implement too, while I was at it :)

leegrosbauer's picture
Extremely useful

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.

cwright's picture
Drag and Drop

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)

PreviewAttachmentSize
Reorder Publications.png
Reorder Publications.png75.08 KB

leegrosbauer's picture
Excellent! Thank you.

Excellent! Thank you.

DanieleCiabba's picture
big step Thanks.... Daniele

big step Thanks.... Daniele

cwright's picture
no prob + ?

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?

fsk's picture
menu length

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).

gtoledo3's picture
i sees it both ways

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(

cwright's picture
ex post facto

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.

gtoledo3's picture
Which is the most current

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.

cwright's picture
betas

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.

gtoledo3's picture
Good point, I was thinking

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".

cwright's picture
ooo

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)

gtoledo3's picture
Watch out!...

...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.

jersmi's picture
Holy sh*t!

Super extra cool! This is a good one...

fsk's picture
drag and drop to macros

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.

cwright's picture
awesome

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? :)

mattgolsen's picture
Drag and Drop into macros

Drag and Drop into macros would be great. I've often wondered why this wasn't a normal behavior in QC.

cwright's picture
multi-selection

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)

gtoledo3's picture
You and your darn iterators!

You and your darn iterators! It amazes me the stuff you have pulled off with iterators.

gtoledo3's picture
...but if they aren't even

...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)

cwright's picture
Troy

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)

gtoledo3's picture
Lol, I know I was being

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!).

fsk's picture
small bug catch

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.

cwright's picture
good find!

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).

cwright's picture
off track

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.

gtoledo3's picture
This sounds invaluable!!! I

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.

psonice's picture
Useful

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?

cwright's picture
super-recorder

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.

toneburst's picture
Sounds Handy To Me too

I'm find the one-frame render thing handy, I'm sure. Great idea!

a|x

gtoledo3's picture
This will certainly make

This will certainly make isoRaytrace animations a more streamlined process. :o)

cwright's picture
done

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 :)

gtoledo3's picture
respect

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.

cwright's picture
Definitely

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 :)

leegrosbauer's picture
PerformanceInspector

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.

smokris's picture
very cool.

Now.. Can you make it step backwards?

:^P

cwright's picture
not to get political

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.

kristopf's picture
This sounds super useful.

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.

cwright's picture
pulsation

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.

psonice's picture
Pulse problems

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 :)

dust's picture
publish all

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.

gtoledo3's picture
I've seen this comment

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?

cwright's picture
Multiple Publishing

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 :)

mattgolsen's picture
Actually I ran into this

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.

DanieleCiabba's picture
one of my nightmares...

please go into this... one of my nightmares...

leegrosbauer's picture
yes, please

I would use it.

mfreakz's picture
Good option

It seems really useful, i'm interested !

SteveElbows's picture
Yes please, I could of

Yes please, I could of really used such a feature last weekend when building a dodgy sequencer with 3D UI.

gtoledo3's picture
That would be great.

That would be great.

usefuldesign.au's picture
Re: Publish all inputs function

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!

PreviewAttachmentSize
Picture 22.png
Picture 22.png368.43 KB

gabemott's picture
Re: Publish all inputs function

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)?

usefuldesign.au's picture
Re: Publish all inputs function

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.