Somewhat related to the thread: IOBox ovelays datatypes at certain vertical sizes there is another area in the editor that needs to be scrollable: the list of operations, properties, etc.
I know this is probably fairly rare that you will have more operations than vertical space, even on our 27" 4K Monitors, but it does happen. This is for our context, which naturally has a ton of get and set operations and I cannot get to the bottom of the list:
Currently I am not seeing a way to get around this other than maybe turning my screen vertical just for that one patch.
Kind of feels like the scroll wheel ALWAYS zooming in and out the canvas has hit some limitations. Scrolling long lists of data is just too ubiquitous and sensible.
Thanks for considering a solution and always remembering Murphy’s Law - if it is technically possible, then it will happen at some point! So even something seemingly unlikely like someone creating so many operations in one patch that you will have to scroll, will eventually happen ;)
if you reach this point imo it makes sense thinking about splitting into multiple vl files
pro tipp: use dell ultrasharp 49 in portrait mode
We already have ;) But the Context basically holds all the data we need in the patches, so no way around just having tons of get and set operations, unfortunately.
Definitely a necessary feature but I agree with @schlonzo
There are things that could belong to different class. I can see some property related to “Managers” and other to “Midi” or even “Global”. You would gain a lot refactoring this.
Thanks. Yes, we could group things together a bit more on this page. A lot of it is already grouped, so we set a whole patch in the context and that then contains another set of operations. That’s what the Managers are usually. It just means that also when you need to access something you always need a bunch of getters and setters to go to the hierarchy level you need.
The proper way would be to use the new channels, but refactoring everything to use that will take forever.
Hey, encountered very similar situation
Can I suggest an another solution?
Can a node tree be added according to what is written in brackets, grouped together?
“Internals” can be easily grouped to another expandable tree node