foreground_mask.model uses cv.jit.ravg external

jamoma / JamomaMax

Implementation of Jamoma for Cycling'74 Max:

http://www.jamoma.org

41 stars 9 forks source link

foreground_mask.model uses cv.jit.ravg external #990

Closed theod closed 8 years ago

theod commented 8 years ago

is not problematic to keep such a dependency ? or maybe this means we should add cv.jit library to the Max dependencies ?

jln- commented 8 years ago

I think @reno- already made a ticket about this. I dont remember the conclusion of the discussion, though...

theod commented 8 years ago

you're right this external is mentioned here : https://github.com/jamoma/JamomaMax/issues/686

theod commented 8 years ago

but xray is part of JamomaMaxDependencies repository while cv.jit is not so I'm not sure of what is the policy about dependencies ... maybe @lossius and @tap have an opinion ? and what about pointing to the Package Manager is that case as cv.jit is available ?

tap commented 8 years ago

I agree that we should point to the package manager instead of including in dependencies.

It would also be nice if we could handle the error when it is missing. Can it be done by creating an abstraction using the error object that (when it sees an error about the xray or icst etc object) pops up a dialog telling you what to do?

theod commented 8 years ago

I can try to make a new j.dependency component to handle that.

theod commented 8 years ago

I can't find any external that pop up a simple warning. the [dialog] external have a text field which is not useful here. any idea ?

theod commented 8 years ago

I've found a solution...

theod commented 8 years ago

I tried but the main problem is that the error object cannot catch errors at loading time it self ! so if it works when patching but not the loading the model...

theod commented 8 years ago

dependency.zip

here is what I tried to do in case you have an idea how to open the warning window when loading j.dependency.maxhelp.

tap commented 8 years ago

The problem appears to be that the foo object is created before the j.dependency object.
This problem is then amplified by the use of loadmess which doesn't fire until even later.

There is a two part solution:

Eliminate the loadmess and give the error object an argument of 1. I can see that this not documented, so I'll fix the Max documentation for that. Giving an arg of 1 will turn on the error object immediately (sooner than if you use loadmess).
The j.dependency instance needs to be in the patcher with the foo object. Max loads the patcher in z-order, deepest first and then working upward to the top-level patcher. So by having the j.dependency in the top-level patcher it is loaded too late to catch the deeper-embedded foo.

That should work. It's great that you've tackled this problem!

theod commented 8 years ago

as you said the first part of the solution resolved the problem when j.dependency is at the same level and instantiated before foo.test. I've updated the maxhelp to explain this constraint. Is it ok to add it to the package ?

dependency.zip

tap commented 8 years ago

Yes, please!

best, Tim

On Wed, Dec 16, 2015 at 10:37 AM, theod notifications@github.com wrote:

as you said the first part of the solution resolved the problem when j.dependency is at the same level and instantiated before foo.test. I've updated the maxhelp to explain this constraint. Is it ok to add it to the package ?

dependency.zip https://github.com/jamoma/JamomaMax/files/64246/dependency.zip

— Reply to this email directly or view it on GitHub https://github.com/jamoma/JamomaMax/issues/990#issuecomment-165168387.