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

[Siytek]

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

[DjNecro]

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 thinking about? I'll pm you my skype

[Siytek]

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!

[Siytek]

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!

[DjNecro]

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 )

[Siytek]

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 think 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.

[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

[MiL0]

to save costs and get around the potential midi bandwidth issue, what about using a teensyduino as a dedicated LCD controller?

[DjNecro]

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.

[Siytek]

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.