[LOGGED] Update and Save GLSL.txt within Isadora

Maxime

Thanks for the suggestion @Woland

Actually i just tried and it's not working, it's always reloading the code from the txt file on start up, and what i meant is actually saving the txt file located in the glsl folder.

There's nothing really vital as there's some work around, but when you're editing the code, you always need to remember to copy everything from isadora editor, then open the text file and save it (I obviously forgot several times before posting this feature request :D )

mark

@maxime said:

Actually i just tried and it's not working, it's always reloading the code from the txt file on start up, and what i meant is actually saving the txt file located in the glsl folder.

I guess you simply found a flaw in my thinking. I didn't expect people to edit those shaders in Isadora. Instead, I figured that users would "global" GLSL actors externally. But, obviosuly, the fact that you can is obviously an issue. We'll have to present an option to the users I think: when you edit the individual shader, do you mean to update all copies (write out to the global file) or just change the local copy (i.e., disconnect it from the global file.)

Do you have thoughts on this @Maxime ?

In any case, it needs to be fixed and I'm sorry for the annoyance. @Woland please make sure we have a ticket/bug report on this. Thanks.

-- Mark

Maxime

@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.

bonemap

@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

Woland

@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?

Maxime

@Woland then you could even push it further with an actor bin for user actors within the patch (but other story here sorry... :) )

bonemap

@woland

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

Woland

@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 ?

DusX

@bonemap

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.

bonemap

@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

Woland

@bonemap said:

I will be quiet now!

Please don't do that! You always have such wonderful ideas, suggestions, and questions.

DusX

@bonemap

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.