[jitter] Re: metro sometimes unstable not accurate movie playback

On Jan 3, 2008, at 10:18 AM, Leo Mayberry wrote:

> I think that last response is a little harsh.  I think the longer  
> you use Jitter the more you learn to accept the foibles.  Perhaps  
> this angered kneejerk reaction is just the defensive response that  
> most of us develop after having to explain to peers/clients/critics  
> when a big gank appears in the middle of a performance.

I don't think it was harsh.  When I was in school, they drilled it  
into us that we were not gods and there were lots of better ways to  
do things.  Probably always.  That humility is lacking in a lot of  
posts I see.  People forget that most people who use jitter are  
shitty programmers (not there aren't brilliant ones out there, but  
I'd put it generously at 5%).  Also, the hands-on approach to coding  
makes it a visual form of crack - I see so many people who get into  
jitter and then just code on some sort of animal instinct as if  
stepping back and thinking about what they are doing (e.g. squeezing  
a 10000x10000 cell matrix into 20 stacked filters with patch cords  
crossing left and right) is a useful and intelligent thing to do.

If you are getting glitches, do some experiments like Vade and show  
what the issue is.  This vague blabbering is really bothering me.  I  
looked into Quartz composer, Objective C, Quicktime, Mplayer, etc and  
did some heavy research before asking my inane little questions.  I  
hate empty whining on email lists.  If you have evidence, I'd really  
like to see it.  Or descriptions of the problem that are useful.   
Most regular contributors to this list follow these standards, anyway.


> I use Jitter because of the creative possibilities it offers, in  
> spite of underwhelming framerates and irritating freezes.  While  
> coding may be the answer to some of these problems, these are  
> issues that occur when using the software as recommended and  
> involve solutions that require breaking out of the creative model  
> that max/jitter encourages.  These are high hurdles for the  
> programmers, but they are obviously deal-breakers for a lot of  
> people that need to provide reliable solutions in performance  
> situations.
> While it is tempting to demand faster framerates and better  
> performance statistics, I think it would be more beneficial to  
> focus on methods of increasing stability and consistency.  I'd  
> rather have a flawless 30fps than an occasional freeze at 50fps.
> Certainly poor programming can make these issue worse, but expert  
> programmers such as Vade and Joshua are still spending time making  
> workarounds for these issues rather than working on the creative  
> elements of their work.

I don't know, I thought those experiments were pretty creative.  And  
I wouldn't call them workaround, either - this is what I mean when I  
say there needs to be an understanding of the issues involved, and  
techniques to work with them.  I think we all gained a bit more  
understanding from looking at this problem from different angles and  
discussing different compression techniques (like uyvy vs rgb format  
issues) on a public forum.  More of that is good; less of "Damn  
jitter! It's skippy and will never work properly!"

I've got a patch that draws 1800 polygons at 50 fps.  That's pretty  
darn good for jitter, and it took me awhile to find the right method,  
which turned out to be more about OpenGL than Jitter.  I think what  
people are going up against is the limits of what can be done with  
"simple" metaphors that Jitter presents on the surface vs. the all- 
out mind-fuck complexity of digital video formats and compression, 3D  
maths and OpenGL.

My 2cents.  You use may vary.

Cheers
Evan





> _______________________________________________
> jitter mailing list
> jitter at cycling74.com
> http://www.cycling74.com/mailman/listinfo/jitter