Ben Bracken

We are happy to announce the release of Max 7.2.5. This release has a few MIDI-related fixes, VIDDLL improvements, a fix for the hi object in 64 bit, and more. Please take a look at the short change log below.

As always, you can download the installers here:

• jit.gl.imageunit: fixed for Mac El Capitan OS

• Max For Live jit.movie: fixed texture_output glitches in Live in certain situations

• MIDI: deleted devices are properly hidden from the UI and @name attribute

• mpeparse: correct zone number in mpeevent output for channel pressure events

• playbar: only bangs jit.movie if @automatic is set to '0'

• plot~: redraws properly after a buffer~'s size is changed

• polymidiin: properly outputs all cc/pitchbend messages

• VIDDLL jit.movie: fixed crash when asyncread sent with movie file already loaded

• VIDDLL jit.movie: fixed issue with certain gifs when @output_texture is enabled

As always, you can download the installers here:
https://cycling74.com/downloads

Fixed Bugs:
• hi: fixed 64bit usage
• jit.expr: fixed functors for 64 bit
• jit.gl.imageunit: fixed for Mac El Capitan OS
• jit.movie~: works in a standalone
• Max For Live jit.movie: fixed texture_output glitches in Live in certain situations
• MIDI: deleted devices are properly hidden from the UI and @name attribute
• mpeparse: correct zone number in mpeevent output for channel pressure events
• playbar: only bangs jit.movie if @automatic is set to '0'
• plot~: redraws properly after a buffer~'s size is changed
• polymidiin: properly outputs all cc/pitchbend messages
• VIDDLL jit.movie: fixed crash when asyncread sent with movie file already loaded
• VIDDLL jit.movie: fixed issue with certain gifs when @output_texture is enabled


max-7-2-5-released

Hey Ben, unfortunately i still have this asyncread problem with viddll. (el capitan, 64bit, h264 test-files)

Please check this patch i made. Load a folder with around 10 video clips in, and let it run.

It may take some minutes but it will always chrash after a while (sometimes immediately, sometimes after after 5min)

Hey Ben, unfortunately i still have this asyncread problem with viddll. (el capitan, 64bit, h264 test-files) 

Please check this patch i made. Load a folder with around 10 video clips in, and let it run.
It may take some minutes but it will always chrash after a while (sometimes immediately, sometimes after after 5min)

i can reproduce your crash, and will see if there's anything to be done to alleviate this.

however, it will be much more useful for me to understand the actual real world scenario that is causing the crash. in this case, it seems you are trying to quickly load a folder of movies and extract a frame from them. possibly to make thumbnails?

there's a much smarter way to achieve that. the following patch illustrates how to use the "read" notification out of jit.movie to trigger frame output at a specific time, and fills a jit.matrixset with those frames. i just tested with a folder of 150 movie files and there are no crashes using this technique.

if i'm wrong about your intentions with this, please clarify with the actual use case.

however, it will be much more useful for me to understand the actual real world scenario that is causing the crash. in this case,  it seems you are trying to quickly load a folder of movies and extract a frame from them. possibly to make thumbnails?

and if the intention is to play short segments of files from a folder, here's a better way to do that, again making use of the "read" notification:

Hey Rob, thanks for your reply. Yes, i want to load clips from a folder very fast, depending on the input (let's say an arpeggiator, or a bpm value, or maybe a Geiger counter) The patch i made was just for understanding what causes the crash, it's just a load test.

Both patches of you are stable as long you stay with this "slow" load. If you go a bit faster in triggering the umenu, both of your patches will crash as well.

Hey Rob, thanks for your reply.  Yes, i want to load clips from a folder very fast, depending on the input (let's say an arpeggiator, or a bpm value, or maybe a Geiger counter) The patch i made was just for understanding what causes the crash, it's just a load test.
Both patches of you are stable as long you stay with this "slow" load. If you go a bit faster in triggering the umenu, both of your patches will crash as well. 

ah i see, prior to 7.2.4, the viddll engine jit.movie didn't actually implement an asyncread behavior, it simply used the synchronous read behavior for both read and asyncread messages.

if you want that behavior, just change the message to read. if you want asynchronous file loading as fast as possible, utilize the technique in my first patch.

Hi Ben, I really dont understand how to update my version. I have a monthly suscription.

Just download the application and simply run the installer, copying over the current application. You will not need to re-authorize your computer.

Drop a line to support at cycling 74 dot com if you are having any problems.

I'd like to make a feature request that jit.movie~ can support multichannel audio tracks. I believe it's the only way to solve the issue once and for all of keeping audio and video in sync when scrubbing. I'm disappointed I cannot even find a workaround.

I've tried everything I can think of and simply cannot keep longer video files in sync with multichannel audio loaded to sfplay~ object, because there is a significant lag when using "frame" or "time_secs" messages to the video file which causes it to lose sync with sfplay~ (which has no problem jumping around to different places instantly).

There is also no notification from the "dumpout" of jit.movie to indicate that the file is now playing from the new location (in order to use that to trigger a message to sfplay~ to jump to the same location).

I'm not getting any "seeknotify" notification from the dumpout either.

I've tried using 1GB cache and loadram message but no matter what values I specify for loadram, I get a notification that it has only loaded just under 3 seconds of the video to ram.

It would be really really great if a future version of jit.movie~ could detect the number of audio channels embedded in a video file, and create the corresponding number of audio outlets.

I've tried everything I can think of and simply cannot keep longer video files in sync with multichannel audio loaded to sfplay~ object, because there is a significant lag when using "frame" or "time_secs" messages to the video file which causes it to lose sync with sfplay~ (which has no problem jumping around to different places instantly). 

It would be really really great if a future version of jit.movie~ could detect the number of audio channels embedded in a video file, and create the corresponding number of audio outlets.


Update: Not such a showstopper as I did manage to find a way to maintain sync, albeit I am estimating the worst case scenario for video load time and delaying resume by that amount of time - stopping sfplay and jit.video, forwarding the time_secs readout from sfplay, waiting the estimated amount of time (perhaps HDD is slower for seeking in long videos than SSD, but have to accommodate the worst case scenario...), and then trigger both players to resume in sync.

It's a workaround I could live with, but the way to guarantee it staying in sync would be to have it all in a single object!

Max 7.2.5 released