phiol

A profiler like you have in Unity https://docs.unity3d.com/401/Documentation/Manual/Profiler.html

In TD you have 3 things to show you what object is doing what amount of processing. (cooks)

- The probe object, shows you your patch and all subpatche with color coding 

https://www.derivative.ca/wiki088/index.php?title=Probe

- middle clicking on any objects gives you all of it's info , how much process it is doing etc...

Screen Shot 2018-04-03 at 10.06.46 PM.png

- a performance monitor , displaying what every single object is doing, in a single window

https://www.derivative.ca/wiki088/index.php?title=File:PerformanceDialog.jpg

We have something half there with MSP and show CPU usage. colors but no real numbers.

Thought this is really, really important.

ps. Never understood how to use debug mode in max

More Tools for debugging 
A profiler like you have in Unity https://docs.unity3d.com/401/Documentation/Manual/Profiler.html
 and or in Touch Designer 
In TD you  have 3 things to show you what object is doing  what amount of processing. (cooks)
- The probe object, shows you your patch and all subpatche with color coding 
https://www.derivative.ca/wiki088/index.php?title=Probe
- middle clicking on any objects gives you all of it's info , how much process it is doing etc...

- a performance monitor , displaying what every single object is doing, in a single window
https://www.derivative.ca/wiki088/index.php?title=File:PerformanceDialog.jpg

We have something half there with MSP and show CPU usage. colors but no real numbers.
Thought this is really, really important.

ps. Never understood how to use debug mode in max 

More Tools for debugging 
A profiler like you have in Unity https://docs.unity3d.com/401/Documentation/Manual/Profiler.html
 and or in Touch

things-we-would-like-to-see-in-max-8-jitter

Oh, put all ob3d object with @blend_enable 1 by default.

'Official' sensors objects:
kinect, leap, cv lib, etc..


UI objects not killing the jitter frame rate.

parallel / alternativ thread for data (matrices) processing. a bit like with poly audio

'Official' list of working digitizer. blackmagic, usb, etc...

Direct texture to GPU digitizer. Quadro nvidia

Accepting that gpu are/will be bad on Mac, and devellopping specific external for win64 only

Telling us what is the future roadmap and workforce put on jitter max 8, given that max is now ableton owned and will focus essentially on audio

Access and process matrices and jitter objects with a faster language than JS. Java is great and much faster, but lacks many access and is not maintained

Mac is moving toward high end GPU support. It would be interesting to see if this can be leveraged out-of-box with Jitter! I am in the camp of preferring Mac for all things AV but currently needing to use Windows to do the really intensive realtime stuff:

https://techcrunch.com/2018/03/30/macos-finally-gains-external-gpu-support/

I'd have only one request and it's totally not feasible in time for Max 8's Jitter (bet most of these are too late): jump to a much more modern OpenGL version foundation. Everything is going lower level with DX12, Vulkan, etc., and Max's model has always been that since objects are written in C/C++, then the runtime signal side can be quite efficient even though the front end graphical UI is quite high level and user friendly.

So we want the same thing for Jitter, to do incredible things in VR etc, which would require an underlying graphics API that is optimized for GPUs etc in the way that all these modern APIs are.

It would be educational to know exactly which version of OpenGL Jitter is currently (and I assume for Max 8 as well) based on, I am not sure I ever read that but for some reason I vaguely recall it being in the 2.X range.

https://techcrunch.com/2018/03/30/macos-finally-gains-external-gpu-support/ 

I'd have only one request and it's totally not feasible in time for Max 8's Jitter (bet most of these are too late): jump to a much more modern OpenGL version foundation. Everything is going lower level with DX12, Vulkan, etc., and Max's model has always been that since objects are written in C/C++, then the runtime signal side can be quite efficient even though the front end graphical UI is quite high level and user friendly.

You mean paying 2.5x the price for the same OpenGL power on Windows...

And Drivers will (and has never been) optimised on osX compared to windows.

And GPUs frame sync will never be disponible on osX.

That's why I think cycling should accept to look at jit.gl with some windows specific objects.

or vvvv and touchdesigner will definitively take over...

Well, eGPU on Mac,
You mean paying 2.5x the price for the same  OpenGL  power on Windows...
And Drivers will (and has never been) optimised on osX compared to windows.

And GPUs frame sync will never be disponible on osX.
That's why I think cycling should accept to look at jit.gl with some windows specific objects.
or vvvv and touchdesigner will definitively take over...


Yes that is a good point. I really want to make it work with Max to have the tightest possible integration with Ableton (at least for what I'm doing), so I am trying to get some basic benchmark comparisons before I dive in. I think Touch Designer has a pretty deep way of connecting to Ableton too.

And I am surprised by lack of NVidia support for the eGPU. So you are right I think, the most competitive solution would be to rebase on modern graphics framework and push the envelope on the Windows side to reduce bottlenecks wherever possible..

Here's an interesting watch on-topic. It would be so great to optimize GPU usage for realtime graphics and reserve more CPU for audio processing:

http://cdm.link/2018/04/how-to-try-gpu-accelerated-live-visuals-in-a-few-steps-for-free/

@ SPA "Access and process matrices and jitter objects with a faster language than JS. Java is great and much faster, but lacks many access and is not maintained"

This is actually possible now via the codebox inside jit.gen - much faster than Java.

@SPA "parallel / alternativ thread for data (matrices) processing. a bit like with poly audio"

You can use poly~ to process matrices in parallel threads. Also, as it's clearly explained in MAX SDK docs, general structure of many matrices-processing objects are implementing multithreading (under the hood) already.

You can use poly~ to process matrices in parallel threads.  Also, as it's clearly explained in MAX SDK docs, general structure of many matrices-processing objects are implementing multithreading (under the hood) already.

this has been possible in Max for many years, so not really sure what you're suggesting.

let me take this opportunity to link to my 

, that maybe some of you on this thread haven't seen.

let me take this opportunity to link to my Jitter Resources google doc, that maybe some of you on this thread haven't seen. 

regarding eGPU support, I haven't heard any reports from users that Jitter doesn't support eGPUs, so AFAIK they are supported. make sure you've connected your display to the egpu prior to starting Max, and that you instantiate your jit.world / window on the display connected to the egpu (via the rect attribute) if necessary.

I have also some remarks on the eGPU topic (on macOS)... and some more universal remarks.

New macOS native eGPU support allows, inter alia, for video loopback (displaying image on the internal laptop display while all graphics data are processed on external GPU) - this is a nice feature, but must be handled by the application itself and MaxMSP/Jitter hasn't this "mode" implemented yet (but it's really new feature, from the latest High Sierra update, and almost no developers adopted it so far). Also, there is no information in jit.world help/references about the instantiating procedure (or I overlooked this information) mentioned by Rob - and rect attribute is not really handy solution (what if you just drag the window on external display? is that works?). Sum up: I think that Jitter eGPU support is not as encouraging as can be, even if, from technical point of view, it works.

However I have the impression that the poetics proposed by SPA is somehow offensive (sorry if I'm wrong) I can support him to some extent at least in the feeling that it would be nice to share and discuss our ideas and needs for further Max/Jitter releases (not sure if this affect v. 8).

- possible abandoning OpenGL and building Jitter development on Metal on macOS and DirectX on Windows;

- iOS MaxMSP? Any chance? iPad Pro is fast enough, even if iOS is still not full featured OS (from my perspective). Live+MaxMSP/Jitter on iOS (even if somewhat truncated) I would consider it a breakthrough.

@ROB: Thanks for the link (to the  Jitter Resources google doc) - it's a great guide.

I have also some remarks on the eGPU topic (on macOS)... and some more universal remarks.  

New macOS native  eGPU support allows, inter alia, for video loopback (displaying image on the internal laptop display while all graphics data are processed on external GPU) - this is a nice feature, but must be handled by the application itself and MaxMSP/Jitter hasn't this "mode" implemented yet (but it's really new feature, from the latest High Sierra update, and almost no developers adopted it so far). Also, there is no information in jit.world help/references about the instantiating procedure (or I overlooked this information) mentioned by Rob - and rect attribute is not really handy solution (what if you just drag the window on external display? is that works?). Sum up: I think that Jitter eGPU support is not as encouraging as can be, even if, from technical point of view, it works.

Same with @l3vidus — what would happen with Jitter in the long run with the new APIs on Mac and stuff.

y'all for real tho, we just heard about this decision when you did, two days ago. OpenGL is not going anywhere anytime soon. we are not abandoning our code base cause apple wants to push metal on us. we will be watching this area closely over the coming months and make an informed decision on what direction is best for our product.

It's not strictly Max8, but related. Due OSX support for eGPU will be better with upcoming version (here some info: https://www.macworld.com/article/3294696/macs/macos-mojave-egpu-macbook-pros-display.html) my a little bit sceptical remarks about using external GPU with Max/Jitter on OSX become... obsolete?

"preserve_aspect" property on good old jit.gl.videoplane?

It's already present on jit.gl.cornerpin and jit.world internal videoplane...

"preserve_aspect" property on good old jit.gl.videoplane?
It's already present on jit.gl.cornerpin and jit.world internal videoplane...

@PEDRO: you mean something like "@transform_reset 2"?

It's close but not completely, transform_reset 2 stretches the videoplane filling the whole screen. If, by chance, the video is the same ratio than the screen/projection, it's OK but, for instance, a 4:3 video will get stretched on a 16:9 screen/window.

"preserve_aspect 1" will do just that, preserve the aspect ratio of the incoming video.

It's close but not completely, transform_reset 2 stretches the videoplane filling the whole screen. If, by chance, the video is the same ratio than the screen/projection, it's OK but, for instance, a 4:3 video will get stretched on a 16:9 screen/window.
"preserve_aspect 1" will do just that, preserve the aspect ratio of the incoming video.


Yes, there is a functional difference between the transform_reset and preserve_aspect.

And I agree, it will be very useful to see preserve_aspect (or something similar) with jit.gl.videoplane too.

I remember, I was trying to create a similar mechanism some time ago - theoretically, if you know video resolution and pixel aspect ratio you can calculate all needed variables and control scale of the videoplane. But it's really problematic to extract resolution and pixel aspect ratio from video file inside Max.

I remember, I was trying to create a similar mechanism some time ago - theoretically, if you know video resolution and pixel aspect ratio you can calculate all needed variables and control scale of the videoplane. But it's  really problematic to  extract resolution and pixel aspect ratio from video file inside Max.

- CodeBox update: matrix functions e.g. mat2 mat3 mat4, better error messages, global variables, left hand expressions.

- jit.gl.shader update: i have personally found it hard to make vertex shaders. Maybe this is because old posts explaining how to do things are missing files.

- CodeBox update: matrix functions e.g. mat2 mat3 mat4, better error messages, global variables, left hand expressions. 

- jit.gl.shader update: i have personally found it hard to make vertex shaders. Maybe this is because old posts explaining how to do things are missing files. 

Things we would like to see in Max 8 Jitter