Description of the desired feature

I believe @Esteban82 asked this on the forum some time ago: How to make movies using events to plot focal mechanisms? I have an interest in getting this feature implemented as well and here are some thoughts on how this could work. First, a brief overview of how regular symbols are plotted. These are simple (circle, star, etc) so only one parameter. In contrast, focal mechanisms plotted via gmt meca may take 7+ parameters. Here is the workflow:

1. Input data need 1-2 extra columns appended at the end: The time of the event (required) and the optional duration of it (if variable. If constant then we can set it via -L).
2. Given the current frame time and the various parameters set via -E, -M, -L, determine which symbols should be visible (we skip the rest) and determine the individual symbol scale, color intensity and transparency for each one of them.
3. Write a temporary data file with all the events that must be plotted, and append the three extra columns setting symbol scale, color intensity, and transparency.
4. Call gmt plot on this temporary file

To "generalize" this workflow to apply to more complicated symbols via meca and others, I think this may be the path forward:

First, modules like meca and velo will need new options to allow the passing via extra data columns of symbol size (or more like an overall scale), color intensity, and transparency. This could be achieve this way:

1. Symbol size/scale: Since these modules have their own -S option to set many aspects of the symbol type and size, we can add another modifier that basically means "then scale the final symbol size by the factor in the first extra data column". Let's call this modifier +z.
2. Intensity: All of these modules can be given the same -I[intens] option found in plot and then use the second extra column for an intensity value to modify the present color.
3. Transparency: I believe the modules already have an appropriate -t option since it is a common option but I will need to see if it actually works the same way as in plot (-t without arg means read transparency from last column).

With those changes the modules will be capable of issuing the correct plot code when driven by events as well as when run independently.

The second challenge is to tell events you want one of these symbols. I think it is better not to clutter the present -S option (standard symbols) but instead use -Z to select these more advanced symbols. Because meca, velo, coupe etc take many options and they are not all identical, it is not a simple thing to do, especially the many data formats and conventions allowed. My preferred solution to this goes like this:

Let -Z be an option that takes the core command we need, e.g. -Z"meca -Sm6c -T0" or -Z"velo -A+pthicker+ea -Se600c/0+f8p". These strings will form the core of the final gmt command call to these modules, but events will add options and modifiers as needed (such as passing along any -Ccpt -Gfill -Wpen and -N options given to events as well as adding the extra -I -t and append +z to their -S option).

This scheme does assume that any such module accepts these options: -Ccpt to color the symbol based on an extra column value, -Gfill to set a constant color for symbols, -N to not clip them at the border, and -Wpen to set an outline pen. These are all available but I notice coupe uses -Zcpt. I think a backwards compatible upgrade is in order there - I think we actually discussed this earlier but maybe we forgot - it seems like an obvious anomaly.

Would be helpful if real seismologists like @seisman could comment on any shortcomings of this proposal.

Note: I may decide to not use -Z after all and go with -S since we are running low on option letters in events and it may be good to save -Z for the future.