Duplicate Scripts?

[rpatters1]

What is the difference between cue_notes_overlay.lua and cue_notes_create.lua. From the Notes it seems like they do more or less the same thing. Do we need both?

[rpatters1]

This question is mainly directed at @cv-on-hub and @jwink75.

[cv-on-hub]

cue_notes_create.lua will only create cues on empty staves; cue_notes_overlay.lua produces cues "over" existing music (hence "overlay") as well as on empty measure. I personally don't use "create" any more and find "overlay" more versatile and simpler to use.

Because of the need to avoid existing music in overlay I've removed automated stem-flipping since the logic relied on the target being empty. There are so many other mitigating factors in overlaying that such automation merely adds operational complexity with little or no advantage. Manual corrections will be required.

For my money cue_notes_create.lua can happily be removed.

[jwink75]

I’ll want some time to play with both before weighing in, but helping my father in law with a construction project today. cue_notes _create was made for and used in JetStream, so I definitely don’t want to remove it without checking them out first.

[asherber]

Stem auto flipping (stems away from center) is how I always do cues; I would be very sad to see it go.

[cv-on-hub]

cue_notes _create was made for and used in JetStream

You must be thinking of a different script. This cue_notes_create.lua was made expressly for the repo.

[cv-on-hub]

auto flipping is how I always do cues

It makes sense on empty targets, but really none on targets containing music. This is the only argument I can imagine for keeping cue_notes_create.lua.

[rpatters1]

Is there not a way to include auto-flipping on empty measures in overlay?

[jwink75]

Ah, yes, thank you Carl! I think I HAD made one for JetStream and then actually replaced it with yours when I made the shift away from a monolithic file. I’d still love to check out the differences between them though, as “create” is at least being USED by JetStream :)

[asherber]

I disagree that "away from middle" stems doesn't make sense when the target contains music.

Does it really add more complexity to the overlay script (I haven't looked)? I would think the logic would be exactly the same as in the create script, based strictly on the cues notes themselves.

[cv-on-hub]

Does it really add more complexity to the overlay script

It adds operational complexity with the comparatively arcane distinction of freezing up, down, away, or none, which only makes sense when the measure is empty. (Plus the concomitant complexity of having to provide for the erasure of such freezing at a later date). "Overlay" uses the simple expedient of making target note stems oppose the chosen cue stem-direction - a simple, obvious and intelligible choice. Cues might need to be shifted some octaves to sit on the target clef/transposition. This demands trial and error in every scenario with absolutely no single "freeze" decision suiting all conditions.

You seem to be suggesting re-introducing the four freeze-options back in to only take effect in empty targets. Terribly messy for minimum gain! But an argument for retaining the "create" version and not introducing such complexity back in to "overlay".

[asherber]

I'll have to play with the overlay script before adding anything else here--as I said, I haven't looked at it yet.

[jwink75]

From my standpoint: I’m ok with losing ‘create’ after having played with both for a few minutes

[asherber]

Okay, I used the overlay script a bit and took a look at its code. From what I can see, an auto stem feature would be perfectly plausible -- instead of specifying up or down stems for the cues (and flipping the target notes the other way), just let the algorithm decide cue stem direction, as it does in the create script. The only use case I can think of offhand where this wouldn't yield desired results is something like this:

The auto algorithm would see the cue notes lying above the center line and would want their stems to go up, and hence the target stems would go down. I think this is solvable in code, and even if it's not I would rather have an auto algorithm that works most of the time than not have it at all. But I understand if @cv-on-hub isn't interested in adding it.

In the larger scheme of things, this thread has made me think that we should be careful about removing "duplicate" scripts, unless one offers a true superset of the other's functionalities. If we were to remove the create script without adding the auto stem functionality to the overlay script, it's true that I could still maintain my personal copy of the create script, but that's something that's more complicated for a user who gets scripts from the website rather than working directly with the repo.

[cv-on-hub]

But I understand if @cv-on-hub isn't interested in adding it.

That's true - I'm not. You are expecting immensely simpler source and destination material than I am, and contrary-wise I have found almost NO situation in real life in which an automated solution would have produced acceptable results in _overlay. Even when I used to use _create I never used automatic stem direction, finding better solutions in other ways, especially when clefs can be changed at the destination. Point taken about duplicate scripts, though obviously identical functionality should probably be discouraged. (These two clearly aren't identical).

[cv-on-hub]

The consensus seems to be that cue_notes_overlay.lua and cue_notes_create.lua are sufficiently distinct to co-exist.