PDA

View Full Version : seeking advice: Evenflow's "ef_staticChannel.ls" -- suitable for Motion Modifier??



jeric_synergy
10-03-2012, 10:58 PM
Evenflow's "ef_StaticChannel.ls" , found here:

http://lwplugindb.com/Plugin.aspx?id=01d85414

..is a channel modifier.

Is it a good BASE from which to construct a Motion modifier? I crave this functionality, but I'd like it on ALL channels in one swoop. I have ZERO idea what it takes to script a Motion modifier, but it seems a lot of the pieces might be in there.

Thanks!

evenflcw
10-04-2012, 07:32 AM
Why not ask me directly, via my email, as suggested at the top of the same page you got the script or the included readme file? It is the most immediate and sure way to get hold of me, other than slapping me across the head irl.

Yes, you could likely re-purpose the code and make a motion modifier that does exactly the same thing for all channels under the item. From a first look, it might be as easy as extending the global variables to be able to hold more data and looping through all channels calling the MaintainStaticChannel-function in the process callback.

There is however the question if one should and what the right way to implement this is. Motion Modifiers shouldn't perform keyframing operations on channels (as this does), especially not during a phase (motion evaluation) where none is expected! Then again, neither should channel modifiers! Both should just be modifying values in a dynamic fashion (without modifying underlying value in envelope). Which is why I released this as "experimental". If one is to use this system in a production environement I would suggest mixing in a Layout Master script to perform the operations when it could be considered more safe to do so (before/after motion evaluation phase).

I'll try to have a look at that later today or tomorrow if that's ok with you.

FYI. For those that might wonder why I did not use the built in channel/envelope event structures, it's because they didn't work proper. They aren't invoked on all channel/envelope events from all environments (GE, Layout). SDK is better in this respect, Lscript is useless. Neither is complete and 100% reliable.

jeric_synergy
10-04-2012, 08:16 AM
Why not ask me directly, via my email, as suggested at the top of the same page you got the script or the included readme file? It is the most immediate and sure way to get hold of me, other than slapping me across the head irl.
I sincerely apologize if that offended you, I certainly didn't mean to. I do have reasons (really!):

1) I figured you are probably busy,
2) ...and that asking the crowd might get a faster response, because
3) it's just part of the ongoing conversation within the community, and
4) that asking in public would alert many who might not have heard of the plugin of its existence, and
5) that it (and many other scripts out there) is open source and hence amenable to modification, and
6) can serve as educational material (nice commenting! Really.) for those attempting to learn LScript, but
7) also someone might have heard of a script/plugin that already does what I want, and
8) this is just a way of chumming the waters of conversation here on the forum.

Also, I didn't see the note at the top of the page. :foreheads

Yes, you could likely re-purpose the code and make a motion modifier that does exactly the same thing for all channels under the item. From a first look, it might be as easy as extending the global variables to be able to hold more data and looping through all channels calling the MaintainStaticChannel-function in the process callback.
I'm learning stuff already!!! :D

There is however the question if one should and what the right way to implement this is. Motion Modifiers shouldn't perform keyframing operations on channels (as this does), especially not during a phase (motion evaluation) where none is expected! Then again, neither should channel modifiers! Both should just be modifying values in a dynamic fashion (without modifying underlying value in envelope). Which is why I released this as "experimental". If one is to use this system in a production environement I would suggest mixing in a Layout Master script to perform the operations when it could be considered more safe to do so (before/after motion evaluation phase).
Hmmmmm, that sounds more like a religious question: who is defining what MM's should/should not do? As it stands today, the script does EXACTLY what I'd like, very much like the "stopwatch" toggle in AE, and all it lacks is convenience of application. --really, if the solution were a plugin that just automated applying the existing script to all the channels (i.e. 9 operations), that would fine with me. A corresponding one that removed the script would be desirable. Then usage would be VERY comparable to AE's 'stopwatch' toggle.


I'll try to have a look at that later today or tomorrow if that's ok with you.
I would be delighted if you EVER took a stab at this. :bowdown:

FYI. For those that might wonder why I did not use the built in channel/envelope event structures, it's because they didn't work proper. They aren't invoked on all channel/envelope events from all environments (GE, Layout). SDK is better in this respect, Lscript is useless. Neither is complete and 100% reliable.
See? Edumacational, that is.

BTW, why I'm wanting this (on the off chance it matters to the structure of the script): when you are shaping a spline with nulls using DPKit's Spline Deform Node, it's desirable to be able to move the nulls and have them autokeyed, but not animated. One is usually moving the nulls at times away from Frame Zero, and having to continually input ZERO into the makekey dialog is a huge PITA.

evenflcw
10-08-2012, 06:55 AM
Sorry. Some happy and some sad events got in the way of this. I will look at this later in the week.

jeric_synergy
10-08-2012, 08:08 AM
No worries! Good wishes!

evenflcw
11-15-2012, 09:34 PM
Sorry Jeric. I had a plan to make a motion modifier which gave you sort of a control center in which you see all channels under an item and apply and remove the channel modifier by simply placing checkmarks. It would have been the simplest and safest implementation imho. Unfortunately, as it happens sometimes you come across lscript features which just don't work right - In this case the function to check for servers on channels, ie channel.server(SERVER_CHANNEL_H, index).

Since 1) the lscript bug stands in my way, 2) I'm pissed and let down by loosing another couple of hours (it's probably a couple of months worth of work over the years) for LW\Lscript\sdk not working as documented or as reasonably expected, 3) writing the same thing in python or c-sdk would not make it as platform or version independent as lscript ditto, 4) very few people seem interested, 5) there is no worthwhile reward (for me) for pressing on... I'm laying this one to rest. It's not worth the effort. Sorry. If anyone else wants to have a go, feel free to do so. If you reuse my code as-is, then either release derivative for free, or give me a small cut and/or license. Them are the terms. (Good luck).

jeric_synergy
11-15-2012, 09:43 PM
No worries, evenflcw, just a big THANKS for looking into it at all! :thumbsup:

I highly doubt I'd be able to ever do any better: anything I'd do would be some sort of ugly hack that just re-applied your existing code to all the channels in some [email protected] way. Just a time-saver.

it IS a workflow that I think many people could get profitably used to, because it's basically how AE works. Everytime AutoKey lays down an unwanted key, it makes me grit my teeth. (Hmmmmmm, there's an alternate approach: just delete every other key besides the one that just got made, and just leave it when it is....)


:beerchug:

Sensei
11-15-2012, 09:45 PM
Unfortunately, as it happens sometimes you come across lscript features which just don't work right - In this case the function to check for servers on channels, ie channel.server(SERVER_CHANNEL_H, index).


What happens wrong?

Did you try

name = channel.server( "ChannelHandler", 1 );

?

index param always starts from 1 in server() functions in LWSDK.

evenflcw
11-15-2012, 10:21 PM
Sensei: I've checked the defined constant, it's defined and with the right string, and I've tried using the string directly. That is not it.

Jeric: Thanks. What you wrote in parenthesis is pretty much what staticchannel currently does.

Do me the favour of confirming the correctness of my code and the manifestation of the bug by trying the following steps. The script will start the debugger... use F10 to execute the next row, observe the variable-watches bottom left.
0) install attached script
1) add null
2) add any motion modifier to null
3) add any channel modifier to null.position.x
4) run script
You should see that it identifies the motion modifier just fine, but not the channel modifier.

jeric_synergy
11-15-2012, 10:56 PM
not exactly sure what I'm doing here, but here's the screen grab after executing the LS:

109184

And here's the scene:

109185

Question: you HAVE a working solution in the original, is there any reason not to craft a routine that just applies the working solution to every channel, simply automating what the user would have to do?

Sensei
11-15-2012, 11:03 PM
Yeah, nil returned..

LWSDK code worked fine:

#include <lwserver.h>
#include <lwgeneric.h>
#include <lwchannel.h>

#include "LWCItemInfo.h"
#include "LWCChannelInfo.h"

#include <windows.h>

XCALL_( int )
Activate(
long version,
GlobalFunc *globalfunc,
LWLayoutGeneric *layoutgeneric,
void *serverData )
{
if( version != LWLAYOUTGENERIC_VERSION )
{
return( AFUNC_BADVERSION );
}

LWCItemInfo iteminfo( globalfunc );
LWItemID itemid = iteminfo.First( LWCItemInfo::typeObject, LWITEM_NULL );
LWChanGroupID changroupid = iteminfo.ChanGroup( itemid );
LWCChannelInfo channelinfo( globalfunc );
LWChannelID channelid = channelinfo.NextChannel( changroupid, NULL );
const char *server = channelinfo.Server( channelid, LWCHANNEL_HCLASS, 1 );
MessageBox( NULL, server, "", MB_OK );

return( AFUNC_OK );
}

ServerRecord ServerDesc[] =
{
{ LWLAYOUTGENERIC_CLASS, "ChannelTest", (ActivateFunc *) Activate },
{ NULL },
};

evenflcw
11-16-2012, 08:21 AM
Thanks both. I'll write up a bugreport... although I'm unsure about the value of doing that for lscript these days. With python supposedly besting it in 11 and on, lscripts main (only?) advantage is backward compatibility... but those bugfixes surely won't be retrofitted, so what's the use!?