copy & paste a panel setting

[HughBanton]

I'm still occasionally messing with my everlasting additive pipe-organ project. Maybe I've nearly finished, maybe not - there's no discernable way of knowing with Flowstone

Anyway, something on my wish-list that I can't figure. I wondered if anyone's ever done anything similar. My (everlasting) project is littered with harmonic setup graphs as per the attached. (Thanks, of course, to whoever originally came up with the 'Voicing Graph Process' inside).

What I would just LURVE to be able to do is copy the data from one and paste it into the other.

Ideally ... right-click on the top one - a 'copy/paste menu' appears - click on 'copy', right-click on the bottom one, click on 'paste', and hey-presto the array from the top one is copied into the bottom one.

Anyone ever achieved anything like this? I've searched the forum and can only find tentative references.

Or maybe someone can tell me it can't be done

H

[KG_is_back]

something like this?

[RJHollins]

KG ... is something suppose to be displayed in the 2 boxes ?

[KG_is_back]

KG ... is something suppose to be displayed in the 2 boxes ?

no. It's just a module with empty gui that responds to right-click
In fact, in real world scenario you would want to remove the GUI component from the module and attack the ruby view input to the gui component of the parent module.

Here's the modified version HughBanton's schematic

[RJHollins]

ahhh .... RT-KlicK.

Both schematics work ... something for me to study.

Thanks KG

[tulamide]

You shouldn't use it. The module declares a class variable for the RubyEdit, which due to the implementation of Ruby in Flowstone is then a global that is accessible in every instance (running in the DAW) of your instrument. That causes problems. For example, the second instrument will erase all copied data from the first one on startup. also, it is only one global copy paste, you couldn't copy from instrument a.1 and b.1 to then paste into a.2 and b.2, etc.

You can make good use of it, if you know what is happening behind the scenes, but it is not the usual copy/paste mechanism.

[KG_is_back]

The module declares a class variable for the RubyEdit, which due to the implementation of Ruby in Flowstone is then a global that is accessible in every instance (running in the DAW) of your instrument. That causes problems. For example, the second instrument will erase all copied data from the first one on startup.

the problem you mention can be fixed by changing the init code to:

Code: Select all

def init
@@clipboard||=Hash.new
end



That keeps the old value of @@clipboard variable if it was previously defined.

It is true that this not a traditional way to handle clipboard copy/paste functionality, but in context of the plugin it works and makes perfect sense. It will work for copying data within the same plugin and it will also work for copying data between different instances of the same plugin. It will fail to work if all plugins are closed and reopened (which resets the clipboard).
I deliberately made the @@clipboard variable a Hash. That way different types of data can have different hash keys, which makes them not interfere with one another (similar to how copying text into windows clipboard does not erase bitmap data in the clipboard and vice versa).

I do admit it is a "cheaty" way to implement clipboard. I do vaguely remember a long time ago someone posted a correct version that accesses windows clipboard via some sort of function call. Maybe we can modify that if we dig it up...

[tulamide]

the problem you mention can be fixed by changing the init code to:

Code: Select all

def init
@@clipboard||=Hash.new
end


That keeps the old value of @@clipboard variable if it was previously defined.

Yes, the "nil or" trick will solve that issue.

It is true that this not a traditional way to handle clipboard copy/paste functionality, but in context of the plugin it works and makes perfect sense. It will work for copying data within the same plugin and it will also work for copying data between different instances of the same plugin. It will fail to work if all plugins are closed and reopened (which resets the clipboard)..

That's not quite true. The code doesn't differentiate between instances.
Imagine two instances with two elements each. The user wants to copy-paste from element 1 of instance 1 to element 2 of instance 1, and the same for instance 2.
From instance 1, element 1, he selects copy. The data is stored.
Now he switches to the second instance and from element 1 again selects copy. The data from the copy process of instance 1 is now overwritten with the data of instance two. If he now switches back to instance 1 and selects paste on element 2, he expects the data from element 1. Instead he gets the data from instance 2.
This would work with a standard clipboard (one clipboard is connected to one window).

I deliberately made the @@clipboard variable a Hash. That way different types of data can have different hash keys, which makes them not interfere with one another (similar to how copying text into windows clipboard does not erase bitmap data in the clipboard and vice versa).

Yes, I noticed it! It is a good decision, but that was not my point. See above.

I do admit it is a "cheaty" way to implement clipboard. I do vaguely remember a long time ago someone posted a correct version that accesses windows clipboard via some sort of function call. Maybe we can modify that if we dig it up...

I was looking for the clipboard functions on MSDN. I would be very happy to see the code you mentioned, because the functions I found start with "OpenClipboard", which requires a window handle for the active process

[KG_is_back]

http://dsprobotics.com/support/viewtopic.php?f=3&t=2954&hilit=clipboard

Here... apparently, it pastes text form clipboard.

That's not quite true. The code doesn't differentiate between instances.
Imagine two instances with two elements each. The user wants to copy-paste from element 1 of instance 1 to element 2 of instance 1, and the same for instance 2.
From instance 1, element 1, he selects copy. The data is stored.
Now he switches to the second instance and from element 1 again selects copy. The data from the copy process of instance 1 is now overwritten with the data of instance two. If he now switches back to instance 1 and selects paste on element 2, he expects the data from element 1. Instead he gets the data from instance 2.
This would work with a standard clipboard (one clipboard is connected to one window).

Interesting... That is not how I'd imagined clipboard to work. I always thought the point was to have a way to transfer data even between windows...

[Spogg]

What I would just LURVE to be able to do is copy the data from one and paste it into the other.

Anyone ever achieved anything like this?
Or maybe someone can tell me it can't be done

H

This isn't exactly what you asked for but it might inspire you. It simply sends the array from the lower graph to the upper one.

Food for thought or useless?

Cheers

Spogg