NGC language features

[Duggle]

Is it possible, or desired, or will it ever be implemented:

• something like #include "myfile.ngc" where another ngc file (myfile.ngc in this example) gets inserted in the containing file.
• something like #define mysymbol  XYZ where text is substituted (in this example wherever mysymbol is encountered it is replaced by XYZ)

I understand that the internals of NG really determine if these features are even practical possibilities let alone whether they are desirable or not.

I think they would be very useful to have. 

[TK.]

Such features won't be provided by MBNG itself because they consume a lot of memory.

 

But: you can simply use "cpp", resp. "gcc -E" to do the preprocessing like known from C/C++ programs.

 

E.g. try:

 

cpp -xc <your-file>

 

Or alternatively (if the "normal" gcc toolchain isn't installed on your PC)

arm-none-eabi-gcc -xc -E <your-file>

 

The output of this command can be directed into a new file, which then can be uploaded to your MBNG, e.g.:

 

arm-none-eabi-gcc -xc -E your-file.ngc > final.ngc

 

Best Regards, Thorsten.

[Duggle]

That's really interesting, and good to know!

[Duggle]

It works really well.

if you start a comment line with "#", then a warning/error is printed to the console as the pre-processor is expecting a directive.

If you start a comment line with   "##" the warning/error is generally removed and the whole comment line appears in the output file.  

If there is an apostrophe(') in the comment this generates a warning.

If you start a comment line with #// this removes such a warning, but the comment line will not appear in the output file.

 

The pre-processor inserts a few "comments" itself in the output file to indicate certain things such as where an include file has been inserted, but these always begin with # so are happily ignored by NG!  

 

I'm very glad to use the pre processor as it allows to break up a huge *.ngc into smaller components that can be named appropriately, I'm now exploring how #defines can be used to streamline, save typing, and provide more global control e.g easily replace values, etc.    

[Duggle]

Quick question:

Is it possible to evaluate constant expressions with the preprocessor?

[TK.]

yes, all C preprocessor features should be available, inclusive constant expressions

 

Best Regards, Thorsten.

[Duggle]

NGC constants are required to be simple constants, right?

Whereas C constants can and often are formed by constant expressions.

 

Say I want to have a SR offset  in my description of 64 encoders:

ENC n= 1 sr=5 pins=0:1 type=non_detented

I would like to be able to write:

#define OFFSET 4
ENC n= 1  sr=OFFSET+1  pins=0:1   type=non_detented

so I can move the encoder board to a different position in the SR chain without re-writing 64 entries.

But this wont work, so I've tried this:

#define SR_OFFSET  4
#define ADDOFFSET(x,y)	(x+y)
ENC n= 1  sr=ADDOFFSET(SR_OFFSET,1) pins=0:1   type=non_detented

but this does basically the same thing:

ENC n= 1  sr=(4+1) pins=0:1   type=non_detented

So is there a preprocessor method that actually evaluates the expression with a single constant as output?

 I fear that this is done in the compiler which we aren't using. :sad:

[TK.]

No, I don't know such a method.

 

Best Regards, Thorsten.

[Duggle]

I found a way!

Its the Boost library preprocessor macros.

It works, you can to maths on expressions and the output is single constants, parse-able by MIDIbox NG.

I tested the simple offset example like above and it definitely works.

I'll play with it some more, and post back with the details of where to install the library, and examples of use.

In the near future I plan to try some more interesting uses, such as velocity scaling for MAP tables and for constructing sysex messages from #define'd data.  

[ilmenator]

In the near future I plan to try some more interesting uses, such as velocity scaling for MAP tables and for constructing sysex messages from #define'd data.  

 

I'd be very interested in learning more about this, especially the #define / SysEx part!

[Duggle]

I've just been experimenting.

The macros won't expand nested expressions. This is using the arm-none-eabi-gcc compiler.

The single, unnested invocation of add and multiply macros definitely work.

Combining them as you would need for this stuff, produces nonsense (improper expansion).

For example, (from Stackoverflow)

#define REM(A,B) BOOST_PP_SUB(A, BOOST_PP_MUL(B, BOOST_PP_DIV(A,B)))

Is not working.

Unfortunately, it seems the preprocessor functionality of the arm-none-eabi-gcc compiler might not be as sophisticated as some others.

I'll try another gcc.

[Duggle]

I've got the macros working, but I now discover that the arithmetic saturates at 256. Another hassle is that there is no way to insert line breaks with the preprocessor so I've had to run an additional utility to achieve this. So I'm now looking at M4....

[edit] I've downloaded M4 from GnuWin, I'd assume there is a GNU M4 for other platforms.

Its a full featured macro language with 32bit arithmetic and it's design to do these kind of jobs, unlike the C preprocessor which isn't really. Unfortunately, it's not as familiar as cpp, but will do everything I need.

The sysex job is to construct sysex messages containing 16 bit data from lists of defined constants, into a sysex message (that is of course only 7bits per byte).

Anyhow it's working, so I'll continue on, and post back with the methods and results.

Edited April 12, 2013 by Duggle

[Duggle]

M4 has taken some learning, but works very well and is extremely flexible!

So I've started a new thread: