Thread: Midi <-> OSC
View Single Post
Old 11-15-2017, 09:34 AM   #30
Human being with feelings
Join Date: Feb 2016
Posts: 138

Fundorin - more encouragement and assorted suggestions to add to Veto's

Comment out as much as possible in the .ReaperOSC file to minimise OSC feedback from Reaper on items the control surface does not need to follow. A lot of the feedback doesn't matter anyway so don't worry about it (except it makes items of interest difficult to pick out in a console window). Just match the parts that matter and do something in the control surface only with those parts.

Consider carefully how much "state" will be represented in the device hardware, how much in the OSC control surface (OSCII-bot code) and how much in Reaper and design accordingly. The less state in the control surface the easier the code will be regardless of the programming language and its quirks because the states will get out of step with a human in the loop.....

Where will the state or configuration be stored (persist) and restored when the device hardware or Reaper is switched off and back on again? This is a key design decision.

One can use memory as pseudo-arrays as your .png screenshot already does. Provided one keeps track of the sizes (i.e the memory offsets) of each item at declaration time and keep (especially write) access within bounds things will work just fine, and every pseudo-array has a name so the code reads OK.
This thread might help a bit too
with suggestions from Darkstar and others

Note that all memset does is set the memory to a value which can be useful only when the programmer already knows that the space has been earmarked.

One can instead use a stack to store things in memory too if that data structure fits.

One could even use the file system to persist items from memory too: this is how databases work but it's Do It Yourself and probably overkill in the EEL2 / Novation world.
goldenarpharazon is offline   Reply With Quote