PDA

View Full Version : Maestro panels and LScript controls



dballesg
08-10-2010, 02:34 AM
Hi,

Form this thread:


Maestro test (http://www.newtek.com/forums/showthread.php?p=1046395)


We did have popups and buttons working along with the glyph... we took them out but I don't remember why specifically. I don't remember if it caused a technical problem or if it was for aesthetic reasons. I vaguely recall some silliness involving the window redraw that caused a major slowdown when using it... but that may not be related to this particular post.

Having the pop-up or buttons on TOP of the image really create a redrawing mess on the interface, nothing that can't be solved with a bit of design, that is why I have the pop-up on my example out of the image area.

But that can be done in Maestro as well. Leave small horizontal area where those controls can be put so they don't interfere with the Glyphs. And why use Glyphs, instead of image controls? Any other LScript technical reason.


We also found you cannot use more than one non-modal panel with mouse events at a time or Layout would lose track of which window is actually sending mouse events.

Fogbugz?



I'm not 100% certain I understand what the challenge is so I'm not sure if my answers are helpful. Heh.

Well you programmed it! ;) Maybe is time to consider to port Maestro to a C formal plug-in?? Only the speedup benefits will be worthy.

David

littlewaves
08-12-2010, 03:56 PM
Does porting it to a C plugin mean that like all other C plugins I end up begging them to make it work on the Mac too?

dballesg
08-13-2010, 12:14 AM
Does porting it to a C plugin mean that like all other C plugins I end up begging them to make it work on the Mac too?

That will depend if they support the Mac paltform. I'm not doing the port, I only suggested it. But I do not think Eric or Brian are really interested on porting it.

David

NanoGator
08-23-2010, 09:23 PM
What problems would porting it to C alleviate? (Sorry, haven't had time to catch up on the thread...)

geo_n
08-23-2010, 11:09 PM
Would porting it to C allow it to not be affected by future builds of lw hc like the viewport slowness a few builds pre lw 9.6? I've pmd eric about the lw hc maestro problem and its been fogged.

dballesg
08-24-2010, 12:39 AM
What problems would porting it to C alleviate? (Sorry, haven't had time to catch up on the thread...)

I think one of them will be to speed up the timeline. The second one is the different viewport slowness that we suffered specially from 9.6 as geo said.

But that is a bit of wild guess on my side. Someone suggested on the Maestro Test (http://www.newtek.com/forums/showthread.php?p=1046395) thread that it could be due to the LightWave expressions system?

But Maestro suffered a lot from that viewport slowness. Specially from 9.3.1 to 9.6.

David

ericsmith
08-24-2010, 10:25 AM
But Maestro suffered a lot from that viewport slowness. Specially from 9.3.1 to 9.6.

actually it was 9.2 - 9.3. It was fixed in 9.5.

But in the bigger picture, whether Maestro is done in Lscript or C, it still has to integrate into Layout's process. The interaction problem was a Layout re-draw issue, and it wouldn't have made any difference if Maestro was coded in C. Even the graph editor suffered the same problem, as I recall.

I think any timeline slowdown issues are subject to the same limitations. Brian knows more about this than I do, but the basic thing is that in order to access a keyframe at a particular time, we have to cycle through every keyframe in the object and do a time comparison to see if there's a match. It has to do with the way data is structured in LW. Now it's possible that a plugin written in C would execute faster, due to not having to parse on the fly (although I could be totally wrong about this), but that wouldn't necessarily make the kind of difference that we would need to overcome the basic inefficiency of the data structure.

It's also possible that our own code is not doing things the most efficient way, and a different approach could make things much faster. But that's the nature of programming. You try to find a solution to make the code do what you want, and there's almost never just one way to get there. That's why big software companies are constantly optimizing code, and getting speed increases along the way.

Eric

dballesg
08-24-2010, 02:10 PM
I will need to look into the SDK to see how it deals with keyframes. At creation, delete, etc level. To see if it could be faster.

But if you code is parsing every keyframe of the object, a direct port to C will do the same. I think it will benefit of a slight speed increase between C and LScript.

Anyhow I will be a happy camper if Brian can implement a menu as the one I showed on the first post that allows to have User rigs on an User directory, and do not mess with original Maestro content.

BTW I always thought that for being a LScript Maestro it's quite fast, for all the many things it does, really a cleverly coded LScript.

David

NanoGator
08-24-2010, 06:58 PM
I don't think the viewport slowness was Maestro's problem. If anything, it was too fast. It sent update commands to layout faster than it could draw them. The result was Layout would bog down trying to catch up.

The code itself is pretty direct and to the point. The only slowness I encountered was drawing the key editor, and the following generation of processors (2006) fixed that. I'm not sure what going to C would buy me right now except more window/viewport drawing capabilities. I'm not certain, though, that it'd actually fix that Layout slowdown issue unless there's some access I don't have in LScript to tell Layout to take a breather.

dballesg
08-25-2010, 12:37 AM
I don't think the viewport slowness was Maestro's problem. If anything, it was too fast. It sent update commands to layout faster than it could draw them. The result was Layout would bog down trying to catch up.

The code itself is pretty direct and to the point. The only slowness I encountered was drawing the key editor, and the following generation of processors (2006) fixed that. I'm not sure what going to C would buy me right now except more window/viewport drawing capabilities. I'm not certain, though, that it'd actually fix that Layout slowdown issue unless there's some access I don't have in LScript to tell Layout to take a breather.

That is why I said I always considered Maestro a very nicely done script :thumbsup: So forgot to go to C or C++.

Now about that user's rigs directory... :D

My original idea was that Meastro read on startup a directory that we can set on it's options (so for example all the personal rigs can be on a external hardrive, another directory, or even a network server).

Then it makes a list with the sub-directories found on it. Inside of each subdirectory there will be a structure as this:


<User Dir>

<My Rig 1 sub dir>


Background_Images
Controller_Configs
Rigging

Maybe more directories needed



Inside the My Rig 1 sub dir search for a .NGF file, that one can contain a command that tell's maestro the name of the rig. So Maestro get's the name, add's it to it's internal list and put it on the popup with the other Maestro rigs. Then when the user select one rig of the popup, Maestro simply executes the .ngf file found.

What do you think?

David

NanoGator
08-25-2010, 10:37 PM
Dang, I intended to acknowledge you said that and failed to. I'm sorry, man.

It's possible but right now I'm working 60+ hour weeks across two different movies, probably for the next month. (Although it's hard to tell.. Hollywood time is less reliable than a plumber's estimate...)

dballesg
08-26-2010, 12:20 AM
Dang, I intended to acknowledge you said that and failed to. I'm sorry, man.

It's possible but right now I'm working 60+ hour weeks across two different movies, probably for the next month. (Although it's hard to tell.. Hollywood time is less reliable than a plumber's estimate...)

Hi Brian,

Understandable, not on a rush, and thanks for consider to implement it.

David