jit.gen lag on first pass
Hey all!
im having an issue where I have a 4 voice poly~ with about 4 jit.gen objects in it and the first time I send a matrix through any of the jit.gens there is a Moment of latency and my computer hangs. This becomes really slow when I send a matrix through all of them and my computer hangs for like 8 seconds.
Strangely after sending the first matrix through there is no more hang up with subsequent matrices of any dinension.
also it doesn’t matter how big the first matrix is , even 1x1 fin matrix, they all cause the same amount of hang up.
it doesn’t even make a difference if I give the jit.gen arguments and make sure they match the incoming matrix in terms of dim, plane count and type, it will still cause the hang up.
has anyone experienced this and know a way around it? I’m trying a lot but nothing works hence why I’m here. An additional 8 seconds of load up with this is really bad for my project. Thanks a ton!
I should add that the code in them is not even long or heavy or complex. In fact one of the jit.gens is really short and simple code and it still hangs just as long as the others on the first pass of an incoming matrix
Are you using jit.world or jit.gl.render? Depending on what's going on in the patcher, it might takes a while to start for the first time after the patch opened.
Did you try to strip down your patch to the bare minimum and see if the problem persits? It might help you isolate where the problem come from, and if it doesn't, just paste your stripped down version here so we can try to help you further.
I am currently working on a project involving a [poly~] with usually +10 voices, and a jit.anim.node and jit.anim.drive with some named jit.matrix (shared accross each poly~ voice) inside of the [poly~] patcher (no jit.gen though), and I don't experience such a hanging moment when the first matrices come in.
Pretty sure it has nothing to do with that, but just in case: what's your computer specs?
this is jit.gen I’m using so I don’t use a jit world or gl.render, I am just processing some sample data.
just to reiterate it only happens for jit.gen, none of the other jitter objects I’m using have that issue, so if anyone has had a similar issue I’d be curious!
ill try seeing if I can recreate the issue in a simpler patcher to see if it clarifies anything
Just added some dummy default [jit.gen] in the pipeline of my poly~ patcher, but I still have no such issue.
So it's not the combination of jit.gen and jit.matrix in poly~, nor the number of voices or the matrix size that causes that issue, but something more specific to your patch.
Actually I just tried with an extremely simple patch and still have the same issue with just blank jit.gens In your test did you try sending in a float32 jit.matrix because that's what I am doing. Here is it below, this causes my computer to hang on the first matrix sent through:
Actually the issue isnt even poly~ related, I get the same isssue with just this simple patch:
Okay, I can reproduce (even though I'm closer to something like 4-5 seconds of lag). The lag is proportionally bigger/smaller if I add/remove some [jit.gen].
I think it is because jit.gen patchers are compiled when they receive their first matrix.
Not sure if it is supposed to be that slow though, especially for almost empty jit.gen.
However, is it really that bad to get that lag when you start your project? Can't you loadbang a matrix to get that lag at opening, then get run your patch as wanted?
If it gives you too much trouble, maybe you should submit a ticket and see what C74 devs have to say.
In my main project it adds 8 seconds to load time after an already 4-5 seconds just to load the patch. As I a making a maxforlive device this is way too long to load in a device into a DAW, especially if it is something I could maybe work around! Thanks!
Ah yes, M4L with slow init can become quite irritating...
Given that the [jit.gen] compilation time seem to depend on the number of jit.gen more than their content, depending on how your patch is structured, maybe you can
aggregate several [jit.gen] in one?
Also, I tried to save the default [jit.gen] patch as "test.genjit" and then using [jit.gen @gen test] for every [jit.gen] in your example patch, hoping to reduce the init time by telling to Max "they are all sourced from the same patcher". But sadly it didn't changed anything.
So if this slow initialization time is really about compilation, there is definitely some improvement that can be done in the way that Max handles that. If you open a ticket for that, maybe include a link to this topic as well.
Thanks! Unfortunately I can’t combine them because they rely on the results of the previous patchers and there’s no way I can do them all in the same pass because of the nature of jit.gen. I may just remake this without jit.gen thought it’ll be tough! I was debating making a support ticket if it technically isn’t a bug but maybe I still will when I have time
Even if it's not a bug, there is most likely some room for improvement.
Actually let me open the ticket as I feel like almost everything is written already.
Oh that’s really kind of you I would’ve done it myself eventually! Appreciate it! If you don’t end up submitting it lemme know and I can
I got a reply: the delay is indeed due to compilation time, it's confirmed that it can quickly become quite slow, and they are investigating for possible improvement!
Amazing thanks :) also I’ll probably still try something else for this device but that’s good to know for the future!