TodoMap. Any plans for completing it finally?

I just realized that it is a whole year ago that i failed employing the TodoMap for my Project.
I want it as a solution for handling my presets mainly, and there’s really a lot of gaps to bridge there. So after installing the Visual Studio monster again, here’s a sketch for a

  • Fix Bugs:

*** ‘Enable’ button for OSC Output is faulty; it’s somehow connected with ‘Enable’ Input button.
*** “add” and “save” buttons are painted black
*** can’t create new Category when adding variable.
*** exception after several OSC enables/disables
*** MinMax is not taken from IOBox

  • Simple Improvements:

*** Apply deletion to multiple variable selection. (GUI)
*** Allow for editing with multiple selection (Category! MinMax!) (GUI)
*** Take ‘Category’ from IOBox-(Value Advanced)'s Tag
*** Add |Slice| column in OSC mapping to drive different variables with one bundle/spread input (GUI)
*** Add |current value| row. I guess there’s a reason why it is not there, but…
*** Add flag to TodoExposedController-(TodoMap) to make it generate variable names from absolute OSC paths instead of description. At the moment, IOBoxes in multi-instanced subpatches cannot be controlled individually!
*** Add Tag filter to TodoExposedController-(TodoMap) node to add variables to those only.

  • Realize missing parts:

*** Output Learn Mode, OSC Output.
*** Have map path/name in GUI?
*** Have Preset path/name and Load/Save buttons from GUI?
*** TodoLog tab and Variables tab.
*** Help files with warnings about the pitfalls of disabled components and missing server-(vvvv) node. I guess the author wasn’t thinking of internal controlling. Which makes a lot of sense when it comes to presets.

  • Strategy

*** clear out conceptional friction between exposed nodes and TodoMap, especially it’s OSC part.

Thanks for comments and hints to code lines.

Ok, so quite a decent todo list ;)

  • Enable output for osc now fixed.
  • Black color also fixed, no idea why in some systems it was ok.
  • Category is now editable dropdown, so you can also type any category you want.
  • Exception on OSC enable/disable : maybe that came from output issue above, can’t reproduce anymore now,but anyway I tend not to overclick those buttons :)
    *For Min/Max, issue comes from fact it’s not so easy to auto remap a variable (due to the fact that some tweens don’t have an inverse function).

Log tab could be some help, variable tab, no idea why it’s still there, was when I did some tests with treeview instead of listview.

Output Learn Mode I’ve implemented that already, no idea why this was never committed, but it’s on my laptop in france, so will need bit of wait for a commit.

On other side, all the |Slice| |current value| , had some ideas about it, but never really had the need for it tho. I admit some osc controllers tend to favor those still (wanted to look for it mostly for things like SliderXY as an example), so it’s worth a second look (I’ll likely add slice soon, feels pretty valuable).

On the side of presets, Todomap was never really designed to do this, main use I had in a lot of gigs, installations, is to be able to quickly assign a parameter to a control (copy paste of midicontroller nodes tend to be a real pain), and for this it just works pretty fine (expose->learn->done).

Add flag to TodoExposedController-(TodoMap) to make it generate variable names from absolute OSC paths:
I admit I’m against against this, since it breaks the concept of reusability. I always expose what I need outside.

For the tag part, I quite like some ideas, but want to keep the system simple, I’m not a fan of 2 million parameters system do doing a simple task (specially mentioning I use it mostly for quick mapping when I need to as said above). Keeping some things optional could be a god compromise still, you enable advanced features when you need them.

And please note that if you want to contribute/add some code, you’re more than welcomed of course, I’ll happily help for that.

WOW! vux, when i read this, my eyes went half the way to the display, really. Such a quick and comprehensive reply.
I browsed the repository and wanted to compile. My VS complained about the installation path for the Update4 that i seem to need for github support. Do you know something about that? Anyway, if you did a compile, don’t hesitate to put the VVVV.Nodes.TodoMap.dll here (or whatever it needs). If you wait until you are in france, je suis tres impatient!

Just one more thought about generating variable names from absolute OSC paths:
I understand your aim for reusability. When exposing IOBoxes with /same/ descriptions, maybe because they sit in a multiple instanced subpatch, they show up with consecutive indices anyway. I think they could also receive a suffix that i can parse, like their ID or Tag.
Ah, and unfortunately variable selection is not spreadable altogether, so TodoUpdateVariable-(TodoMap) can’t do multiple updating of Categories.

I’m off for breakfast,

Exposed Nodes in cloned subpatches will show up only once in the TodoMap, whereas exposing them is a beautiful solution to driving them individually.

(btw.: adding images the other way fails somehow)

Ok, so here’s a vvvversion of slice| column per OSC input and taking the |Tag| Pin of the [IOBox-(Value Advanced)]( as Category if setup using the TodoExposedController-(TodoMap). It isn’t possible to drive spreads in subpatches this way individually, however. I am looking forward to implement this the easy way also.
Btw. i lost about two days implementing multiple item selection through all TodoMap nodes. I’ll give this another try as soon as i have found out how to use the d4mn ILogger to Log() to the TodoLog tab in TodoMap-(TodoMap)'s window. Anybody?

Version of [TodoMap] node featuring a |slice| column per OSC input and taking the |Tag| Pin of the IOBox as Category (55.4 kB)