MIDI Kinetics Forum

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!

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.

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.

Interesting, the buffer program could work..
another great complexity though. It would need to spy on the MIDI to/from Mopho (or whatever MIDI source).

A few years ago, I wrote an external save/load set of Lemur scripts that will take various sections of template settings (LModIt in this case).. and encode /send them out in bunches of less than 256 bytes containing custom system exclusive data.
Receiving side was setup with MIDIMonitor (Mac, on Windows.. MIDIOX should do the trick too).
When played back to the LModIt, it would take the data and decode to a patch setting. 14 bit resolution of parameters.. so some float variables within the template lost resolution, but it didn't matter because the precision I had was 1000.
But still, all of this requires manual intervention.

I stopped working on it because it would randomly cause the Lemur app to crash. I think that had to do with all the vector variable/memory handing, but that bug seems to be fixed now as of version 5.

ahhh.. someday... we can get the synth patches.

Updated the template today to version 2.5f based on some problems noted by Sculptair, thanks!

Updates in version 2.5f on 10 May 2014:
- bug fixes, reworked 'swap settings' and zoom controls to be more (but not perfectly) predictable (envelope style controls are a problem).
* thank you Sculpair!
- note that the VCA/ENV control 'graph' mode does not work correctly with swap settings controls, use zoom instead
- The side navigation toggle other control panels and can be pressed multiple times to toggle
through setting panels, this is not a perfect interface, but one of my first and may someday be replaced

https://liine.net/en/community/user-library/view/459/