Jump to content

Julian Martinz

  • Content Count

  • Joined

  • Last visited

  • Days Won


Julian Martinz last won the day on February 8 2020

Julian Martinz had the most liked content!

About Julian Martinz

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You have to reset session at the beginning of your callback() with Session.reset() and it should work as expected
  2. @John maybe I don’t get the problem but can’t you just get the project via the entity you’re dealing with? Or are you just looking for a more convenient way? Best, Julian
  3. Hey Alican, I didn't read through the entire thread but I think all you wanna do is adding a reviewable version to an assetversion. If that's correct you just can use the encode_media helper method from the asset_version itself and call it a day. With that method the media will be uploaded and encoded. ... asset_version = session.create('AssetVersion', {'asset': asset}) asset_version.encode_media(local_path_to_media) Best, Julian
  4. Your PYTHONPATH has to be set accordingly. Which OS? And how do you start maya? If you start Maya from the same terminal-session from where you can import the api in an interactive python session, you should be able to import the api inside Maya as well. Edit: Obviously the PYTHONPATH has to be set in the bash-session (or whatever shell you use)
  5. hey @Lorenzo Angeli Okay think I got it. I thought of the proxy location as a mere "switch" that forwards the add_component method to one of the two locations and then the component is addaed to the actual location (server1.managed/server1.unmanaged). But what you are proposing is to actually add the component to the proxy-location and just leveraging the methods from the other (configured) locations. Did I get it? Best Julian
  6. Hey Lorenzo, That's absolutely fine .. but how can I create these two locations with the same name but different behaviour? When trying to create to locations with the same name the session will logically throw an error. Or are you talking about two entirely different location? To stick to my example: studio.server1.managed and studio.server1.unmanaged? If so that's actually not what I am after. The point is that I only want to differentiate on publish/component-creation. Once the components are published, you shouldn't be able to distinguish between components added via the unmanag
  7. Hey @Lorenzo Angeli, looking forward to your example. In the meantime I tried it myself and got a working version up n running. Unfortunately it doesn't really help me with the original problem. I can configure my proxy location to choose between distinct locations with different names like studio.server1 and studio.server2 (which is great btw and helps me solve some other issues I had). However, to choose between a managed and unmanaged version of the same location I'd have to create both instances beforehand, which afaik is not possible as they are essentially the same? Or at least I
  8. Hey Lorenzo, thanks for the reply. I think @JPrydz mentioned that concept before. You don't happen to have a code example ready? Or at least a draft or a hint? After a short glance at the location class I'd start by overriding/extending the add_component method and implement the logic there. Does that sound sensible? Best, Julian
  9. Is there an option to revert a location to default after setting it up to be unmanaged with the ftrack_api.mixin() method? I have to publish components to the same location during a session. Some of them are already where they belong so I want to add them through the unmanaged location. For others (especially those created by the official plugins // publishers) I'd like to rely on the default behaviour. - Julian
  10. Hey Lorenzo, Thats basically what I was planning to do (except for the threading part in the action .. but guess that's the only viable way). Thanks for the reply. - Julian
  11. I am about to shift some specific actions from running locally on user-workstations to one or two central worker-clients. Some of these actions will run a little bit longer and won't be discoverable during processing. To keep it simple, maintainable and scalable I'd like to avoid setting up threading/multiprocessing mechanisms inside the action and do that on a higher level instead. Is there a canonical way to pull this off? If I understand it correctly the event.stop() method will only work if I register the listeners from one single process. So multiple-docker containers or multiple hosts wo
  12. Ah ok .. guess that’s by design. you could setup an event handler that is listening to status changes and sets a ‘latest_approved’ flag on the most recent approved version. Then you could use that attribute in your queries. Quite involved for what you want but it should work. Would be welcome if something like that could be accomplished with the filter queries instead.
  13. I may be wrong but can’t you combine the query filter with the built-in latest version filter and are done?
  14. Digging around I found the answer to my question by myself. For reference it is possible to modify the labels on review-session-objets. More information can be found here http://ftrack-python-api.rtd.ftrack.com/en/1.7.0/example/review_session.html?highlight=reviewsession and in the action here https://bitbucket.org/ftrack/ftrack-recipes/src/master/python/actions/annotate_review_clips/
  15. Hey Johan, Actually, this is exactly what I (and Tim, if I understood him correctly, too) want to do. The question is where to find the default one. Best, Julian
  • Create New...