in the last months multiple users requested faster execution of .NGR run scripts to cover their use cases. The only way to achieve this is the execution from RAM, and in order to ensure that even the execution of long and complex scripts is possible, the NGR commands have to be compressed (resp. I call it “tokenized”)
In the last two days I developed a solution for this request - it was a nice programming challenge (although I hate the immense amount of required spaghetti code to cover all options - next time I will use a code generator…
Typically scripts are now executed in much less than 1 mS, which means that it’s finally possible to use them for timing critical operations!
Only drawback: this feature is only supported for MBHP_CORE_STM32F4, because the other cores don’t have enough RAM available - they are executing the script directly from SD Card like before.
It would be helpful if users could help me with the testing by running their existing .NGR files, and maybe also enhancing the files for realtime processing.
Any feedback is welcome!
I will try .ngr again for some cascade note command to active and flip automation mode with MCU protocole, I think it will save me lot of sender/receiver event and fwd command in my actual .ngc
question: is it possible with ram .ngr to write something to scale data in efficient way?
like “if Ain=x send midi pitchbend=y” in one direction and “if pitchbend=y send Aout=x” in other direction
should be 1024 (9bit) x2 (in and out) x 8 (pitchbend fader) =16384 line of code for my usecase…
question: is it possible with ram .ngr to write something to scale data in efficient way?
like “if Ain=x send midi pitchbend=y” in one direction and “if pitchbend=y send Aout=x” in other direction
should be 1024 (9bit) x2 (in and out) x 8 (pitchbend fader) =16384 line of code for my usecase…
doable
no, IF/ELSE is the wrong approach for this purpose, and the RAM is limited to 16k
But in future I could provide a special command which allows to scale during runtime based on an interpolated curve with n number of nodes. This would consume some additional execution time, but it should be fast enough on a STM32F4 - the memory consumption is then dramatically reduced.
In general it’s an advantage of the .NGR approach that special commands and mechanisms could be provided in future.
Sooner or later I will clean-up the source code to simplify the integration of new commands (I’ve to improve it anyhow, because currently we’ve too much quick&dirty spaghetti code)
So you think real time scaling is better than hard table like the last MF_NG update. memory space VS cpu speed
To come back with this new version, there is something strange about MAP.
let say MAP 1 2 3
I have a button pattern command that involve to set button B to the last status (3) if button A is pressed, to ensure next time I press button B it send status 1 whatever status 1 2 or 3 he have before pressing button A
Button A and B have the same “system” to ensure each other reset the other to 1
It worked well with sender/receiver at NGC. Yesterday with the update I try to “simplify” this with run section and conditional NGR, I try “change” command to do the same function, the button B status change to the respective value forced by button A (debug view) BUT if i press the button B it go cycle to it’s own previous value (MAP 1 2 3) without considering what button A just set to him.
I reload my previous NGC, it don’t work any more ?!?
Could you please give me a downstripped .NGC file (and/or .NGR in addition) which demonstrates your intention? It could be that due to the changes a new way has to be found.
Here is the .NGC section, it’s “beta”, and it work with my actual DAW (not bidirectional for led unfortunately),
It’s under MCU protocol, it allow to switch between read and rec automation with 3 rec mod.
One button select read or write, second is write mode (touch, latch, overwrite). Two led (green/red) follow the pattern to light in specific order.
The specific “reset” function is red highlighted below. It force last MAP value to ensure first MAP value at next press. Work well with pre6 not with pre14 (I don’t try other version).
I also have a NGC+NGR allowing bidirectional operation, but it don’t work well for the moment at LED side (button patter work fine with less code…). The only DAW return data for read touch or latch (for my led pattern) is a sysex for the mackie LCD update… I don’t think it’s relevant for the MAP problem we talk now.
