F Script allows you to modify actual runtime objects. In the javascript patch, you're only able to access the stuff that's piped into the patch, because the script is executed in "javascript space" that only knows about its inputs.
F Script is executed in Quartz Composer's actual memory space, meaning Anything can get any method invoked. This would allow changes to the patcher interface itself, any patches, and any other objects Quartz uses while running.
That said, F Script doesn't appear to be quite turing-complete, so I'm not sure how useful such a patch would be. Still investigating that though.
anything that stops the performance hit and sandboxed issues of the javascript patch would be "a good thing" in my books. i'm not interested in rendering in "safe" environments, i'm interested in maximum performance (and if i'm going to be using cocoa/obj-c as my main language, then not having to drop back into javascript).
F-Script is an interpreted language, just as javascript is. The only advantage here is the raw Objective-C messages it generates, which will execute native code.
I don't think the F-Script patch would be a wise replacement for the javascript patch.
I have no skill with F-Script but the idea that with any code (F-Script or other) patch and connections can change on the fly (as cwright said)
is enormous !
With this idea, custom nodal GUI can be developped inside QC and compositions becomes dynamics. It is opening the door for the design of really cool new tools....
What's the advantage of using Fscript vs JAvascript ? I understood that it allows matrix based operations....
F Script allows you to modify actual runtime objects. In the javascript patch, you're only able to access the stuff that's piped into the patch, because the script is executed in "javascript space" that only knows about its inputs.
F Script is executed in Quartz Composer's actual memory space, meaning Anything can get any method invoked. This would allow changes to the patcher interface itself, any patches, and any other objects Quartz uses while running.
That said, F Script doesn't appear to be quite turing-complete, so I'm not sure how useful such a patch would be. Still investigating that though.
anything that stops the performance hit and sandboxed issues of the javascript patch would be "a good thing" in my books. i'm not interested in rendering in "safe" environments, i'm interested in maximum performance (and if i'm going to be using cocoa/obj-c as my main language, then not having to drop back into javascript).
F-Script is an interpreted language, just as javascript is. The only advantage here is the raw Objective-C messages it generates, which will execute native code.
I don't think the F-Script patch would be a wise replacement for the javascript patch.
I have no skill with F-Script but the idea that with any code (F-Script or other) patch and connections can change on the fly (as cwright said) is enormous ! With this idea, custom nodal GUI can be developped inside QC and compositions becomes dynamics. It is opening the door for the design of really cool new tools....
yanomano.