Developer/Programmer Questions (Copy/Paste Buffers)

[Rodney]

This is a bit of an odd question but I'ma gonna ask it anyways...

 

When a person using a program such as A:M performs a copy/paste I must assume that:

 

Data selected is stored in a copy/paste buffer

That data is not stored in the operating system's clipboard (i.e. the operating system's standard copy/paste buffer usually used for text and images).

 

I will further assume that if we could see the data we might only see the bits or the bytes or... perhaps the exact data that was selected at the time (numbers, text, etc).

I realize this can get complex when we step away from standard text and image data for those times when a spline is selected and copied... or a selection of Control Points.

Still, I cannot help but think this data useful if the formatting of that data were a known thing.

 

So a few general questions might be:

 

What would we see if we could see the data in the buffer?

What benefit (or problems) might arise if we could access that data (for pasting generally into places that may not be specifically designed for such)?

How can we access that copied data?

Why is it the usual practice for most/many programs to use a separate paste buffer rather than the OS clipboard/paste buffer (Note that I assume several things may be true here but am more interested in answers from those knowledgeable of such things)?

 

What will I do with this information?

At this point I'm not sure but I am trying to wrap my head around something of a space where diverse programs can talk to each other and share data that would otherwise not be available.

 

Thanks in advance for your time and for any information and insights you can share.

 

 

Added: I have seen a few programs that offer a choice of how to copy data. For instance, one might right click and select Copy to Clipboard or Copy to Memory, although the latter would very likely have a more appropriate name. Shortcut keys then could be assigned to those menu items if such was desired or needed.

[tysono_71]

It it were me I would use XML or JSON to store the data but that might be to wordy for A:M so maybe some sort of struct which would be raw and hard to read but normal folk.

 

Would also ise in-app memory. OS clipboard is probably too small.

 

 

My $0.02

Tyson

[nemyax]

What would we see if we could see the data in the buffer?

Probably pointers to A:M's data structures.

[Rodney]

Probably pointers to A:M's data structures.

 

Yes, that makes sense.

 

It it were me I would use XML or JSON to store the data

 

That would at least be humanly readable.

 

Assuming A:M would store pointers to data structures this makes we wonder if these pointers could be saved to disk for loading later.

Of course a tag would need to specify the type that would be encountered in order to avoid data being pasted into incompatible places.

This makes me think that one of the reasons a copy/paste might fail (in A:M) is that code checks to make sure the proper pointers are present in order to allow the data to be pasted.

For instance, if copying a group of splines then opening a material and trying to paste that data into a given field the paste would fail because the pointers indicate incompatibility.

This would be true even if the data copied would otherwise be compatible... say copying a value of 100 from one field of property data into another field.

Note that in most cases this particular copy/paste (numbers in any property field) will work for copy/paste because the pointer is likely identifying the data as an integer or general value that can be pasted anywhere an integer is designated. The code may or may not specify an allowable range or type (percentage, range of values, etc.)

 

I suppose one could consider any given Model, Project, Action, Material, etc. as the output of a successful 'copy' operation.

So here is where we can get Tyson's suggested XML formatting.

This data can then be loaded into the program again as a copy of that state.

Thinking in these terms one option might be to have a content sensitive option to 'Copy to ' at every stage of the operation where the location the data is saved is user defined.*

For example, when modeling a head/face a group of Control Points is selected, Right Click and 'Copy to Model' appears as an option. Selecting this option would then bring up a dialog box prompting user for location of file to be saved. The file would then contain only those elements that where copied just before saving.

 

How is this different that what we currently have?

We'd have to do several steps to isolate the thing that will be copied in order for it alone to be saved.

 

Yes... I am over thinking this.

 

 

*Some of these exist already or have plugins that more or less do the same thing.

 

 

I'll add this also:

A spline section in isolation of course would not necessarily be the same as that connected to other splines.

For example: if two CPs are copied from a three CP spline the three CP spline might have a curvature that will not be preserved as the two CP 'version' would be a spline between those two points... a straight line.

Similarly, there is no preserving consideration for copying individual CPs such as the first and last CPs on a spline where the middle CP is not copied. I suspect that A:M does actually copy those CPs but when pasting them back into the Model the CPs fail to persist because they aren't connected to any spline and A:M will only recognize CPs attached to a spline.

[nemyax]

 

 

Assuming A:M would store pointers to data structures this makes we wonder if these pointers could be saved to disk for loading later.

A pointer is a number that specifies the address of something in memory. When your A:M session ends, any pointer value you saved during the session makes no sense any more.

You can always dereference a pointer (meaning, get the thing it points to). Note that the referenced data structure will contain pointers of its own, so you'd need to do some deep dereferencing to gather the data you need. But when you've gathered everything you want, you can save it in any format you please, binary or text-based.

[Rodney]

A pointer is a number that specifies the address of something in memory.

 

I believe I've seen some of those numbers (the static references that is) but perhaps it's best not to go into detail on that.

 

Copy/Paste is a valuable tool but it seems to me that many programs don't open that tool to the user.

I'm sure there are very good reasons for this approach.

deep dereferencing

 

That almost sounds like work....

 

Here might be a reasonable use case to consider (in promoting a more useful approach to copy/paste buffering):

 

Open two instances of A:M.

Create a Model with a few splines in one instance of A:M, select some or all of the splines and hit Control C on your keyboard to Copy those splines.

Open the other instance of A:M and create a new (empty) model.

In the model window hit Control V (Paste)

In a (more) perfect world the copied splines *should* appear in the empty Model.

Currently, this doesn't work.

 

If I understand correctly this might be because each instance of A:M creates its own set of pointers which don't match so copy/paste process fails to recognize it as a legitimate option.

 

The question I might have is what it would take to make these two instances of A:M talk to each other, share data in memory, etc.

 

 

Disclaimer: Obviously one way to get the splines into the second model would be to save to disk in the first instance and then open or import that model into the second instance. But the point of the use case would be to use shared memory or some clipboard style copy/paste buffer to quickly move data from one place to another.

[nemyax]

 

 

The question I might have is what it would take to make these two instances of A:M talk to each other

I suppose A:M would have to define a common clipboard format for its data so that multiple versions of the program can read and write it.

 

 

 

share data in memory

That is not a good idea =)

[Rodney]

That is not a good idea =)

 

I understand some of the pitfalls but... even if Read-Only?

 

In considering the use case I identified above I sense that it's not a particularly useful... use case... which is something of a requirement I would think.

The thing is with those two instances of A:M that as soon as one updates a model on disk the second instance can update from that model on disk. Almost instantaneously.

So, while not quite the same thing it is for practical purposes a near equivalent.

 

I may need to come up with some better use cases.

[nemyax]

 

 

I understand some of the pitfalls but... even if Read-Only?

You'd likely want full transparency even if one instance was 32-bit and the other 64-bit. Couldn't even do much reading in this case =)

 

The thing is with those two instances of A:M that as soon as one updates a model on disk the second instance can update from that model on disk. Almost instantaneously.

A lot of software monitors changes to currently-opened files. Your preferred text editor probably does it.

 

Another approach is to use a client–server model where the server manages the data and the clients work with it over a specialised protocol. You may have heard of the Verse protocol, which was an experiment in adapting this client–server stuff to 3D graphics. It didn't catch on though.

[robcat2075]

Here might be a reasonable use case to consider (in promoting a more useful approach to copy/paste buffering):

 

Open two instances of A:M.

Create a Model with a few splines in one instance of A:M, select some or all of the splines and hit Control C on your keyboard to Copy those splines.

Open the other instance of A:M and create a new (empty) model.

In the model window hit Control V (Paste)

In a (more) perfect world the copied splines *should* appear in the empty Model.

Currently, this doesn't work.

 

 

 

Since we can already open more that one model window in one instance of A:M to do this copy/paste, you'll probably need to identify a more compelling reason to copy/paste between two instances.

[Rodney]

Since we can already open more that one model window in one instance of A:M to do this copy/paste, you'll probably need to identify a more compelling reason to copy/paste between two instances.

 

I'd say the primary benefit of running two or more instances of A:M over use of one is that A:M locks down while rendering which (for all practical purposes) results in no available instances.

Of course, the primary solution to that render lock down is to use Netrender but that doesn't negate the fact that other benefits can be derived from running several instances simultaneously.

Theoretically, at a minimum, a triad of instances would appear to be optimal. This would have two instances passing data back and forth while the third manages rendering. When one instance renders the other two do not render.

This three fold cord then provides a foundation for exploiting parallel processing; because at a minimum there are always two instances available.

 

Running two instances technically won't work because as soon as we hit render... the other instance locks down and has no one else to communicate with (so she delays her work until her friend is no longer rendering).

I should add that when I think of 'managed rendering' I'm not necessarily speaking of rendering to disk, which is more fully in the realm of Netrender.

An optimal rendering solution would likely be rendering to screen (presumably realtime) which is something Netrender itself can't do... it has no display capability... at least it doesn't without aid.

For example, as soon as Netrender renders a frame that frame can be picked up by any program that can display images, including... one or more instances of A:M.

And of course that program needs to know where to look for and retrieve the image(s) so if follows that benefits derive from sharing that information (whether within the same program or between several).

 

Since we are speaking of rendering though my one suggestion to improving A:M's rendering would not be to connect to some external renderer but rather to allow the render panel to maximize to full screen with all options logically in view at the same time and with an optional view of some or all of the images rendered. This should make sense especially given the fact that when a single instance of A:M initiates a render it is totally dedicated to rendering.

[robcat2075]

Unrelated nostalgia... I recall the AMIGA had a clipboard that survived even a reboot. It was writing the data to disk. You could copy today, turn off he computer, then reboot tomorrow and paste.

[Rodney]

Unrelated nostalgia... I recall the AMIGA had a clipboard that survived even a reboot. It was writing the data to disk. You could copy today, turn off he computer, then reboot tomorrow and paste.

 

That's quite related to this discussion. Someone either accidentally created a useful tool or purposefully did.

And besides that, the Amiga was ahead of its time in many areas.

 

I can't recall the specific program I was referencing before but I think it had four different copy/paste options.

My first thought was... well, that's a bit confusing.

I don't have it installed now but not long ago I had a clipboard extender installed that allowed copies of the clipboard to be saved and recalled later.

It was a little bit useful but obviously not enough to keep installed.

 

A lot of software monitors changes to currently-opened files. Your preferred text editor probably does it.

 

Yes indeed. Notepad++ asks if I want to update to the changed version of the file.

Quite handy.