mrRay
Interfacing with the ISF UI
Amazing work on this, and I can't wait to implement into my workflow.
My only concern is how to build interfaces that communicate with ISF-UI. Specifically, I need to know when the UI has finished building, and how to interact with the UI from other points in Max. For example, I would like to remotely control a slider in the UI using something like the [midiin] object, and I would like it to not begin communication until after the UI has been built.
I suppose I could follow the getparamlist done message to determine when the UI is done building, but it's not clear if that will dump out before or after the UI is generated. Likely it occurs beforehand, so it would be good to know when the UI has completed it's build process.
Then there's the question of direct communication w/ the UI. I really need a way to communicate with those generated UI objects from other parts of my max patch if needed. Opening up the bpatcher I see the generated objects, but no method by which to send them messages from outside the bpatcher. This would be a monumental function to implement for myself and for many others who want to use the platform!
Edit It would also be nice to display the credit for the shader file in the UI
"My only concern is how to build interfaces that communicate with ISF-UI"
jit.gl.isf doesn't generate any UI items. all of the UI items you see in the "play!" tab of the help patch were generated by max patches/javascripts.
"Opening up the bpatcher I see the generated objects"
the bpatcher is "ISF_UI_stack.maxpat", and it doesn't contain any UI items whatsoever- just an inlet, outlet, and a javascript that coordinates UI item creation in response to messages received from the jit.gl.isf object.
if you double-click on a bpatcher in a max patch, you're not "opening the bpatcher"- you're just examining an instance of the bpatcher that max has loaded and begun executing (read-only- that's why you can't unlock or modify it in the resulting window). actually opening up a bpatcher means inspecting the bpatcher, determining which max patch its contents were loaded from (in this case, "ISF_UI_stack.maxpat"), and then opening that file up in max so you can edit it. the difference is subtle, but very important if you're trying to pick apart an existing max patch to determine how it works!
i suspect this one answer will probably clear up all your other questions, but just in case i'll forge ahead...
"Specifically, I need to know when the UI has finished building"
- jit.gl.isf outputs a "getparamlist done" message when it has finished describing the ISF file's parameters.
- the UI items are all generated by max, so you know exactly when the UI has finished building- it follows all the standard max rules for message dispatch.
"Then there's the question of direct communication w/ the UI. I really need a way to communicate with those generated UI objects from other parts of my max patch if needed."
- if you want to interact with the automatically-generated UI items from elsewhere in max, you need to modify the javascript/s that generate them so you can add the appropriate hooks (invisible 'receive' objects, giving the objects custom names based on patcherargs, etc- i don't know what you're trying to do, these are just a couple techniques off the top of my head that could be used to pass msgs to the UI items).
"It would also be nice to display the credit for the shader file in the UI"
thanks, we'll most likely add this!
Thank you for your replies. I've already begun modifying the JS scripts to improve the UI interface for my needs. I'll share my modifications when I'm done, in case you'd like to implement any of it into the official build.