The 8.1.4 Jitter Roundup
Rob Ramirez
May 27, 2020, 6:30 PM
Hey everyone, the Max 8.1.4 release is crammed full of fantastic new features and bug-fixes, so I thought it would be helpful to highlight and expound a bit on the Jitter specific changes.
jit.pwindow
First up, and probably the most impactful on your everyday Jitter patching, the jit.pwindow performance improvement when displaying textures. Patches will no longer experience FPS drops when a jit.pwindow is added to the chain as a viewer. In many cases this will result in significant improvements. The screenshot below shows the same patch running in 8.1.3 vs 8.1.4. On the left we can see the output hover ~20 FPS when using 8.1.3, compared to the right side which maintains a steady 60 FPS.
Dynamic patchcords
This screen shot highlights another significant update in 8.1.4 — video object patchcords (jit.movie, jit.grab, jit.playlist, jit.world) will now dynamically update their type (matrix green or texture blue), depending on the object’s output_texture state. While this change doesn’t impact performance, it does give a much more accurate picture of what’s going on in your patch.
Matrix / Texture Probe
Speaking of what’s going on in your patch, the revamped Matrix Probe debugging tool (Debug —> Matrix Probe) now fully supports probing on all video objects and texture output objects. A super useful tool neglected no longer. Expect to see continued improvements to matrix and texture probing in future updates.
jit.pworld
We’ve also snuck in a new object, jit.pworld, which provides an alternate way to view GL and video content in your patch. Unlike jit.pwindow, jit.pworld is an “active” GL context, so there is no need for an additional jit.gl.render or jit.world to display GL objects. Additionally texture output from video objects is fully supported by jit.pworld. What this means is displaying HD video in your patch only requires 2 objects, the video object and a jit.pworld.
Viddll and Hap
Also in 8.1.4 we have an update to the Viddll engine, with the most significant change being greatly improved performance with Hap encoded files. The Viddll engine Hap player also provides several advantages over the old Windows Hap package player, such as no requirement for AVI container format (windows-hap’ers know how much of a pain this was), reverse playback, and loadram support.
With this update there is no longer a need to install a separate package to support Hap playback on either OS (the avf engine added Hap support in 8.1.2). This also brings Hap support to both the sidebar video browser, and jit.playlist (when the viddll engine is enabled in Max Preferences).
We’ve also added a new Jitter entry the Max Preferences, called Default Cache Size, which sets the default value of the cache_size attribute for new jit.movie and jit.playlist objects when using the Viddll engine.
jit.playlist
The playlist family objects received significant love this go round, and it really shows. See the 8.1.4 release notes for the full list of changes. I'll just reiterate here, significant performance improvements when using jit.playlist with several files in a single playlist object and with still images, in addition to all the fantastic UI improvements.
Hopefully this gives you an idea of what to expect in 8.1.4 for moving your pixels around, happy patching!
Pedro Santos
May 27, 2020, 6:53 PM
Thank you, Rob and Cycling74 for Max/Jitter's continued improvement!
Rob Ramirez
May 27, 2020, 6:59 PM
Cheers Pedro!
Quick note I forgot to mention, GL3 users please update to the latest in the Package Manager for 8.1.4 support.
df1
May 27, 2020, 7:16 PM
Woohoo, been looking forward to this one, especially for colour coded patch cords! Thanks Rob!
Pedro Santos
May 27, 2020, 9:35 PM
That and jit.pworld, although I've some doubts about its implementation. I thought it would be similar to jit.world (render, videoplane, physics, camera, etc) but it seems to be more basic. For instance, I can't find a way to control its internal frame rate when drawing OpenGL objects, when receiving texture it seems to adjust automatically to the incoming framerate.
Rob Ramirez
May 27, 2020, 9:39 PM
yup designed with absolute simplicity in mind. we can always add features based on user feedback, but we can't take them away. feedback is welcome.
Jazer Giles
May 27, 2020, 9:46 PM
This is great Rob! Thank you!
Herr Markant
May 27, 2020, 10:43 PM
jit.pwindow without CPU readback: I weep with joy!
Thank you!
stefano
May 28, 2020, 12:23 AM
I have been waiting for this since Rob anticipated some features on that YouTube streaming last month... Amazing update!!!
I don't want to be the party pooper here but I noticed a problem with looping in VIDDLL. I am working with my students on some project using multiple video looping / phasing and it seems that VIDDLL + Apple Pro Res on 8.1.4 = movies getting stuck without frames output at the end of each loop. Here an example patch that runs very smoothly in 8.1.3 but that stucks at each video loop in 8.1.4. (see fps attached to jit.movie)
and the video used in the patch:
https://base.uni-ak.ac.at/cloud/index.php/s/oKesgX5RfPg5N8D
running Catalina on a MacBook 16inch
Herr Markant
May 28, 2020, 12:38 AM
GUI problem: It is not possible to send the new jit.pwindow "to back" or put any other GUI or Text messages "on top" (bring to front) of it.
Federico-AmazingMaxStuff
May 28, 2020, 9:00 AM
That's great Rob!
One question about jit.pworld: you cannot use more than one in a patch, is that correct?
Or can you use something like the @shared attribute and visualize what's going on in another gl context?
Or is it more like a buffer visualizer that is going to go reading the address of the texture you send it?
Pedro Santos
May 28, 2020, 9:57 AM
Hi Federico. As I understood, what you describe (buffer visualizer) is closer to what jit.pwindow is now (e.g., showing matrices or textures without the CPU readback).
Jit.pworld seems. to be an even more simplified render/window context than what jit.world is.
As you can give a name (render context) to each jit.pworld, you can have several of them in a patch.
Federico-AmazingMaxStuff
May 28, 2020, 10:52 AM
Hi Pedro!
Yes you are right, I completely overlooked the improvement in jit.pwindow. I'm getting old!
Rob Ramirez
May 28, 2020, 2:36 PM
cheers everyone! Markus, that's the trade-off with removing the CPU readback. if it's an issue I could see us adding an attribute to force readback on textures, to get back the pre 8.1.4 behavior.
Herr Markant
May 28, 2020, 8:24 PM
@rob Yes, unfortunately this is a big issue for me, and I would prefer the "old style", even if it would reduce my performance. For me, it is essential to have settings and buttons "above" the pwindow! Many thanks, Markus
Pedro Santos
May 28, 2020, 11:06 PM
I think Herr's problem could be easily solved if jit.pwindow behaved differently for matrices and textures.
Actually, it seems to already be doing that, but with an unexpected behaviour. Notice the attached patch: the UI element is in front of the jit.pwindow, it's only when output_texture is turned on that the window stays in front. After that, even if you turn output_texture off, the jit.window never behaves as it originally did.
On a related topic, Herr, did you try to build a GUI above a jit.window? You could use a similar approach to put your GUI on top of a jit.pwindow, as the compositing would be done by the OS window server, not Max/Jitter.
Rob Ramirez
May 29, 2020, 2:53 PM
Pedro is correct. jit.pwindow will exhibit pre 8.1.4 behavior as long as it is displaying matrices. As soon as you send a texture it will enable texture display mode. There is no way to disable texture display mode after it is enabled. If you want pre 8.1.4 behavior you can simply routepass jit_gl_texture messages through a jit.matrix (or more efficiently, albeit delayed by a frame, a jit.gl.asyncread)
but Pedro's solution of placing the GUI in it's own sub-patcher with a floating window, transparent background (or optionally enabling the new "Enable Transparent Patcher With Titlebar") would be my recommendation for best performance.
Would either of the above work for you?
If we do end up adding an attribute for readback mode, it will default to no readback (i.e. the current 8.1.4 behavior). But for now the above is you best course of action with 8.1.4.
Pedro Santos
May 29, 2020, 4:48 PM
Hi again, Rob. I've just tried my patch from the topic I referred (GUI in a tranparent window above jit.window/p.window). I've noticed that it behaved as expected, but now it doesn't anymore.
In order to have the possibility of a transparent background, I had to use the "window notitle" flag.
I understand that in the patcher inspectar now it has a flag to enable a tranparent background regardless of the title/notitle configuration. Unfortunately, it now must be explicitly enabled even if I already have the "notitle" configuration. So, I think it would be better named as a general "Enable Transparent Patcher" as it must always be turned on... See attached patcher:
And since, we're at it, here's the updated patch from the previous referred topic:
Rob Ramirez
Jun 1, 2020, 3:14 PM
thanks pedro, I'll pass this along to the interested parties.
foldh
Jun 11, 2020, 12:42 PM
A fantastic update. Thanks Rob and all at C74.
DFICT
Aug 11, 2020, 8:11 PM
dear rob,
i'm really impressed by the functionality of the gui in the jit.playlist object. is there any plans to update someday with a MSP dedicated object, like, "jit.playlist~"? I really get a lot of mileage out of "jit.movie~"—this makes recording dedicated performances with the jit.vcr object much more clear. Or, is there some way to route audio from jit.playlist that i do not understand?
Rob Ramirez
Aug 12, 2020, 3:09 PM
hi Daniel, thanks for the feedback. I have received a few other similar requests for a jit.playlist~ object since 8.1.4, so I will file a ticket for this and we will have it on our radar.
but yes, there is currently no way to route audio from a jit.playlist through MSP (unless you use a virtual driver like Blackhole/soundflower/etc).
What you can do now is extract the audio track from the video track and load the audio in a playlist~. The two objects are fairly straightforward to keep in synch.
A simple ffmpeg command to extract an audio track from a video track is:ffmpeg -i blading.mov -vn blading.wav
Martin Beck
Sep 20, 2020, 10:30 AM
Feature requests for [jit.pworld]
a) Enable/Disable rendering via int message like jit.world (in order to save laptop power and calm down the fan).
b) Attribute for frame rate that controls fps if no texture is connected to the object.
Rob Ramirez
Sep 21, 2020, 7:47 PM
thanks Martin, agree both those items are missing, will ticket.