\\ walmart'74

[integer at www.god-emil.dk]

havnt tried it [jzt imagine having 2 work with software kalld jitter
+ feel the unsanitary slimy hands ov drug adikt jankee hipiez on ur sexi balkan bitz ... faaa.ukkk]  
so cannot confirm mais ... quite f.amusing+


chk out the subtle + deadli zmakz:


"fails to live up to the Œreal world¹

"I¹m not having to work around someone else¹s idea of how things should be done, but am having to 
adjust my work process to laboriously slow software that is not designed for anything more complex than ¹studies¹ in OpenGL!"

vs.

"You are able to build the programs you want to use, rather than being forced to work around somone else¹s 
idea of how things should be done."





kmfdm sagt: CYCLING74 HIPPIES SUKC+


this is what happens when stupid + lazi MOTHER FUCKERS like David Zicarelli
rent others ideas (Miller Puckette's) + rent others to supply the WALMART74
which is CYCLING74  ... patching up the simply.inferior neo-hippi Zic mamal 










I chose the wrong softwareŠ. 


Posted on Monday 7 March 2005 

I¹m working on a performance project with a friend, and am using Max/Msp/Jitter developed (originally by Miller Puckette) 
by Cycling74 to assist artists and others doing realtime a/v work. This is a blurb from their website:


"Jitter is a set of 135 brilliant video, matrix, and 3D graphics objects for the Max graphical programming environment. The Jitter objects extend the functionality of MaxMSP with flexible means to generate and manipulate matrix data ‹ any data that can be expressed in rows and columns, such as video and still images, 3D geometry, as well as text, spreadsheet data, particle systems, voxels, or audio. Jitter is useful to anyone interested in real-time video processing, custom effects, 2D/3D graphics, audio/visual interaction, data visualization, and analysis. Since Jitter is built upon the Max/MSP programming environment, the limitations inherent in fixed purpose applications is eliminated. You are able to build the programs you want to use, rather than being forced to work around somone else¹s idea of how things should be done. This power is not to be underestimated, so please use it wisely." 



This sounds fantastic, except that Jitter fails to live up to the Œreal world¹ when used on projects involving complex and mutli-faceted uses of OpenGL in conjunction with video and audio. I use a Powerbook G4 1 Ghz processor with 1 G memory, have my media on a LaCIE external, have optimized system settings, and when using OpenGL 3d and 2d text (two separate matrices) along with a video matrix, I¹m chugging along at 5 fps (slow!)ŠTheir website says the following:


"If your patches use little jit.pwindow objects as monitors, and the data being displayed on them is larger than the dimensions of the jit.pwindow objects (e.g. you¹re monitoring a 320¥240 matrix on an 80¥60 jit.pwindow object), turn OFF Œuse onscreen¹ in the object¹s inspector. (Why? Onscreen mode uses Apple¹s copy routines, which feature a slow averaging filter when downscaling images. Offscreen mode uses custom routines which are faster, in this case). If your patches use Jitter objects with multiple inputs (such as jit.chromakey), you can eliminate a copy step by using the @in2_name (or @in3_name, etc.) attribute to force the object to use the specified matrix in-place (don¹t forget to disconnect the patchcord from the right inlet of the object). Look at the Œjit.chromakey-pile.pat¹ example for a demonstration of this technique."



Both things I did, and still maybe got up to 7 or 9 fpsŠmy friend is using Java/OpenGL (specifically the Lightweight Java Game Library) on a Windows machine and it is blowing my efforts away! 
I think the folks at cycling74 should spend some time adjusting their ad copy for Max/Msp/JitterŠI¹m not having to work around someone else¹s idea of how things should be done, but am having to adjust my work process to laboriously slow software that is not designed for anything more complex than ¹studies¹ in OpenGL!