DTD - further explanations

vvvv’s DTD lists some attributes, which functions/usage i couldn’t figure out until now.

as there are:

ATTLIST NODE
managers CDATA #IMPLIED
mute (0 | 1) #IMPLIED
solo (0 | 1) #IMPLIED
ScrollX CDATA #IMPLIED
ScrollY CDATA #IMPLIED

ATTLIST LINK
color CDATA #IMPLIED

ATTLIST PIN
pintype (Input | Output | Configuration) #IMPLIED
valueslost CDATA #IMPLIED

thankfully i found this thread and think i understood the usage of the PINattribute “slices” now.
am i right?
it may modify one or more slice of a spread without setting the whole spread?.
so sending
<PIN pinname=“Y Input Value” slicecount=“10” values=“1,2” slices=“0,5”>
would set slice “0” of the spread to value “1”
and slice “5” of the spread to value “2” without affecting the other slices?

if i only knew this earlier…

some explanations or little hints would be very fine and inspiring for furthermore misuse of vvvv…

for completion of this thread i list the undocumented/unlisted attributes mentioned here also in this place.

bgcolor
no need for info, i found out eagerly and liked to misuse it…
saveme
deleteme
deletemedontask

btw:
i tried to set the “Minimum” and “Maximum” pins (pintype=“Configuration”) to
pintype “Input”.
sadly without success…

and i also hoped to be able to set those pins with a higher slicecount than 1 and spread their values…
would have been fine in my case.
well, newbies won’t miss those features.

oui kalle,

the managers attribute is used to save boygrouped nodes. boygroup, save and see yourself.

all the other attributes you listed are not used.

the pintype is hardcoded for every node and cannot be user-changed. changing min/max of ioboxes to inputs was a bit more work than i thought (when i looked into it, once), so i skipped it…for then.

<PIN pinname=“Y Input Value” slicecount=“10” values=“1,2” slices=“0,5”>
your thoughts on this should be correct. you found it like this in a saved patch?

ai iorec,

in the above mentioned thread gregsn attached a patch named “callmenames.v4p” (…) which i stumbled upon during a search.
explanations within the patch are not that overboarding but thankfully i found it!

with my current state of knowledge i assumed that behaviour:
and:
YESSS!
it seems to behave that way.
now i have to rework only some modules and suppose that their performance will increase dramatically.
formerly i modified whole large spreads (slicecount lots more than 100) via setpatch. only replacing some slices promises to be lots more effective…

jo, then…good lukc!