Know when a process is finished
Jun 07 2019 | 4:36 am
This is probably a simple question but how do I know when Max/Jitter has finished processing a task, say writing an image to disk using exportmovie, or when its done with a very complicated and slow processing of an image. I want to sequence the processing and saving of a large group of big images and want a mechanism to know when to start the next image. Is it "safe" to just stack them up and let Max sort it out? If I use a trigger object where the first trigger initiates the sequence is it "safe" to assume the next bang to the left of it does not get triggered until, say, the 3 seconds it takes my massive image to save to disk is done? I do notice that the feedback from the button press I use to trigger the save doesn't flash until the save is done but I cant imagine that Max doesn't hand off the save process to some async thread and move on with its tasks. Any advice on strategies to do this would be greatly appreciated. My current strategy of using delays and guessing the time is really lame. :)
- Jun 07 2019 | 8:36 amI don't know what exactly You are using to process and store, but if it were a single object, sending comma separated commands usually works. Like telling buffer to :replace, normalise 0.99, writeaiff jit.matrix sends messages after export is done, so You can use that. With objects that don't report such things one can ask object to dump some info. example : send message to vst~object to load a plugin and ask it if it is a synth vst object will report if plug is a synth only after it loaded it. plug "/My Stuff/Audio-Plgs/ABC.vst", get -7
- Jun 07 2019 | 4:06 pmjit.matrix image writes are synchronous (and therefore will block the main thread) so there should not be any need for delay objects.
- Jun 09 2019 | 6:49 amThanks SA and Rob. I guess it makes sense that the jit.matrix image write are synchronous and that is why I see the UI flash at the *very end* of the write. As I said I am processing a big group of massive images and doing this over and over again. I will stop asking questions and make some tests but I still cant wrap my head around stacking 20 or so process-and save-to-disk chains "simultaneously" and hoping Max can internally sequence them without choking. To be more clear about what I am trying to do, here is a more concrete example: 1. I open a 8000x8000 pixel image 2. I rotate it 15 degrees w jit.rota (processing this takes a good 2-3 seconds on my PC) 3. I save the new image to disk as a .png (processing this takes a good 10 seconds on my PC) 4. I repeat this 20 timesSo if I trigger the above chain with an "uzi 20", counting on uzi to deliver the next initiating bang as quickly as possible after the last chain is completely finished processing, I should be able to start the Uzi, come back in 10 minutes and find my 20 images and an un-crashed PC waiting for me. Lets see (cant actually try until I get home from weekend)!In my mind I wanted Max to "tell me" when the image write was done so I could use that message to trigger the next rotate/write. BTW I am making a "tool" that I use over and over so I am trying to get it right. :)
- Jun 09 2019 | 7:50 amI would not use uzi for that. Best practise is report done from the last object which saves file to disk, to trigger next process , using for example counter. If that is not possible, and If You want to use something like uzi, I would rather try qmetro / counter combo.I allways use that for example when preloading many audio files into sfplay and similar.
