First Midibox project

[Triffki]

Hi all

I’ve wanted to get stuck into building a Midi controller for a few months now, and it looks like the Midibox64 is my safest bet. A few long sessions of browsing through uCApp have given me enough background knowledge to start visualising an end product.

I intend to use the device primarily as a mirror-mapped controller for Traktor; allowing me to control as many features in the software as possible. The majority of inputs will be buttons, but there should be a healthy selection of pots aswell for knobs and faders. Ideally, most of the buttons will have LEDs next to them to indicate their current state. I’m not fussed about having a jogwheel for scratching, and it would probably be too complex to implement anyway. I will also use the controller in FL Studio to aid in parameter control.

After doing some more research on these forums, I decided on the following as a preliminary layout:

PIC Based core running MIOS8

DINX4 with 32 buttons

second DINX4, chained to 1st, with 16 buttons and 8 encoders

DOUTX4 with 32 LEDs

AINX4 with 32 pots

DOGM26 lcd display

Are there any obvious blunders in this design? I was unsure about the 8 encoders/16 buttons on one DINX4 arrangement, I guess this will require quite a bit of manipulation in software.

I’ve been looking at encoders and pots on Alp’s website, and to some extent they fit the bill for what I need. Does anyone know of any good suppliers in the UK, or a particularly good eBay seller? I would also like to get my hands on some encoders equipped with push switches as well, as these would be excellent for controlling loop lengths in Traktor.

In terms of acquiring the pcbs, would setting up a bulk order on this forum be my best bet, or should I see if I can get them manufactured locally?

I have decent electrical knowledge and respectable soldering skills, but my programming skills are still fairly meagre. I will be scouring this forum over the next few weeks to fill in all the gaps in my knowledge that I possibly can, and I’ll be learning more about programming in C.

Thanks in advance for any help

[nebula]

PIC Based core running MIOS8

DINX4 with 32 buttons

second DINX4, chained to 1st, with 16 buttons and 8 encoders

DOUTX4 with 32 LEDs

AINX4 with 32 pots

DOGM26 lcd display

Are there any obvious blunders in this design? I was unsure about the 8 encoders/16 buttons on one DINX4 arrangement, I guess this will require quite a bit of manipulation in software.

No major manipulation is required. Encoders and buttons can share the same DIN ICs. The only rule is that encoders must be on one of the 4 primary input pairs on a DIN IC (so 0+1, 2+3, 4+5, or 6+7 - you can’t do 1+2 for example). You’ll get this when you configure your first app.

Your parts list makes sense, but you should double-check the musings on these forums about DOG LCDs. I don’t know how well they perform under MIOS8, and they don’t work with all apps. You might be better off going with a “regular” HD44780-based LCD.

I’ve been looking at encoders and pots on Alp’s website, and to some extent they fit the bill for what I need. Does anyone know of any good suppliers in the UK, or a particularly good eBay seller?

Try Farnell? Or maybe digi-key?

In terms of acquiring the pcbs, would setting up a bulk order on this forum be my best bet, or should I see if I can get them manufactured locally?

You’d be better served just ordering the boards from either of the two web shops that offer them for sale.

Smash TV: http://avishowtech.com/mbhp

Mike: http://www.mikes-elektronikseite.de/mshop_englisch/

Either that or try making them yourself - it’s not that hard, and single-sided layouts for all these boards exist.

[Triffki]

Thanks a lot for your help.

Is there a recommended limit on the number of DIN modules for a single core? I’m thinking I may need up to 3

[nebula]

Maximum is 128 DIN inputs. DINX4 has 32 inputs, so you can use up to 4 of them.

http://ucapps.de/mbhp_din.html

[Triffki]

Been a busy few months, but I’ve finally managed to finalise a panel layout (image below) and pcb to mount underneath.

I’m in the process of laying out tracks on a single sided pcb at the moment, but its proving ridiculously time consuming due to the limited space at my disposal (effectively 128 buttons, 96 LEDs and 64 pots on an area the size of an A4 sheet).

Would it be a bad idea to connect all the ground lines together on the pcb rather than having each one connected individually on the respective AIN/DIN/DOUT modules? This would probably make the task a little bit easier.

I know that linking digital and analog ground is generally a bad idea, but surely this won’t be a problem so long as I isolate them.

I’m using DesignSpark PCB from RS to draw the circuit. Does anyone know if theres a way to add a plain hole to the design i.e. one with no copper lining?

[Triffki]

Ok, I’ve managed to sort the pcb out, and all the parts are currently on order. Just need to order the circuit modules now. However, I’m still torn as to whether to go for the old PIC based MIOS8 approach or the snazzy new LPC17.

I understand there have been numerous updates to the new MIOS2 in the past few months, and I would feel more comfortable going for the newer hardware. Would this be overkill though? All I’m essentially trying to do is send and recieve MIDI signals from Traktor.

Would the fact that my project contains a fairly odd selection of modules (2 x AIN, 4 x DIN, 3 x DOUT) tip the balance in one method’s favour?

[Triffki]

I Finally got round to switching the unit on for the first time. Had a few issues with power rails to start off with but managed to fix them, so I’m sure each module is now getting the required 5V supply.

I connected the PIC core (preprogrammed with MIOS) to my Mac using a cheap USB to MIDI cable (the final unit will house a USB GM5 chip once the latest bulk order goes through), and opened the MIDI studio application. To start with, my Mac detected the link and showed it as having 2 ports; one with input/output, the other with just output. I opened up MIOS which also detected the link, but it gave an error: ‘Core not responding’ or something similar.

After resetting the unit however neither MIDI studio or MIOS detect any link. Am I wasting my time trying to talk to the unit with the cheap cable, and should I just wait for the GM5 which I assume is more reliable?

My box is an augmented MIDIbox64, so I know I’ll have to do some code editing at some point point to get it to work. Could someone please point me in the right direction of a tutorial or something to make this slightly less daunting for a programming novice? Even just a list of what I need download from the uCApps database would be a huge help .

Thanks

[T.K]

If you mean this MIDI cable:

then I can confirm, that it neither works properly under MacOS, nor under Windows or Linux

It has a design flaw which prevents proper SysEx transfers.

The GM5 order will probably start this weekend!

Best Regards, Thorsten.

[Triffki]

Yes the very same, thanks for clearing that up. I’ll wait for the GM5 then.

In the meantime, I’ve been searching the forums for firmware tips. I’ve just installed Xcode, SDCC and GPUtils on my mac, and downloaded the MIDIbox128 app files. As far as I can tell, the only bit of of editing I’m going to have to do before uploading it to the core is to change the number of DOUT modules from 4 to 3 and specify which inputs on the DIN modules are encoders.

Which .c files do I need to make changes in?

[T.K]

The MIDIO128 application is implemented in assembler - without knowledge of the PIC instruction set it will be difficult to add encoder functions.

Instead I would propose to create a new application based on the template (apps/templates/sdcc_skeleton)

Here are the programming examples for the functions that you need: http://www.ucapps.de/mios8_c.html

Best Regards, Thorsten.

[Triffki]

Ok I’ll give that a go, thanks for the advice.

Conveniently enough, I just started learning C at Uni

[Triffki]

I can’t seem to download the SDCC_skeleton files from the SVN repository. I can view the contents of the files on my browser, however