4midiloop emu project with Midibox

[findbuddha 0]

You want to be using the BLM_SCALAR app as a base for your own software. DIN_BLM_NotifyToggle is in app.c, and is called whenever a pin changes on the BLM. TK's code is very well commented!

(I'm seeing all this in the MIOS32 section, it's a little different in the MIOS8 section but you should be able to work it out)

:)

[Rics 0]

I'm back!

In these last days i had to fix a problem with my core32 module and a character LCD, then i've some problems with my small BLM module that gave jitter because i was too smart to leave opened pins on the BLM IC's! :blush:

So i've decided to build a complete BLM module to do a complete hardware test. (As Thorsten said, "i will never do again", and i quote this for a single BLM module! so much wires! :sick: )

Ok, i've builded it, and seems that works fine, also if i've not did a complete test.

From the original module the difference is that i've not used the duo-leds, but the classic single color leds.

Pictures will explain better.

Please get schematic references here:

http://www.ucapps.de/mbhp/mbhp_blm_scalar.pdf

http://www.ucapps.de/mbhp/mbhp_blm_map.pdf

-Here's the module builded on two veroboards

On the left side the leds are connected to the R (Red) jumpers on J4 and on the right side are connected to the G (Green) jumpers on J3.

Buttons are connected to the I (Input) jumpers on J4 and all the C (Catodes) jumpers on J3.

When i connect the core32 to the USB port i get a flash on/off state only from the left leds (R.).

Now that the module is powered and no midi connection with softwares is done i try to push the buttons to see the leds behaviour:

What i get is that the left leds (R.) needs to be pushed two times to be in on-mode and pushed two times to get back in the off-mode.

Instead, the right leds (G.) go in on-mode or off-mode with a single push of the buttons.

Another thing that i've noticed is a "pre-on" state of the left led (R.) if i do an "on-off cycle" (two times push) on a right led (G.).

The corrispective first row eighth led on the left veroboard gets this "pre-on", seems like a small power comes to it.

Now that i'm using these single color leds i'm wondering if i don't have to use only one 74hc595 for the leds and connect them all or to the J3 or the J4.

To be clear, all to the Red line or all to the Green line referring to the BLM map scheme ignoring one line between red and green line, without using the last 74hc595 IC, IC4.

PS

I've forgot to mention that when then i open traktor and i map the buttons and the leds to the midi mapping setting i get the left buttons and leds working correctly, i don't need to push two times the button to have a midi message output and the leds react immediately on the output message sent by traktor.

At the moment i've tried only with the first four buttons from the left veroboard placed on the first row.

Later i will try to map all the buttons and the leds to do a complete test.

So seems that all the problems reported in the upperside are relative to BLM module when not connected via midi to other hardware or software (midi via usb).

Edited 11 Dec 2010 by Rics

[findbuddha 0]

What i get is that the left leds (R.) needs to be pushed two times to be in on-mode and pushed two times to get back in the off-mode.

Instead, the right leds (G.) go in on-mode or off-mode with a single push of the buttons.

Another thing that i've noticed is a "pre-on" state of the left led (R.) if i do an "on-off cycle" (two times push) on a right led (G.).

That would be the expected behaviour, as per the readme. As you're using single colour LEDs, you won't see (for example) the red LEDs turn green (first button press) or orange (third button press).

[Rics 0]

That would be the expected behaviour, as per the readme. As you're using single colour LEDs, you won't see (for example) the red LEDs turn green (first button press) or orange (third button press).

Yes, but i'm getting this behaviour only for the left board, not for the right one!

On the left one i've to toggle, on the right one i need only one press to get led on and one press to get the led off...

[findbuddha 0]

For the right hand (green LEDs), you'll get the first button press (green), you won't get the second button press (red), you'll get half of the third button press (should be orange but you'll get green as it's just a single LED)

[Rics 0]

For the right hand (green LEDs), you'll get the first button press (green), you won't get the second button press (red), you'll get half of the third button press (should be orange but you'll get green as it's just a single LED)

Ah ok, that's clear now!

I'll check the code to adapt it for the single color leds in the next days. I hope to have success with not so much questions here in the forum. :blush:

[Rics 0]

Well, i've not adapted the code, but to have an immediate check i've switched to a single 74HC595 and switched the left board red line to the other board green line as reported on the BLM schematic.

Now both the beards, left and right, works in the same way.

The code adapt will be done later as adviced from Thorsten:

For your usecase, just remove the code inside DIN_BLM_NotifyToggle() and APP_MIDI_NotifyPackage(), and add your own button/led handler

What i don't get yet is that "pre-on" state that i've reported with the third picture in my

Seems that a small amount of current comes to corrispective leds, i mean:

**=full led on

* = small power on the led (see third picture on my )

First row of the 2 boards (Left and Right, all connected to the Green control line with 74HC595):

L1 L2 L3 L4 L5 L6 L7 L8 R1 R2 R3 R4 R5 R6 R7 R8

**____________________*_______________________

If i switch-on another Led, eg L6, R6 will have that small amount of power.

And so on for the other leds and belower leds rows.

That's all at the moment about leds, i hope that's something related to the code adapt that i've to do.

Then i've tried to connect in chain, after the BLM module, a DIN module with an Encoder.

I've did as Thorsten said in the first reply of this thread:

adding software handlers for encoders and pots isn't a big task, this would just be a 1:1 integration of existing programming examples:

http://www.ucapps.de/mios8_c.html

Obviusly with core32 i'm going to see the examples in http://www.ucapps.de/mios32_c.html

I've tried to insert into the BLM firmware both the examples #014 and #015 (one per time obviusly) but what i get, when i turn the encoders, are different midi note messages on different midi channels.

That's a small list of the output in mios_studio when i turn the encoder one time to the left and one time to the right:

[3354.074] 94 0e 7f

[3354.084] 95 0e 7f

[3354.094] 96 0e 7f

[3354.104] 97 0e 7f

[3354.114] 94 0e 00

[3354.124] 95 0e 00

[3354.134] 96 0e 00

[3354.145] 94 06 7f

[3354.155] 95 06 7f

[3354.165] 96 06 7f

[3354.176] 97 0e 00

[3354.187] 95 06 00

[3354.198] 96 0e 7f

[3354.208] 97 0e 7f

[3354.221] 96 06 00

[3354.232] 97 0e 00

[3354.242] 94 0e 7f

[3354.252] 95 0e 7f

[3354.262] 96 0e 00

[3354.273] 94 06 00

[3354.284] 95 0e 00

[3354.298] 94 0e 00

[3354.309] 96 06 7f

[3354.319] 97 06 7f

[3354.329] 94 06 7f

[3354.339] 95 06 7f

[3354.350] 96 0e 7f

[3354.360] 97 0e 7f

[3354.370] 94 0e 7f

[3354.380] 95 0e 7f

[3355.269] 96 06 00

[3355.279] 97 06 00

[3355.289] 94 06 00

[3355.299] 95 06 00

[3355.310] 96 0e 00

[3355.320] 97 0e 00

[3355.330] 94 0e 00

[3355.340] 95 0e 00

[3355.366] 96 0e 7f

[3355.376] 97 0e 7f

[3355.386] 94 0e 7f

[3355.396] 95 0e 7f

[3355.406] 96 0e 00

[3355.416] 97 0e 00

[3355.426] 94 0e 00

[3355.436] 95 0e 00

[3355.446] 96 0e 7f

[3355.456] 97 0e 7f

[3355.466] 94 0e 7f

[3355.476] 95 0e 7f

[3355.487] 97 06 7f

[3355.498] 94 0e 00

[3355.508] 95 0e 00

[3355.518] 96 0e 00

[3355.528] 97 0e 00

[3355.543] 97 06 00

As you can see there are midi ch.5-ch.6-ch.7-ch.8, notes are always 0e and 06 and the on off messages 0 and 127.

The encoders that i'm using are the Bourns PEC11-4015F-S0024 with switch, i've connected as reported in the wiki page, A C B pins, A & B to the Digital inputs and C, the common to 5v with the switch pins connected one to the Common and one to another Digital input.

I've tried also to disconnect the switch and to put to the ground the metal shaft of the encoder, but the midi output behaviour still remain the same as reported above.

I'll try other tests today but any hint will be appreciated as ever!

Thank you! :)

Edited 14 Dec 2010 by Rics

[Rics 0]

I've investigated a bit more into the encoders area so i've decide to disconnect at the moment the BLM module and connect directly to the core32 a DIN module with one encoder connected to the first Shift register.

Used Pins are D0 D1 and D2 for the button switch.

It works perfect. Midi CC messages works flawlessy.

Ok, now i'm going to copy the code parts from Tutorial#14 and paste into the BLM_Scalar app.c file.

I reconnect the BLM module, then chained a DIN module.

After i compile the BLM_Scalar, got the .hex, uploaded to the core and now the encoder sends note values, no more CC like before. (See the previous post code snip)

The modified BLM_scalar is the following:

(i'll include here only the modified parts)

/////////////////////////////////////////////////////////////////////////////

// Local definitions

/////////////////////////////////////////////////////////////////////////////


#define PRIORITY_TASK_BLM_CHECK         ( tskIDLE_PRIORITY + 2 )

#define NUM_ENCODERS 64


/////////////////////////////////////////////////////////////////////////////

// This hook is called after startup to initialize the application

/////////////////////////////////////////////////////////////////////////////

void APP_Init(void)

{

  sysexRequestTimer = 0;

  midiDataReceived = 0;

  testmode = 1;


  // initialize all LEDs

  MIOS32_BOARD_LED_Init(0xffffffff);


  // initialize rotary encoders of the same type (DETENTED2)

  int enc;

  for(enc=0; enc<NUM_ENCODERS; ++enc) {

    u8 pin_sr = enc >> 2; // each DIN SR has 4 encoders connected

    u8 pin_pos = (enc & 0x3) << 1; // Pin position of first ENC channel: either 0, 2, 4 or 6


    mios32_enc_config_t enc_config = MIOS32_ENC_ConfigGet(enc);

    enc_config.cfg.type = NON_DETENTED; // see mios32_enc.h for available types

    enc_config.cfg.sr = pin_sr;

    enc_config.cfg.pos = pin_pos;

    enc_config.cfg.speed = NORMAL;

    enc_config.cfg.speed_par = 0;

    MIOS32_ENC_ConfigSet(enc, enc_config);

  }


  // initialize BLM_SCALAR driver

  BLM_SCALAR_Init(0);


  // initialize SysEx parser

  SYSEX_Init(0);


  // start BLM check task

  xTaskCreate(TASK_BLM_Check, (signed portCHAR *)"BLM_Check", configMINIMAL_STACK_SIZE, NULL, PRIORITY_TASK_BLM_CHECK, NULL);


}


/////////////////////////////////////////////////////////////////////////////

// This hook is called when an encoder has been moved

// incrementer is positive when encoder has been turned clockwise, else

// it is negative

/////////////////////////////////////////////////////////////////////////////

void APP_ENC_NotifyChange(u32 encoder, s32 incrementer)

{

  // toggle Status LED on each AIN value change

  MIOS32_BOARD_LED_Set(1, ~MIOS32_BOARD_LED_Get());


  // determine relative value: 64 +/- <incrementer>

  int value = 64 + incrementer;


  // ensure that value is in range of 0..127

  if( value < 0 )

    value = 0;

  else if( value > 127 )

    value = 127;


  // send event

  MIOS32_MIDI_SendCC(DEFAULT, Chn1, 0x10 + encoder, value);

}

The original BLM is here

Without the BLM Module (DIN directly connected to the core32) the encoder is working well and sends CC values using the code from C Tutorial #014. (code that then i've pasted into the BLM app.c as you can see above in the code snip).

Edited 14 Dec 2010 by Rics

[Rics 0]

Ok, i went for exclusion, i know that's the right method as i'm not laerning nothing this way, but at least i've found the origin of the problem so i can investigate on it!

I've removed the following code from the" void APP_Init(void)" section:

// start BLM check task

 xTaskCreate(TASK_BLM_Check, (signed portCHAR *)"BLM_Check", configMINIMAL_STACK_SIZE, NULL, PRIORITY_TASK_BLM_CHECK, NULL);

Deleting this i get the encoder sending CC values when a DIN module is chained after the BLM module.

If i restore this code the encoder will send Note values.

What do this section of code to change CC values to Notes for DIN Encoders?

Edited 14 Dec 2010 by Rics

[Rics 0]

Mhhm, things going interesting:

Now i've found that if i delete that BLM check task all the buttons on the BLM module will send midi CC events, no more midi Notes events.

So i've restored that code, uploaded and now i've the buttons sending midi Notes events, and also the encoder do not sends anymore CC events, but Notes events.

Accidentally i've leaved the midi Ch.1 CC024 assign in the traktor controller manager for a parameter.

So now i've the encoder sending midi Notes if i do a new midi learn and i can see that are midi notes also on the mios_studio monitor.

But the old midi Ch.1 CC024 mapped to a traktor parameter receive also messages from the encoder.

In two words:

I've the encoder that is sending midi Notes values, checked by midi learn in traktor and in the mios_studio midi events monitor.

But if i map a traktor parameter with Ch.1 CC024 this will receive data from the encoder!

I don't understand this...

[Rics 0]

Ok, back from the adventures!

I finished the controller, i've used in gig and (for my label) we did a totally "unprofessional" video to show my work.

Probably we have to change the subtititles as my friend, that did the video, got some mismatch into the translation about technical stuffs. :blush:

It was really exciting getting done this project, i was almost going to be crazy about getting done the PCB wirings...anyway, that's the video about the controller, credits for ucapps, community and all the people that helped me at the end.

Picture!

Of course it's not finished, i've problems with some leds because the pcb holes weren't done really well, anyway the BLM works great.

Last thing that i'm working on is the jitter that i've on the AIN, not really annoying when using the controller, but annoying when using midi learn functions.

I'm going to work over the deadband settings to see if i can manage it, otherwise i'll try to switch to pic-core from stm32-core to see if is something related to the deadband.

Edited 11 Dec 2011 by Rics

[Rics 0]

I've solved for the AIN jitter!

I did a mistake into the pins connections on J5A-J5B-J5C and i've correctly set the deadband on the application.

Now works flawlessy without jitter!

The bad news is that a line of buttons don't work probably by the pcb card, i've found that if i tighten the screw near that line of buttons they could work in some cases and not work in other...i've not found a solution yet about this.

Anyway at the moment i'm happy to have solved the jitter problem, the pcb fix will come in the next spare time that i'll have!

[ilmenator 36]

The bad news is that a line of buttons don't work probably by the pcb card, i've found that if i tighten the screw near that line of buttons they could work in some cases and not work in other...i've not found a solution yet about this.

This sounds like you should re-solder all solder joints on that PCB - heat up every single one, you may have broken some mechanically when fitting the board to the frontpanel.

Edit: just saw that you have one single PCB underneath that frontpanel - so it's a big task to re-solder every joint... :rolleyes: Of course, look at those that are related to buttons that don't work!

Edited 18 Jan 2012 by ilmenator

[ranger930 0]

Hi Rics,

nice job !

i would like to see more detailed pictures.

is your controller really bus powered with the all led's?

how was your frontpanel printed ?

kindly regards

ranger930

[Rics 0]

This sounds like you should re-solder all solder joints on that PCB - heat up every single one, you may have broken some mechanically when fitting the board to the frontpanel.

Edit: just saw that you have one single PCB underneath that frontpanel - so it's a big task to re-solder every joint... :rolleyes: Of course, look at those that are related to buttons that don't work!

Well, the main problem that i had is that who printed the 2-side pcb for me didn't a really good job, i had all the leds holes that were smaller than the leds pins, and also the buttons holes were too smaller.

The pcb was pricey and my uni final exam too near..so i tried the repair and try way!

This was the first time that i sent pcb file to be printed from a 3rd party service, so probably i did a mistake not evaluating some tolerance in holes size, but at the end i had to redrill all the leds holes to make leds to fit into their places and then i had also to reconnect and manually check all the vias that passed through the led pins to be sure that connections worked.

Of course when i'll have time i'll try to fix this annoying problem, it's a pity that this beast have this defeat. :(

Hi Rics,

nice job !

i would like to see more detailed pictures.

is your controller really bus powered with the all led's?

how was your frontpanel printed ?

kindly regards

ranger930

Hi, yes, it's bus powered, this thanks to the T.Klose BLM (button led matrix) module.

If i used in cascade multiple DIN and DOUT needed for that amount of leds, i had no possibilities to use only a usb connection, a power unit supply were needed because of the current consumption.

But the BLM module makes possible to save current, so i used the principle and i've adapted the scheme to my needs!

The frontpanel is a 1,5mm aluminium sheet, drilled with an industrial CNC (computer numeric control) machine from friends at their factory.

They did me as a favor and as a challenge for themselves because usually they work on smaller aluminium objects.

Both technically & cost effectively is better to do this panel in a laser cut environment with an amount of minimum 10 pieces, but for one piece, in a laser cut enviroment is too pricey, and with cnc my friends make me to pay only the used current because of their experimental process! I was lucky on this! :)

Almost all the pictures that i've did are placed in the previous posted video, if you aim to something more specific let me know, i will see to make a picture of it. ;)

Edited 22 Jan 2012 by Rics

[ilmenator 36]

Well, the main problem that i had is that who printed the 2-side pcb for me didn't a really good job, i had all the leds holes that were smaller than the leds pins, and also the buttons holes were too smaller.

...

but at the end i had to redrill all the leds holes to make leds to fit into their places and then i had also to reconnect and manually check all the vias that passed through the led pins to be sure that connections worked.

Have you done the same for the button holes?

[Rics 0]

Have you done the same for the button holes?

No, the button with a bit of strenght and after filing the pins with a scalpel fit almost well.

I've tried also to unsold and then resold this line of buttons, but without solving the problem unfurtunatelly.

[Rics 0]

Oh oh oh, forgot to reply to this thread!

I've fixed that problem, it was a pcb track fault.

 

Got back to this thread because i've seen that NI released after 4/5 years the first interesting traktor controller with waveform displays, the only interesting thing over my needs satisfied with my controller.

Would be nice to know on how to get these waveform data displayed for an MK2 of my controller.

Edited 24 Sep 2014 by Rics

[TK. 0]

Just ask NI about the communication protocol - but it might be that they want to keep it secret.

 

Best Regards, Thorsten.

[Rics 0]

Yup Thorsten, probably they will keep it secret, the only hope is about that Pioneer Nexus thing, where Traktor sent waveform and data to the Pioneer cdjs displays, but you know, big corporate can pay to have something...