Traktor track name / time to LCD via MIDI! ...using Denon LCD support & Arduino

Home :: Reviews of DJ equipment :: Traktor track name / time to LCD via MIDI! ...using Denon LCD support & ArduinoReply
Traktor track name / time to LCD via MIDI! ...using Denon LCD support & Arduino
Posted on: 15.04.2011 by Lillia Mestdagh
Hi All

This has already been discussed in another thread however it was decided that it was probably a good idea to put the info in a new thread.

Firstly.... here it is in action!

http://www.youtube.com/watch?v=9gQBgCKsGgc

Here is the info I posted about how its done...

By using the MIDI outputted for the Denon HC4500. When you add a HC4500 to your list of controllers, Traktor will start to output MIDI for the track name, artist and time. Its not an option you can select in the 'add out' section in Traktor, it happens in the background as soon as you add the DN4500 controller and select a MIDI OUT port. I used the Denon MIDI sheet to get the info

Here is the sheet I used, Denon MIDI (page 7) : HC4500 MIDI Command List

As only 7 bits of the MIDI data messages are available (the first bit is used to identify the message type) and the LCD needs 8 bits of data to display a character, each character needs to be transmitted in two control change messages. The first bit is used to idenfify the message, nothing to do with LCD but will be used in your code by the MIDI IN routine. The next three bits are discarded, and the final 4 bits are used for the data. The first control change message contains the first 4 bits of the 8-bit LCD character data, and the second CC message contains the second 4 bits, so....

X000AAAA
+
X000BBBB
=
AAAABBBB

Where X is the message identifier bit, the '0s' are discarded, A is the first CC and B is the second CC.

Assuming you have Arduino sucessfully receiving MIDI CC, by loading two CC messages into cc_data1 and cc_data2 the following code is a simplified way of getting the MIDI messages to the LCD. The actual code uses bitwise (see arduino website) to join the two nibbles together and simplified looks like this...

This line shifts the first 4 bits of the first message along 4 places to make
0000AAAA into AAAA0000
lcd_nibble1 = (cc_data1 << 4);

This line takes the data from the second CC message and passes it to a variable for the LCD routine
lcd_nibble2 = cc_data2;

Now we have the following
lcd_nibble1 = AAAA0000
lcd_nibble2 = 0000BBBB

Now we need to merge the two using the bitwise OR operator...
lcd_output = lcd_nibble1 | lcd_nibble2;

so now 'lcd_output' is AAAABBBB, a complete byte which can be passed straight to the lcd.print command using the standard Arduino LCD library...
lcd.print(lcd_output);

Now this code could be better as the library will break the byte up back into nibbles to pass to the LCD using the 4-bit interface (as my design uses 4-bit connection) so when I get some time, ill most likely make a few mods to the library to save some considerable processing time! However at the moment in development, this method works great and is a good way to simply use the standard Arduino LCD library in 4 or 8 bit mode.

There is one more thing, I described how to pass the CC data to the LCD but nothing about CC numbers. The value of the CC message relates to the character but the CC number determines both the character position and identifies whether the message is the first or second nibble of data. Its all in the Denon MIDI sheet. For example....

If you (or Traktor!) wanted to display the letter 'A' in the second (of 16) character position and on the first line you would use the following...

The character 8-bit code (from Denon or Hitachi LCD datasheet) is 0100 for the first nibble and 0001 for the second nibble, so...

CC message 1 = 0001 = 1 (in decimal)
CC message 2 = 0100 = 4

From the Denon sheet, CC number 2 (0x02 in hex) represents the first nibble for the second character on the first line of the display. CC number 34 (0x22 in hex) represents the second nibble for the second character on the first line of the display, so...

CC#02 value 1
CC#34 value 4

will display the letter 'A' in the second char position on the first line. BTW Deck A will output all this info on channel 1 and Deck B will output it on channel 2... so my advice if your designing a controller with the Denon LCD system, reserve ch1 and ch2 for the LCD data!

Here is the actual code with bits removed that dont relate to the LCD (easier to understand! ), please note the MIDI channel is currently ignored but a simple if or switch statement could be included to check the channel is correct or identify whether the data is from deck A or deck B, just havent got round to doing it yet! to use this code the receiveMIDI routine is fired whenever the serial port data is read and verified to be a recognised MIDI message. The following variables must be passed to the routine...

statusType = type of message, CC, note on, note off etc...
MIDIchannel = self explanatory!
param1 = first parameter of data (for CC this would be the CC number)
param2 = second parameter of data (for CC this would be the CC value)

Code:
void receiveMIDI(byte statusType, byte MIDIchannel, byte param1, byte param2){

  switch (statusType) {

    break;
    case 0xB0:
    ///// IF MESSAGE IS CONTROL CHANGE MESSAGE (0xB0) /////

    switch(param1){ // CHECKS CC NUMBER, MSB GETS PUT IN tn_byte1
      
     case  0x01:
           tn_byte1 = (param2 << 4);
     break;
     case  0x02:
           tn_byte1 = (param2 << 4);
     break;
     case  0x03:
           tn_byte1 = (param2 << 4);
     break;
     case  0x04:
           tn_byte1 = (param2 << 4);
     break;
     case  0x05:
           tn_byte1 = (param2 << 4);
     break;
     case  0x07:
           tn_byte1 = (param2 << 4);
     break;
     case  0x08:
           tn_byte1 = (param2 << 4);
     break;
     case  0x09:
           tn_byte1 = (param2 << 4);
     break;
     case  0x21: // BEGIN LSB, MSB IS READY IN tn_byte1
      tn_byte2 = param2;
      tn_output = tn_byte1 | tn_byte2;
      track_name(0 , 0 , tn_output); // FIRES LCD PRINT WITH CO-ORDS AND CHAR DATA          
     break;
     case  0x22:
      tn_byte2 = param2;
      tn_output = tn_byte1 | tn_byte2;
      track_name(1 , 0 , tn_output);      
     break;
     case  0x23:
      tn_byte2 = param2;
      tn_output = tn_byte1 | tn_byte2;
      track_name(2 , 0 , tn_output);
     break;
     case  0x24:
      tn_byte2 = param2;
      tn_output = tn_byte1 | tn_byte2;
      track_name(3 , 0 , tn_output);
     break;
     case  0x25:
      tn_byte2 = param2;
      tn_output = tn_byte1 | tn_byte2;
      track_name(4 , 0 , tn_output);
     break;
     case  0x27:
      tn_byte2 = param2;
      tn_output = tn_byte1 | tn_byte2;
      track_name(5 , 0 , tn_output);
     break;
     case  0x28:
      tn_byte2 = param2;
      tn_output = tn_byte1 | tn_byte2;
      track_name(6 , 0 , tn_output);
     break;
     case  0x29:
      tn_byte2 = param2;
      tn_output = tn_byte1 | tn_byte2;
      track_name(7 , 0 , tn_output);
     break;
      
    }

}

}

void track_name(byte lcd_col, byte lcd_row, byte lcd_data){
  
      lcd.setCursor(lcd_col , lcd_row);
      lcd.print(lcd_data); 
  
  
}
enjoy

Here is the post about the board itself and the spec im aiming to achieve...

* Arduino based design using ATMega168 (or 328) with on-board MIDI I/O port
* 48 Analogue / Digital inputs or outputs (6 ports with 8 pins, each can be either I or O) by use of on-board multiplexers
* Built-in twin 8-LED bargraph VU meter, controlled by MIDI CC
* 8x2 (or 16x2 if you want) LCD display
* Menu system allows for changes without reprogramming, so Arduino is optional, the MIDI config can be changed with the LCD menu
* Supports the display of Traktor track name, artist and time on the LCD display (Uses/hijacks the data Traktor sends out for the Denon HC4500 LCD display)

There is no built-in FTDI chip like there is with the Arduino boards however there is a connector for an FTDI programmer, I use the Modern Device USB-BUB, http://shop.moderndevice.com/products/usb-bub, the little red board shown in my picture below

Im keen to get some feedback about whether peeps are interested in this kind of product aimed specifically at Traktor or Ableton. This is only a prototype board meant for testing all the features, so it looks a bit of a mess! Please excuse rubbish mobile phone camera pictures too!





Nathanael Yerk
22.10.2012
Originally Posted by fullenglishpint
Yeh, add out > deck common > play/pause.
Yeah I figured it. Thanks anyways.
Lillia Mestdagh
27.02.2012
Originally Posted by thatdjdjkid
So how easy would it be to port the string information coming out of the denon driver into osc to send track titles to touchosc or lemur? because that would be awesome.
The data produced by Traktor for the Denon is all MIDI so I would have thought this would be quite straight forward given the right tools. The MIDI data could be passed out of Traktor over a 'virtual MIDI cable' to a program which could convert the data to OSC. This program would also need to be able to convert the MIDI bytes into a format which controlled a display over OSC. I have not had any time to experiment with Max for Live yet, but I believe this program is the kind of thing you would need to use to achieve this.
Lillia Mestdagh
27.02.2012
Originally Posted by MiL0
bump - anyone made any more progress with this?
I have been meaning to come out of hibernation! lol I have been very busy with my new career as a PCB frontend engineer so not had as much time to work on music tech stuff as I have been used to in the past.

I have put Arduino to one side temporarily, I have been developing with PIC and C more recently and now have a working USB MIDI core design. After manufacturing my first Arduino design (01M) I decided that I just couldn't move forward without being able to add USB to my designs. I have not abandoned Arduino, I have just developed a way to add full speed USB MIDI to any of my projects The chip I have been working with is a PIC8F4550 (same as the one on the CUI board). Although I could now theoretically add USB MIDI to Arduino with my recent project, im not sure if it is 'ethically' right to use AVR and PIC in one design!!

So with regards to the Denon LCD MIDI project, I would hope that utilising full speed USB MIDI (no UART emulation / FTDI chip) could iron out some of the issues we were having.

Im currently working some really exciting projects and will no doubt return to the community s in the near future when I have some new and exciting developments to discuss
Louisa Oberc
27.04.2011
Originally Posted by MiL0
to save costs and get around the potential midi bandwidth issue, what about using a teensyduino as a dedicated LCD controller?
That's what I would do... the teensy would handle the lcd's and the LED's.
Lillia Mestdagh
27.04.2011
Originally Posted by Siytek
1152 * 6 = 6912 bits to move track and artist within the given second
24 bits to change minutes
24 bits to change seconds
100 * 24 bits to change frames (as 100 frames count over in 1 second)

= 9360 bits are required maximum to update all information over the period of one second

9360 x 2 = 18,720 bits for both decks

18,720 / 31250 * 100 = 59.9% of the MIDI bandwidth taken up.

EDIT: If artist/track move 3 times a second (closer approximation) then .... 11,808 / 31250 * 100 = 37.78% of the MIDI bandwidth taken up.
Think I should have taken in to account the start and stop bits too. This makes each MIDI message 10-bit instead of 8, so a full MIDI message requires 30 bits, not 24 so the bandwidth required to change track, artist, minutes, seconds and frames over the period of 1 second is (note: based upon DjNecro's estimation of about 2.5 movements per second, this calculation roughly estimates the LCD scrolling to happen about 3 times a second)...

12 chars for title * 60 bits (2 MIDI messages)
12 chars for artist * 60 bits (2 MIDI message)
= 1440 bits to display track and artist * (about) 3 movements a second = 4320 bits
Minutes = 30 bits
Seconds = 30 bits
100 frames per second * 30 = 3000 bits

= 7380 bits total * 2 decks
= 14,760 bits total

14,760 / 31250 * 100 = 47.23% MIDI bandwidth used
Lillia Mestdagh
18.04.2011
Originally Posted by DjNecro
Likely due to cost issues with regards to the 20meg crystal... Also, wouldn't your timing be seriously altered if you ran the same sketch from an atmega running at 16meg on one running at 20?

I have had zero issues so far chaining three controllers together with the head controller receiving and passing through the signals from two different midi sources. Each one has at least 2 or 3 varying multiplexers (4051's 21's 595's etc).

The only time I have encountered issues is when I try my first ever controller that has a hacked apart synaptics touchpad built into it and two rotary encoders. If I enable the touchpad (which uses the ps2 protocol) it causes the encoders to become a little jittery... I'm sure there's a way (either in hardware or software) to work around it, but I haven't really bothered taking it any further since I don't really use the xypad that much right now...

My ideal controller will have one per deck, so I'm going to have to figure it out eventually

I've seen that .net board.. but the first time i saw the ".NET" part, I kinda threw up in my mouth a little... I have a deep down hate of any and all msft products and use them as little as i can (heh, that's coming from a IT admin managing a couple dozen ms servers )
Yeh I agree dude! microsoft sucks and I dont use anything made by them! I wouldn't go with a .NET system, just liked the look of the hardware spec.

Glad to hear your not having probs with the MIDI. Although it seems like a bit of a mission to sort out the problem with the processing for the LCD, it would probably be worse if it was a MIDI speed issue though as the only resolution would be to design a system from the ground up and run USB-MIDI to get a higher speed.

Yeh I believe you would defo encounter timing problems using a 20Mhz xtal. I believe you can recompile the Arduino bootloader to accept a 20Mhz xtal but you get some timing issues with things like delay(x); ..I was more wondering why Arduino didnt just write the bootloader and programming environment for 20Mhz in the first place. As you say cost could very well be the issue of cost.
Louisa Oberc
18.04.2011
Originally Posted by Siytek
I know its not a great leap in performance but I dont know why Arduino dont use 20Mhz clock speeds as the ATMega is capable!
Likely due to cost issues with regards to the 20meg crystal... Also, wouldn't your timing be seriously altered if you ran the same sketch from an atmega running at 16meg on one running at 20?

I have had zero issues so far chaining three controllers together with the head controller receiving and passing through the signals from two different midi sources. Each one has at least 2 or 3 varying multiplexers (4051's 21's 595's etc).

The only time I have encountered issues is when I try my first ever controller that has a hacked apart synaptics touchpad built into it and two rotary encoders. If I enable the touchpad (which uses the ps2 protocol) it causes the encoders to become a little jittery... I'm sure there's a way (either in hardware or software) to work around it, but I haven't really bothered taking it any further since I don't really use the xypad that much right now...

My ideal controller will have one per deck, so I'm going to have to figure it out eventually

I've seen that .net board.. but the first time i saw the ".NET" part, I kinda threw up in my mouth a little... I have a deep down hate of any and all msft products and use them as little as i can (heh, that's coming from a IT admin managing a couple dozen ms servers )
Lillia Mestdagh
18.04.2011
Originally Posted by DjNecro
I'm not nearly as worried about the midi bandwidth as much as I'm worried about available cpu cycles... We only have 16mhz with the arduinos I'd love to get into the better and faster pic's and even the maple processor which runs at a 'blazing' 72mhz... (http://leaflabs.com/devices/maple/)
Funny you should mention that, I got a news letter from cool components earlier and was looking at this...

http://www.coolcomponents.co.uk/cata...m_medium=email

The Fez Panda II using a 72Mhz ARM processor. It made me wonder about stepping up to a higher performance chip.

I know its not a great leap in performance but I dont know why Arduino dont use 20Mhz clock speeds as the ATMega is capable!
Lillia Mestdagh
18.04.2011
Originally Posted by MiL0
Siytek - this was the site I was talking about for low run PCB manufacturing:

http://dorkbotpdx.org/wiki/pcb_order

It costs $5 per square inch (2 layer, 3 pcbs per order included in price)

You reckon you could get the Arduino(s) talking to Traktor via midi over usb? That would be some achievement because afaik, this is notoriously difficult (especially with the older 1280 atmel's). Good luck!

Oh and I might hit you up on Skype this week to discuss an idea I had regarding all of this stuff
Sweet! Had a look at that PCB manufacturing, looks pretty good. I have had a look at a few companies in China but that seems like an easier way to get a one off made or a small run.

I have not looked at the USB in great detail yet, its a future project though. I want to start with making a USB MIDI interface utilising the class compliant driver first. I have also been looking at the possibility of tweaking the descriptors within the FTDI to make it appear as a MIDI device, aliasing the baud rate seems possible too for 31250 but to fully understand this im going to have to learn what I would have to know to making something from scratch with an MCU anyway! It would be nice to be able to offer a USB-MIDI shield for Arduino that can offer the full benefit of USB-MIDI speeds, virtual cables and still leave the UART open so the Arduino could function as a USB to MIDI interface too.

Yeh defo up for some Skype at some point, keen to discuss ideas. Im hectic this week, still working on the live set every day and I got three gigs this week too so if not this week then defo next!
Lillia Mestdagh
19.04.2011
Originally Posted by steffanko
So, I have no idea what you guys are doing, cuz Im a noob to electronics, but I have seen something similar in this vid. Traktor is sending song names to dns1200 display. Don't know how...

http://www.youtube.com/watch?v=vEP3GLTrlvU
Hi steffanko

Basically what we have achieved is we have 'hi-jacked' the MIDI data Traktor sends out in order to get track names and artist names to appear on Denon (DN4500 compatible) decks so we can get this info on the displays of our own custom MIDI controllers. We use Arduino with MIDI capability to capture this information that is intended for the Denon, and display it on our own LCD screens
Caridad Fan
02.01.2013
Still trying to figure this out to use with my teensy... Not getting it!
Nathanael Yerk
22.10.2012
Originally Posted by fullenglishpint
Yeh, add out > deck common > play/pause.
Yeah I figured it. Thanks anyways.
Tatum Ansaldo
21.10.2012
Yeh, add out > deck common > play/pause.
Nathanael Yerk
13.10.2012
Can Traktor output deck playing/deck not playing info? I'm building my own MIDI controller and I've got LED indicator on the play button so if I could somehow get info about when the track stopped playing I would turn that LED off.

Sorry for bumping btw.
Arcelia Siebeneck
30.03.2012
good to see you back on the community s man... you and djnecro made some really interesting threads/posts... this place is kinda boring nowadays
Lillia Mestdagh
27.02.2012
Originally Posted by thatdjdjkid
So how easy would it be to port the string information coming out of the denon driver into osc to send track titles to touchosc or lemur? because that would be awesome.
The data produced by Traktor for the Denon is all MIDI so I would have thought this would be quite straight forward given the right tools. The MIDI data could be passed out of Traktor over a 'virtual MIDI cable' to a program which could convert the data to OSC. This program would also need to be able to convert the MIDI bytes into a format which controlled a display over OSC. I have not had any time to experiment with Max for Live yet, but I believe this program is the kind of thing you would need to use to achieve this.
Lillia Mestdagh
27.02.2012
Originally Posted by MiL0
bump - anyone made any more progress with this?
I have been meaning to come out of hibernation! lol I have been very busy with my new career as a PCB frontend engineer so not had as much time to work on music tech stuff as I have been used to in the past.

I have put Arduino to one side temporarily, I have been developing with PIC and C more recently and now have a working USB MIDI core design. After manufacturing my first Arduino design (01M) I decided that I just couldn't move forward without being able to add USB to my designs. I have not abandoned Arduino, I have just developed a way to add full speed USB MIDI to any of my projects The chip I have been working with is a PIC8F4550 (same as the one on the CUI board). Although I could now theoretically add USB MIDI to Arduino with my recent project, im not sure if it is 'ethically' right to use AVR and PIC in one design!!

So with regards to the Denon LCD MIDI project, I would hope that utilising full speed USB MIDI (no UART emulation / FTDI chip) could iron out some of the issues we were having.

Im currently working some really exciting projects and will no doubt return to the community s in the near future when I have some new and exciting developments to discuss
Arcelia Siebeneck
27.02.2012
bump - anyone made any more progress with this?
Maida Vorenkamp
07.12.2011
So how easy would it be to port the string information coming out of the denon driver into osc to send track titles to touchosc or lemur? because that would be awesome.
Lillia Mestdagh
03.05.2011
After some further testing, I am finding issues with the standard MIDI baud rate. Although the bandwidth is sufficient to deliver the messages there is still quite a lot of it taken and a noticable delay in certain messages. There is a slight pause in the 'frames' counter when displaying track time, which I believe happens when the messages to move the LCD text are sent. The Denon HC4500 would be connected with USB-MIDI running at USB data transfer rate so this would not be a problem in the case of Traktor to Denon, however using the standard MIDI baud rate just doesnt seem quick enough. Even though all the messages get delivered, when you send constant MIDI data streams (such as MIDI clock, VU meter and frames) delays happen when additional messages (such as moving LCD text) are sent. The solution I believe would have to be a seperate processor for the LCD which coupled via USB-MIDI. This chip could receive the LCD data and display it, then pass and MIDI data not related to the LCD out of the USART at 31250 bps so would double up as an internal USB to MIDI interface for Traktor controller projects as well as the LCD controller.

Teensy seems like a good idea as it has a direct USB connection running at full speed and not a USB-to-serial FTDI type sollution which is limited to the slower USART speed, it would be a great board to start working with that has capability of utilizing the USB-MIDI class compliant driver plus its USART is free to use so it could function as the LCD controller and internal USB-MIDI interface at the same time, its just a shame its not open source, I would rather design my own host board from scratch.
Louisa Oberc
27.04.2011
Originally Posted by MiL0
to save costs and get around the potential midi bandwidth issue, what about using a teensyduino as a dedicated LCD controller?
That's what I would do... the teensy would handle the lcd's and the LED's.
Arcelia Siebeneck
27.04.2011
to save costs and get around the potential midi bandwidth issue, what about using a teensyduino as a dedicated LCD controller?
Lillia Mestdagh
27.04.2011
Originally Posted by Siytek
1152 * 6 = 6912 bits to move track and artist within the given second
24 bits to change minutes
24 bits to change seconds
100 * 24 bits to change frames (as 100 frames count over in 1 second)

= 9360 bits are required maximum to update all information over the period of one second

9360 x 2 = 18,720 bits for both decks

18,720 / 31250 * 100 = 59.9% of the MIDI bandwidth taken up.

EDIT: If artist/track move 3 times a second (closer approximation) then .... 11,808 / 31250 * 100 = 37.78% of the MIDI bandwidth taken up.
Think I should have taken in to account the start and stop bits too. This makes each MIDI message 10-bit instead of 8, so a full MIDI message requires 30 bits, not 24 so the bandwidth required to change track, artist, minutes, seconds and frames over the period of 1 second is (note: based upon DjNecro's estimation of about 2.5 movements per second, this calculation roughly estimates the LCD scrolling to happen about 3 times a second)...

12 chars for title * 60 bits (2 MIDI messages)
12 chars for artist * 60 bits (2 MIDI message)
= 1440 bits to display track and artist * (about) 3 movements a second = 4320 bits
Minutes = 30 bits
Seconds = 30 bits
100 frames per second * 30 = 3000 bits

= 7380 bits total * 2 decks
= 14,760 bits total

14,760 / 31250 * 100 = 47.23% MIDI bandwidth used
Lillia Mestdagh
18.04.2011
Originally Posted by DjNecro
Likely due to cost issues with regards to the 20meg crystal... Also, wouldn't your timing be seriously altered if you ran the same sketch from an atmega running at 16meg on one running at 20?

I have had zero issues so far chaining three controllers together with the head controller receiving and passing through the signals from two different midi sources. Each one has at least 2 or 3 varying multiplexers (4051's 21's 595's etc).

The only time I have encountered issues is when I try my first ever controller that has a hacked apart synaptics touchpad built into it and two rotary encoders. If I enable the touchpad (which uses the ps2 protocol) it causes the encoders to become a little jittery... I'm sure there's a way (either in hardware or software) to work around it, but I haven't really bothered taking it any further since I don't really use the xypad that much right now...

My ideal controller will have one per deck, so I'm going to have to figure it out eventually

I've seen that .net board.. but the first time i saw the ".NET" part, I kinda threw up in my mouth a little... I have a deep down hate of any and all msft products and use them as little as i can (heh, that's coming from a IT admin managing a couple dozen ms servers )
Yeh I agree dude! microsoft sucks and I dont use anything made by them! I wouldn't go with a .NET system, just liked the look of the hardware spec.

Glad to hear your not having probs with the MIDI. Although it seems like a bit of a mission to sort out the problem with the processing for the LCD, it would probably be worse if it was a MIDI speed issue though as the only resolution would be to design a system from the ground up and run USB-MIDI to get a higher speed.

Yeh I believe you would defo encounter timing problems using a 20Mhz xtal. I believe you can recompile the Arduino bootloader to accept a 20Mhz xtal but you get some timing issues with things like delay(x); ..I was more wondering why Arduino didnt just write the bootloader and programming environment for 20Mhz in the first place. As you say cost could very well be the issue of cost.
Louisa Oberc
18.04.2011
Originally Posted by Siytek
I know its not a great leap in performance but I dont know why Arduino dont use 20Mhz clock speeds as the ATMega is capable!
Likely due to cost issues with regards to the 20meg crystal... Also, wouldn't your timing be seriously altered if you ran the same sketch from an atmega running at 16meg on one running at 20?

I have had zero issues so far chaining three controllers together with the head controller receiving and passing through the signals from two different midi sources. Each one has at least 2 or 3 varying multiplexers (4051's 21's 595's etc).

The only time I have encountered issues is when I try my first ever controller that has a hacked apart synaptics touchpad built into it and two rotary encoders. If I enable the touchpad (which uses the ps2 protocol) it causes the encoders to become a little jittery... I'm sure there's a way (either in hardware or software) to work around it, but I haven't really bothered taking it any further since I don't really use the xypad that much right now...

My ideal controller will have one per deck, so I'm going to have to figure it out eventually

I've seen that .net board.. but the first time i saw the ".NET" part, I kinda threw up in my mouth a little... I have a deep down hate of any and all msft products and use them as little as i can (heh, that's coming from a IT admin managing a couple dozen ms servers )
Lillia Mestdagh
18.04.2011
Originally Posted by DjNecro
I'm not nearly as worried about the midi bandwidth as much as I'm worried about available cpu cycles... We only have 16mhz with the arduinos I'd love to get into the better and faster pic's and even the maple processor which runs at a 'blazing' 72mhz... (http://leaflabs.com/devices/maple/)
Funny you should mention that, I got a news letter from cool components earlier and was looking at this...

http://www.coolcomponents.co.uk/cata...m_medium=email

The Fez Panda II using a 72Mhz ARM processor. It made me wonder about stepping up to a higher performance chip.

I know its not a great leap in performance but I dont know why Arduino dont use 20Mhz clock speeds as the ATMega is capable!
Lillia Mestdagh
18.04.2011
Originally Posted by MiL0
Siytek - this was the site I was talking about for low run PCB manufacturing:

http://dorkbotpdx.org/wiki/pcb_order

It costs $5 per square inch (2 layer, 3 pcbs per order included in price)

You reckon you could get the Arduino(s) talking to Traktor via midi over usb? That would be some achievement because afaik, this is notoriously difficult (especially with the older 1280 atmel's). Good luck!

Oh and I might hit you up on Skype this week to discuss an idea I had regarding all of this stuff
Sweet! Had a look at that PCB manufacturing, looks pretty good. I have had a look at a few companies in China but that seems like an easier way to get a one off made or a small run.

I have not looked at the USB in great detail yet, its a future project though. I want to start with making a USB MIDI interface utilising the class compliant driver first. I have also been looking at the possibility of tweaking the descriptors within the FTDI to make it appear as a MIDI device, aliasing the baud rate seems possible too for 31250 but to fully understand this im going to have to learn what I would have to know to making something from scratch with an MCU anyway! It would be nice to be able to offer a USB-MIDI shield for Arduino that can offer the full benefit of USB-MIDI speeds, virtual cables and still leave the UART open so the Arduino could function as a USB to MIDI interface too.

Yeh defo up for some Skype at some point, keen to discuss ideas. Im hectic this week, still working on the live set every day and I got three gigs this week too so if not this week then defo next!
Louisa Oberc
19.04.2011
Phewww Too much math I just checked my display and it moves 20 segments to the left every 8 seconds... (2.5 segments per second).

I'm not nearly as worried about the midi bandwidth as much as I'm worried about available cpu cycles... We only have 16mhz with the arduinos I'd love to get into the better and faster pic's and even the maple processor which runs at a 'blazing' 72mhz... (http://leaflabs.com/devices/maple/)

..Mil0, what sort of ideas are you believeing about? I'll pm you my skype
Lillia Mestdagh
19.04.2011
Originally Posted by steffanko
So, I have no idea what you guys are doing, cuz Im a noob to electronics, but I have seen something similar in this vid. Traktor is sending song names to dns1200 display. Don't know how...

http://www.youtube.com/watch?v=vEP3GLTrlvU
Hi steffanko

Basically what we have achieved is we have 'hi-jacked' the MIDI data Traktor sends out in order to get track names and artist names to appear on Denon (DN4500 compatible) decks so we can get this info on the displays of our own custom MIDI controllers. We use Arduino with MIDI capability to capture this information that is intended for the Denon, and display it on our own LCD screens
Clay Lorow
18.04.2011
So, I have no idea what you guys are doing, cuz Im a noob to electronics, but I have seen something similar in this vid. Traktor is sending song names to dns1200 display. Don't know how...

http://www.youtube.com/watch?v=vEP3GLTrlvU
Lillia Mestdagh
18.04.2011
Just pondering a few numbers with regards to my last post about USB-MIDI and baud rates, I realise this may be basic stuff to some but thought I would post it here just incase it was beneficial to anyone. I have done a few calculations related to the amount of bandwidth the LCD MIDI setup might take from a serial MIDI data stream, here are my findings
Arcelia Siebeneck
18.04.2011
Originally Posted by photojojo
Mind if I get OT for a minute? Can any of you smart people help me with this?

http://djranking s.com/community /showthr...ktor+text+file
That's possible using the Autohotkey script I'm writing (thanks to djnecro and siytek for working out all the tricky bits). So far, I've got a Windows exe that acts sits between Traktor and your controller and reads the artist/track name (endlessly! see the 'bugs' above). This information could easily be written to a text file. Can I ask what you intend to do with this text afterwards? It might help me to customise the script to better suit you.

Two disadvantages:

- It requires Windows (no AHK support on MacOSX)
- It requires a virtual midi input, rather than being plug'n'play
Leeanna Ayla
18.04.2011
Mind if I get OT for a minute? Can any of you smart people help me with this?

http://djranking s.com/community /showthr...ktor+text+file
Lillia Mestdagh
18.04.2011
The percentage track position gave me an idea actually... what about mounting a softpot potentiometer just above or below the LCD? Like this:
Defo good idea MiL0 I was believeing about adding a little header to the board (next to the LCD header) which could accept some kind of menu key / pot inputs, the user could then choose their own pot / buttons for menu control
Arcelia Siebeneck
18.04.2011
Siytek - this was the site I was talking about for low run PCB manufacturing:

http://dorkbotpdx.org/wiki/pcb_order

It costs $5 per square inch (2 layer, 3 pcbs per order included in price)

You reckon you could get the Arduino(s) talking to Traktor via midi over usb? That would be some achievement because afaik, this is notoriously difficult (especially with the older 1280 atmel's). Good luck!

Oh and I might hit you up on Skype this week to discuss an idea I had regarding all of this stuff
Lillia Mestdagh
18.04.2011
Nice! I like the way you managed to calculate the remaining time!

I have just been doing some reading about the MIDIStreaming subclass with intentions to hopefully develop my own USB connectivity in the future and have discovered some interesting stuff...

It turns out that USB-MIDI never emulates the serial MIDI baud rate of 31250bps. The basic principal is something like this... the MIDI bytes are encapsulated with an additional USB header byte to make a 32-bit packet of data which is transferred over USB at the USB connection speed and passed to the USB input of the MCU on the other end (MCU with USB input necessary). The MIDI bytes can then be manipulated as you choose within the code.

So even by the USB 1.1 standard at 12Mb, USB-MIDI information is being transmitted at just over 50 times the speed of standard serial MIDI!

When Denon setup their hardware to accept MIDI to control the LCD, as we discussed before it seems a bit stupid to have to receive all that data constantly to display information on the screen. It would seem better to send the track name and artist over MIDI with a start and end marker, as DjNecro mentioned in an earlier post, which could then be loaded in to the Denon and the Denon could handle the display including the scrolling.

When you believe about it though, having the LCD set up in the way which they have done it has a plus side too, the host software can have complete control over what is displayed on the screen rather than be bounded by the Denon displaying info in a certain way. In terms of 31,250bps, it takes quite a lot of bandwidth to deliver this information but when we are talking USB speed its no prob at all!

Im not sure if this poses a problem, DjNecro your screen seems to be running nice and smooth with a standard MIDI connector, but this thought on USB does kind of answer why the Denon LCD MIDI stuff works in the way they have set it up!

Arcelia Siebeneck
18.04.2011
Good work man

The percentage track position gave me an idea actually... what about mounting a softpot potentiometer just above or below the LCD? Like this:

http://www.sparkfun.com/products/8607

If the softpot is the same length as the LCD display then it could be used to interact with the LCD in interesting ways. For example, as a touch pad to quickly scroll through the track. When the softpot is touched, the LCD changes mode, displaying the current track position (like this perhaps: [0--------||-----99]. It could also be used as a filter, eq or effects control parameter (all with visual queues from the LCD display).

Only problem is that the softpots are a bit pricey
Louisa Oberc
18.04.2011
Here's what I came up with... It will decode the track title and artist name, as well as the minute, second, track position (in percent). It also calculates the total track length every 20 seconds. It's not 100% accurate, but it's the best we have

The example video shows it rotating between the artist/track and a two line time display with simple bar graph. The delay between changes is currently 15 seconds.

http://www.youtube.com/watch?v=6nkZ4E0p2Nk

Note: Just want to draw attention to the fact that the decoding functions are completely independent of the MIDI code and the lcd code. While they are of course designed to decode MIDI, how you get the MIDI messages to the functions is up to you

Code:
#include <WProgram.h>
#include <LiquidCrystal.h>
#include <Midi.h>

struct DENON_SEGMENT {
  boolean valid;
  byte seg;
  byte col;
  byte val;
};

struct DENON_TIME {
  boolean valid;
  byte minute;
  byte sec;
  byte pos;
  byte totMin;
  byte totSec;
  
};

LiquidCrystal lcd(8, 11, 9, 4, 5, 6, 7); // initialize the library with the numbers of the interface pins

class MyMidi : public Midi {
  public:

  MyMidi(HardwareSerial &s) : Midi(s) {}

  void handleControlChange(unsigned int channel, unsigned int controller, unsigned int value) {
    if (channel == 1 || channel == 2) {
      DENON_SEGMENT segData = checkForSegmentData(controller, value);
      DENON_TIME timeData = checkForTimeData(controller, value);
      static unsigned long curTime, prevTime = 0;
      static boolean flip = false;
      
      curTime = millis();
      if (curTime - prevTime > 15000) {
        prevTime = curTime;
        flip = !flip;
        lcd.clear();
      }

      if (segData.valid == true && flip == false) track_name(segData.seg, segData.col+2, segData.val); // col+2 to center it on my 2x16 screen (the denon only has a 2x12)
      if (timeData.valid == true && flip == true) updateTime(timeData.minute, timeData.sec, timeData.pos, timeData.totMin, timeData.totSec);
    }
  }
};

MyMidi midi(Serial);

void setup() {
  lcd.begin(2, 16);
  digitalWrite(14, HIGH);
  midi.begin(0);
}

void loop() {
  midi.poll();
}

struct DENON_TIME checkForTimeData(byte controller, byte value) {
  static byte minute, second, pos, totMin, totSec, lastSecond;
  static float tot = 0;
  
  if (controller >= 0x40 && controller <= 0x49) {
    if (controller == 0x42) {
      minute = value;
    } else if (controller == 0x43) {
      second = value;
    } else if (controller == 0x48) {
      pos = value;
      if (second != lastSecond) {
        if (second % 20 == 0) {
          tot = ((minute*60)+second) / ((float)pos / 100);
          totMin = tot/60;
          totSec = (int)tot%60;
        }
        lastSecond = second;
        return (DENON_TIME){true, minute, second, pos, totMin, totSec};
      }
    }
  }
  return (DENON_TIME){false,0,0,0};
}

struct DENON_SEGMENT checkForSegmentData(byte controller, byte value) {
  static byte seg1MSB, seg2MSB = 0;
  if ((controller >= 0x01 && controller <= 0x05) || (controller >= 0x07 && controller <= 0x0D)) { // segment 1 MSB
    seg1MSB = value;
  } else if (controller >= 0x0E && controller <= 0x19) { // segment 2 MSB
    seg2MSB = value;
  } else if ((controller >= 0x21 && controller <= 0x25) || (controller >= 0x27 && controller <= 0x2D)) { // segment 1 LSB
    return (DENON_SEGMENT){true, 0, getColumn(controller, 1), ((seg1MSB<<4) + value)}; // return completed packet
  } else if (controller >= 0x2E && controller <= 0x39) { // segment 2 LSB
    return (DENON_SEGMENT){true, 1, getColumn(controller, 2), ((seg2MSB<<4) + value)}; // return completed packet
  }
  return (DENON_SEGMENT){false,0,0,0}; // incomplete packet
}

// parameters: cc- controller number, seg- segment number
// returns: column number (zero indexed) or 255 if invalid segment
byte getColumn(byte cc, byte seg) {
  byte col=255;
  if (seg == 1) {
    col = cc - 33; // convert into segment number (column)
    if (col >= 6) col--; // work around the fact that Denon skipped 0x06 for segment 1-6 (they got segment 2 correct)
  } else if (seg == 2) {
    col = cc - 46; // convert into segment number (column)
  }
  return col;
}

void track_name(byte lcd_row, byte lcd_col, byte lcd_data){
  lcd.setCursor(lcd_col, lcd_row);
  lcd.print(lcd_data); 
}

void updateTime(byte minute, byte sec, byte pos, byte totMin, byte totSec) {
  char one[17], two[17] = {};

  strcat(two, "|");
  for (byte i=1;i<=14;i++) {
   if (i <= map(pos, 0, 100, 0, 14)) strcat(two,"#");
   else strcat(two, " ");
  }
  strcat(two, "|");

  sprintf(one, "R:%02i:%02i  T:%02i:%02i", minute, sec, totMin, totSec);
  lcd.setCursor(0, 0);
  lcd.print(one);
  lcd.setCursor(0, 1);
  lcd.print(two);
}
Lillia Mestdagh
17.04.2011
Some great findings guys, Iv been smiling at the idea of a twin processor project all weekend!

Just one thing to add further to DjNecro's findings with the MIDI OUT stuff...

'MIDI OUT > Output > Track End Warning' outputs CC every time you load a new track in whether it be right click and load, or drag and drop, the only problem is it also outputs the same message when the play point crosses the '30 seconds left' boundary, if you skip the play point before and after the 30 second left point this message is outputted whether the track is playing or not. I was believeing the LCD MIDI could be checked for new data if this message was received and the track was not playing, however if someone was to skip before and after the 30 second point with the track paused it would probably screw up the reading. grrr!! With what DjNecro said and what I have found there are several options that come close, but with a single quirk making it a pain!!

I personally don't believe Arduino-based scrolling in a 12 segment window is much of a problem as the remaining 4 segments could be used for other things (like time or a deck indicator)
I was believeing about having something like...

A> TRACK NAME
TRACK NAME <B

...so I agree the 12 seg thing wont be a prob


All it would have taken would be to send one command to indicate the start of the string, then send each character in order one by one, and one more command to indicate the end of the string... SIMPLE!!!
Agreed agreed agreed! Anoying isnt it!

Im gonna have a believe a bit more about the final spec of my board design, defo got me believeing what has been said on here which is great, and part the reason I got involved on here so thanks again guys for giving me inspiration!
Louisa Oberc
17.04.2011
Yeah man I have no idea who to even blame... Did Denon set their controllers up so that they can only deal with the data like this? Which is how it seems to be since they have commands for specific VFD segments... All it would have taken would be to send one command to indicate the start of the string, then send each character in order one by one, and one more command to indicate the end of the string... SIMPLE!!!

But yeah... with the available room in most larger controllers, and the cost of the extra atmega hardware (my custom 'arduino' cost less than $10 CDN (~

<< Back to Reviews of DJ equipment Reply

Copyright 2012-2023
DJRANKINGS.ORG n.g.o.
Chuo-ku, Osaka, Japan

Created by Ajaxel CMS

Terms & Privacy