and here is a multiradio abstraction. it has the same functionality as the multislider but a different appearence.
and its based on the vradio from the ofelia gui abstractions.
ofelia_multiradio.zip

@nicnut hi. It has nothing to do with declare. And i get the same error. Forgot at least to change something in "pd r.l.shift". Wondering if it would make sense to save the toggle states independently from the colors, that could make things easier (especially with more than one "marker" color) but means also a lot of changes. Edit: This change in [pd left.right] should work:

in this version i implemented a multislider for (midi) velocity and note length. could also be nice for controlling/ visualizing synth parameters. i am sure the patch can be improved but i am happy that ofelia seems to be a good pure data solution for complex interface ideas. ofelia_multitoggle_pvl.zip

@nicnut yes, you need to change the number that goes into the color inlet of the cell struct. and yes, it can start to get glitchy or it takes some time until the interface reacts (with more than 2000 fields on my computer) . i think visual data structures in pure data are a little bit more efficient than a big amount of toggles, but not very much. changing the colors should not make a big difference. and it works nice when you dont need a large grid.

here is a basic grid abstraction for ofelia (multitoggle.pd).
its based on the toggle from the ofelia gui abstractions.
it has three arguments for togglesize, x-number and y-number.
its possible to draw inside the grid with the mouse.
all the midi / sequencing things from the example happen inside the abstraction, it could be simplified or modified for other purposes.
ofelia_multitoggle.zip

@nicnut here you have a horizontal grid: grid1.0 pd0.48wpatternswitch_marker.zip i had to change something in cell, make.grid, sequencer, make.new.seed, and get.pattern.state. the downside with very large data structure grids is that they slow down the pure data interface. something like this build with ofelia could be nice and more efficient for very large grids.

thats very nice. for me it somehow makes more sense if the id is the hot inlet, that way also the id argument isnt needed anymore.
i think its a nicer list-idx with less subpatches and objects. but i have to admit i never used the extra functionality of list-idx and in most of the cases i can just use list split for the id.
list-ida.pd

thank you. the advantage of [list-idx] seems that it can handle negative values, and doesnt output anything if the index is outside of the list range. and it can have an argument for the id. yes, i can imagine that [list store] is still the most efficient (didnt measure it).

just realized this is like a simpler [list-idx].

and i neither need [list-idx] nor [list store] for getting a pointer with a certain id
pointer-list-store-test_c.pd

an easy way to store, get and set pointers with [list store] instead of [list-idx].
pointer-list-store-test_b.pd