phiol

I am curious about your opinions and why you advanced Jitter

users would choose Jitter over Touch designer/unreal/Unity.

I have never experimented with these 3 but have several friends

I am curious as to what several gurus here think and if

you've tried and compared the pros and cons of each software.

I for one , only know Jitter and love it but for more

complex stuff , it sometimes feel like building a wooden car with

popsicle sticks -if you know what I mean.

Been @ it every single day since march 2014.

As the title of the post says,
I am curious about your opinions and why you advanced Jitter
users would choose Jitter over Touch designer/unreal/Unity. 

I have never experimented with these 3 but have several friends
who swear by these 3 latter.  

I am curious as to what several gurus here think and if
you've tried and compared the pros and cons of each software.

I for one , only know Jitter and love it but for more
complex stuff , it sometimes feel like building a wooden car with
popsicle sticks -if you know what I mean.

I have to practice everyday.
Been @ it every single day since march 2014.

curious-about-your-opinions-on-jitter-vs-touch-designer-vs-unreal-vs-unity

Well I ain't no Guru but I've dabbled in Touch designer and unity.

-Touch designer, similar environment to Jitter with node based patching :)

A LOT of very cool patches get released which make it I'd say more accessible to new users. Sometimes with Max I still feel that the examples miss sections for the beginner.

TD reminds me of of quartz composer sometimes, like particle systems, bang easy to use object and your just going. Max could definitely have more working examples with things that they know people will want to do a lot. Like particles :)

downside PC only. Which is why I still use Max, I need to use my macbook pro for live Vj shows.

-Unity. I get a lot done in unity (and processing) with Javascript due to its very clear explanations on every function plus online wiki with very clear Code examples. Clear debugging which I miss with Max.

Sometimes in Unity I write 4 lines of code and I end up using 20 Max objects to do something similar. Max and Javascript is not friendly to use. Its not aimed at the total beginner like unity (or processing) is. I can always find an answer to a syntax problem with unity but not with Max and javascript.

Unity has some incredible shaders (pro only) that can be applied to the Master camera view like sunbeams and so on. I could use Unity to do live visuals but only the pro verison allows SYPHON, so thats out of my budget.

Downside- getting data in and out of unity is not a simple process and to use most externals you have to know C+ to tailor them to your needs.

Well I ain't no Guru but I've dabbled in Touch designer and unity.
-Touch designer, similar environment to Jitter with node based patching :)
A LOT of very cool patches get released which make it I'd say more accessible to new users. Sometimes with Max I still feel that the examples miss sections for the beginner.
TD reminds me of of quartz composer sometimes, like particle systems, bang easy to use object and your just going. Max could definitely have more working examples with things that they know people will want to do a lot. Like particles :)
downside PC only. Which is why I still use Max, I need to use my macbook pro for live Vj shows.

-Unity. I get a lot done in unity (and processing) with Javascript due to its very clear explanations on every function plus online wiki with very clear Code examples. Clear debugging which I miss with Max.
Sometimes in Unity I write 4 lines of code and I end up using 20 Max objects to do something similar. Max and Javascript is not friendly to use. Its not aimed at the total beginner like unity (or processing)  is. I can always find an answer to a syntax problem with unity but not with Max and javascript.

Unity has some incredible shaders (pro only) that can be applied to the Master camera view like sunbeams and so on. I could use Unity to do live visuals but only the pro verison allows SYPHON, so thats out of my budget.
Downside- getting data in and out of unity is not a simple process and to use most externals you have to know C+ to tailor them to your needs.

interesting. I wrote a book about Max for audio and TD for video, which feels the most natural for me personally. Obviously, that seems like a bad idea at first, so I really gave some thought about the advantages of TD over Jitter:

 more efficient. Jitter had problems even playing an HD video without hick-ups for a long time just to name one example. That might have improved by now.

I think TD is more headed towards interesting possibilities of creating procedural 3d geometry. (also since it comes from side FX's Houdini). Also, TD simply comes from video, and Max comes from audio. (You can build audio synths in TD, and people do that. I wouldn't. Bandpass filters in TD where distorting as hell until recently, now they are fine.).

I think Jitter is a bit better when it comes to analyzing Video signals(like blob tracking etc.) and there is a bigger community I think.

TD is also a bit more visual, meaning, it shows a bit more what it's doing in a visual sense (due to the OP viewer), so I would also call it a bit more intuitive/beginner friendly.

There are so many differences which one could elaborate on, but I don't want to bore anyone. I think you can do everything in Jitter that you can do in TD and vice versa, but the workflow is different.

About unreal: really impressive stuff, I've always wanted to try it for visuals, but never had the time to learn it until now.

interesting. I wrote a book about Max for audio and TD for video, which feels the most natural for me personally. Obviously, that seems like a bad idea at first, so I really gave some thought about the advantages of TD over Jitter:
TD seems more efficient. Jitter had problems even playing an HD video without hick-ups for a long time just to name one example. That might have improved by now.
I think TD is more headed towards interesting possibilities of creating procedural 3d geometry. (also since it comes from side FX's Houdini). Also, TD simply comes from video, and Max comes from audio. (You can build audio synths in TD, and people do that. I wouldn't. Bandpass filters in TD where distorting as hell until recently, now they are fine.).
I think Jitter is a bit better when it comes to analyzing Video signals(like blob tracking etc.) and there is a bigger community I think.
TD is also a bit more visual, meaning, it shows a bit more what it's doing in a visual sense (due to the OP viewer), so I would also call it a bit more intuitive/beginner friendly.
There are so many differences which one could elaborate on, but I don't want to bore anyone. I think you can do everything in Jitter that you can do in TD and vice versa, but the workflow is different.
Just my 2 cents.
About unity: never used it.
About unreal: really impressive stuff, I've always wanted to try it for visuals, but never had the time to learn it until now.


@Andro: thanks a lot for your insight. If I asked you the question this way then,

"why would you chose Jitter over any other?".

Also, just to let you know, the TD team is cooking up a Mac version of TD. :-)

https://www.youtube.com/watch?v=y_7awHM-pr0

@woyteg: go right ahead and say all you want , I will not get bored. I really want to know what you think.

@both: The reason for this post is that I've invested my entire last year in learning Jitter,

and it's great but as I said, it's sometimes feel like a putting wooden car together using popsicle sticks. To get the equivalent or way cleaner results in TD, it will only be a 2-3 step process over 20 in Jitter. Also, hiring companies here in Montreal are really geared towards Unity and TD.

Unreal: well what I've learned is that it used to be 1.2 million $ to own a license aimed towards big companies like Ubisoft who could afford it. And that recently, they've made more accessible with a 20$/month fee. I saw the results for the 1st time yesterday and do not see how one could achieve this in Jitter. Maybe the Jitter development team could. but...

@Andro: thanks a lot for your insight. If I asked you the question this way then,
"why would you chose Jitter over any other?".
 Also, just to let you know, the TD team is cooking up a Mac version of TD. :-)
Unreal: here is a demo: https://www.youtube.com/watch?v=y_7awHM-pr0

@woyteg: go right ahead and say all you want , I will not get bored. I really want to know what you think.
@both: The reason for this post is that I've invested my entire last year in learning Jitter,
and it's great but as I said, it's sometimes feel like a putting wooden car together using popsicle sticks. To get the equivalent or way cleaner results in TD, it will only be a 2-3 step process over 20 in Jitter.   Also, hiring companies here in Montreal are really geared towards Unity and TD. 

Unreal: well what I've learned is that it used to be 1.2 million $ to own a license aimed towards big companies like Ubisoft who could afford it. And that recently, they've made more accessible with a 20$/month fee. I saw the results for the 1st time yesterday and do not see how one could achieve this in Jitter. Maybe the Jitter development team could. but... 

To be honest i wouldnt choose jitter over anything else. Like you said with the example of building the car from wooden sticks. Its like that for me.

I love max jitter. I really do. They opened a world to me that was inaccessible before. But other software can do the same. Just a different workflow.

Td is free with a resolution cap of 1280 x 720. Too small for what i do now.

Its all ease of use. I believe that jitter misses a lot of clear "practical" examples. Why did i love quartz composer ? Because they made objects just ready to go.

I dont need control over every parameter with matrixes to control a particle system. I just want an object where i can plug in my arguments and go.

QC particle object was working in 2 minutes when i was a complete noob. I got results. I've never got anything close to that in max :(

I just wish that max had more out of the box objects. The new jit.gl.pass objects are a great example. DOF. Bloom. Bam. They just work. I don t want to reinvent the wheel for established systems that everybody uses. Im not a guy that will ever write shaders.

TD has a huge library of stuff that just works. I think thats what i miss with max but jitter even more. A library of ready to go items that are not a patch that only a jitter sith lord understands. Oh. Another one. Jit.gl.slab. Love it. But can we get some new shaders please !

TD has that. Thats why if you compare jitter projects to TD then jitter seems to be behind. TD developers focus on function AND giving us quick tools to make things look great. They re all there in jitter but damn they take a long time and hours of forum searches to get working.

I ll stick with jitter but i am going back to TD in the near future. After all i ve learnt the last year i know touch designer will be much easier to use.

To be honest i wouldnt choose jitter over anything else. Like you said with the example of building the car from wooden sticks. Its like that for me.
I love max jitter. I really do. They opened a world to me that was inaccessible before. But other software can do the same. Just a different workflow.
Td is free with a resolution cap of 1280 x 720. Too small for what i do now.
Its all ease of use. I believe that jitter misses a lot of clear "practical" examples. Why did i love quartz composer ? Because they made objects just ready to go.
I dont need control over every parameter with matrixes to control a particle system. I just want an object where i can plug in my arguments and go.
QC particle object was working in 2 minutes when i was a complete noob. I got results. I've never got anything close to that in max :(
I just wish that max had more out of the box objects. The new jit.gl.pass objects are a great example. DOF. Bloom. Bam.  They just work. I don t want to reinvent the wheel for established systems that everybody uses. Im not a guy that will ever write shaders.
TD has a huge library of stuff that just works. I think thats what i miss with max but jitter even more. A library of ready to go items that are not a patch that only a jitter sith lord understands. Oh. Another one. Jit.gl.slab. Love it. But can we get some new shaders please !

TD has that. Thats why if you compare jitter projects to TD then jitter seems to be behind. TD developers focus on function AND giving us quick tools to make things look great. They re all there in jitter but damn they take a long time and hours of forum searches to get working.
I ll stick with jitter but i am going back to TD in the near future. After all i ve learnt the last year i know touch designer will be much easier to use.


Another thing. Object materials. Theres a library in unity and TD. Not in jitter. Not even a couple of basic things like metal and emission materials.

Drag and drop functionality with things like this have to be the future in max. Blender now has a huge material library where basic geometry can be made to look amazing. I mean im not a 3d modeller. I work with live gpu geometry. But it just looks amateur like in max compared to what i get in TD or unity.

The ease of use with max 7 is mainly file based not functional examples or objects.

I truly hope that will change in the future. Vjs like me dont and wont ever use video. Its GPU gaming like systems. I truly believe that the future of live vj sets and interactive media will be generated on the fly. Game engines provide more of that than max( which makes complete sense ! )

Unreal is a game engine. Theres teams of pro modellers. Texture artists etc. that make it look incredible. Most max geeks are solo. Thats why out of the box functionality is so important to get on the same level as the other software.

Another thing. Object materials. Theres a library in unity and TD. Not in jitter. Not even a couple of basic things like metal and emission materials.
Drag and drop functionality with things like this have to be the future in max. Blender now has a huge material library where basic geometry can be made to look amazing. I mean im not a 3d modeller. I work with live gpu geometry. But it just looks amateur like in max compared to what i get in TD or unity.
The ease of use with max 7 is mainly file based not functional examples or objects.
I truly hope that will change in the future. Vjs like me dont and wont ever use video. Its GPU gaming like systems. I truly believe that the future of live vj sets and interactive media will be generated on the fly.  Game engines provide more of that than max( which makes complete sense ! )
Unreal is a game engine. Theres teams of pro modellers. Texture artists etc. that make it look incredible. Most max geeks are solo. Thats why out of the box functionality is so important to get on the same level as the other software.


@andro: thanks a lot for you 2 cents . I really appreciate and agree with you. On all of your points.

I believe the worst for example is the jit.gen family. why keep it so cryptic ? It's probably why they've made it free by now. I've literally dedicated my last year to jitter. And yes I've accomplished really cool things. But for the amount of life/work involved, the cleanness/quality just doesn't look like other software.

-the other thing would be to have jit.gen working on the gpu side. [jit.gl.vertex]. that would dramatically change everything, but that's a whole other topic.

I decided on Jitter because of the physics (bullet) library that TD doesn't have. And coming from the MSP sound world, I really like having everything in one software. I just do.

@andro: thanks a lot for you 2 cents . I really appreciate and agree with you. On all of your points.
I believe the worst for example is the jit.gen family. why keep it so cryptic ? It's probably why they've made it free by now. I've literally dedicated my last year to jitter. And yes I've accomplished really cool things. But for the amount of life/work involved, the cleanness/quality just doesn't look like other software.

-the other thing would be to have jit.gen working on the gpu side. [jit.gl.vertex]. that would dramatically change everything, but that's a whole other topic. 

I decided on Jitter because of the physics (bullet) library that TD doesn't have. And coming from the MSP sound world, I really like having everything in one software. I just do. 

Jit.gen. Almost no examples for beginners. I dont even understand how max is using it half the time. I d love to understand that by example.

Hello, guys. Interesting topic, no doubt!

Jitter vs Touch Designer, VVVV or Quartz Composer:

In this regard, I agree that Jitter even had an initial advantage and lost some ground to the other tools. My short experience with Touch Designer led me to believe that it is a more high-level environment than the other tools, more geared towards "artists" than "programmers". It has excelent video performance, multi-threaded, really efficient and robust. Production-ready timing accuracy.

VVVV is DirectX only, it will never be on Mac (unless they change the architecture). I guess it has some advantages compared to Jitter in the rendering department (support for DirectX 11, while in Jitter I think we have a not up-to-date version of OpenGL). Quartz Composer: easy to use, I guess not-so-powerful functionality-wise, optimized performance.

All this tools have free versions available (TD and VVVV with limitations towards commercial use). This is great to stimulate college adoption in their curriculums and therefore growing the community (the same could be said for Processing or Open Frameworks)!

Come on, guys! Do you want to compare the market of mostly independent audio or audio-visual artists with that of the video game industry? Epic Games' number of employees with Cycling'74's? They will never be able to compete with that... and they shouldn't, it's impossible.

Sometimes I use game engines, often in combination with Max. I've used Unity (briefly), I've used CryEngine for a few years and I am now using Unreal. These are great tools! I like the ease of use of setting up a scene, dragging assets around, the workflow is great. The rendering is gorgeous. If you don't want to, you don't have to reinvent the wheel to include depth of field, shadows, motion blur and that sort of stuff... as Steve Jobs would say: Boom!

Now, let's talk about cost: Unity has a free version, Unreal has a free academic program or $19/month subscription (in which you can subscribe for just a month and keep using that version indefinitely, you just don't get access to upgrades...), CryEngine has a free (older) version and now is subscription based ($9.99/month).

But as they are right now, they too have it's limitations. The access to each and every parameter is not there, the things we're able to dynamically control are sometimes restrictive... for instance, one of them is dynamically or procedurally based geometry generation. Game engines usually load pre-built 3D models; with Max or other similar environments, you have much more freedom in that regard.

So, I think that the ideal tool really depends on each project's purpose. Sometimes it would be a game engine, other times it would be a more general visual programming environment like Max.

With that said, I also think that a few things could be done in order to bring to Max some of the functionalities that game engines have, and I agree with some of the things you guys referred (Is it possible or desirable to have a more interesting/diversified material library? Of course!) I've just happen to think that some of the things are unreachable, particularly regarding the comparison with game engines.

What would I like to happen? Here are some things, in order from most feasible ones to least feasible:

1. Cycling'74 should keep up doing what they've done in Max 7, it should be said that it really was a step in the right direction, both in terms of functionality and ease of use (jit.world, MTR, jit.gl.pass and all that stuff), performance (the use of AV Foundation on the Mac, Windows solution still waiting...) and even licensing models (subscription, full purchase). But nothing competes with free. As I said, most of the other environments are free for non-commercial projects. In Max 7 you can try for free but not save any work. A possible workaround would be to let the user save patches and have a sort of watermark (audio beep every now and then, visual flash on jitter's output)... I don't know, but free for educational purposes seems to be the way to go, if college courses teach your tool, there's a better chance of you using it professionally in the future... I understand the need for Cycling'74 to get paid for their hard work, but if other developers are doing it, it must be compensating them. To me, the main question for Cycling is: how do we enlarge our customer base, or, in other words, how de we attract new users? And each time someone starting in this area chooses TouchDesigner, VVVV or other tools because "it's free" is a lost opportunity for Cycling later on.

2. A more robust infrastructure for communicating between Max and game engines, that doesn't rely almost exclusively on OSC (the current way of doing it) but is also able to share audio streams and matrices (or GPU textures, Syphon style!), vertex data, etc. If you think about it, wouldn't it be great to have a "Max4Live" sort of solution inside a game engine? Wow! If I could encapsulate a Max patch inside Unreal, have the equivalent access to the game engine as we do with the Live API, exchanging information between Max and game engine would be incredible! As Cycling chose Ableton to collaborate in this deep integration, it could do the same with Epic, Crytek or Unity!

3. A Max 8 powered by "CryEngine" or "Unreal" engine! Licensing and incorporating a renderer and including it in Max.

I think it's a little unfair that we're having this kind of conversation after Max 7, a major upgrade in the graphics department, just came out... but we can dream, can't we? ;-)

P.S: Andro, while agreeing with most of what you said, I think it's somewhat contradictory to say "Im not a guy that will ever write shaders" and ask for "out of the box things that just work", and then saying that you'd love for Cycling to better document jit.gen in order to understand and use it. Cycling is not a very large company and it probably can't do all of these (justifiable and desirable) things at the same time...

Jitter vs Touch Designer, VVVV or Quartz Composer: fair comparison.
In this regard, I agree that Jitter even had an initial advantage and lost some ground to the other tools. My short experience with Touch Designer led me to believe that it is a more high-level environment than the other tools, more geared towards "artists" than "programmers". It has excelent video performance, multi-threaded, really efficient and robust. Production-ready timing accuracy.
VVVV is DirectX only, it will never be on Mac (unless they change the architecture). I guess it has some advantages compared to Jitter in the rendering department (support for DirectX 11, while in Jitter I think we have a not up-to-date version of OpenGL). Quartz Composer: easy to use, I guess not-so-powerful functionality-wise, optimized performance.
All this tools have free versions available (TD and VVVV with limitations towards commercial use). This is great to stimulate college adoption in their curriculums and therefore growing the community (the same could be said for Processing or Open Frameworks)!

Jitter vs Unity, Unreal or CryEngine: unfair comparison!
Come on, guys! Do you want to compare the market of mostly independent audio or audio-visual artists with that of the video game industry? Epic Games' number of employees with Cycling'74's? They will never be able to compete with that... and they shouldn't, it's impossible.
Sometimes I use game engines, often in combination with Max. I've used Unity (briefly), I've used CryEngine for a few years and I am now using Unreal. These are great tools! I like the ease of use of setting up a scene, dragging assets around, the workflow is great. The rendering is gorgeous. If you don't want to, you don't have to reinvent the wheel to include depth of field, shadows, motion blur and that sort of stuff... as Steve Jobs would say: Boom!
Now, let's talk about cost: Unity has a free version, Unreal has a free academic program or $19/month subscription (in which you can subscribe for just a month and keep using that version indefinitely, you just don't get access to upgrades...), CryEngine has a free (older) version and now is subscription based ($9.99/month).
But as they are right now, they too have it's limitations. The access to each and every parameter is not there, the things we're able to dynamically control are sometimes restrictive... for instance, one of them is dynamically or procedurally based geometry generation. Game engines usually load pre-built 3D models; with Max or other similar environments, you have much more freedom in that regard.

With that said, I also think that a few things could be done in order to bring to Max some of the functionalities that game engines have, and I agree with some of the things you guys referred (Is it possible or desirable to have a more interesting/diversified material library? Of course!) I've just happen to think that some of  the things are unreachable, particularly regarding the comparison with game engines.

P.S: Andro, while agreeing with most of what you said, I think it's somewhat contradictory to say "Im not a guy that will ever write shaders"  and ask for "out of the box things that just work", and then saying that you'd love for Cycling to better document jit.gen in order to understand and use it. Cycling is not a very large company and it probably can't do all of these (justifiable and desirable) things at the same time...


@pedro : what a great answer! thanks a lot.

I have greater most respect for your work and patching quality in Jitter.

What you've produced is esthetically some of the slickest stuff I've seen that can be done in Jitter.

You've definitely been a reference point for me and hours uppon hours of research and studiying to try to figure out how you could of done certain things.

-In one particular case I've been at it for over a month. But that's another topic. At some point soon, I'll poke you directly about it.

As for your point #1 in your last paragraph. I don't think the reason for the lower Jitter user base has do to money. I think it has more to do with having more basic examples that serve more popular uses.

The 1st that comes to mind is that there not even a very basic example that demonstrate the use of @blend_enable 1 to have the cutout area not show when using a .png.

I mean I learned this because of silicat who generouly told me when I contacted him in an email when I asked him how he was using it in his work.

I tell you , being a year old everyday user, I see that quite a lot simple knowledge is overlooked in the example patches.

(What I mean is that theses examples take for granted that we already master a lot of concepts they overlooked explaining them.)

Hours and hours are wasted in confirming simple things that could simply be mentionned in a comment.

I guess it’s what can happen when you become @ the level of writing glsl shaders and C++ externals like the developpers,

I can only assume that for them looking @ a Jitter patch dressed in in closed object is probably already very very obvious what is happening in the patch. No real code is shown , only @ttribute control.

Popularity and practicality in Artistic situations;

A great deal of techniques and object combos that I use are not even in the helpfile. I discovered them by chance.

-for drawing/trigger other stuff (sounds for ex) uppon collision-contact.

Take the sound, why is that not an example in the option-click helpfile.

A new user has to discover it by chance in the jitter example/render/physics/“phys-picker-impulse”.

As I’ve asked 2 days ago, I believe we lost the use of collisions with jit.world, an important part of physics.

the [sendphys collisions 1] doesn’t seem to work.

-phys.ghost as a zone/area detection object

to trigger things in an interactive patch .

gl.path : examples with physic (string drawing) , all the physics examples with no strings.

Say the “physics patch a day 3 “ angry huddle”. If you were to use this in a real visual piece,

one would need to draw strings, would of been a great to time to intoduce the use of [jit.phys.multiple @contraint point2point @constraint_matrix 1 ] connected to gl.path to draw a string.

-And little things like having the [jit.window @floating 1] by default in every helpfiles.

Or redoing a makeover of the all the helpfiles and replace the qmetro /t b erase / jit.gl.render/jit.window combo with

-Explain why some qmetro are @5ms sometimes @60Hz sometime @2ms @33ms.

Yes one can research and discover it in wikipedia that: When broadcast at 60frames per second (which equivalent to 60Hz), 720p features the highest temporal (motion) resolution possible under the ATSC and DVB standards. In ms. this is the equivalent to 16ms .

Pratical examples for practical use and being a more cryptic software for new users who are trying out Jitter

are much more of a reason why it’s not as popular as say TouchDesigner.

this sounds like complaining but it really isn’t it’s just a hypothesis on why Jitter is not as a much popular choice of Visualsoftware over others.

That’s actually what my main question was really : Why do you guys use Jitter over other software? Maybe that should’ve been the title.

@pedro : what a great answer! thanks a lot.
I have greater most respect for your work and patching quality in Jitter.
What you've produced is esthetically some of the slickest stuff I've seen that can be done in Jitter.
You've definitely been a reference point for me and hours uppon hours of research and studiying to try to figure out how you could of done certain things.
-In one particular case I've been at it for over a month. But that's another topic. At some point soon, I'll poke you directly about it.
but for now the thread topic.

As for your point #1 in your last paragraph. I don't think the reason for the lower Jitter user base has do to money. I think it has more to do with having more basic examples that serve more popular uses.
The 1st that comes to mind is that there not even a very basic example that demonstrate the use of @blend_enable 1 to have the cutout area not show when using a .png.
I mean I learned this because of silicat who  generouly told me when I contacted him in an email when I asked him  how  he was using it in his work.

I tell you , being a year old everyday user, I see that quite a lot simple knowledge is overlooked in the example patches.
(What I mean is that theses examples take for granted that we already master a lot of concepts they overlooked explaining them.)
Hours and hours are wasted in confirming simple things that could simply be mentionned in a comment.
I guess it’s what can happen when you become @ the level of writing glsl shaders and C++ externals like the developpers,
I can only assume that for them looking @ a Jitter patch dressed in in closed object is probably already very very obvious what is happening in the patch. No real code is shown , only @ttribute control.

Popularity and practicality in Artistic situations; 

A great deal of techniques and object combos that I use are not even in the helpfile. I discovered them by chance.
I believe they should be. 

physics: collisions 
-for drawing/trigger other stuff (sounds for ex) uppon collision-contact.

Take the sound, why is that not an example in the option-click helpfile.
A new user has to discover it by chance in the jitter example/render/physics/“phys-picker-impulse”.

Take jit.world as you mention.
As I’ve asked 2 days ago, I believe we lost the use of collisions with jit.world, an important part of physics.
the [sendphys collisions 1] doesn’t seem to work. 

-phys.ghost as a zone/area detection object
to trigger things in an interactive patch . 

gl.path : examples with physic (string drawing) , all the physics examples with no strings.
Say the “physics patch a day 3 “ angry huddle”. If you were to use this in a real visual piece,
one would need to draw strings, would of been a great to time to intoduce the use of [jit.phys.multiple @contraint point2point @constraint_matrix 1 ] connected to gl.path to draw a string. 

-And little things like having the [jit.window @floating 1] by default in every helpfiles.
Or redoing a makeover of the all the helpfiles and replace the qmetro /t b erase / jit.gl.render/jit.window combo with
jit.world. 

-Explain why some qmetro are @5ms sometimes @60Hz sometime @2ms @33ms.
Little things like this.
Yes one can research and discover it in wikipedia that: When broadcast at 60frames per second (which equivalent to 60Hz), 720p features the highest temporal (motion) resolution possible under the ATSC and DVB standards. In ms. this is the equivalent to 16ms . 

Finally
Pratical examples for  practical use  and being a more cryptic software for new users who are trying out Jitter
are much more of a reason why it’s not as popular as say TouchDesigner.  

this sounds like complaining but it really isn’t it’s just a hypothesis on why Jitter is not as a much  popular choice of Visualsoftware over others. 

i do little things with jitter... but it takes time it's true

still, the main "selling point" of Jitter is that it's inside Max so it's ideal if you do mainly sounds and want to experiment the sounds and graphics interaction

Correct me if i'm wrong, but the possibility of using Jitter in a more professional graphics-oriented setup (like everything OpenGL and slabs) is quite new, no ? i mean compared to the concurrents you cite (VVVVV, Touchdesigner, Unreal...)

i do little things with jitter... but it takes time it's true
still, the main "selling point" of Jitter is that it's inside Max so it's ideal if you do mainly sounds and want to experiment the sounds and graphics interaction
Correct me if i'm wrong, but the possibility of using Jitter in a more professional graphics-oriented setup (like everything OpenGL and slabs) is quite new, no ? i mean compared to the concurrents you cite (VVVVV, Touchdesigner, Unreal...)


@vichug Correct me if i’m wrong, but the possibility of using Jitter in a more professional graphics-oriented setup (like everything OpenGL and slabs) is quite new, no ? i mean compared to the concurrents you cite (VVVVV, Touchdesigner, Unreal…)

Was there back in Max 4.6.3 in 2007.
So 8 years ago.

Hello again! Phiol, thank you for the kind words, but there are people in this forums more knowledgeable and certainly more deserving of your praise... and no, this really isn't false modesty ;-)

All the examples you've given are perfectly valid and Cycling should listen to you and your frustrations as a new user... it really is important because of what your particular profile represents: people just starting up in Max and/or Jitter, not running away, really investing in learning it, and struggling with some parts of it.

Regarding the documentation: I agree that there are many important things that are not in the documentation, they are just here on the forums. Couple that with a very weak forum "search" implementation... I know they're aware and working on it...

Max 5 help files were much more thorough, and I guess, in order not to intimidate beginners, they simplified it for Max 6. A good system would be a very simple first tab, and then advanced ones.

With that being said, I don't think that other alternatives have much better documentation... for every of these tools I've tried I had to search the forums and even post specific questions that I didn't find answered elsewhere.

One thing I guess would make Max, but particularly Jitter better and easier to learn: get rid of legacy, obsolete procedures! Break compatibility! Build a new foundation, where necessary.

Jitter started in 2003, was mainly (exclusively?) CPU based. In Jitter 1.5 (2006? I'm not sure) it gained OpenGL functionality using the GPU. Processing on the GPU started being progressively more used, as GPUs gained more functionality and performance. OpenGL's implementation was based on a fixed-pipeline. Nowadays, graphics cards use a fully programmable pipeline using shaders. What I mean is that the working paradigm changed so much... Jitter was able to incorporate some of the new features, but never got rid of the old... For example, why wouldn't Jitter objects automatically draw using a default jit.material object (programmable pipeline) instead of using the fixed-pipeline and slowing down the frame rate in NVidia's cards because of the drivers (a conclusion we obtained in the benchmark thread, Phiol)? Another example, who still uses the fog attribute of OpenGL's fixed pipeline? But it's there in the properties of every OB3D Jitter object. Talking about obsolete, on the video side, Quicktime's limbo situation from Apple didn't help... we're waiting for a good Windows solution now, but Cycling is heading in the right direction...

Another thing that I think confuses beginners is the different objects between CPU and GPU. Ideally every matrix should automatically be processed on the GPU, as long as its algorithms' complexity would allow (although we would still have the problem of texture readback to the CPU...).

I'll stop now, as I don't want this post to be so long as my previous one...

Regarding the documentation: I agree that there are many important things that are not in the documentation, they are just here on the forums. Couple that with a very weak forum "search" implementation... I know they're aware and working on it...
Max 5 help files were much more thorough, and I guess, in order not to intimidate beginners, they simplified it for Max 6. A good system would be a very simple first tab, and then advanced ones.
With that being said, I don't think that other alternatives have much better documentation... for every of these tools I've tried I had to search the forums and even post specific questions that I didn't find answered elsewhere.

One thing I guess would make Max, but particularly Jitter better and easier to learn: get rid of legacy, obsolete procedures! Break compatibility! Build a new foundation, where necessary.
Jitter started in 2003, was mainly (exclusively?) CPU based. In Jitter 1.5 (2006? I'm not sure) it gained OpenGL functionality using the GPU. Processing on the GPU started being progressively more used, as GPUs gained more functionality and performance. OpenGL's implementation was based on a fixed-pipeline. Nowadays, graphics cards use a fully programmable pipeline using shaders. What I mean is that the working paradigm changed so much... Jitter was able to incorporate some of the new features, but never got rid of the old... For example, why wouldn't Jitter objects automatically draw using a default jit.material object (programmable pipeline) instead of using the fixed-pipeline and slowing down the frame rate in NVidia's cards because of the drivers (a conclusion we obtained in the benchmark thread, Phiol)? Another example, who still uses the fog attribute of OpenGL's fixed pipeline? But it's there in the properties of every OB3D Jitter object. Talking about obsolete, on the video side, Quicktime's limbo situation from Apple didn't help... we're waiting for a good Windows solution now, but Cycling is heading in the right direction...
Another thing that I think confuses beginners is the different objects between CPU and GPU. Ideally every matrix should automatically be processed on the GPU, as long as its algorithms' complexity would allow (although we would still have the problem of texture readback to the CPU...).

I'll stop now, as I don't want this post to be so long as my previous one...


Very well agree with everything should simply be on the gl side.

Been patching sound hardcore in MaxMSP since 2006. I tried Jitter quite a few time throughout the years. But would give up. Because of all the reasons mentioned. I really stayed hooked on this time because of one incredible user (matmat) whom gave me a incredibly good quick start. He is amazing!

In other words, my brain and grasping the concepts was never the problem , but good and clear explanations. Being less mystical.

Anyways, thanks a lot to all you guys for your input and @pedro I think I will contact you soon enough for my questions about the patch I was talking about. It has something to do with the sound atoms video :-)

Very well agree with everything should simply be on the gl side.
Jit.matrix should be jit.gl.vertex

Been patching sound hardcore in MaxMSP since 2006. I tried Jitter quite a few time throughout the years. But would give up. Because of all the reasons mentioned. I really stayed hooked on this time because of one incredible user (matmat) whom gave me a incredibly good quick start. He is amazing!
In other words, my brain and grasping the concepts was never the problem , but good and clear explanations. Being less mystical.

Anyways, thanks a lot to all you guys for your input and @pedro I think I will contact you soon enough for my questions about the patch I was talking about. It has something to do with the sound atoms video :-) 

Hi Phiol, to me jit.gen is a multipurpose tool for processing Matrixes in a much more powerful way. Shaders are beyond my ken and thats fine with me. I suppose I'm just saying that it couldn't do no harm to have more example files which are clearly documented. Like everything else, I could maybe pick up how to do shaders but with the current lack of multiple examples showing the simplest things (or that they're just hard to locate) its just not gonna pay off with the time it would cost me.

Jit.gl.pix is a great way for me to play with shaders, but once again, no simple library to learn by example ! Almost all the objects assume your already a decent programmer.

Why is there not a jit.gen example for every SINGLE jit.gen object ?? It is cryptic, it is not aimed at teaching beginners.

A couple of hours of work for cycling 74 building jit.gen examples and then people like me would be actually able to learn how to use it in our time.

Jit.gen should even just have its own tutorial section.

When I started Max/jitter I had no programming experience what so ever.

I have learnt so much due to the awesome work of cycling 74 :)

I remember when I started out with jitter. I couldn't get anything to work. The basic goal was like in resolume to overlay two video files with alpha transparency.

After two weeks I almost gave up, without Rob Ramirez guiding me through the process of learning open GL i would have seriously considered just quitting . And trust me I don't give in so quickly.

All the examples and lessons explain the parts, but not the sum of them being used together.

I'm now proud to say that I now have my own custom VJ software which is very modular, all GPU based and something I love to use in live events.

But its not due to good documentation for beginners.

I pulled it off because of the help I received in the forums, and by just slogging it out.

I truly believe that the examples and documentation with Jitter start out for complete beginners and then just jump to advanced. There is no intermediate.

Example. I asked Rob how to do 3 effects I used in Blender, the main one being doing multiple objects with position and rotation offset. That one example he built made it very clear how to use jit.gl.multiple. The help file is a nightmare for a beginner ! It uses very complex jit.expr expressions.

Why doesn't this help file have a simple. intermediate and advanced example ??

And thats what it is for me with Jitter, most of what I learnt came from the help files but I learnt nothing when the example was more advanced than it needed to be.

I have nothing but respect for cycling 74, they do amazing work and none of what I say is intended as negative criticism. Max 7 is a great leap in the right direction and I think the software is developing nicely.

I just hope we can make the introduction to Jitter and mainly OPEN GL easier for people to get into.

Hi Phiol, to me jit.gen is a multipurpose tool for processing Matrixes in a much more powerful way. Shaders are beyond my ken and thats fine with me. I suppose I'm just saying that it couldn't do no harm to have more example files which are clearly documented. Like everything else, I could maybe pick up how to do shaders but with the current lack of multiple examples showing the simplest things (or that they're just hard to locate) its just not gonna pay off with the time it would cost me.
Jit.gl.pix is a great way for me to play with shaders, but once again, no simple library to learn by example ! Almost all the objects assume your already a decent programmer.
Why is there not a jit.gen example for every SINGLE jit.gen object ?? It is cryptic, it is not aimed at teaching beginners.
A couple of hours of work for cycling 74 building jit.gen examples and then people like me would be actually able to learn how to use it in our time.
Jit.gen should even just have its own tutorial section.
When I started Max/jitter I had no programming experience what so ever.
I have learnt so much due to the awesome work of cycling 74 :)
I remember when I started out with jitter. I couldn't get anything to work. The basic goal was like in resolume to overlay two video files with alpha transparency.
After two weeks I almost gave up, without Rob Ramirez guiding me through the process of learning open GL i would have seriously considered just quitting . And trust me I don't give in so quickly.

All the examples and lessons explain the parts, but not the sum of them being used together.
I'm now proud to say that I now have my own custom VJ software which is very modular, all GPU based and something I love to use in live events.
But its not due to good documentation for beginners.
I pulled it off because of the help I received in the forums, and by just slogging it out.
I truly believe that the examples and documentation with Jitter start out for complete beginners and then just jump to advanced. There is no intermediate.
Example. I asked Rob how to do 3 effects I used in Blender, the main one being doing multiple objects with position and rotation offset. That one example he built made it very clear how to use jit.gl.multiple. The help file is a nightmare for a beginner ! It uses very complex jit.expr expressions.
Why doesn't this help file have a simple. intermediate and advanced example ??
And thats what it is for me with Jitter, most of what I learnt came from the help files but I learnt nothing when the example was more advanced than it needed to be.
I have nothing but respect for cycling 74, they do amazing work and none of what I say is intended as negative criticism. Max 7 is a great leap in the right direction and I think the software is developing nicely.
I just hope we can make the introduction to Jitter and mainly OPEN GL easier for people to get into.


Ive been posting many threads about OpenCL in max.

I understand than gen is supposed to behave partially in the same way.

But why not having a standart industry like OpenCl process in Jitter

Ive been posting many threads about OpenCL in max.
Nobody ever answered (cycling or users)
I understand than gen is supposed to behave partially in the same way.
But why not having a standart industry like OpenCl process in Jitter
Wouldn't it be wonderful?


I honestly didn't read all of your posts, but what I read seemed all very reasonable. I only wanted to add some thoughts about Jitter vs. TD, since that's the only two of these tools I know in depth.

Somebody said, TD seems more high level. I think that's somewhat wrong, but it's a good point. Going professional in TD you soon find yourself writing a lot of expressions, Python scripts, GLSL and maybe C++. So it's really open, but you don't have to write code.

Greg, the founder of derivative(which makes TD) once said to me, max has so many objects, in TD you have very few.

It's a bit like the english language, where you can use the word 'get' in so many ways and meanings. You have one Math operator that does multiplication, addition, subtraction, remapping etc.. depending on how you adjust it. So that's one major difference I think (be it good or bad).

The other thing that has been mentioned is GPU acceleration. In TD, all image processing is happening on the GPU.

That makes working with it a lot more efficient of course. And you don't have to care a lot about uploading to the GPU etc.

I think both of these points can be summarized as 'headed towards artists'. And that's what I would say is the most convincing point. It is a development environment obviously, but the balance between having to develop and artistic expression is ideal for me.

Hi again,
I honestly didn't read all of your posts, but what I read seemed all very reasonable. I only wanted to add some thoughts about Jitter vs. TD, since that's the only two of these tools I know in depth.
Somebody said, TD seems more high level. I think that's somewhat wrong, but it's a good point. Going professional in TD you soon find yourself writing a lot of expressions, Python scripts, GLSL and maybe C++. So it's really open, but you don't have to write code.
Greg, the founder of derivative(which makes TD) once said to me, max has so many objects, in TD you have very few.
It's a bit like the english language, where you can use the word 'get' in so many ways and meanings. You have one Math operator that does multiplication, addition, subtraction, remapping etc.. depending on how you adjust it. So that's one major difference I think (be it good or bad).

The other thing that has been mentioned is GPU acceleration. In TD, all image processing is happening on the GPU.
That makes working with it a lot more efficient of course. And you don't have to care a lot about uploading to the GPU etc.
I think both of these points can be summarized as 'headed towards artists'. And that's what I would say is the most convincing point. It is a development environment obviously, but the balance between having to develop and artistic expression is ideal for me.


curious about your opinions on Jitter vs Touch Designer vs Unreal vs Unity