Copy/paste between instances

Hi there

Having [this](http://forum.renoise.com/index.php?/topic/20523-fixed-b4-copypaste-from-one-renoise-to-another-renoise/page p 156266 hl copy fromsearch 1#entry156266) problem again. Only this time it’s also happening when I’m copying Track DSPs and instuments. It usually takes 2-3 tries before anything happens.

I’m on 2.8.1, windows 7 sp1.

Any suggestions?

Happens here all the time.

Now I can reproduce.

  1. Open 2 instances of renoise
  2. Load “Acoustic-Flute.xrni” and “Acoustic-Guitar.xrni” from renoise’s own instrument folder in the first instance.
  3. Copy the Acoustic-Flute from first instance. Wait 2 seconds.
  4. Paste the Acoustic-Flute into second instance.
  5. Copy Acoustic-Guitar from first instance and VERY QUICKLY change focus to second instance.
  6. Paste in second instance

Result: It’s still the Acoustic-Flute which is pasted.

  1. Now change focus back to first instance. Do nothing - just wait a few seconds.
  2. Go back to second instance.
  3. Paste again.

Result: Now the Acoustic-Guitar is pasted.

So it seems renoise stops processing the copy operation as soon as the program loses focus, then picking up on it when it regains focus. Not ideal for copying between instances.
When working with large songs/instruments I sometimes have to wait over 10 seconds before I can paste an instrument into the other instance.

See video illustrating the problem. Notice the quick change from first to second instance right after performing copying of Acoustic-Guitar.

Can anybody else reproduce?

Copying and pasting sample based instruments or VST instruments that are sample based requires time. You are copying sample data to the clipboard that can be bigger in size than high quality mirror-reflex camera images.
Also when you copy VST instrument data, they contain data chunks that may hold a large part of the sample library that the instrument may be based on.
I doubt that the speed can be improved as it is the system that has to handle the data storage and transmissions between the clipboard and the program and not Renoise.

Smaller xml snippets like envelope data from automation or instrument envelopes shouldn’t be much of a big deal, but copying and pasting large blocks of data i’m afraid simply requires a little more patience.

Thanks for the thoughtful reply, vV

Time and patience is not the issue for me. I fully understand copying takes time and I’m not requesting a speed-up.

But the current behaviour simply feels buggy - from an end-user perspective. The behaviour in the video I just posted is obviously odd. Letting the succes of a copy operation depend on for how long a renoise window is in focus seems odd. And it’s quite an impediment for me when working with renoise. Why?

You have no way of knowing when a copy operation is complete and when you can change to the other instance and paste the file.
So: you go to instance 2, paste, it doesn’t work (it typically inserts a previously copied instrument), you undo the pasting of the instrument you don’t want, return to instance 1, wait some time, go to instance 2, try pasting again, maybe it works, maybe it doesn’t …

Another thing: it sometimes, though rarely happens I get a “Failed to open the file for reading” dialog because of this.

A few suggestions which will improve the current situation a lot:

  1. Don’t let Renoise paste (in instance 2) a previously copied instrument when an unfinished copy operation (in instance 1) is going on or is paused. You would never want to paste an previously copied instrument. You always want the instrument you copied most recently to be pasted. If not that, then nothing.
  2. Don’t pause the copy operation when bringing an instance out of focus. Alternatively: let instance #2 resume the copy operation when/before pasting.

The ideal solution
Make instance #2 wait until the copy operation in instance #1 is complete - then paste. Maybe show a progress bar/tell the user he has to wait. That’s how things normally works.


The not ideal but pretty good solution

I know the suggestion above requires a bit of shared intelligence. If it’s too much trouble to implement that, maybe you could just let the status-bar show the progress of a “copying to clipboard” operation (like it’s doing when loading instruments). That way you would know when you can move over to instance #2 and succesfully paste.

What do you say?

This makes sense.

However I’m seeing the exact same thing happening when I’m copying native track DSPs. If I understand you correctly, these don’t take up much data? The copy/paste problems I’m having are similar to the bug I linked to in my original post.

Understandable, but applications unfortunately don’t get all the means necessary to improve this part. Copy data between applications can be done through the system clipboard but an application developer depend on the means and options that the system kernel api library supplies to an application developer.
For the system clipboard you have a load of API options to communicate with, but polling for current progress is unfortunately not one of them and getting a status-return isn’t incorporated either (not in Windows at least).
I’m not going to bother you with the specific details, but if you want to have an idea, here is the info at least for Windows:
http://msdn.microsof…clipboard.aspx
I don’t expect other platforms to work much differently.
The main thing is:you can set or get data, and whenever you have given the order to the Kernel to proceed, you are at its mercy and hope it will manage to store the content or send you some content.
The behavior may not be logical, but also not really something that can be influenced or monitored.

Thanks for the detailed explanation. I understand there’s not much to do here. But maybe one thing…

When bringing a renoise instance out of focus, the copy-to-clipboard operation is paused. Would it be possible to make renoise continue/complete the copy, even though it’s out of focus?

If yes, that would imho be a considerable improvement.

I don’t know what the system does with clipboard datatransfers when an application is brought back in the background.
It might perhaps completely pause a data transfer to the clipboard.

Could you always blank the clipboard (copy null data into it) before starting the new copy action? At least then with large copy requests like this, rather than pasting the old instrument (or whatever you have copied) would would paste nothing, making it obvious the copy hasn’t yet completely and thus not so easily slip through the net.

Yes! Would also be a big improvement, if possible.

Haven’t experienced this problem before, but blanking the clipboard before copying anything potentially “big” (like a sample or instrument) seems to me simply like a clean programming habit. Just my $0.02