Re: [Denemo-devel] Internal tags/markers needed for a new kind of selection.

[Richard Shann]

On Wed, 2011-06-01 at 01:20 +0200, Nils Gey wrote:
> Hello list,
> 
> as mentioned briefly in IRC today I came to the conclusion that we
> need a second kind of selection which is not a range from start to end
> but where each item is tagged/marked as part of the selection until the
> processing is finished.
> 
> This is needed for any destructive work with
> selections, mostly inserting or deleting notes.
> 
> One way to achieve this is to have a temporary tag that can be applied
> to any object in the score without difference. An object is anything
> that can be placed, selected and deleted (or in other words anything
> that reacts to d-GetType): notes, rests, chords, tuplet markers,
> stand-alone directives, voice-directives, clefs, keysigs etc.
> 
> These tag must be different from the directive-tags for two reasons
> 1)Directive tags have a logical meaning connected to the music and
> output, the new tags are purely technical and internal.
They only have meanings once values are assigned to the fields, a
directive that is just a tag is purely technical and internal.
> 
> 2)Handling directive tags is overly complex because you have to handle
> so many cases and in the end, or if something goes wrong, you may have
> tags on all objects. (see P.S.)
Yes.
> 
> Conclusion:
> A new tag, invisible to the user, lilypond and the "real" tag/directive
> system is a good and direct way to apply all possible functions to a
> selection. From "delete" over "split" to out-written embelishments.
The straight-forward way to do this is to attach directives to the
DenemoObject (at the moment, we have them attached to the type of
object, with one type Chord having further "objects" viz, notes within
it). This would just be a mechanical exercise (a fair bit of cut and
paste, but nothing new).
> 
> These tags would be generated from the normal selection by a scheme
> script. They shold be as temporary as possible,
hmm, 
>  like the original
> selection is. By no means they should be saved in the .denemo file.
It would slightly reduce the cut and paste to not save them...
>  I
> think they could even deleted automatically after a function 
> (which may
> call other functions) has finished. But even if they have to be deleted
> manually (in the script while processing) please as simple as possible.
> No custom name, no additional attached data. Just (d-Tag) (d-Untag)
> (d-Tagged?) and if you look away they vanish into thin air :)
this is very problematic. Deciding on circumstances to delete the tag
and searching for and deleting the tags would all require significant
effort. There are other strategies - keeping hash tables of tags created
(and then being sure that the objects referred to still existed when it
came to delete the tag...) - significant design and implementation...
If we had the d-PutDirective-object then just cloning away the current
code would mean these directives would go into the copy buffer, which
would be problematic. It would be a case of dropping a bit of
cut-and-paste in the coding to make this not happen (as with the
not-storing-to-file requirement).

Another approach altogether might be to give DenemoObjects an id field -
a unique handle never re-used in a session of Denemo. Quite how this
might be used to achieve your ends I am not sure...

Richard


> 
> Greetings, 
> Nils
> 
> 
> P.S.
> I have written one or two scripts with those work-around directive-tag
> markers already. Most important d-DeleteSelectionLeaveEmpty. Its
> horrible! Most of the code in there is just deciding which type of
> object the current one is
this would go away with a (d-DirectivePut-object "mytag") if we had it.
>  and using a different function to attach a
> directive, or rename and delete the one in case of a stand-alone
> directive. A new type of tags would reduce this to a few lines.
> 
> 
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/denemo-devel