Julian Martinz

Members
  • Content Count

    13
  • Joined

  • Last visited

  • Days Won

    1

Julian Martinz last won the day on October 10

Julian Martinz had the most liked content!

About Julian Martinz

  • Rank
    Member

Recent Profile Visitors

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

  1. 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
  2. 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
  3. 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
  4. 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 won't work because this would lead to multiple actions with the same name showing up for users. Is that correct? Anything else to watch out for?
  5. 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.
  6. I may be wrong but can’t you combine the query filter with the built-in latest version filter and are done?
  7. 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/
  8. 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
  9. Hey there any news on this one? Is it possible to customise the default dialogue or is the only solution to build a custom version from scratch and override the default one with the layouts?
  10. Is there any option do add comments/descriptions to versions in the client-review? Apparently the only information that are carried on to the review-session are the TaskName, parent object name and version index. It would be great if it is possible to forward comments / descriptions from the AssetVersion to the client-review. Or display the Asset Name as well. For example when I want to share 2 Versions of the same edit with different audio files or different endings the only ways to make clearly distinguishable for the reviewer is to either comment the versions myself right in the review, add slates or create separate parent objects or tasks for each version. And frankly, I don't find any of them appealing. Including the AssetName as information for the reviewer would be a step forward but an option to manually pick attributes/comments which will be forwarded would be even more useful. Maybe I am missing something and it is already possible? AFAIK there is also no option to work something out via the api?
  11. Hi there, you have to specify key, value pairs if you want to query custom attributes and metadata. The right syntax is s.query('AssetVersion where custom_attributes any (key=downstream and value=True)').first() Also notice that bools are written in upper case. So true won't work as value.
  12. Hey there. Please invite martinz.julian@gmail.com. thanks
  13. Hey there, I am in the process of evaluating ftrack and have some questions regarding publishing. Quite possible that I am missing anything as I am having some trouble understanding the basic principles in ftrack (coming from shotgun). I am gonna first outline what I think is the default render/publishing workflow. Gone through that in afx and nuke but I guess the workflow is similar in maya. Here the procedure in nuke: Open nuke via ftrack-connect (correct context). Nuke script is saved in an (more or less) arbitrary location. Do your work Render to another arbitrary location Attach a ftrackpublish node to the write node and publish (or is the intended way to use the publisher via the ftrack menu and the ftrackpublish-node is legacy?). During the publish the nuke-script as well as the rendered-sequence will be copied to the fileserver. - Script and image-sequence will be placed side by side into the following structure (given that the task was tied to a shot): project/sequence/shot/scriptname/version/ - The name of the script will be generic (nuke-script.nk or something like that) and thereby the version/shot/sequence will be not saved explicitly to the files but implicit in the ftrack database as well as the file structure. If theses assumptions are correct, here are some questions: is there any way to access/parse the ftrack-context in nuke? I'd rather like to use a custom write node which is automatically populated with the correct render-path (built from the task/shot/sequence etc.) on our fileserver. This is especially true for renderings running on the farm. I don't want the artists to manually navigate to the appropriate location and enter the correct filename as this is one task which should be handled by ftrack imo. the same applies to the script itself. I'd like to force the artist to save the script on our file-server (in the correct location and name) which is - as opposed to local files - backed regularly is the publish-action itself customizable? As the components (rendered sequence and script) already are in their appropriate locations on the fileserver there would be no need for any copying. Instead I'd like to only register the components and create the versions on the ftrack-server. Guess that this could be done with a custom publisher but I'd really like to let the built-in do the heavy lifting and just modify it I am quite sure that everything is possible. Just trying to figure out how much effort it takes. Best, Julian