Something I have always been curious about is the ezdac~ GOP feature/anomaly. When I open ezdac~, the toggle and hslider GUIs are not situated anywhere close to one another. When I return to the abstraction, everything seems to situate itself into a simple GOP. Re-opening the abstraction, if I move the GUI objects around, they always seem to find their way into the GOP red-outlined field. But, wait, there is no GOP field there!

I copied the entire contents of the ezdac~ abstraction into a new abstraction with a different name. The new abstraction loads, but with GOP not activated. Activating the GOP function places a red field in the patcher window, but not in a place where it could encompass both GUI elements. In addition, the GUI elements do not reorient themselves into the GOP box as before. My next theory is that the actual file, the text that defines the ezdac~ abstraction must have some special voodoo in it to place the GUI elements in the right place (which would be a powerful bit of knowledge, indeed), but searches for ezdac~.pd brings up nothing on my Mac. Strange. I seem to remember similar behaviour under Ubuntu.

What's up with this?

Jgeist

>>I copied the entire contents of the ezdac~ abstraction into a new abstraction with a different name. The new abstraction loads, but with GOP not activated. Activating the GOP function places a red field in the patcher window, but not in a place where it could encompass both GUI elements.<<

when you copied, you only copied the objects inside the patch, and the connections between them. AFAIK, there is know way to copy the GOP info as well (unless of course you just copy the abstraction in your OS to a new filename). So, when you create a new patch and paste the copied stuff into that, the new GOP you make will just be the default PD one...which is different to the one from your original patch. That's why it's not working for you.

If you manually change the co-ordinates of the GOP box, it will work as you expect.

>>My next theory is that the actual file, the text that defines the ezdac~ abstraction must have some special voodoo <<

yep, here it is:

#X coords 0 0 1 1 90 55 1 100 30;

OK, that's great, that certainly answers the second part of my question, where the GOP area is and how it is encoded into a file . . . but, how do the GUI objects know to reorient themselves to that space? What I am getting at is that there seems to be two display modes, one for presentation (GOP abstraction closed) and one for programming (when you are working in the GOP). I guess, similar to what Max has adopted.

So, the GUI objects seem to exhibit two sets of coordinates depending on where you are in the patch.

Just curious,

Jgeist

the GUI objects don't move to the space,

YOU have to move them there yourself.

EXACTLY! This is why the behavior is so strange. I will try to walk through what I am experiencing, if you are so inclined, try this:

1. Create an ezdac~, notice how the hlsider and toggle are next to one another. You would expect they would be similarly configured when you open up the abstraction, as you say, YOU have to move them there yourself, but the objects are not located within the GOP field.

2. Right click on the abstraction, open it up. Those objects are no where near one another. In fact, there is no way these should be visible in the GOP because the GOP field is at these coordinates, as you note, #X coords 0 0 1 1 90 55 1 100 30;

3. Move the GUI objects around, in fact, make the patcher the size of the entire screen and put the GUI objects in separate corners. Close the abstraction. When I do this, the GOP is somewhat resized, but the objects do realign themselves to be within the visible GOP space. Wierd, huh?

4. If you create a new object in the abstraction, like a text box, the behavior is broken, the GOP field appears, and the object is broken as well.

5. I don't think it is possible to create an ezdac~ object, like the one which comes with Pd, which has the same lay out.

6. Perhaps this is a bug/feature which only happens with my version of Pd.

Thanks,

Jgeist

ahhh!

actually, i think i know. There was a rewrite of the way pd handles GOP a few years back. [ezdac~] is a really old patch, so probably still uses the old system, which must still work to some degree for backwards compatibility.

However, once you change something using a newer version of pd, your GOP handling is then handled by the new system, hence the confusion.

I just tried it, and even by opening the canvas properties dialogue, the small red box appears in the ezdac~ abstraction. If i then move the volume slider and toggle into that box, it now works with 'modern' versions of pd.

i just made a 'new' version like that, and compared it with the original ezdac~ abstraction. here's what the last line of each patch looks like in a text editor:

original ezdac~ :

#X coords 0 0 1 1 90 55 1 100 30;

new copy:

#X coords 0 0 1 1 90 55 1 0 0;

you can see the last two numbers in that list are just 0 now. I guess that's the default for modern GOP handling. It looks like, as soon as you edit an older GOP patch, then those last 2 numbers are now automatically set to zero so that your patch will follow the new GOP system.

by the way, the new system is heaps better. It used to be quite tricky to arrange a GUI layout!

>>5. I don't think it is possible to create an ezdac~ object, like the one which comes with Pd, which has the same lay out.<<

yes, you are correct. GOP handling has been changed within pd itself. You would need to install an old version of pd to make it work the way it used to.

I guess it would also be possible to change your patch to the old system by changing that last line in a text editor. Also, it could even be possible using dynamic patching, with a donecanvas message, but again, not sure why anyone would bother...

Mod:

Thanks for the clarification. About three years ago I was demonstrating GOP functionality to a student when, all of a sudden, I grabbed ezdac~ as an example. Who knew? I have been perplexed until today.

Appreciate the follow up. Case closed.

Jgeist