Recursively searching for named object
I am trying to come up with a js function that will recursively search a patch for a named object…
What I am finding is that I am not able to look inside subpatchers. It looks like when I call firstobject of a patcher object it does not return anything. I have reviewed my code, but I don’t see any obvious problem.
Does firstobject work differently than I am using it? Am I missing something?
I haven’t looked closely at your JS code, and I’m sure you have a good reason for doing this via the JS/Max API.
Try this one. I still don’t find your object, but it’s iterating properly now. I made a couple of comments in the code.
[attachment removed due to error, see below]
Also, searching the JSON structure directly is not exactly future-proof. We might change the patcher document format again, or start saving patchers in "Copy Compressed" format, or introduce a binary format. Or maybe it’s a M4L device and there’s no valid JSON document available, or, or, or… Anyway, the JS I posted should be appropriate for all anticipated version of Max in which patchers and objects are still part of the landscape.
By the way, the problem my semi-solution JS above is a missing () after the word subpatcher on line 49. The attached version works properly.
Jeremy thanks for your help, it works like a charm. I have been using the following link as documentation
I can not find any documentation for subpatcher(). Am I missing something?
This is much easier to do with the applydeep function:
----------begin_max5_patcher---------- 787.3ocsVtziaBCD.9L7q.4yYivNuH8V+GTo1aqVEY.GhSIFjsIaZWs+2qeD 7ZHP1j1zK4wLi8L9yyLddKL.jVchH.QeI54nff2BCBLhzBBN++.vA7orRrvX F3.QHvEDvDqNI4jzHeKkkGIIB4rVUUMxRhT9qZhc+AfnWNqpFKy1QYEa3jLo U65kSWLIBlrZZ7jnEq0eBSlF6VBM23lpz8Okz5gsULICevr+fuxo3xVMrlCT lx6lXF4Ytf9ai4PjxCNasgpwXnV36gg5OlbiLgQdUEWWfj8hHk3enXBZ5dwe IVVowBBtTCjUFrfhGFKn6DKv6BKmkJvGI4aTtSEgavRIml1HsYPAN5n1SZIw EBWBA8QkqTKI7MJ6RKMFFazYX+C5FnN56MoeSSUBG7oP1l0kL6ZPd9cB436A xw9gnJhG.pGIbAsh4ckD.v00dhC7VhlR6qLazxINQTlUTrSDmbj1t9DqPE6C aU1xIHJIVCm0FPsbt4OyS7Pk5dpnrJ6mjbeG.ppILJqlSDDlDKO6Im5bxVbS obyvPpq9s3LxnKdvKj.PAmlWwzAQmUpE25N0gagomyB+CiwBFtdfEKTmiFQJ lqI24DXTqRYUUYWUtKKUdLlQOfkDI0FrnX2lROTyoLYGGYqO1Ix3Ukkc1Jql iCnIWcelQdklK2Y1KeTpLmV2dE.bLJmVnpQ6JShKDckz44B+DM+BzNxuVgpQ 8QL2cs4+9QudoT4TEz3zSQyPwQn4w9lcQOUk4arlCl30gcrF.vDS+U3pDyWw n9s.FqW60aELZO2qzRXf1BnVE1Vile7QNZIk0dkD8Rneo6s1r9es75yKeuib tAChq37wbppMTJt7bmT2ZGH09Q8nS+7XzkyCLVN7Mm+NXtKDZlbBAGI20Ouc 1+yYDPObFBGjgEkS4DVNgG8Jk8Tl7znXLEyJtU.lX4GxxO3v7a8ifeytA9Yb tescKNMG.s7tPUT0vyZO1mGRN5iifpDTRYtWde10Eyylcz77NOxopOE5WXxc Cm0I35M1gNP5MtQuQM5OlgZ2dO7O3Rs5TC -----------end_max5_patcher-----------
autowatch = 1;
var scripting_name = null;
if (obj.varname == scripting_name)
scripting_name = _scripting_name;
@Anthony, Jeremy, yes of course you should do this in the officially supported way, if that exists (which it does apparently).
@Jeremy, binary format sounds nice! If for nothing else, would be great to export as standalone using BSON or similar for smaller package size, etc. I know you were just making a point of future-proofing your patches, but anyways…
@Nat thanks for pointing this out. It is indeed easier and works!
No problem, nevermind my reply then (it was a reply to the message you deleted)