More of an initial design approach. Philosophy sounds like it was a soft/fuzzy decision. From a programmer standpoint, if your initial approach takes advantage of a certain size for things (16x16 grids, 256 bytes, etc) it is a significant undertaking to redo that for any other dimension. One time in my programming career I had to rewrite 30k of assembly code to support a video display change from 640x480 (w. 8x8 character cells) to 1024x768 (9x12 or something character cells). The original programmers had severely optimized the code to take advantage of the 8-ness of things and initially there was a big performance hit and a ton of code that had to be added to unwind all the shortcuts. That was for a 'simple' video display. For something like Lemur, it's probably never going to happen. If you increase the size of MIDI_ARGS to support receiving more than 256 bytes, then every array/vector has to change which ripples through the entire codebase.Joe Soap wrote:Apparently it's a "philosophical issue"?
https://forum.liine.net/viewtopic.php?f=28&t=2214
At this point I wanted to insert a rolleyes, but the board-supplied ones don't seem appropriate, philosophically speaking. Sure, they're fine from an ontological POV, but c'mon!
What would be a better request would be for some external buffer/program (OSC based?) that sat in front of Lemur on the MIDI ports and had the ability to send/receive large buffers of data. Then you'd need a programming interface to that external program to say 'here is some data', 'here is some data', 'here is the last chunk of data, send it' and on receipt, 'give me 256 bytes', 'give me 256 bytes', etc.
That would move the problem out of Lemur so it wouldn't have to change. You'd still have to be clever in the way you used the large data, but you can essentially build up an array of arrays to support accessing more than 256 bytes of data.
