Fpic preloads?
Hello,
I wonder if there is a way (or more likely a trick, because the help file doesn't offer much) to preload a big folder of png images (180Ko each) for later display by one or more fpics, potentially in unpredictable order.
On recent machines I'm not sure the difference would be huge, but I'm prototyping on an older Macbook Pro. There's sometimes a perceptible delay and I need the display switch to happen closer to a specific time mark — and ideally, not interfere with more important calculations in the background.
I suspect Jitter would be the way — I see the matrix out of fpic obviously — but I'm not sure what that entails in term of ressources vs. the original. I'm less fluent with Jitter than Max and MSP so forgive me in advance if that's another shtupid question :)
Thanks !
sounds like 3 questions
[chooser] is great for quickly loading a lot of images or movies
easily get them out using counter, random, urn-jb
There's sometimes a perceptible delay and I need the display switch to happen closer to a specific time marknot sure what the switch is
or directly into jit,movie (not sure your end game)
I think switch means recall of image - precisely with set time.
If that are not huge png files, fpic is perfectly ok,
one can populate umenu with media, and simply recall.
Oops I was editing and deleted my reply by mistake.
Yes "switch" meant calling any other image in that folder for display in a given fpic. The latency is perceptible enough to be annoying.
The pngs are less than 200Kb each, but still loading is janky on my 2019 Macbook Pro 2,3 GHz Intel Core i9 (much better on my M2 Macmini). So clearly fpic is not perfectly ok. I'm trying to find a solution to a problem that didn't improve over the last 10 years, possibly due to Intel graphics…
So preloading in the RAM was one possible solution.
The other solution is Jitter. But I'm just not sure if I win anything by switching fpic with jit.movie in term of ressources. I have two fpics one on top of the other, working as a sort of A B A B A alternate for musicians to see page turns in advance.
I have a 2017 MacBook Pro - have to charge it up
for now looks like jit.qt.movie is faster than fpic -
you can see the latency on fpic
(m1 Mac)
"preload" sounds like a jitter job.
not sure about ther reliabily of modern builds of vanilly GUI objects, but worst was loading lcd sprites, where loadbang message can simply fail at init.
using a jitter matrix also means that max itself has the control over loading a file only once and then dispaying instance of it in various places.
@WIL Thank you, I tried your example but latency is slightly better than fpic but still perceptible on my machine :(
Also more problems I didn't expect compared with the simple fpic approach :
1) I usually superimpose some semi-transparent sliders on top of my two fpics, to represent time passing for the current phrase. It seems that's not possible with the GL texture output / jit.world running, where everything comes to the front of my jit.pwindows (unless I missed something). So I'll need to learn how to do this without matrices… (I'm getting old, my last Jitter course was in 2005 😵💫)
2) I'm not sure how to handle dimensions anymore. My fpics were quite big (3308. 475.) and with both forceaspect and autofit turned off, to avoid stretching my pngs which are large horizontal pictures sometimes with different heights.
In jitter, changing the size on each load from jit.qt.movie (right output moviedim) to jit.pwindow generates some black blinking. So not the right approach but I'm not sure where to go next…
@ Roman
Thanks for the new lead ! Do you see another way to do this outside of GL, where I could preload all those pngs in different jitter matrices on the fly? Not sure how, something like n instances in poly~ then call them by name or something in that vein?… Again my jitter is very basic but if you have a clue of which objects to look at that would be already a huge help. Thanks !
no need for poly~, but it will be a good idea to store them all in once place.
in the past i have also been storing very small pixelgraphics right in a [coll] and move that data to a jit.matrix at init.
in modern versions of max you could do that also with medium sized pictures. and if collectives, plug-ins or standalones is your target, you probabyl should experiment with including the media files right inside in the app (which can not be tested during programming in max, but can solve problems which might appear there)
Hi , if you want to try again try to load the png directly as texture, on M1 I see fpic with more delay
JULIEN VINCENOT I think this is close to what you want
reworked a patch from 2014 using matrix
in this scenario the image on the right moves to the image on the left (like orchestra page turns)
I set matrix dimension to largest image (changing dimensions of the fly blows it up! maybe someone has a better way)
haven't test on older machine - but code written in 2014 shouldn't have a delay on a machine from 2019
P.S. - I make these helpers because I might use it later!!!
Sorry I forgot to reply, and then Max 9 came out and I suddenly had many more problems 😅
Thank you both for the few examples.
I'll need to do more tests on Apple silicon, fpic is still not the best result but still easier to manage. If I want to superimpose those timing sliders in Jitter (since I cannot use actual Max sliders) I need to… well learn Jitter more in depth so probably not now for me. Anyway thanks again for your time !