Duggle

When chaining events (we can chain up to 4 EVENT_* controls) a delay may need to be inserted between to operations to allow the receiving midi device time to react. I encountered the situation The idea is to forward the event to an EVENT_DELAY which in turn forwards to the next control in the chain. The EVENT_DELAY would postpone forwarding for a duration of value=milliseconds. If the EVENT_DELAY is re-triggered (i.e the forwarding control changes again) during an active delay, then the delay period restarts, guaranteeing a minimum delay period from a control change to the forwarded event. Here is an example (ignoring the possible significance of the order the EVENT_ definitions) EVENT_ENC id= 1 hw_id= 1 fwd_id=DELAY:1 fwd_to_lcd=1 chn=1 type=ProgramChange EVENT_DELAY id=1 fwd_id=SENDER:1 value=50 EVENT_SENDER id=1 type=SysEx stream="0xf0 0x00 0x20 0x33 0x01 0x00 0x30 0x00 0x40 0xf7" In the above example, the effect is that the Sysex dump request only happens once the ProgramChange selection has "settled" for at least 50ms.

The order in which controls are defined in NGC is important. If a control forwards to a sender, the sender has to be defined first. If the EVENT_SENDER is defined after the EVENT_ENC then debug output shows fwd_id=DISABLED. According to debug output the following works for what I described in the OP. ###Dump request EVENT_SENDER id=2 type=SysEx stream="0xf0 0x00 0x20 0x33 0x01 0x00 0x30 0x00 0x40 0xf7" ####Progchange -> Dump request EVENT_ENC id= 66 hw_id= 66 fwd_id=SENDER:2 fwd_to_lcd=1 chn=1 type=ProgramChange range=0:127 label="^prgch" ###Bank Select -> Progchange -> Dump request EVENT_ENC id= 65 hw_id= 65 fwd_id=ENC:66 fwd_to_lcd=1 chn= 1 type=CC cc=0 range=0:7 label="^banksel" The synth is not responding reliably. I will try implementing a delay between operations by calling an NGR run section.

I just realised the SCS section of the manual talks about Var(iable) in regard to their use in Sysex dumps. This is very cool. But would it (or could it) be possible to introduce a similar concept that works with general control settings? I think the main usecase for myself is to implement a channel change. This would affect all CC controllers as well as the output of NGR audition sections. Later on, further down the track, I'd like to work with synth multi's where I would potentially be wanting to simultaneously change groups of controls to different channels. E.g setup multiple "channel strip" where I'm adjusting a group of paramters on say four channels at the same time, then activate a control and be working on another group of channels. I know that "banks" provide some of this functionality. I think I'm hitting the wall with memory limitations: I'm at 77% with just 1 channel. I was hoping to trigger a sysex dump when the channel is changed to update all controls with the new channel/synth states. One more thing: Is it, or will it be possible to change NGC (and NGR) from the SCS?

Have you changed the LED that never lights? (sometimes they get damaged soldering etc, I had about 2 per 1000 or so on my 4 Fairlightiii PCBs). Have you swapped the PCBs in the SRIO chain? (need to eliminate signal integrity problems and isolate faulty hardware.) It's good to have a settup.ngc that works with just one PCB, and have just one PCB connected to do this. PS I like you colour scheme with the LEDs!

So far, so good. I've set up an "Audition Panel" which gives control #1 Phrase, #2 Note, #3 Velocity1, #4 Velocity2, #5 Tempo. A toggle mode pushbutton activates the phrase while down. This executes an "Entry" section where the beginnings of non repeating phrases happens (held notes and chords). It then jumps to another section where cyclic (looped) phrases happen. It is possible to freely turn the encoders to change any variable while it plays. I plan to use conditionals to control what the parameters do according to the Phrase selection to consolidate to only 4 encoders. Velocity1 and Velocity2 gives control over the velocities of up to 2 groups of notes in a phrase. The worst thing that can happen is the odd stuck note as there is no way to guarantee every note on has an off. This really isn't an issue because the exit of all phrases when the button is toggled off is AllNotesOff CC. Not in any way necessary, but would be "nice to have" features for the NGR: Be able to ADD the value off a control to a constant. This has the following uses: Modify (shift) the velocities of a phrase (that has a variety of base velocities in it) Transpose the note values of a phrase (that has a variety of notes values in it) Also if there was a simple statement to block (and unblock) the reading of new values. Would be used while a note is "down" that would prevent stuck notes before they happen.

Great, I'm doing this, I have a display on order!

You would have 4 row drivers (1 shift register, 4 pins) and 16 r,g,b columns (6 shift registers), right? This is what I effectively have on my big NG now. It gives brighter, more colour resolution, and "smoother" appearance than the 8x8 that I set up initially (8x8 worked very well, though).

Hi Marxon, I changed the schematic to an imagelink (edited the OP). Is that better now?

I've since moved on to SEQ4 (full, with 4 MIDI ports fitted, of course!). The idea here is to have separate MIDI Ins and outs to each device (synth) so that it is possible to run a separate patch editor for each synth on PC, using the Router functionality to associate multiple USB Ports with different apps/synths. It works! I've since discovered I don't like the patch editor software that much and am putting together hardware based editors based on MIDIbox NG. So far this approach is shaping up to be brilliant!

When interfacing a Joystick, Modwheel or Pitchbender it is sometimes found that the voltage range on the potentiometer output is well inside the range of the Core ADC input. This can often be overcome with digital calibration in the firmware (e.g MIDIbox KB) in some cases there is extreme loss of resolution. Presented here is a circuit to overcome this to give the ADC the full range (in this case 0..3.3V) even though the range of the potentiometer is well inside this. The design process is very easily done following this app note:sloa097.pdf 230.01K 12 downloads I've done a spreadsheet to make it even easier!Scale Offset.zip 2.45K 9 downloads If you don't have MS Excel, you can use it with free tools Google Docs, or Open Office. To use the speadsheet you enter numbers into the blue fields. The input range at the top as measured on your pot. In preparing the examples, I played with the value of Rg2 so that Rg2+R1 came close to 10k. This allowed to replace them with a 10k trimpot as in the example circuits. It was just as well, as the trimpot did require some tweaking away from the calculated values, I found. I chose LM324 op amp as it's output goes down very close to 0V. It's maximum possible output with a Vcc=5V is about 3.5V which should be quite safe with a 3.3V Core ADC such as LPC17 MBHP Core. There are 4 op amps in this device, so 4 scaling/offset circuits can be implemented with 1 chip. Here's the circuit with 2 worked examples: Here's the test (input on left, output on right) showing 3 points (Modwheel example): Here's another test (input on left, output on right) showing 3 points (Pitchbender example):

Actually I'll probably exchange LCD#24 from a 16x20 to a 20x2, then simply swap E1 and E24. I can then just adjust the m4 lookup definitions to cater for the address change. My previous question still stands, does insertion of an SCS affect the addressing of LCDs? Will configuring the bootloader for 24 of 20x2 be o.k?

Thanks, TK! Working great, this will keep me busy for a while!

Ok, if I put a 20x2LCD on E1 and shuffle the rest of the E along 1 position, are the LCDs 2..25 addressed by @(2:1:1) to @(25:1:1) now? And If I change my bootloader config to 25 of 20x2, that should do the trick right? (I understand where fields traverse LCDs there would be "holes", but this is easily avoided) I realise now, on such a project an SCS should have been allowed for.

I'd now like to ad an SCS (Standard Control Surface) to my big Midibox NG. SCS offers control over things I really want: change ngc files for alternative functionality change global channel and device easily etc It looks straight forward, however I'm unsure of how it will work with my display setup. Main question being: I'd like to connect a 40x2LCD to which enable line? Also: I've set up the boot loader for 24 of 2x16 LCDs how should this be changed? Below is the circuitry developed to work with the particular displays I bought on Ebay. If anyone is thinking of building a box with this many displays perhaps write to this (or another thread) as there were issues most of which are addressed by the schematic (but not all). My displays are all working perfectly.

The real fun begins! On the subject of power, USB from computer or power adaptor will power a surprisingly high number of MBHP modules (not sure about MF though). My NG project is powered from an external 5V source plugged into J2. (For use with standalone midi equipment) If you do this please take care of polarity as there is no protection! A 5V supply through the USB Socket is a safer solution of course. (I have a shottkey diode in series with J2, gives polarity protection but also a small voltage drop to solve an obscure problem with driving 24 LCD modules!)

I think examples like this should help: fwd.ngc Just combine the RECEIVER of example #3 with the SENDER of example #4. The midi protocol only allows 7 bits per data byte, some applications combine 2 to provide 14 bit values.

Folly, you at least have to take the time to write to the vArranger user forum (if no one reports it, how can it be fixed?) Such poor handling of MIDI streams by hosts is not universal (nor standard)! Based on previous posts TK is v.unlikely to add features to KB. The ongoing development is taking place with MIDIbox NG which supports keyboards and much more. I think what you want would be referred to as " an option of data thinning on controller MIDI output" Or try kpete's modification above, of course.

Have you written to vArranger forum or Support yet?

I'm having very unexpected behaviour! if ^section == 4 if ENC:67 == 0 LCD "@(24:1:1)VAL0" delay_ms 1000 elsif ENC:67 == 1 LCD "@(24:1:1)VAL1" delay_ms 1000 elsif ENC:67 == 2 LCD "@(24:1:1)VAL2" delay_ms 1000 else LCD "@(24:1:1)VAL3" delay_ms 1000 endif if BUTTON:3 != 0 exec_meta RunSection:4 else LCD "@(24:1:1)----" endif exit endif The control elements here: #Audition phrase push on push off EVENT_BUTTON id=3 fwd_id=LED:38 type=Meta meta=RunSection:4 button_mode=Toggle EVENT_ENC id= 67 hw_id= 67 range=0:3 enc_speed_mode=Slow:7 value=0 fwd_to_lcd=1 label="^c3_10" LABEL c3_10 "@(23:1:1)enc %3d" Now when ENC:67 is at value say 1, then Button 3 is pressed, the LCD display 24 shows "VAL1"..."VAL2"..."VAL3".."VAL1".."VAL2"..etc (with 1 sec pause between changes) When Button 3 is released the display counts up to VAL3 again then finally rests on "----" When ENC:67 is at value 2, and Button 3 is in active state, the LCD display 24 shows "VAL2"..."VAL3"..."VAL2"..etc (with 1 sec pause between changes) The label display for the encoder is steady and correct. It seems the value of ENC:67 read by the script is unstable like incrementing with rollover, between the selected and maximum value?

Thank for the suggestion TK, I was about to try something like this. I'll post back with what I find. The label from the EVENT_ENC that matches the value is being printed, for each position of the encoder. Doesn't that mean that if_equal condition is being met? If so then why is the meta not executed?

This is what I have tried: #Virus state dump EVENT_BUTTON id=4 fwd_id=LED:37 button_mode=OnOff type=SysEx stream="0xf0 0x00 0x20 0x33 0x01 0x00 0x30 0x00 0x40 0xf7" ###SBank Select -> Progchange -> Dump request EVENT_ENC id= 65 hw_id= 65 fwd_id=SENDER:1 fwd_to_lcd=1 chn= 1 type=CC cc=0 range=0:7 ports=1000100000001000 enc_speed_mode=Slow:4 label="^Sbanksel" EVENT_SENDER id=1 type=Meta meta=RunSection:12 ####Progchange -> Dump request EVENT_ENC id= 66 hw_id= 66 fwd_id=BUTTON:4 fwd_to_lcd=1 chn= 1 type=ProgramChange range=0:127 ports=1000100000001000 enc_speed_mode=Slow:4 label="^prgch" and the run script: if ^section == 12 delay_ms 100 LCD "@(23:1:1)trigger ENC" trigger ENC:66 LCD "@(23:1:2)trigger button" trigger BUTTON:4 exit endif Encoder 65 and 66 and button 4 work as controllers here, but there is no evidence of events being forwarded: Here's moving the Encoder 65: [10641.717] MBNG_ENC_NotifyChange(65, -1) [10641.718] [EVENT] id=ENC:65 hw_id=ENC:65 bank=0 fwd_id=SENDER:1 type=CC value=1 label=^banksel [10641.718] MBNG_EVENT_ItemReceive(1, 0) (Sender) Here's moving Encoder 66: [10774.467] MBNG_ENC_NotifyChange(66, 1) [10774.467] [EVENT] id=ENC:66 hw_id=ENC:66 bank=0 fwd_id=BUTTON:4 type=ProgramChange value=24 label=^prgch [10774.467] MBNG_DIN_NotifyReceivedValue(4, 25) [10774.468] MBNG_DOUT_NotifyReceivedValue(37, 25) It seems the notifications are generated, but not the forwarded actions themselves? Is there a simpler way to achieve the intent?

If the timestamps are in miliseconds, then you performed the sweeps, about over the the same time period (300 to 400ms), right? Then the MIDIbox KB is outputing much higher resolution (normally this is considered a good thing!). Can you see that the KB is outputing events at a rate of nearly 10X that of the Korg. I don't see a problem with KB as such. Have you tried other hosts? (there are plenty of free one's out there) I suspect vArranger could do with some improvement. You should post to their forum, or otherwise contact the developers. If you find that you discover similar (or rather equivalent) problems on other hosts, then maybe put in a feature request with TK for some kind of "data thinning" option. It's likely he wont do it for KB but he might for the Keyboard option of MIDIbox NG which uses the same hardware plus an sdcard.

I'm trying this: EVENT_ENC id= 67 hw_id= 67 fwd_to_lcd=1 type=Meta meta=RunSection:20 if_equal=0 range=0:3 enc_speed_mode=Slow:7 label="^c3_10" EVENT_ENC id= 671 hw_id= 67 fwd_to_lcd=1 type=Meta meta=RunSection:21 if_equal=1 range=0:3 enc_speed_mode=Slow:7 label="^c3_11" EVENT_ENC id= 672 hw_id= 67 fwd_to_lcd=1 type=Meta meta=RunSection:22 if_equal=2 range=0:3 enc_speed_mode=Slow:7 label="^c3_12" EVENT_ENC id= 673 hw_id= 67 fwd_to_lcd=1 type=Meta meta=RunSection:23 if_equal=3 range=0:3 enc_speed_mode=Slow:7 label="^c3_13" The different labels are printed so it seems the encoder coupling is working, but the RunSection(s) are not being executed at all. [edit] The above produces the following debug output: [11392.515] MBNG_ENC_NotifyChange(67, -1) [11392.515] [EVENT] id=ENC:67 hw_id=ENC:67 bank=0 fwd_id=DISABLED:0 type=Meta value=2 label=^c3_10 [11392.515] [EVENT] id=ENC:671 hw_id=ENC:67 bank=0 fwd_id=DISABLED:0 type=Meta value=2 label=^c3_11 [11392.517] [EVENT] id=ENC:672 hw_id=ENC:67 bank=0 fwd_id=DISABLED:0 type=Meta value=2 label=^c3_12 [11392.517] [EVENT] id=ENC:673 hw_id=ENC:67 bank=0 fwd_id=DISABLED:0 type=Meta value=2 label=^c3_13

Carefully state the experiments you perform with all relevant conditions. Then for each case, describe the results. You need to quantify your results, words like "nervous" and even "very sensitive" are vague and not helpful. Also your posts and communications are way too "terse"! (I know english is not your first language, it does not matter if you communicate faulty english, you need to explain yourself more fully (e.g use more words, carefully explain yourself), otherwise you will simply appear lazy, and this does not inspire others to help you.) Do an experiment by moving the modwheel from max to min over 1 second, then count the events generated (look at the timestamps in MIOS Studio beside each event) then compare (i.e repeat the experiment with the "good" master keyboard. Determine (ie measure) what the differences are. Do the same experiment with midi-ox monitoring the values being sent from both keyboards to vArranger. There will be a difference. Tell us precisely what you discover. Once you have replicated the "faulty" result (i.e. vArranger loses sync) and understand why this is happening (e.g event rate too high; midi buffer overflow) and can replicate the problem from a device or source other than MIDIbox KB. Then you can head over to vArranger Forum and report what you have discovered with some authority. Because you've quantified the conditions, the vArranger authors will be able to replicate the problem and fix the software.