[LOGGED] Update and Save GLSL.txt within Isadora
-
@mark I can understand the logic behind your thinking as well, the thing is Isadora is the best place to edit the Isadora controls at least :)
I guess the optimal configuration would be to have a "save as macro" where it would keep the changes locally inside the Isadora patch, and a "save .txt" which would edit the shader file and therefore every instances, past or future if this shader.
-
@mark said:
write out to the global file) or just change the local copy (i.e., disconnect it from the global file.)
Hi,
I am also dealing with this at present. The thing is that of course the shader code is going to be modified within a patch because Isadora hooks that make interactivity are a key strength of integration. It just is annoying to write a Usadora param that hooks into the shader and then have to save a discrete version of the shader code in the applications library for a particular instance within a one off patch. I now have a number of variations of a number of shaders to manage. My preference, if a change is being offered, is that the shader should have the ability to be saved locally to a particular patch.
This would allow a master or template library to sit in the shaders tab but instances saved with specific modifications for a particular patch saved locally to the patch file.
Best wishes
Bonemap
-
@bonemap said:
This would allow a master or template library to sit in the shaders tab but instances saved with specific modifications for a particular patch saved locally to the patch file.
Sounds like we could have an actor bin for Master/Global/Template GLSL Shader actors and an actor bin for Local GLSL Shader actors maybe?
-
@Woland then you could even push it further with an actor bin for user actors within the patch (but other story here sorry... :) )
-
I will be showing my ignorance here, but isn’t there a number of code baring Isadora actors that just save specific code within an instance of the actor? And why can’t the glsl actor just pass whatever code has been saved to a ‘disassociated’ instance within a specific patch? Doesn’t the JavaScript actor and the Serial Input actor pass a unique code saved in a patch?
Is there a reason that glsl code has to be treated differently from these other actors?
I do like the ability to build a shader actor library in Isadora, but for the sometimes small modifications to the code when integrating the shader into a patch, a simple ‘local’ edit and save would be much more efficient than the current management of user shader actors.
Best wishes
Bonemap
-
@bonemap said:
a number of code baring Isadora actors that just save specific code within an instance of the actor? And why can’t the glsl actor just pass whatever code has been saved to a ‘disassociated’ instance within a specific patch? Doesn’t the JavaScript actor and the Serial Input actor pass a unique code saved in a patch?
@mark ?
-
The glsl actor works much like the JS actor its true.
1 work around to the problem outlined here is to add the glsl scrip that is wanted from the tool bin as well as the GLSL actor (empty/default).
Open the script you want to use (the glsl actor from the tool bin that is based on a link txt file) copy the script code. Paste this code into the emoty/default GLSL actor and close it.
The code is then saved locally to that instance of the GLSL actor and you can work on the code locally without any link to the txt file.
-
@dusx said:
The code is then saved locally to that instance of the GLSL actor and you can work on the code locally without any link to the txt file.
Great tip, thank you I will be quiet now!
Best wishes
Bonemap
-
@bonemap said:
I will be quiet now!
Please don't do that! You always have such wonderful ideas, suggestions, and questions.
-
It's not ideal, but a reasonable work around.
The actor should probably have a different Icon (or other visual indicator) if linked to a Txt file as opposed to saving local.