Moho Forum

hayasidist wrote:

synthsin75 wrote: ... I don't know what all the bezier "components" mean ...

I think it's an index to the settings for the separate x,y,z handles --

a quick look at a file's internals for a 3d Bezier key (actually layer translation in this case) with a "loop" to the next:


{"im":9,"v1":-1.0,"v2":-1.0,
"b":[
{"ao":0.183271,"ai":-0.152106,"po":0.205828,"pi":0.15657},
{"ao":-0.099733,"ai":-0.035167,"po":0.287141,"pi":0.36332},
{"ao":0.000011,"ai":0.013836,"po":0.386905,"pi":0.315506}
],
"in":1,"h":0,"s":false,"t":0}

So a straight guess from me: component 0,1,2 => x,y,z; no idea what would happen if you tried to set / get one that was greater than the dimensionality of the item..

Better guess than any I had. No idea why just about any component number returns something, even a changing value.

((A complete aside: noted that you have the types / modes in a comment at the end; those are globals with, IIRC, a MOHO. prefix should you prefer to use the constant name rather than the value))

I did that for easy reference. The docs are listed in ID order, but mohoscripting.com isn't. I've already emailed Stan about maybe getting an ID column for Moho constants.
Yeah, I know I could use the names, but some of those "if" statements were long enough already.

synthsin75 wrote: No idea why just about any component number returns something, even a changing value.

another guess based on solid (bad! ) experience in this sort of situation - the table entries are 4 reals wide; so the first one is at offset 0; the Nth one (counting from 0) will be at offset N*4reals - there's no table length checking in lua (or the c interface) so rather than returning nil (or an "out of bounds" table error) you get whatever's in memory at that offset and that's interpreted as a real. Try to write there and that's the thing that crashes are made of.

synthsin75 wrote: I've already emailed Stan about maybe getting an ID column for Moho constants. Yeah, I know I could use the names, but some of those "if" statements were long enough already.

Looks like he's already done that! However... whilst I think it's highly unlikely to happen with moho, strictly speaking the actual value might change over time - e.g. with major releases we might find that (e.g.) MSG_BASE needs to be changed for some reason (with the attendant need to recompile scripts etc or some other compatibility mechanism analogous to the selecting icon types in 12 onwards or legacy curves in 7 onwards). As such the "value" column *strictly* needs to be "value at release xx" and there may need to be additional columns in the (unlikely but not impossible) situation where there's a change. (Oh and maybe drop Stan a note about binary / bitwise values such as LDQ...)

anyway -- the script itself looks good from here, so let's see what happens when it gets put to real work...

If nothing else, those IDs are good reference for scripters, testing the returned values. I'm reasonably confident most developers are mindful of not breaking things, and generally follow the best practice of adding new stuff at higher values.

Hi, thank you very much and sorry for the very late answer.
I could try the script, but sadly can't make it work. I'm getting this message:

Do you know how I could fix that?

Thanks again!

Víctor Paredes wrote:Hi, thank you very much and sorry for the very late answer.
I could try the script, but sadly can't make it work. I'm getting this message:

Do you know how I could fix that?

Thanks again!

Hey Victor, thanks for testing it.

I can verify the problem you're seeing, but I haven't figured out why it happens.

I'm starting to suspect it's an issue with the scripting interface. I'll let you know if I get it solved.

it may be to do with the "all channels" channel (CHANNEL_LAYER_ALL) -- you may need to skip that one or, alternatively, ONLY process that one!?

hayasidist wrote:it may be to do with the "all channels" channel (CHANNEL_LAYER_ALL) -- you may need to skip that one or, alternatively, ONLY process that one!?

I tried that, but it didn't help.

I get the error while trying to use it on a handful of Animation>Copy Current Frame keyframes for the whole document.
It seems like it doesn't really recognize key values until the user has done something, like setting the value with a tool.

Odd.

ok - another idea -- maybe to do with having more than one channel type? (V12 brought in strongly typed channel info) ??

hayasidist wrote:ok - another idea -- maybe to do with having more than one channel type? (V12 brought in strongly typed channel info)

Code: Select all

						if ch:ChannelType() == MOHO.CHANNEL_BOOL then
							chDet = moho:ChannelAsAnimBool(ch)
						elseif ch:ChannelType() == MOHO.CHANNEL_COLOR then
							chDet = moho:ChannelAsAnimColor(ch)
						elseif ch:ChannelType() == MOHO.CHANNEL_STRING then
							chDet = moho:ChannelAsAnimString(ch)
						elseif ch:ChannelType() == MOHO.CHANNEL_VAL then
							chDet = moho:ChannelAsAnimVal(ch)
						elseif ch:ChannelType() == MOHO.CHANNEL_VEC2 then
							chDet = moho:ChannelAsAnimVec2(ch)
						elseif ch:ChannelType() == MOHO.CHANNEL_VEC3 then
							chDet = moho:ChannelAsAnimVec3(ch)
						end

??

I didn't notice that. Good idea, Paul. I'll try that when I have time.

Victor, please check the latest version of my keytools script, it has the CLEANUP option, making what, I suppose, You wanted. Unfortunately it does not check bezier handles, but in some cases it can help.

Yeah, Paul, it seems the problem was not casting the channels as their types. This seems to be working now:

https://sites.google.com/site/synthsin/ ... ects=0&d=1

Hi Wes, looks ok here on multiple channel types.

Hey! thank you very much and sorry for the delayed answer again.
Both scripts are working great! You are awesome. Please, if there's anything I could help you with, just tell me.

Awsome script Wes, thanks for sharing.
There's been hundreds of situations in the past where I would have loved to use this.

I do sometimes see a few hold keys that would be better off removed too. See this example file: CleanKeysHoldExample.moho

Also, support for cleaning up keys in separated XYZ channels would be pretty useful, especially for the Translate layer channel & Translate camera channel.

Lukas wrote:Awsome script Wes, thanks for sharing.
There's been hundreds of situations in the past where I would have loved to use this.

I do sometimes see a few hold keys that would be better off removed too. See this example file: CleanKeysHoldExample.moho

Also, support for cleaning up keys in separated XYZ channels would be pretty useful, especially for the Translate layer channel & Translate camera channel.

Updated script (same link): https://sites.google.com/site/synthsin/ ... ects=0&d=1

Improvements:
1. Added better handling for step keys so it deletes more unneeded hold keys.
2. Figured out how to handle separate dimensions.

Lukas, it won't work exactly like you colored the keys in your example file. It always leaves the last keyframe in a channel, but if I got enough feedback that that was undesired, I could change that. And if you use that file to test separate dimensions, the z-axis is unchanged, so it will only leave the last key on that channel. Still doesn't handle camera channels.