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.

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.

I get it. It looks like a nice controller. The GLCD will probably have better resolution than the Led Rings anyway.

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.

Welcome! though I haven't done this with NG and a LPC17 core, the section under AIN in http://www.ucapps.de/midibox_ng_manual_ngc.html specifies a mask of 6 bits implying 6 core analog inputs available. I have built the LPC17 based MIDIbox KB which has only 6 analog ins, so I think this is correct. Have you considered encoders? The non-detented ones have the same feel as rotary pots but have the benefit of total recall! This board works really well:http://www.midibox.org/dokuwiki/doku.php?id=MB-LRE8x2CS_PCB I think there is an 8 knob version in the works. cheers

O.k, this time I shall assume "user error" until I prove otherwise! :D

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:

I think this could be very helpful, as I've found the controls to be very slow to respond while a phrase is playing.

It works! :smile: I should mention something that'll need attention at some point though: It would appear there is some memory artifacts/corruption that only affects the 1st row. It seems to typically effect columns 2,3,4,5,6,7,8 (ie not 1) of the first row. It manifests in a pink hue (when the LEDs have been set to white), sometimes the affected LEDs output a dull red. At certain points in time they spontaneously get better/worst. If I change bank, the affect LEDs seem to all go to the correct colour, and then if I change back to the original bank the wrong hue is back. I don't think it could possibly be faulty hw because the rest of the array all 8 columns of the remaining 7 rows are perfect, as well as (1,1) seems to be fine!

Functionally it works, fantastic! :frantics: For reference here's the section: if ^section == 4 send NoteOn USB1 1 36 80 delay_ms 500 send NoteOn USB1 1 36 0 send NoteOn USB1 1 38 80 delay_ms 500 send NoteOn USB1 1 38 0 send NoteOn USB1 1 40 80 delay_ms 500 send NoteOn USB1 1 40 0 if BUTTON:3 != 0 log "Retriggering section 4" exec_meta RunSection:4 else log "Finished." endif exit endif and here's the terminal output (missing endif message, repeats the else branch twice): [1045.724] Retriggering section 4 [1045.725] [MBNG_FILE_R:56] WARNING: missing ENDIF command! [1047.230] Retriggering section 4 [1047.231] [MBNG_FILE_R:56] WARNING: missing ENDIF command! [1048.737] Finished. [1048.738] [MBNG_FILE_R:56] WARNING: missing ENDIF command! [1050.243] Finished. [1050.245] [MBNG_FILE_R:56] WARNING: missing ENDIF command! Neither of these is a problem because the midi is generated perfectly.

What I think I'd like to do is have a button that triggers the execution of a section which I've done following the provided example: # start script with ^section == 1 EVENT_BUTTON id=1 type=Meta meta=RunSection:1 button_mode=OnOnly I'm just not sure what to put (and where) to make the section re-trigger on completion as long as the toggle mode button is in the active state?

Yes, I think I understand some of the potential for problematic side effects, complexities etc. Without adding anything to the NGR capability a couple of methods come to mind: Using (very?) long sections that poll the button/control state regularly to exit Could there be a way of re-triggering the execution of a meta by another/or same control thus repeating a section but without the linguistic complexities?

BTW, if you hadn't thought of it already: without any hardware you could trigger a CRO on the falling edge of the cathode row driver (assuming using DOUT pin without 2803 driver, else with a driver attach a pullup) . Then with another probe look at the RBG column driver pins (for a simultaneous high) to see when the non-existent LED would come on.

My usecase is to play a phrase in a loop continuously while designing synth patches. The simplest way I can think of is a label-goto pair. Something like this would be fine: if ^section == 10 loop10: if BUTTON:8 > 0 #loop phrase until button toggled send NoteOn USB1 1 24 100 delay_ms 1000 send NoteOn USB1 1 24 0 goto loop10 else exit endif endif Of course a more sophisticated (and structured) while {expression} .. wend would be welcome also, or instead of goto!

Seriously, I have a module (like this:http://www.futurlec.com.au/LEDMatrix.jsp 8x8 common cathode, RGB) which I could wire to IDC plugs and mail it to you, ready to connect to a standard smashTV DOUTx4 (which I can also provide, btw). Let me know the destination address via email if you would like it. It might take a bit longer than I would like for it to arrive at your end, but it would be handy for you to be able to quickly test this stuff in the long run?

No change, but with debug on I only see: [7812.529] Executing DEFAULT.NGR with $section==1 $value==0 [7814.534] DEFAULT.NGR with $section==1 $value==0 processed. unlike other sections(which work), I get [7804.531] MBNG_DOUT_NotifyReceivedValue(34, 100) on a set LED etc. Here is the fragment that sets up the RGB and turns it on: DOUT_MATRIX n=1 rows=8 inverted=1 sr_dout_sel1=1 sr_dout_r1=2 sr_dout_g1=3 sr_dout_b1=4 led_emu_id_offset=1001 EVENT_LED value=100 id=1001 bank=1 rgb=7:7:7 EVENT_LED value=100 id=1002 bank=1 rgb=7:7:7 ...

This works: set LED:34 100 delay_ms 200 set LED:34 0 These don't work: set_rgb (id)LED:1001 15:0:0 delay_ms 1000 set_rgb (id)LED:1001 0:0:0 delay_ms 1000 set_rgb (id)LED:1001 15:0:0 Also not with: (hw_id)LED:1001 or: LED:1001

I have "special hardware". I'll let you know! :smile:

Does that mean my example should work without modification in the next version? Also: I'm using statements like this to set an RGB LED to a different colour, with each bank. EVENT_LED value=100 id=1001 bank=1 rgb=7:7:7 How would I activate this LED with different colours during a run script?

My default.NGC includes the following lines: EVENT_BUTTON id=8 fwd_id=LED:33 type=Meta meta=SetBank button_mode=OnOnly range=1:1 radio_group=1 value=1 EVENT_BUTTON id=7 fwd_id=LED:34 type=Meta meta=SetBank button_mode=OnOnly range=2:2 radio_group=1 If I have a default.NGR with: if ^section == 3 set LED:34 2 endif I get: [33887.626] Executing DEFAULT.NGR with $section==3 $value==0 [33887.628] [MBNG_FILE_R:26] 'set LED:34 2' failed - item not found! [33887.628] DEFAULT.NGR with $section==3 $value==0 processed. I want to test it by activating the led. What am I doing wrong?

Thanks, TK. I'm glad I asked! J5 has support routines in mios32_board.c which will make it pretty straight forward to implement.

I'd like to use multiple CLCD's on a Core STM32 as part of an ongoing hardware debug excercise :happy: Of course the STM32 PCB does not have a J28 for the attachment of a DOUT board that provides the extra E lines to all the extra LCD modules. So my strategy for this was to implement the MIOS32_BOARD_J28_* routines (which at present for STM32, just return -1), with equivalent code that bitbangs J16 or J19. Is there an easy way to achieve this? I couldn't see support routines for J16 or J19 so I would I have to write these? Are there any major problems with what I'm proposing?

Hi John, I don't have midio128 and am not familiar with it, so I only have a few general suggestions: enable debug mode and observe the MIOS Studio terminal window for feedback. flash test apps into your core and thoroughly test each keyboard and and each matrix din/dout pcb in isolation (e.g test a matrix pcb o.k, then use it to test all the keyboards in turn. When your satisfied that all hardware is working correct (I suspect it is or else you'll find something wrong in the previous step) look at your configuration data. (e.g is a control surface element i.e button etc, mapped to the SR that is in one of your matrix?) good luck with this! PS it might be best to continue this in another thread.

From what I understand, the .ngr is a way of making anything you want happen at startup (and much more..) It looks like an easy way to me. Alternatively: I'm not familiar with your use case, but generally I've found setting the "value=" property to an active value is like triggering it, which takes place on startup.

That seems pretty reasonable, and very workable. Perhaps, in time, it would be possible to produce a MIOS Studio warning in such a case, and to be able to gracefully terminate the script at a prompt.