io: Done!

u7angel: Hi! Initially my usecase was to make a list of all the fonts used in a rather large application in order to detect which ones were missing on any given client machine. With a nodeset like this I managed to do just that, every text node I used has an S on the font input pin and somewhere else I receive all these font names and check against installed fonts in the running system to create a list of used vs missing fonts. It was of no relevance for me to know where exactly in the many patches the font was used, I just needed a full list.

With a Queue node and the existing S/R I did not find an easy way to do that. If you send from multiple places into the same S on the same frame, only one value makes it through, and how would you Queue up values from many different locations without having to link every source into the Queue node? Maybe I missed something. In any case, that is one usecase, my hope is that other users might have other cases where this makes sense.

Hope that brings some light into what these nodes are trying to accomplish.

And yes, a better help patch would help. I will work on that.

Cheers!

thank you for the explanation and for sharing. some sort of database it is i guess.

hey colorsound: thanks for the kind words, glad to hear it is useful for you.

Regarding your requests:

• an "Add" bang pin is fairly easy to add, I will get it done soon and update you on it. My only question is, should this manual bang be now the only way to send data, or should I add another pin on the lines of "AutoUpdate" or something similar which let's you decide if you want the manual bang or the onChange behavior? Any thoughts?

• having the nodes know which value in the spread has changed so only that value is updated is a bit more tricky since I do not really have any information on the execution order in which the S nodes are sending data. An option from the top of my head would be to have an additional pin in which you can specify an index/name for the specific slice you want to write into, but this is effectively almost the same as having a separate Send node which writes only to that value. I need to give it some thought. An example of how/where you need it would be helpful to design the solution properly.

• as for the dynamic input pins to choose where you are adding or removing data, sounds to me like you want direct write access to the inner data structure holding all the values. I could add a couple of more nodes like GetData/SetData which take in the name of the S/R and a spread of values, allowing you to set the inner structure's data manually, would this be handy? Here again an example of what you are trying to achieve would be best to think about an optimal solution.

Let me know what your thoughts are.

Cheers!

Super! Exactly what I always wanted to have. My usecase: Write whatever infos to a log from anywhere in your patch graph. but have access to that log at a single patch and write it from there to the HD. The Add pin is missing indeed!
Nice!

@colorsound and @david: Add and AvoidDuplicates pins have been added. Let me know how if they are working as you expected.

Happy patching!

@colorsound: String category is already there, let me know if you cannot find it