jit.cellblock functionality, but with different UI objects
I'm making a dynamic UI, that needs to have <n> rows of specific UI elements, more or less like this:
jit.cellblock works for a lot of my needs, specifically that I be able to keep the displayed data elements in sync with a coll, and that it should show scroll bars if the number of rows exceeds the allotted vertical space in my UI. Also, the number of rows is dynamic; rows can be added or deleted by the user.
However as we know, jit.cellblock can only display textual values, and not UI elements as above - thus my post. I could probably brute force this somehow with dynamic scripting of the addition/deletion of bpatchers that contain the row of UI elements, but wondering if anyone has an imaginative different approach to make this be more easily accomplished.
perhaps this new Max9 "jit.ui.group" thing
A good idea, but unfortunately I can't easily use a jit.canvas object for the jit.ui.group to write to in my patch, as it will eventually need to be a standalone in its own window...
(as you know) i would put the radio buttons/toggle in an lcd or jitter element and then put some transparent numberboxes above it.
Not sure I'm completely following you Roman - so do you mean use native jit.cellblock functionality to store the toggle state (0 or 1), but hide those from the user, and use overlaid toggles to programmatically set those cells' values? I could potentially do that without an LCD or jitter too.... Will explore (at least if that's what you meant! :-))
if you want to display a variable number of square elements it is easier to draw some squares into an lcd compared to thispatcher scripting. (unless you really only want to hide their view and show the background instead? that can even be reached using picturecontrol)
i know such situations where you want to avoid using bpatcher, and moving multiple functions into a signal jitter or lcd element is one strategy.
If I understand this correctly, it is not to only display, but to also set values.
I would personally avoid having too many GUI elements on the screen.
maybe use 10 rows and bind coll lines to them, using scrolling of some kind
when coll grows.
Correct, it's both to display and set values.
@Source Audio, yes that's what I was planning on when I alluded to "brute force," but it just all seems messier than ideal. :-)
I don't know of any max objects that could serve that task
just like that.
Choice is to insert max number of possible object
rows into bpatcher and to scroll depending on number of coll lines,
or to use fixed number of rows by binding them to coll lines.
how many rows could be expected, maximum ?
Technically no limit to the number of rows (this is for a software editor supporting an old hardware sequencer), but practically I can't imagine more than a few hundred, perhaps 200 or 300.
My original thought was to dynamically add/remove rows (a bpatcher called "row" with the GUI objects above) to a patcher ("all_rows"), and then to display that all_rows patcher as a bpatcher itself at my top level patcher, but only displaying a small number of those rows, and using a <scrollbar> object (not documented but available) and to dynamically offset the "all_rows" bpatcher based on where the scrollbar is. Each row would feed into a single coll for tracking the state of all data.
or you grab coll lines by scrolling and set that rows values?
could be much more efficient than to add or remove so many GUI elements.
here showing only 1 and 10 , which would then be in 10 bpatchers ...
rows get set with values, making any changes sends list back to coll .
Nicely done, thank you!
Only thing I wouldn't be a fan of is displaying all 10 rows; in some instances, there might be only 3 or 4 rows of information, and it would be confusing to the end user to see 10 rows of data. So I'd need to come up with an ability to hide bpatcher rows if the total sequence length was less than 10. But I should be able to do that I think.
Of course then I'll also want to be able to insert rows of data in-between existing rows of data, or delete specific rows of data, but again, this too I think I should be able to do.
It is a matter to querry coll length in a smooth way,
in order to hide or extend to 10 or as many rows as you set.
but you want to reserve space for 10 rows in the main patch.
inserting or removing in between is simple coll management,
one only needs to update that 10 rows list.
Yes, what you describe (and show) is exactly what I was thinking. Thanks for this new way of approaching the problem Source Audio - I always appreciate your help and ideas!
back again ...
I had a look at the patch I posted yesterday, it needs parameter update
when instance receives data from coll.
otherwise previous list would remain in there.
while being at it, I thought insert and delete buttons next to index number would
come handy to perform that actions on the spot.
and undo / redo buffer, select range to delete or insert ....
Wow, you're doing all my work for me! Thanks again!
I had many similar cases , not necessary having to do with display like yours is,
but with storage of parameters into coll .
So it's just a matter to reuse stuff from the past,
which is simply a shame not to do.
Code re-use is a core part of Max for me! ;-)
this is somethig to play with.
buttons have 300ms hold time to execute.
at the moment execution is prevented if one reeases mouse outsigde of button.
can be changed...
delete , isnsert, undo, clear shoud work, but one should check it together
with file storage etc
Incredible, thanks! Works nicely on quick check, will look more closely this weekend. Really appreciate this!
You are welcome.
if any questions arrise, feel free to ask.