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

phiol's icon

Hi all

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.

Thanks a lot

:-)

Andro's icon

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.

-Unreal. No clue never used it.

woyteg's icon

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.

phiol's icon

Thanks to both for your answer.

@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...

Thanks again

phiol

Andro's icon

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.

Andro's icon

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.

phiol's icon

@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.

Thanks again Andro

phiol

Andro's icon

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.

Pedro Santos's icon

Hello, guys. Interesting topic, no doubt!

My humble opinion:

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.

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...

phiol's icon

@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.

Furthermore:

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.

For example:

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.

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.

Much respect to all of you

Phiol

vichug's icon

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...)

phiol's icon

@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.

Don't think TD was out yet...

Pedro Santos's icon

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...

phiol's icon

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 :-)

phiol

Andro's icon

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.

Spa's icon

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?

woyteg's icon

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.

phiol's icon

Thanks for your answer guys,

@ woyteg Andro spa: so why do you choose Jitter over any other. More precisely, what situations make you choose it over other softwares.

@andro : I 2nd everything you said about jit.gen. I did do a nice starter pack for jit.gl.multiple.
https://cycling74.com/forums/sharing-is-fun-quick-jit-gl-multiple-starter-set-up/
But it should have been in the example. as you said

Time: I built a huge patch last fall involving phys, a shit ton of pngs and the kinect for a live performance where the crowd was helping/influencing the music based to hitting visual node areas in the projected visuals and it literally took me 12-14 days for nearly 2 months to be built the damn thing. A Lot of the time lost was not finding good examples. A good chance Rob Ramirez is here often. But having the workload I can only imagine he has, it should depend on 1-3 employee and user waiting sometimes 2-3 days for an answer. Like you mentioned. Sitting down for a few hours and writing better and more straight forward intermediate level example , and a help file for all jit.gen, would save tons of time for all down the line.

Anyways, thanks for your thoughts

woyteg's icon

so why do you choose Jitter over any other. More precisely, what situations make you choose it over other softwares.

I love Jitter for martix processing (FFT stuff eg.), it's useful if you have multidimensional data inside Max. Otherwise I used it for small visual stuff. But honestly, as soon as I think about visuals, I tend to not use it. If I would use Jitter, then probably for a project that has to be done on a mac(TD is windows only for the time being).
One other advantage, Jitter has: You can make one package for an audio/video app, you have all the comfort of Max standalone creation. And you end up with one App. If you'd make an audio in Max/Video/GUI in TD package, and give it to somebody(some customer or end-user) they'd ask you if you are crazy. You'd have to tell them to download TD, Windows only, and run two applications at the same time..etc. Not ideal.

phiol's icon

@woyteg: thanks and good points.

Rob Ramirez's icon

thanks for all the thoughts and suggestions guys. documentation, discoverability and usability are works in process, so all this feedback is useful to us as we continue to make improvements.

one think i'd like to mention, if you do feel like essential things are missing from the docs please feel free to add to the wiki. it'd be great to get some more action over there.
here's the editing quickstart, in case you're interested in contributing:
https://cycling74.com/wiki/index.php?title=Editing_QuickStart

dtr's icon

I use Jitter for its total integration with audio synthesis and sensors/motion tracking in my Max systems. This lets me develop tightly coherent audiovisual instruments. I'm proficient in Max so doing my graphics in it as well grew naturally. That being said, I've haven't felt the need to try developing graphics in other environments so can't make informed comparisons.

Max Gardener's icon

I'll second Rob's suggestion that you seriously consider adding the things you think are missing from objects, and add that there are refpages "extensions" on the Wiki for every single object in Max. You can add what you think is missing there as an aid to others, and we also keep an eye on those pages when considering how to modify existing materials.

Andrew Benson's icon

I will weigh in (although I am also a C74 employee) as someone who has been a fairly dedicated Jitter user since about 2003. The big difference between Jitter and the other software mentioned is that Jitter developed out of the long history of Max, and began at a time when 320x240 quicktime videos were about all you could expect out of a computer in realtime. These other applications are fairly narrow in scope, and are purpose-built for a very specific type of work. As an open-ended prototyping and performing tool, I find Jitter to be very hard to beat, and I keep coming back to it when it's time to get work done. What other tool lets you build a granular sequencer and an image-distorter controlled by an accelerometer all in one place? For me, jit.gen and jit.gl.pix were a revelation in getting FX ideas running really quickly. I realize it can be tough to dig into, but if you are working with images in Jitter at all, you need to learn to use jit.gl.pix. I'm happy to help.
That said, there's a lot of work for us to do. I totally agree that we can do more to present ready-to-use solutions for things that everyone wants to do. A good example of this thinking is jit.world, which doesn't offer any new features, but makes it dead simple to get a render context running. This type of thing doesn't just make it easier for beginners, it also gets advanced users into the creative zone faster. There are things like this all over Max that we can improve upon. On my agenda for the week is putting in a proposal for a more user-friendly particle effects generator. To that end, I'm always happy to hear about things that you find yourself doing, or wanting to do often where it seems like the available tools are too complex.

phiol's icon

@Andrew : thanks for your nice input. And thanks for all your recipes and support in the forum throughout all the years.
>>To that end, I’m always happy to hear about things that you find yourself doing, or wanting to do often where it seems like the available tools are too complex.

Again, I don't think the tools are too complex if they are well demoed in context. (I guess @ intermediate level for my case).
I think all I can ask for/suggest at this point is a help file for every jit.gen and jit.gl.pix as you've done with all other max and MSP objects. Is there a reason why it was never done?

Thanks a lot for all your hard work, 'cause of guys like you making software like this, has change my life. All I've been thinking about for the past 10 years. Poor girlfriends ;-)

Probably the equivalent of when the piano 1st came out to some people :-)

thanks again

phiol

MH's icon

Thanks Phiol for rising the subject

I first would like to warmly thank all this community of great people ! The forum is very helpful and this is very much complementary to answers we don't find in the tutorials or help file.

I personally like it when softwares are open even though it is more difficult for someone like me who started as a painter !!! I have looked at Touch Designer, not worked with it unfortunately but I have the impression that yes it can be faster to create something but the customization might be hard to achieve. As an artist creating the tool is sometimes as important as using it (importing let says video material) and how you use it in performance.

For people who are looking for simple patches to understand the concepts and with increasing difficulties ... yes that could be helpful to have better reference patches and manual.

I have looked at IMI-Max-patches and they are really great and well organized for learning ... could use a little more explanations or comments on the patches.

Rob Ramirez's icon

these IMI patches are a great resource! thanks for sharing!

Pedro Santos's icon

Hello again to all of you.

Particularly to Cycing'74:
I just wanted to end my intervention in a more positive note.
Some of the issues I mentioned in my previous two posts of what I would like Max/Jitter to have, eventual problems, or even its positioning in the market's current offerings, was said because I love it and I would like for it to also become the main reference for visual artists as it is in the music world.
I know you guys work hard in it and I'm grateful for your efforts. We know you listen to your customers and that's why we bother to post these thoughts. And, independently of the features we would like to be implemented, we can always do great stuff (not easily replicated with other environments) with what's currently provided... as an example, this patch was done with Max 6 before multiple render targets and jit.gl.pass awesomeness (and it even could have been done with Max 5, as I'm not using any 6 exclusive feature like jit.gl.node or physics). So, independently of us wanting better Jitter multithreading, better video playback performance, more easy to use functionalities, etc, it's always possible to creatively overcome some of it, by "reinventing/replicating some wheels" in the process.

I might add that your're guilty of most of the "criticism" you receive. You're being a victim of your own success, as people want to keep using Max and pushing it to its limits, even for purposes that you've never even thought of. So, I guess this is a compliment. Keep up the great work, Cycing'74!

P.S: This is just a real-time recorded video I just did, examplifying the influence of the depth of field effect in 3D generated graphics (which you can now use in Max 7 very easily!). Depth of field is turned on from 30s onwards. The effect is more easily seen if you watch the HD version, although the video compression doesn't help...
https://vimeo.com/120682906

phiol's icon

+1 on everything you said Pedro. Also, thanks a lot for uploading and sharing new video on your vimeo channel.
This post had zero negative intentions in mind. It was solely to know why other people were using Jitter over other softwares. I only know Jitter and so am I very passionate about it.
What I was/am curious about is that every time I see some stunning realtime work (other than the guru's stuff I've seen here) and found out what software was being used, it's never Jitter. I was wondering why? Cause I know it can do stunning stuff.

Here in Montreal, the two most popular software used in Companies is for big production installations are Unity and TouchDesigner. I only know of only 1 other person using it, but know quite a lot of people using the other 2.

Last spring, I thought Jitter to a college Visual arts department staff, so they could include teaching interactive(and not) visual arts with in their curriculum. They hadn't even programmed with Max before and in 4 days they were doing pretty impressive gl stuff on their own with the module I had built for them. Boom! @ least 120 people trying it out right there this year! :-) (spreading the seed).
------

The "Better gen examples" demand:
1. It's always been of my nature to share what I learn and am passionate about with everyone.
2. the most impressive stuff I've seen in Jitter has jit.gen and jit.gl.pix associated to it.
3. I would love to have a help file for each jit.gen/gl.pix object like we do with max/msp so I could better figure it out on my time and in turn include it in my workshops. I mean a good example of efficiency is [snorm] and [norm].

thanks again for all the great work throughout the years C74.

phiol

Andro's icon

+1 Pedro. That video is incredible !! Did you use the particle system or jit.gl.multiple ??

Pedro Santos's icon

Thanks, Andro! Jit.gl.multiple for the spheres, jit.gl.mesh for the trails and points. The principle is very basic, the camera automation, the shader goodness (coloring, "bloom", feedback "motion blur", depth of field,etc) and some parameter optimization do the rest... If Max 7 had been released when I programmed this I wouldn't have to develop the dof and the motion blur... damn! ;-) No regrets, at least I learned to do it!

Andrew Benson's icon

Thanks Pedro for the kind words and for sharing your work. We really all appreciate the frank thoughts shared here. I want to invite anyone in this thread that is interested to email me directly to talk about how you are using Jitter and how you could see it being better (andrewb@cycling74.com). As we plan future features or improvements, it helps us a great deal to hear honest feedback about where we are and how the software is working for you, or where you see room for improvement.
As far as visibility of Jitter projects, I highly encourage taking a minute to browse the Community section of this site. We have nearly 1,000 user-submitted projects to date, many of them are pretty amazing. There could be 100x that many if everyone was sharing, but a lot of good work that gets done is either done under NDA or by people who don't want to give away their trade secrets. I know I do a lot of freelance work that doesn't get promoted as a Jitter project per se.

phiol's icon

Thanks to all of you and
thank you Andrew, this is truly amazing.

Thanks

mmake's icon

I have been using Touch for maybe two years now. We use it for visuals, driving leds and possibly dmx later this year. I like the fact that i can buy a used gamer pc and really boost the live performance, using the tips and the tools for optimising systems with Touchdesigner.

Lately i've been goofing with glsl and that worked as a gateway back to Max. Now with Max7 i can really get as deep as i want with only my mbp, into say video filters in Gen. I dont have to carry my gamer-rig to the coffee house to work on my displacement filters :)

I tried running some of the Max patches on the pc too but i didn't like it as much as TD. When i open my projects in Touch, i forget that i'm using a windows machine. I have also been using the gen export, to export shaders to Touch. That's my workflow now. I'll work on ideas on the laptop in Max, but do all my "bigger" shows on the Touch machine. Btw note to self, this summer i wont be using modul8 on small laptop gigs. I will use Max for those.

thouldcroft's icon

i jumped into this thread because I have beeb lucky enough to land in a professional environment where I function as a technician and a media educator. I've always thought Jitter as the be all end all, but now that I'm back in education students and faculty are coming from other places when it comes to visual creation. The comparisons were VERY helpful.

I'm one of maybe two Max programmers in the school (small lib arts college and) I've developed an intro class for sound and visual artists focused on interactivity. Anything we can do either as a community or on the Cycling 74 side to make it easier for beginners to get into Jitter would be appreciated. i too came to Max from the audio world (where I also had a formal education), but I soon developed an interest functioning as woder media artist. I still to this day have to do a lot of catch up whenever I spend some time away from Jitter, and I find I don't need to do that with the rest of Max/MSP. I'm glad to hear that other people have the same experience (it's easy to get discouraged; I feel like I'm am advanced Maxer and then I dive back into Jitter and I feel like a beginner sometimes). Really any way for beginners (or old beginners ha) to get acclimated and creating is a great idea to me!

One caveat: I still think buidling blocks are important so that fundamentals are understood. maybe it's my personal style (though students of mine have voiced similar thought), but tools that jump the student ahead glossing over some building blocks can be frustrating. So while some objects and tools to get students up and running but also tutorials so that students can rewind and see illustrated how to build up to those points would be great for education.

I always feel terrible making suggestions like this while I dont have time to contribute on the community level as much as I would prefer, so I want to make sure I express my appreciate for the community and Cycling 74, it's why I still use Max every day!

Andrew Benson's icon

Hi @Thouldcroft, have you looked at the Video and Graphics tutorial series (found in the documentation window in Max 7)? This is a fairly major rewrite of Jitter tutorials based on a practical approach and current usage. It was completed earlier this year and I think it gets overlooked often.

enrico wiltsch's icon

Touchdesigner is Now also mac compatible.

phiol's icon

Hi all, this thread is now 2.5 years old.

What is interesting is that (because of work) I've since learned and have been using almost exclusively Touch Designer in the passed 2 years. And with all software, there are plus and minus in each.
What is quite above in TouchDesigner is the patching workflow speed , it's insane how you can get stuff done in no time. Literally , (I've actually tested this) stuff I get done in 10mins in TD , can take me 35-40mins in Jitter. Because I'm fighting with patching more than concepts.

What I like best about TD it's environment designed. Every object has a name with a instance number and as you duplicate it , it's name number auto-increases. (Equivalent to scripting name in Jitter. myname[0], myname[1]etc...).
But the way every works in TD is that there is now UI message objects @ all. Everything is referenced using python scripts.
I.E. Jitter equivalent: Say you have a LFO as a dynamic moving value and
pretend we get rid of all numberUI and message UI , and all you have is the info window in the right side. What if you want the LFO value to manipulated a param value , well you simply ;
1. select the object value / reference it to the LFO output by writing the LFO's name and output OR
2. drag the LFO output to you object param value.
-----
Coming back to Max (and trust me I always do because I love it) but coming back to max feels exactly like coming back to the way new Apple products are now designed. 1 laptop and tons of adaptors to communicate with the inputs and outputs. So much time wasted in patching , instead of creating ideas. There has been a huge improvements with things like jit.world but still traditional max patch building can really be a pain sometimes. I'm mean I speaking from the point of view of someone of uses this software as a living. So yes quickkeys & shortcuts etc.. can easily become real time consuming if not present in the software design.

Back to the topic:
Now 90% of what we all do as Programmers is instancing of modules we create . But you want each instance to have independent behaviour and unique params.
So imaging the speed when everything is name based and you can reference to it.

poly~ / abstraction / bpatchers are the way to go , but can definitively be somewhat daunting for new users. Simply because of how there are designed and what is made obvious and available to users.

For example; when using abtraction and bpatchers ,
I had to search and find here in the forum , a way to get an instance name using js.
**see attached example.
Why am I so obsessed with object naming systems, well because you can use math to create
unique params for each individual instance in one go.
I even use poly~ nested in poly~ to achieve insane workflows that would otherwise create gigantique patches with tons of wiring.

But I only develop this way of thinking/patching because of TD.
Finally, what I think is most important and missing in Max is the object immune ability in max.
We all agree that the point of using abstractions is that you change the parent master/save and voilà , all clones are automatically changed. But sometimes, you want some clones to have unique objects that are immuned from the master. <-- this is huge, huge time saver.

mmmmm... I believe this post would be more clear if I'd done a video comparing the 2 softwares. Hope this is somewhat pertinent anyways.

Oh and C74 , please get rid of most everything that is not gpu based.
Old jitter is confusion for new comers to learn and then all have to relearn the way gl jitter works differently.

New Users, Jitter is really not to hard to grasp , you just have to get passed it's cryptic ways.

weird name like @jump 3 in jit.unpack to refer to unpack 3 planes. It could easily be jit.unpack [@inputs 1 @plane_amt 3 @offset 1] <-- you know straightforward simple stuff like that.
This is all over the place in Jitter. The nomenclature should always be the same for each objects. always.

But really, thanks for everything c74. I'm happy you exist .

01_bpatch_getnameV2.zip
application/zip 4.82 KB


Federico-AmazingMaxStuff's icon

Hi Phiol! Want to add my 2 cents too.

I have worked recently with Unity for a project and this is my experience:
super difficult to script. The documentation is not good at all, a lot of functions and classes are not well documented. To create a particle system using a mesh is crazy complex for a Unity beginner. You cannot create meshes with a number of vertices greater than a certain amount, so I ended up using more meshes aligned.
To use shaders is quite complex. I mean, if you want to write a shader from scratch you have a lot of options that don't make much sense for a newcomer.
A thing that I found good was the ability to add post-processing shaders directly on the camera with a drag and drop.

What I like of Max is the ability of creating everything on the detail, going as deep as I want.
I am the guy the writes his shaders from scratch, and I like a lot the possibility to use glsl functions inside jit.gen. I like very much the matrix system and how you can operate on a lot of numbers (like an array) without having to use for loops but just using the gen system.

Talking about the visual output, with Max you can have the same quality as Unity, is just that you have to work a bit on the shaders. Max doesn't really give you those pre-made modules, but if you are interested in understanding how the things work, is the perfect environment.

Said that, it took me 4 years to get to an advanced level with Jitter, the learning curve is quite steep. And that's also why I started doing tutorials : )

phiol's icon

Yup ! Do you remember contacting me ;-) !
Did you try to get your hands wet with TD ?

Sam Hains's icon

I have done a bunch of projects in Touch Designer(TD), then I took a class in video performance with Jitter.

Short version: Jitter is to breadboarding, TD is to custom PCB.

I have predominantly been working with video processing techniques for performance and installation purposes and haven't really gotten into 3D stuff at all yet, which from the looks of things TD is vastly superior.

Jitters default nodes run on the CPU. You have to use special nodes to use Jitter on the GPU.

Jitter CPU-mode feels like breadboarding - its fun, fast and playful. You can get ideas running fast and experiment with less friction. Max is very elegant language and it shines here, providing workflow advantages over Touch Designer when you are using the jitter cpu nodes.

Most Touch designer nodes seem to run by default on the GPU, and the workflow can sometimes feel a little clunkier, but the performance is an order of magnitude better and it feels much more robust.

However, VERY QUICKLY with Jitter you start running into performance issues when using the default nodes.

In trying to improve performance, most users look to Jitter GPU nodes but this is where the comparison starts to become very imbalanced..

In Jitter 'GPU-mode' what I am talking about is using the Jitter GPU nodes like jit.gl.slab or jit.gl.pix to do all of your visual work. So jit.rota becomes a jit.gl.slab shader, jit.brcosa becomes a jit.gl.slab shader etc.. Once you start using these nodes, you can't really switch back into using regular jit objects as this kills much of the performance gain. This is all OK, but compared to TD Jitter starts to feel like the clunky one.

Jitter GPU-mode is kind of like using like the using the Touch Designer GLSL node to do absolutely everything. Although that said the TD GLSL node feels a lot a lot more intuitive and well integrated than jit.gl.slab  and thats not even getting to the 100+ modular GLSL abstractions that TD gives you for free with their own GUI you can play with along side that.

GPU jitter really just feels like an afterthought to me, and as much as I love Max and the idea of a monolithic development environment for audio/visuals/interaction etc I don't think it holds a light to TD at the moment for serious visual work.

They really should rewrite Jitter so that it only runs on the GPU, and I think this comparison might become a lot more balanced. Although, perhaps C74 is more interested in optimizing performance for lower spec'ed computers - which is also a very worthy goal, of course.

If you just want to throw together some ideas and try some simple audio/visual ideas out, I think using the default jitter nodes to play is a great idea... But I'd probably just learn Touch Designer and communicate with Max via OSC if you find yourself starting to get into jitter GPU nodes to improve performance....

alex de selve's icon

hi !
Im a 3d graphic designer and a singer in an electro band : http://www.bad-pilot.com (france)
Now, I want to do Vjing to mix my 3d stuff with my music , and my first idea was to do it with Unity3d
but i cant find tutorials to explain how to animate the objects of unity with audio controllers ... I found the big great job of Keijiro and tested some stuff but ... i would like to learn with good tutorials .
If anyone can help , would be great .
Thank you for all this conversation . It helps me already .
Alex