Duggle

It looks like the modwheel is outputing CC#1. A quick google tells me this is normal for modwheel.

The default bank LCD strings are showing at startup using the EVENT_LED technique. The string (which is 216 chars) is now displaying in full Thanks!

I've good experience with ebay on bulk LCDs (I bought 24 of 16x2LCDs) for a total of about $90 including postage). I just got 10 of these: through their web shop. They were $10 each but the postage was $20 ( a lot for a 3 week delivery time), anyhow very nice displays, good value overall, I consider.

Nice, simple! My Headings string has a lot of embedded " " (space) in that makes it longer, the purpose of which is to align the headings, but also to erase what was there before. There is no "clear all" similar to "%C" that would clear the entire array? (I guess the problem with that idea is that it would need to happen before anything else, otherwise new content might get erased... Anyhow, I'll try the new build and the new method to display the headings. Thanks! In my NGL: LABEL HdBank1 "..." LABEL HdBank2 "" LABEL HdBank3 "" LABEL HdBank4 "" was enough to cause this, so I make sure the unused strings contain at least a space. Also in the example above, only HdBank1 was being referenced by a "label=^HdBank1"

Just received the displays, they're nice!

The problem of these LCD strings not displaying at startup is still a problem. Apart from this, it's now working as expected except: LABEL HdBank1 "@(1:1:1) OSCILLATOR 1 @(2:1:1) OSCILLATOR 2 @(3:1:1)FILTER1 @(3:9:1) FILTER2@(4:1:1)FILTER*ADSR**AMP@(17:1:2)OSC3 SUB @(18:1:2)MIXER @(18:9:2)VELOCITY@(19:1:2) VELOCITY @(20:1:2) OSC @(20:9:2) MISC " the last 2 headings are missing i.e "OSC" and "MISC". The LCD 20 is working fine. Is there a reason the string may be truncated?

I'm noticing that the message for the default bank (=1, in this case) is not printed on startup, but only appears when the bank is re-selected. EVENT_BUTTON id=8 fwd_id=LED:33 type=Meta meta=SetBank button_mode=OnOnly range=1:1 radio_group=1 lcd_pos=1:1:1 label="^HdBank1" value=1 EVENT_BUTTON id=7 fwd_id=LED:34 type=Meta meta=SetBank button_mode=OnOnly range=2:2 radio_group=1 lcd_pos=1:1:1 label="^HdBank2" Also is there a limit on the content of the LABEL HdBank in this situation? "^HdBank" is 238 chars long and contains about 16 "@(x:y:z)" cursor movements. [edit] I've noticed a statement like LABEL Abc "" causes the whole LCD array to go blank. This is confusing and seemingly unnecessary (at least a warning would be nice).

Hi folly, with just MIOS Studio connected to your MIDIbox KB, tell us what midi messages are produced when you move the pitch and modwheel.

For my RGB LEDs, I'm changing their colour with a change of bank: EVENT_LED value=127 id=1035 bank=1 rgb=7:15:0 EVENT_LED value=127 id=1035 bank=2 rgb=7:0:15 If I wish to have an LCD text field that similarly changes with the currently selected bank, what is the recommended method?

Common choices for these diodes are 1N914 and 1N4148, there are many others that will work. The controller in this LCD is said to be compatible with the common HD44780 LCD controller, so yes it can be used. Remember that this 40x4 display is organised as 2x(40x2) displays hence it requires 2 Enable (E) lines per module.

Not sure what you mean, I thought you were planning on using the same modwheel and pitchbender which have limited range, and hence the scaling and offset is still required. [edit] I forgot that the op amp requires a +ve rail about 1.5V higher that the maximum desired output voltage. For a 5V output, this implies a required +ve supply of >6.5V which may be inconvenient. It might therefore be appropriate to go back to just digital calibration, given that the ADC reading with the AINSER converter will have better resolution ( as well as less jitter).

This talk of perl is a few days too late! :D I spent all this time exploring the C pre-processor, then discovering M4, and now working on a lovely set macros to handle things really nicely. (Hey, learning a new language is good for the brain!) Like I said, translating what I've done to perl should be straight forward when the time comes (maybe soon). I'm building my ngc files, and ngl fragments with the following *.bat REM process macro expansion m4 NGsource.m4 > output.txt REM new file from lines containing LABEL sed -n '/LABEL/p' output.txt > labels.ngl REM new file with lines NOT containing LABEL sed -n '/LABEL/!p' output.txt > config.ngc Using the standard "stream editor" sed to split off LABEL content for the ngl file. The workflow is to have config.ngc in a window of Notepad++ silently update (after running the above), then CNTRL-A,CNTRL-C (select all, copy) then paste in the MIOS Studio File browser window with DEFAULT.NGC open and CNTRL-A, CNTRL-V (select all, paste) then "save" button. Voila, the changed NCG is running. With the DEFAULT.NGL, I similarly paste the LABEL content from above, as required. The conditional statements in NGL don't change as much, so atm they're manual.

Thanks for the hint, TK! (I'll continue discussion in the other thread)

Correct! Remember to recalculate the resistances for 0..5V output (hint: use the spreadsheet, let me know if problematic, change the values so that only one resistor need be re-soldered, if any) You may be lucky and just a tweak of the trimpot(s) is all that is required.

Fair enough. Anyway, it's not too difficult open an extra editor window. With the script/macro approach it's easy enough to split the LABEL lines to a separate file for output, anyhow.

That's cool. It's good to know that if I find that M4 stops me doing something I want/need, I can switch to perl. At the moment they seem roughly equivalent, but I'd bet perl is more powerful/flexible as a language.

Would it, could it, or will it ever be possible to include LABEL definitions in an NGC file? Its nice to be able to write the definition close to where it is being used.

I'd like to see a lot more examples of this in the current context. It's an interesting subject. I like the way the M4 code is embedded in the unmodified source text, so that if you only use a few macros, for example, the source is uncluttered by printf() everywhere. I have an open mind.

M4 has taken some learning, but works very well and is extremely flexible! So I've started a new thread:

Motivation It is possible to compile from source files for NGC, NGL and NGR rather than type them directly. The idea here is motivated by my rather massive NG application: 64 encoders, 64 ledrings, 64 RGB LEDs, 24LCD modules organised as over 80 text fields, lots of buttons and normal LEDs. The required NG definition files are also rather massive! Pre-processing the required NG files has certain advantages in this situation: break up the project into multiple files to organise different areas of functionality substitute text (e.g values) that occur in many places by a single variable definition, that is easy to change. perform mathematical operations that output text parse-able by NG (e.g "value=4" rather than "value=2+2" ,NG cannot process the latter) create concise, function like macros that expand to the long winded entries that NG requires. perform the calculations and manipulation required to turn user defined data into sysex message defintions All of this allows rather major changes in structure to be done easily (e.g. add,remove or change the order of a SRIO PCB in the chain) that would otherwise create a horrible amount of typing! About M4 I tried the C preprocessor, and although it works for #include files, and #define for text substitution, that's about all that can usefully done with it (e.g there is no way to arbitrarily insert a carriage return in the output, for example). So enter a tool designed for the job: M4 It is free, GNU, cross platform, well documented, powerful, and from what I've discovered quite easy to use. Invocation The following is in a windows batch file, other OS's will be similar. m4 MySource.m4 > MyOutput.ngc To set up, I simply located m4.exe, and a required dll in my working directory, in the long term it should be located in the system path. The m4 extension on the input file is optional, any extension can be used on input or output. Include In the input file any text you want is put, along with any macros you wish to use: first we'll look at a built in one for including the contents of other files: RESET_HW include(`EncoderDefs.m4') include(`LedRingPatterns.m4') include(`Buttons.m4') I this example the contents of 3 files is inserted into the output file along with any other text (i.e preceded with RESET_HW in this example fragment) Define To substitute one value for any other use define: define(`OFFSET',`13') define(`SomeDefaults',`chn=1 type=CC fwd_to_lcd=1 range=0:127 offset=0 ports=1000100000001000 led_matrix_pattern=3') EVENT_ENC id=1 fwd_id=LED_MATRIX:eval(OFFSET+1) SomeDefaults EVENT_ENC id=2 fwd_id=LED_MATRIX:eval(OFFSET+2) SomeDefaults EVENT_ENC id=3 fwd_id=LED_MATRIX:eval(OFFSET+3) SomeDefaults This expands to: EVENT_ENC id=1 fwd_id=LED_MATRIX:14 chn=1 type=CC fwd_to_lcd=1 range=0:127 offset=0 ports=1000100000001000 led_matrix_pattern=3 EVENT_ENC id=2 fwd_id=LED_MATRIX:15 chn=1 type=CC fwd_to_lcd=1 range=0:127 offset=0 ports=1000100000001000 led_matrix_pattern=3 EVENT_ENC id=3 fwd_id=LED_MATRIX:16 chn=1 type=CC fwd_to_lcd=1 range=0:127 offset=0 ports=1000100000001000 led_matrix_pattern=3 note the use of eval() to calculate a value. There is much, much, more that can be done, but this much should provide some idea, and starting point. If anyone is interested please post to this thread.

TK does say that the LPC17 analog inputs (as implemented on the core PCB) are very jittery and instead recommends AINSER solutions for pots etc. I've used the LPC17 Ain on my MIDIbox KB modwheel and pitchbender and they seem o.k to me for that purpose.

I also note that there is enc_speed_mode property, which I'll try. Also MAP would be a way as well, I suppose.

This question relates to encoders that control a parameter that has a low range: range=0:5 Such as the filter type in a synth, this example has 6 positions. The problem seems to be that the encoder is capable of 128 steps and that in this situation only the first 6 steps are used. The result is that when the encoder is used as a selector like this, it is overly sensitive to touch IMO. Would it be possible for the encoder to output a state such as ((Position*RangeSteps)/127), or similar? Perhaps this would be a little insensitive for on/off type parameters (you'd have to do up to a half turn to change states) so the arithmetic may need a little adjustment to cater well for all cases.

IR photo interrupter techniques work well for this kind of application. I once prototyped a photo harp that worked really well (long ago). It was velocity sensing based on the timing of breaking closely placed pairs of IR beam paths. If you're good with DIYing some circuitry, it can be achieved with: (an IR diode, IR photodiode, an opamp, 2x resistors, and a DIN input) x 12, in this case. Also +7V, -5V supply for the op amps. If you're good with firmware, the MIDIbox KB, or even NG could be adapted for velocity sensing based on timing between breaks in beam pairs. Otherwise MIDIO128 would work off the shelf. Let me know if you're interested in the circuit for the the IR beam sensor.