OK I see why this is and it means I need to change one bit of my strategy. Will get a fix in. Very much appreciated.
OK I pushed a fix just now. Nightly soon.
The problem was I was scrolling over a frame buffer and not resizing it. But when i resize it to be long enough for that JSON document it canāt allocate (understandably) so for now Iām not buffering the window drawn in the list myself and just using the clip rect. I should revisit this to be more parsimonious and buffer but for now it works fine and doesnāt do much work at all so I pushed it.
No-one will run this module in performance patches anyway I hope!
Great feedback from everyone here today. Thanks.
hehe - the thing I do is donāt do any āfinalā layout at all until the module is done. Then lay it all out visually. Use the tools in the visual editor to line everything up, etc. when happy, copy it over manually into the code.
Thereās not really any way to cheaply change your mind. If you do it in code you can change your mind about minor things, like the spacing between knobs, but no matter what you do itās going to be difficult to change your mind about the basic layout.
Thatās why a designer might do a few ālow fidelity mockupsā, but will charge you less it you pick one, let them make final ācamera ready artworkā, and only do that last thing once.
I make a bunch of mockups on the screen, send them to testers, look at themā¦ Itās usually easy to pick one, then finish it off and put it in the code.
Of all the time consuming things, the copying the numbers to the code is for me the only one that is super fast. make a module from scratch ā a month. Make a panel design I like ā a day. Copy the coordinates to code ā half an hour or less.
Showing your age there
I think the last time my artwork went in front of a camera was around 1993.
You were probably saving your code on floppy disks at the time.
haha, busted. but by then our company did have a small network and an enormous 330MB scsci drive we shared. version control software and everything. Now in the 80ās we used floppies and a chalkboard to keep track of who āownedā which filesā¦
Just for the record: Iām using DEBUGSTRING in my crappy prototypes even now but I limit myself to a short sentence/word/string and send it to a knob/paramater.
paramQuantities[WHATEVER_PARAM]->description = DEBUGSTRING;
OK I just pushed a version (new nightly in about 15 minutes) which does a few things
- Put up a warning when you start it that it is for devs
- Change the HTML temp file management in a way which should (I think) work on windows as well as macOS (but I still donāt have a windows env)
- Add an option to dump to the rack log also
I have other modules in the collection which make me want to library submit a new version shortly so wanted to at least clean that up. if a windows user could at least confirm it doesnāt explode that would be lovely, but even if it does, thatās OK. This is for devs and they can build if I have fixes post library.
And as always glad to add tests and take PRs as you wish.
Enjoy!
Just tested on Windows. It did not explode
Output to HTML still does not open the file in my web browser. (where would the HTML file be?)
Output to Rack.log works fine.
I like the WidgetPositions direction. Since Meander panel is totally procedurally generated at runtime, I can imagine this being useful to see where things end up. I have several ways to doing this currently and they are tedious.
The html file will be in documents /rack2/:baconmusic/lintbuddy and will be deleted when you remove the module or shut down the rack session
Good the log file worked - I wonder why the file:// url did not. Curious if the file is there? If it isnāt do me a favor - switch the skin on lintbuddy from light to dark and then try again. (I can also test my thesis that makes me say this when Iām back at my computer if you donāt get to it)
And yeah lots we can do indeed - I am happy to merge other tests and I think itās pretty clear how to add them but I will slap a quick comment in the cpp file also
Thanks. Now I see the HTML file. I guess I was looking after I ended my session, or I just overlooked it somehow. I can double click on the HTML file in file explorer and it is opened in Firefox as expected.
So, I have no idea why the HTML file is not being autoloaded.
the file:// url must be being misformed on windows from the path is my guess.
Iāll sub current version to the library and then open an issue to look one day unless someone else with a windows env fixes it first!
It help me catch a hidden debug output that I forgot to remove from the Outputs enum, useful tool thanks!