John E. Finster

Hi, I am looking for some infos regarding fader motors: As far as I understand this, the direction of the fader (up, down) is set by the prolarity of the motor. So theoretically by switching the +/- connections of the motor, I can detemine, if the fader moves up or down. I tried this with regular Alps faders (RSAON11M9). Can this be considered a general rule for all motorfaders, cored and coreless? The reason I am asking is this: I am planning a frontpanel with motorfaders, but I would like to allign the faders, so that the motors are located "below" the fader, not above (like in TK´s picture with the K-faders). I know this is possible with the mentioned Alps N-faders, but I got some Penny & Giles fader (PGFM3200) I want to use, and I don´t want to ruin them by accidentally damaging the motors. Does anyone have any experience with those faders? Thanks and greets.

Thanks again. Another rookie mistake of mine :rolleyes: (read first, type later). But really, this is very helpful.

Hi novski, thanks for the answer. I found the problem now. I missplaced vs and vd at J2. That must have confused the motors. Rookie mistake :mad: . Now it works. I have some trouble calibrating the motors though. I am not familiar with with all the parameters (deadband, duty cicle,...) in Mios Studio. I am using recycled faders, so I figure, calibrating them will not be easy. Is there some kind of "calibrating guide" already or do you have some insight to share maybe. That would be great. Greetings

Hi everybody, i´m in need of some advice for the MF_NG module. I connected 8 motorfaders today for testing and they don´t work as expected. The faders seem to work, i can see the value output in Mios Studio, but the motors don´t. They jump either all the way up or all the way down if they receive value changes from Mios Studio. If the lever is in the upper half of the fader, it jumps up, regardless if the value changes up or down, and the lever always jumps down, if it´s in the lower half of the fader. I suspect there is some kind of electrical fault, like bad wiring or so, but I don´t know where to start looking. The wiring and the soldered mf_ng pcb seems to be ok, no visible fault here. Where do I start looking for errors? I am using RSA0N11M9A07 Motorfaders. The Power for the MF_NG module comes from a laboratory psu (~9V). I believe I read about a similar problem here in the forum, but this was some time ago and I can´t find this thread anymore. Maybe someone can point me there too. Many thanks and greetings John

Du musst im Script einem EVENT_ENC einen enc_mode=<mode> Parameter hinzufügen. Die verschiedenen Modi kannt Du in der Anleitung für die .NGC Dateien nachlesen.

Also zunächst einmal brauchst Du einen Prozessor, also ein Core-Modul, am besten einen LPC1769-basierten Core (Quasi der Arduino in der Midibox-Welt), mit der neuen Midibox_NG Firmware lassen sich deine Vorstellungen am ehesten verwirklichen. Link Core-Modul: http://www.ucapps.de/mbhp_core_lpc17.html Link Midibox_NG Firmware: http://www.ucapps.de/midibox_ng.html Dann brauchst Du ein DIN-Modul für die Taster. Folientastaturen können meines Wissens nach nicht unbedingt verwendet werden, sondern es müssen einzelne Taster verwendet werden (die aber auch in einer Matrix angeschlossen werden können), da findest Du hier im Forum aber sicherlich noch andere Beiträge zu. Ein LCD-Bildschirm kann direkt an die Core-Platine angeschlossen werden. Da kann man eine große Bandbreite an Bildschirmen verwenden. Für Dich wäre ein 16x2 LCD schon ausreichend, die gibt es zu Hauf bei Ebay ab 5-10 €. Link mögliche Bildschirme mit Midibox_NG Firmware: http://www.ucapps.de/midibox_ng_manual_lcd.html Alle Module sind auf der ucapps-seite sehr ausführlich beschrieben.

Hallo und herzlich willkommen, also erstmal ist es gut, dass Du gerne bastelst, dann wirst Du hier viel Spaß haben. Zu deinen Vorstellungen: Grundsätzlich wird man sicher ein solches Gerät mithilfe der Midiboxplattform realisieren können. Ich bin mir nicht sicher, ob das mit der Eingabe der Programm-Nummer so programmiert werden kann, aber ich bin mir sicher, dass es da mehrere mögliche Lösungsansätze gibt. Allerdings heißt Eigenbau nicht automatisch, dass man ein gewünschtes Gerät billiger bekommen kann. Im Gegenteil, ich würde sagen, die Möglichkeit, seine ganz eigenen Vorstellungen in einem Gerät realisieren zu können, macht ein Gerät sogar noch ein bisschen teurer als herkömmliche Ausrüstung "von der Stange". Das größte Problem, dass ich zunächst bei Deinen Vorstellungen sehe, betrifft die Größe des Geräts. Ich habe mal ein kleines "Handgerät" gebastelt (mein erstes fertiges Projekt) und war überrascht, wie viel Platz man doch für die einzelnen Teile braucht. Alternativ könnte man natürlich eigene Platinen entwerfen, auf dem beispielsweise neben den benötigten Prozessoren auch die Taster, Lcds, usw. platz finden. Aber das heißt wieder viel mehr Basteln und natürlich mehr finanzieller Aufwand. Am besten schaust Du Dich mal hier um und auf der Midibox Seite und schaust Dir mal die verschiedenen Module und Programmierungsmöglichkeiten an. Wenn Du Fragen hast, einfach fragen...

Awesome :smile: , very much appreciated.

Indeed you have to install the bootloader once via LPC Link (project.bin), but you can upload the bootloader any time after that via usb on the Core PCB (project.hex) if you want to change the lcd type for example. After the bootloader is installed the first time, you can upload an application via usb on the Core PCB, but you have to remove Jumper J27 for that.

You have to install the bootloader without the jumper J27. You can use jumper J27 as a failsave in case the bootloader crashes and you do not have access to it the usual way (without J27). Try removing Jumper J27 and upload the bootloader again. After that you can upload the midibox_ng application.

Thank you very much for considering this. I also believe that others could benefit from this, when they are using small ssd1306 displays and want to use a bigger font for the mackie control message. Greetings

Yeah, it turned out to be a wiring problem, it´s working now. But I came across another problem with the Mackie Control message: "^txt56" only seems to work with a font that has a height of 8 pixels. The problem seems to be that the "^txt56" syntax sets the cursor to the second line after 56 characters regardless of what the current font height is. If I use a bigger font, then the lower half of the first line is printed over by the second line. Greetings

Hi TK, thanks for the fast reply. After I checked the whole wiring again, I believe this is simply the case of bad wiring. I´m not 100% sure yet, but I found some bad connections and I´m going to fix them first before I jump to any more conclusions (sorry about that :whistle: ). Thanks for the help Greetings

Hi, i´m sorry if that sounds stupid, but... i want to connect 16 ssd1306 displays and afaik the first 8 chip select lines are connected to j15, that does work on my side, and for the next 8 (9-16) displays i have to use a dout module for the chip select lines. Is that correct? I tried all evening to connect the displays to a dout module, but all i got are the first 8 displays working correct and the 9th displays shows lcd16, the remaining 7 displays stay dark. Anyone can help? Greetings

Take your time, I´m not in a rush. I have some work coming up, too. Even with this current font behaviour I can work on some ideas, so no need for a quick fix here. Thanks for the effort and have a nice holiday. Greetings John

Hi Thorsten, thanks for stepping in. I attached the files i modified and all the <font>.c and <font>.xpm files I created. For better overview over my little font project I put the fonts in dedicated folders. You will see if you open the glcd_font.mk. Greetings P.S. Sorry, I forgot. Are *.Zip files ok? fonts project.zip

The mystery of the artifacts continues..... :o Seriously, i did some additional testing on this matter and a general pattern is starting to reveal itself. After some experimening with different sizes and characters it seems that the artifacts only appear if the first vertical pixel line of a character has a 0xff byte in it and some special conditions are true. I will try to explain what I mean by reffering to the <font>.c file: ------ If a character starts with 0xff,.... (font height 8px) or 0xff,.... (font height 16px) 0xff,.... then the artifacts are always there. ------ If a character (font height 16px) starts with 0xff,.... 0x7f,.... (e.g.) then the artifacts are only there if the character is placed on an even line (like "lcd_pos=1:1:2") ------ If a character (font height 16px) starts with 0xfe,.... (e.g.) oxff,.... then the artifacts are only there if the character is placed on an uneven line (like "lcd_pos=1:1:3") ------ That´s it so far. I can work my way around this, i just have to avoid characters that start with a 0xff byte. This limits my design ideas a little but I can work with this. At least I have a pattern now, that I can take into account when I´m designing more fonts.

thanks. regarding the "title" font: it is one of my personal favourites, it reminds me a bit of old gear i used a few years back :happy:. but the main reason i chose this one for now is that it could be easily implemented without much additional bitmap modification and the letters fitted perfectly into a 12x16 pixel field. i´m working on other more practical fonts right now :ahappy: . this one is more or less to prove to myself that i actually can do that. i aquired a profession, that has absolutely nothing to do with programming or electronics whatsoever, so this was a little challenge for me.

hi, i´m in the middle of creating some new fonts and nice graphics for glcds and i want to share some preliminary results :happy: . this is how my mackie control emu might look like when it´s finished (some day... :whistle: ). what you can see here is a very nice font for the "title", some icons for mute,solo,rec and monitor status (those invert, when the track is muted, soloed, etc.) and some high definition bars (128 steps) for pan and volume (or other parameters). the label of the bars are the default "normal" midibox font. i´m using some very nice and small ssd1306 displays with a 128x64 px resolution, so especially the bars are quite big, 128x16 px, to improve readability. i will create smaller bars, more additional fonts and icons and make them available to everyone in a few weeks, once i took care of the problems i´m still fighting with.

I came across another problem i don´t get my head around. i experimented with an inverted font and there are strange artifacts appearing on other glcds. i attached both font files i used. other fonts (non-inverted) i created are displayed without problems. mb_font_6x8_inv.c mb_font_12x16_inv.c

allright, Blaumph2cool, i will count you in. it´s tool late to organize a bulk order, so i´m just going to order a few sets and we will take care of business afterwards. greetings

EUREKA!!!! i got it! i looked into the original font files again and i noticed, that i forgot to pass the additional parameters " -icons 16 -height 16" on to the cmd terminal while converting the *.xpm file to *.inc. many thanks for the help. greetings