John E. Finster

Hi Thorsten, thanks for the reply. here is what i wrote into the *.inc file // converted with 'convpix mb_font_12x16.xpm' #include <mios32.h> const u8 MB_FONT_12x16[] = { 12, 2*8, 0, 12, // width, height, X0 offset, char offset 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,.... }; after that i renamed it to "mb_font_12x16.c" and compiled the mb_ng firmware. Today I tried it with a 16x16 font, but i had the same result. P.S. Sorry about the RAR, i will remember that. EDIT: i just went over the whole procedure again just to make sure: 1. created the *.xpm file 2. converted it with convpix_c.pl to *.inc 3. added the header bytes above 4. renamed the *.inc file to *.c 5. compiled mb_ng firmware -> same result i attached the font file i created. mb_font_12x16.c

hi, i´m currently trying to implement an alternative glcd font (12x16), but it won´t work. the letters are not complete, kind of shifted, etc. if i want to print "button" the display shows half a "p", half a "w", some curves which look like "s"s and so on. what i did: i created a bitmap (192x128 px), exported it to *.xpm, converted it with convpix_c.pl to *.inc, added the header bytes (width, height,...) and renamed the file to *.c. i managed to implement the additional font into the mb_ng firmware and into the glcd driver, "&1" and "&2" now activate the additional fonts i created, everything peachy so far. so i think the problem must be with the fonts. which font sizes are supported? i know the height must be devidable by 8 (so 8,16,24,...), is this also the case for the width? is there something wrong with the *.xpm i created? i attached it if someone wants to take a look. is there something else i am missing? thanks mb_font_12x16.rar

sorry, it didn´t work. i can´t be of much help here since i ripped apart my old cores a while ago for the parts, so i can´t really test any of this. with the mb_ng, it works a little different. i guess you already had a look into the manual, so you know that mb_ng works with scripts. so you upload the mb_ng firmware, after that you write a script (with Mios Studio e.g.) and tell the midibox what it has to do. and there is already a (almost complete) script for the logic controll emulation, that TK wrote here. it supports the lcd messages, motorfaders, .... and since up to 64 lcds are supported natively, there is no problem connecting and displaying the mcu message on 4 lcds.

and even if you assembled everything already, you can keep everything. you just need to change the core module. i even believe you can ceep the old core module to drive just the motorfaders (i´m just assuming you have some) so you wouldn´t need to get a seperate mf_ng module. EDIT: There is a comment in the 11553.0 topic about the rebooting problem: it is said there that Resistor R10 of the core module has to be clamped to ground with this firmware. R10 is connected to 5V by default. maybe you try that and use the original x4 firmware from this topic again. EDIT2: also check if you are using 4-bit lcds. if so, you have to disconnect D01-D03 from the the core to the lcds.

Sorry, :happy: , das mit den Matrizen über die DINs/DOUTs war mir noch nicht ganz bewusst. so gesehen passt der Einkaufszettel erst mal. Für das MF_NG Modul brauchst Du noch einen PIC18F452. Den gibt´s zwar bei Reichelt, da muss aber noch der Mios Bootloader aufgespielt werden. Einen PIC mit vorinstallierten Bootloader kannst Du bei SmashTV oder bei MIKE in Deutschland kaufen

why don´t you get a new lpc17 core? that would solve all your lcd problems almost instantly, since you could connect up to 64 lcds and it would drastically decrease the coding effort. there is already a logic control script available for the new mb_ng firmware. EDIT: i belive i tracked down the firmware you were looking for (the mblc firmware to use with 4 lcds, right?). the link on that 4-lcd page leads to an old forum topic, which can not be opened anymore. but you can type "11553.0" into the search field of the forum and you get to an old topic where the firmware can be found (somewhere on page 2).

the MF_NG module has to be driven with a power input of 9 to 12 volts. i believe a usb port delivers around 5 volts, so you probably need a seperate psu. any psu with 9 to 12 volts will do (like a laptop psu or one for an external drive).

ich habe genau dieselben gekauft, auch von dem gleichen Händler. Sie sollten eine blaue Hintergrundbeleuchtung haben, jedenfalls nach dem Datenblatt, das ich habe und nach der Modelnummer. Sie funktionieren, allerdings bekomme ich keine blaue Hintergrundbeleuchtung hin. Um überhaupt eine Hintergrundbeleuchtung zu haben, muss man auch die Anschlüsse B+ und B- irgendwie an die Anschlüsse auf der Rückseite löten. Die normalen Pinne 15+16 werden nicht genutzt. Ich hab da mal zwei Fotos gemacht. Ich glaube eigentlich nicht mehr, dass die zu einem blauen Licht fähig sind, aber wer weiß... wenn´s jemand trotzdem irgendwie schaffen sollte, bitte Bescheid geben.

4 Fader können unter Umständen direkt am LPC17 core angeschlossen werden über die Buchse J5. Für weitere Infos schau Dir am besten mal die Seite über den LPC17 core an, dort werden alle Anschlussmöglichkeiten ausführlich erklärt. Wie Ilmenator schon gesagt hat, schau Dir bei der Gelegenheit auch mal die anderen Module an. Für eine Buttonmatrix brauchst Du das DIO_MATRIX Modul, an ein DINX4 Modul kannst Du "nur" 32 Buttons oder 16 Encoder anschließen. Bei der Verwendung der Buttonmatrix gibt es aber Einschränkungen bei der Belegung mit Midibefehlen. Ob diese Dich betreffen werden oder nicht hängt natürlich davon ab, was dein Controller irgendwann mal steuern soll. Am besten ist es, Du liest Dich mal ein wenig ein. Welche Module gibt es, welche Hardware kann angeschlossen werden, welche Midibefehle können damit verarbeitet werden und wie, und wie programmiert man seinen Controller. Wenn Du fragen hast, bist Du hier im Forum bestens aufgehoben :happy:

Man kann eigentlich auch immer ganz gut bei ebay nach einzelnen Bauteilen schauen. In der Regel findet man immer Angebote, bei denen auch die Versandkosten angemessen sind (Achtung: Conrad verkauft auch bei Ebay: Bsp. 10 Widerstände für 1 Euro plus 5,95 Euro Versandkosten :rofl: ). Das Teil gibt es übrigens noch bei Reichelt. guck hier.

i´d like to offer some advice on your controller design too. you said you are using mostly Reaper and also Cubase/Nuendo. i also used Cubase years ago ( i got the SL3 version with my soundcard). i finally switched to Reaper in the end. since i tried implementing a midi controller in both daws, i´d like to share some insight i gained: With Cubase/Nuendo it is very easy to implement a midi controller (at least it was with the old version, i can´t speak for the new Cubase 6 or 7 - where are they now? - ), since almost every function/knob/slider..... in the program can be mapped to a physical controller. but it can get very messy and combining multiple midi protocols (in your case the mackie mcu and the native cubase midi control) is tricky. With Reaper, though you can assign midi events to almost every action/macro action there is, you can´t assign every knob/slider in the program. natively you can only assign Volume/Panorama/Mute/Solo/Arm/Select to a controller globally and Send/Track FX parameter on a per channel Basis. that means you can only control the sends/fx paramter for the channel that is currently selected. You can also assign Vst parameters directly without putting them into the track fx parameter, but then they won´t provide feedback !!! (this point is actually very importent). Here also combining multiple midi protocols can be tricky. the controller mockup you made may not be usable in Reaper the way you intended. a tip: look (with both daws) into the preferences for control surfaces and make a list of what commercial controllers are natively supported. then look around the internet and try to get every piece of information you can find for those controllers and how they are implemented in the software. then you get a rough idea on what is already possible (e.g. for Reaper you will not find a controller with more then one fader row and one encoder row). i don´t say this would be the end of the line, there are almost endless possibilities and workarounds when it comes to midi controllers. but it also important to know what kind of limitations one is faced with when using the controller with a daw. That´s just a general point on how to implement a controller into a software and why an extensive testing phase is always necessary before building/designing a controller.

well, i also did some reading over the night, and it seems it might be possible for you to use a matrix for the buttons as well as for the leds after all. i studied the example scripts in the repository and i found this one . in there you can see how individual events are mapped to the buttons/leds in a matrix. there might be limitations though, e.g. the toggle mode is not supported for button events. but you have to decide if you would want that mode with your controller. i guess, the next step would be to get a core, some din/dout/dio_matrix modules, some buttons, encoders and leds and do some testing (that´s actually the fun part :happy:).

thanks, i´m just gonna try that. i don´t care about the resistors, just don´t want to destroy any of the remaining parts that are attached to the resistors (like my midibox :rolleyes: ).

(i didn´t use the Fairilightiii pcbs yet, so bare with me if i give you any false information :happy: ) Fairilightiii pcbs have 16 encoders each, that makes a total of 32 digital inputs. that means 4 pcbs need 128 digital inputs. you would have 128 digital inputs (128 buttons or 64 encoder) left. that´s 4 DINx4 modules. for the 64 ledrings i think 16 ledrings use 1 DOUTx4 module, that means 4x16 led rings = 4 DOUTx4 modules, so you would have 128 digital outputs left for other leds. that´s 4 DOUTx4 modules. If you need more inputs/outputs however, it is possible to use a second core module (e.g. only for the Fairlightiii pcbs) and connect it to the "mastercore" via midi. EDIT: i took the liberty to compile a preliminary shopping list for you (just an example): 1 Core LPC17 4 Fairilightiii PCBs - for 64 encoder and led rings 4 DINx4 - for 124 buttons and 2 additional encoders 5 DOUTx4 - for 128 status leds (mute,solo,....) and 1 additional doutx4 for the remaining lcd screens 2 MF_NG - for 16 motorfader this is not a complete list, just a thought on which and how many modules you would need

i think the new bootloader 1.010 was created due to the problems windows had with the usb-midi connection. did you try connecting the core via midi to a seperate midi interface? you should be able to get able to get a response from the core if you do it this way.

hi, i just got a bunch of resistor networks for the DIN modules, but they have 7 pins (6 resistors + 1 common pin). i can´t return them, so i am wondering. is it possible to cut off the unnecessary resistor or are the resistor networks destroyed if i do that? thanks and greets

You don´t need those for the motorfaders. you connect the motorfaders to the MF_NG modules and those you connect via midi to the core. The LPC17 core has two native midi in/out ports and two additional ones you can build using this schematic. The touch control inputs from the faders are also handled on the MF_NG module, so in the end, there are no direct connections necessary from the faders to the core or a DIN module. I´m not 100% sure, but if you want to use those leds for your buttons (and not for led rings), then you can´t do it this way. if you want to map different led events (like solo, mute, etc) you have to connect them to individual pins on the DOUT modules. so 1 DOUT module = 32 output pins. maybe you can use a DIO_MATRIX module for that, but as i said, i´m not 100% sure. Also the input/output connections are limitied (256 inputs/outputs per core) and you are using some of those already for the 64 encoders/led rings. You definitely have to check that before you start to order. For more than 6 lcd screens you have to use an additional DOUT module to provide the additional "Enable" lines for the screens. see here for more information. i think this has to be connected to j28 on the the core module. Also i noticed in the mockup you made (nice one btw.) that you are want to use 16 lcds with 16x2 characters and a bigger one on the top left side. i think the lcds connected to the core have to be the same size. Other than that, i have to say: very nice project so far. especially the idea with the encoder assignment feature (the conditional events) i like very much. i didn´t think about that possibility. Carry on...

i got some of those illuminated encoders for my mb_seq (from somewhere else). they´re pretty nice, but they do not fit on a standard pcb with a 0,1 inch grid. one has to make up a workaround for these. i would be very interested in prices if anyone gets a hold of whoever is in charge there.

I don´t think reselling the SmashTV boards in Germany would be much easier or cheaper compared to SmashTV. If one would want to do that, one would have to order a huge amount of boards from Smash to keep the shipping costs per board to a minimum. SmashTV already puts the minimum price on the board itself, so there is just no way to get cheaper boards even if one would order a huge amount of them. Then one would have to pay german sales tax and, due to the amount one would have to order, also custom fees. So per board one would have to raise the price to add the sales tax, the custom fees and the shipping costs from the states (thats board + 19% tax + ~ 5% custom fee + shipping + 19% tax for shipping + 5% custom fee for shipping). Then the reseller probably wants to add a small expense allowance (for the time and the effort) and BOOM! i guess the price per board would have been doubled by now. One could save some money when one has a small business here in Germany to avoid paying extra sales tax. But then other costs would arise like income and business taxes plus the annual fee to the IHK (i hate those guys!!!). And the sales tax would have to be paid by the customer anyway. If a commercial seller would take care of the reselling then the boards would be even more expensive since he wants to make a reasonable profit out of it. Plus think about the effort and time SmashTV puts into this community. He is always around to help if you have problems with the boards or with the kits he provides. He also has an excellent customer communication policy. If you order something you can check the status of your order on his site. If anything doesn´t go as planned you get the info straight away. One would have to be ready to do the same. As for fast: When i order some boards from SmashTV they normally get here in a week. That´s fast enough for my taste. I have to wait longer for the new boots my wife orders from OTTO here in Germany. I know this sounds kind of bathetic, but really don´t think changing the staus quo would make anything faster/easier/cheaper for anybody. It would just complicate everything.

that´s the beauty of the new mb_ng firmware. you don´t have to "program" or compile anything in the traditional sense anymore. You just have to write a script for the midibox and upload it and the midibox will compile it for you :happy:. in the script you just tell your midibox what kind of hardware you are using and what you want it to do with that hardware. there is a little bit of syntax you have to learn, but it´s very easy compared to traditional c language. its level of difficulty is comparable to writing webpages with html.

ok, i´m out of ideas for now.... unfortunatly i ripped apart my old mb64e quite a while ago to use the parts for something else, so i´m flying blind here. though i can not test it myself, i don´t have a mac, i begin to suspect, that Mainstage doesn´t really provide a fully working bidirectional connection with the controller. one thing you could do now, is to monitor the midi output of Mainstage with a midi monitor. if your midibox has an lcd you can use the mbmon app, or you can use a software monitor (i don´t know which one you can use for mac). it´s a longshot, but you could see, what Mainstage actually sends back to the controller. it can help adapting your midibox design to the software.

did you try another mode for the global buttons. so instead of "toggle" maybe "on/off" or "on only"?

you could try another metafunction: but then you would have the same problem with your global buttons, i guess. what are those 4 toggle buttons controlling? if Mainstage reports back the status of these buttons, then they shouldn´t change, if you switch to another bank.