Event notifications for remove editing files?

Hello, 
 
I'm currently migrating over from Mac to Windows but looking for an FTP client that can handle the same or similar functionality to Transmit. I have spent some time with the demo version of your software and I have been able to figure out the majority of the functionality I need besides one thing.
 
I'm unable to find out how I can turn on notifications / sounds / alerts for successful file transfers when editing remote files on the server. I'm using an external editor and saving which uploads on the fly however the only event notification available triggers when all files have completed in the queue, however as the remote file remains in the queue there is no trigger for the sound / notification but the file does successfully upload.
 
Please could you help me out with this? I would be purchasing the ultimate version if I could iron out these issues in my workflow.
 
R

Typo in the title " remote* "

Looking further into it, the queue seems to clear after 30 seconds (which seems to be tied to the retry delay) which triggers the event notification sound. I opened up the connection properties and found the retry delay and set it to 1 second however there is still a 10 second delay until the retry and queue clear.
 
Can anyone help me out and let me know if I'm missing something?

I think the problem is related to the file monitor. Under some circumstances (depending on how the editor saves the file) the system sends two change notifications which trigger two file uploads. If the number of workers in the queue is >= 2 then the same file is uploaded at the same time and one transfer will most likely fail. Workaround: reduce the number of workers in the queue to 1.
Another cause could be that the first attempt to upload the file fails due to a file sharing violation (SmartFTP tries to open the file but the editor did not finish saving the file). The transfer will then be retried after x seconds. Once it succeeds the queue complete event will be triggered.

Thanks for coming back to me so quickly, 
 
It was successfully uploading the file off the bat, I could see the changes almost immediately after saving with a quick refresh. It was the retry that stayed in the queue for another 10 seconds after this.
 
I'll have another go later today with a different external editor ... notepad.
 
If that doesn't work, I'll then try reducing the workers to 1... but this would get a good bit annoying if I had to change this about every time I had to upload a folder with a lot of files.
 
Isn't this something that you have come across before? 

The mentioned causes were merely guesses based on your description. What we have changed for the next build (no ETA) is that the transfers will be serialized. This will eliminate the problem of multiple concurrent uploads of the same file.