Hey Nathan,
Just double checked that and yes, I'm passing the same callable:
nuke.addAutoSaveFilter(foo.bar)
nuke.removeAutoSaveFilter(foo.bar)
# Result:
Traceback (most recent call last):
File "<string>", line 5, in <module>
File "/apps/Linux64/nuke/nuke7.0v5/plugins/nuke/callbacks.py", line 388, in
removeAutoSaveFilter
_removeCallback(autoSaveFilters, call, (), {}, 'Root')
NameError: global name 'call' is not defined
So, had a peek in callbacks.py and it seems there's a bug on 388: call arg
to the _removeCallback func should be replaced with filter.
Will report this.
-E
On Fri, Apr 19, 2013 at 6:54 PM, Nathan Rusch <nathan_ru...@hotmail.com>wrote:
> Make sure you’re passing the same callable to removeAutoSaveFilter
> that’s being passed to addAutoSaveFilter.
>
> -Nathan
>
>
> *From:* Ean Carr <eanc...@gmail.com>
> *Sent:* Friday, April 19, 2013 3:21 AM
> *To:* Nuke Python discussion <nuke-python@support.thefoundry.co.uk> ; Deke
> Kincaid <dekekinc...@gmail.com>
> *Subject:* [Nuke-python] Re: [Nuke-users] delay on autosave
>
> Hey Deke,
>
> (moving this to the python discussion...)
>
> Regarding your point 2: someone at our facility has implemented a rolling
> autosave to an alternate directory so we no longer get that feature I quite
> like that you mentioned: when Nuke sees a newer autosave in the same dir,
> it asks the user if they want to open it instead. I really, really miss
> that.
>
> So, I did a bit of digging and it looks like someone added an autosave
> filter using nuke.addAutoSaveFilter(<callable>). In doing so it appears the
> autosave features in the Nuke prefs are completely disabled. The knob
> "AutoSaveName" has the expression:
>
> [firstof [value root.name] [getenv NUKE_TEMP_DIR]/].autosave
>
> but nothing goes there.
>
> So, I tried adding a second filter which restores the functionality I
> like. However, through my testing it looks like Nuke only honours *one* of
> the strings returned by autosave filter functions in the
> nuke.autoSaveFilters dict (the index 0 in the Root list?) I've added a
> second test function to it which prints 'foo' *AND* returns the root name +
> '.autosave'. I see 'foo' prints, so the code is being executed, but no
> autosave is made at the location given by the second function's returned
> filename.
>
> Also, nuke.removeAutoSaveFilter appears not to work. Has anyone else had
> success with it?
>
> Maybe it's time for a bug report.
>
> -Ean
>
>
> On Fri, Apr 19, 2013 at 8:44 AM, Deke Kincaid <d...@thefoundry.co.uk>wrote:
>
>> The autosave function in Nuke runs on the main application thread. I’m
>> not sure exactly why but when the Nuke files get in the 20 meg range the
>> Windows version has always had a considerable lag over the network doing
>> autosaves then linux or osx.
>>
>> A few ways to combat this:
>> 1. set your autosave to not be as often(every 360+ sec instead of every
>> 30).
>>
>> 2. Explicitly set the expression for your autosave to a folder on your
>> local machine instead of the network. By default it always saves to the
>> same location of the nuke file. The really annoying thing with this
>> solution is when your Nuke crashes and you open a file it won’t say “you
>> have a newer autosave, do you want to open it” because it is not being
>> saved in the same location as the original file anymore. So you have to
>> manually open the autosave. So not a great solution but it definately gets
>> rid of that lag every 30 seconds with large scripts.
>>
>> 3. If you have a cameraTracker, pointCloudGenerator, PoissonMesh, or even
>> large sets of roto or any other nodes which makes really big Nuke files.
>> Take it and make those nodes into a nuke precomp (other > Precomp). Then
>> the large part of your script will be a separate referenced nuke script and
>> not making your file size blow up. The referenced precomp will not be
>> constantly autosaving. If you have a heavy piece of geo from the
>> PointCloudGenerator then write it out as an Alembic file and read it back
>> in.
>>
>> -----
>> Deke Kincaid
>> Creative Specialist
>> The Foundry
>> Mobile: (310) 883 4313
>> Tel: (310) 399 4555 - Fax: (310) 450 4516
>>
>> The Foundry Visionmongers Ltd.
>> Registered in England and Wales No: 4642027
>>
>>
>> On Wed, Apr 17, 2013 at 5:00 AM, Fabian Fischer
>> <i...@visualplastic.net>wrote:
>>
>>> Hello,
>>>
>>> we got a problem with the nuke autosave function. The UI gets
>>> unresponsive on every autosave attempt for about 10 up to 30 seconds. It is
>>> a larger script with 18 MB, but I think that should not be a problem
>>> anyway. It doesn't matter which storage device is used (We tryed everything
>>> from SAN, NAS to local SSD) it is always the same.
>>> It is Nuke 7.0v6 on Windows 7 64 bit.
>>>
>>> Any advice would be great,
>>> thank you,
>>>
>>> Fabian Fischer
>>>
>>> ______________________________**_________________
>>> Nuke-users mailing list
>>> Nuke-users@support.thefoundry.**co.uk<nuke-us...@support.thefoundry.co.uk>,
>>> http://forums.thefoundry.co.**uk/ <http://forums.thefoundry.co.uk/>
>>> http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-users<http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users>
>>>
>>
>>
>> _______________________________________________
>> Nuke-users mailing list
>> nuke-us...@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>
>
>
> ------------------------------
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
>
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
>
_______________________________________________
Nuke-python mailing list
Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
