TK.

I would use a PCM1725 instead of TDA1543 - availablility and quality are significantly better Best Regards, Thorsten.

Ploytec doesn't sell PCBs, the evaluation boards are provided - as the name says - for evaluation only. Outdated info: they consider to sell PCBs Best Regards, Thorsten.

OSC is cool, but my primary focus is on MIDI, therefore you won't find alternative solutions from my side. This doesn't mean, that a skilled programmer wouldn't be able to build other protocols into his MIDIbox firmware. With MIDI, a MIDIbox can easily talk with any MIDI compatible device without firmware changes. For example, it doesn't matter if you control a MIDIbox SID directly from your MIDI keyboard, from your hardware sequencer, or from your computer. You can especially control it from all these devices the same time with the same protocol, and without baudrate adaptions. Or a MIDIbox SEQ can not only send data to your computer, but to any MIDI device without firmware changes. Today, OSC is still only useful in conjunction with computers. So, why not using a Proxy which converts MIDI into OSC instead of OSC (or any other plain serial stream) into MIDI? From the functional point of view, it's the same, you only need to find a clever MIDI event coding. Yes, OSC has also advantages, but just compare them with the possibilities already given by MIDI, and decide by yourself which advantages are stronger. We could also say: it's a different philosophy. Example: go to youtube, and watch my stribe demo (keywords: "stribe ucapps"). Search for other stribe demos, and tell me, which solution is using MIDI as transfer protocol, and which one is using OSC. Do you see any function, which cannot be realized with MIDI? As mentioned above, most firmwares have been tailored for MIDI baudrate. However, a generic device like a x*y button/LED matrix could also run with a much higher baudrate, but most MIDIbox firmwares are "a bit" more complex than a minimal application like Monome... anyhow, it's the same: a skilled programmer should know, how to change the baudrate, and what it means for his application. Btw.: do we really need to talk about such technical topics in a "bulk order" thread? Best Regards, Thorsten.

Hi Juergen, it would be interesting, if the transistor amp stage is working. The mbsid_testtone application provides a special testing feature for this: In addition, a 1 kHz pulse will be generated on the CS lines to the two SIDs. This feature allows you to test the output amplifier of the SID module (unplug SID, connect socket pin #8 with #27) [/code] So, after connecting pin #8 with #27, you should hear a 1kHz pulse sound Best Regards, Thorsten.

Just ask them, and please let me know about the reasons. Yes, TK has considered this several times. There are at least three reasons why I don't find them suitable for MBHP: - SSOP package, you are not able to solder this with a soldering iron - expensive (because you need an additional adapter board SSOP->DIP (or similar) format) - MIDI protocol not natively supported, a proxy is required which makes the usage complicated and error prone whenever you upgrade to an operating system which isn't supported by the proxy Both: standard USB-MIDI and dedicated driver for windows (which hopefully fixes the known flaws which are documented at my website - I will test this) You don't need a programmer, the closed-source firmware is already programmed into the chip. We will see... ;) As mentioned in my initial posting, I won't order the first batch before I tested the chip under Windows and MacOS You will see multiple devices - the max configuration I ever tested was 3 MBHP_USB and 1 MBHP_USB_PIC module. I guess, that for the GM5 chips it will work the same way... Best Regards, Thorsten.

If you would have mentioned this earlier, I'm sure that the discussion would have gone into a different direction. I think, that there is no need to continue the discussion (therefore the thread has been locked). Looking forward to get inspired by your creations, and I hope that one day you will share your experiences (regardless if good or bad ones) that you made during the re-implementation in this forum. :) Best Regards, Thorsten.

Ich habe die beiden Postings zusammengefuehrt Ausser der MIDIbox LC gibt es auch die MIDIbox MF Firmware. Sie bietet die gleichen Features wie MB64/MB64E (also bspw. mehrere Configurations-Baenke, On-Screen Editierung, bis zu 64 Taster, MIDI Learn, Parameter-Morphing, alternative Konfiguration via SysEx, etc...), ist jedoch auf die Verwendung von Motorfadern zugeschnitten. Du findest die Firmware in der MIOS Download Section unter "midibox_mf" Gruss, Thorsten.

Ich programmiere auf einem MBP, und verwende meinen PC mittlerweile nur noch, um PICs mit dem MBHP_BURNER zu brennen. Da via SVN nur die Source Files uebertragen werden, muss ich sie vor dem Brennen auf dem PC assemblieren - deshalb ist mir das Problem bisher noch nicht aufgefallen... Gruss, Thorsten.

Schade, dass wir das Problem nicht loesen konnten. Ich befuerchte, dass auch andere in Zukunft darueber stolpern werden. :/ Welche Windows-Version verwendest Du eigentlich? Im Anhang die aktuelle MB808 mit Ext Trigger mod und Swing-Poti aktiviert (falls Du keins angeschlossen hast, muss zumindest PIC Pin #2 an Masse geklemmt werden, ansonsten wackeln die Sequencer-Timings) Gruss, Thorsten. setup_808_with_swingpot.hex setup_808_with_swingpot.hex

In theory yes. In practice it can affect the architecture of the firmware. E.g., required MIDI In/Out buffer size, maximum allowed CPU load, interrupt priorities, etc... MIOS and most main applications have been designed for MIDI baudrate. Using higher baudrates can lead to failures. Best Regards, Thorsten.

Wow, after almost one day 182 chips have been ordered! 68 left to reach the minimum limit! :) Best Regards, Thorsten.

This hasn't been discussed yet. I don't know how customs are handled in the US, but if it is similar to Europe (no customs have to be paid so long the costs are below a certain limit) it will be favourable to distribute the chips to individual people from Europe. Best Regards, Thorsten.

Doch, vorgestern hat mich jemand wegen des gleichen Problems kontaktiert, und gestern hat er mir auch schon die Loesung praesentiert: das .hex File wurde unter MacOS generiert, und enthaelt deshalb keine Carriage-Returns (CR). PBrennerNG kommt damit nicht zurecht. Kurzfristige Loesung: .hex File bspw. mit Wordpad oeffnen, und am Ende eine Leerzeile einfuegen. Alternativ: Source Code nochmal unter DOS assemblieren. Einfach "make" eingeben, das hast Du bereits geuebt! Mittelfristige Loesung: ich muss die releasten .hex Files nachtraeglich in das DOS-Format konvertieren Langfristige Loesung: PBrennerNG geschmeidiger machen - Sprut ist informiert Gruss, Thorsten.

Great that you found the solution by yourself! :) Best Regards, Thorsten.

This thread is about continuously running bulk orders for the "GM5" chip - this is an Atmel AVR based USB chip with preburned USB-MIDI firmware (out-of-the-box solution) This product has been developed by http://www.ploytec.de Schematic/PCB Layout: http://www.ucapps.de/mbhp_usb_gm5.html Unbeatable prices: 4.50 EUR per unit for a batch of 250 chips 3.50 EUR per unit for a batch of 1000 chips Minimum order quantity: n x 250 The compact PCB can be ordered as well: 3.00 EUR per piece for a batch of 100 PCBs Minimum order quantity: n x 100 The chip will work under Windows/MacOS/Linux with the common USB-MIDI-Driver, but there is also a custom driver for Windows available for better performance (a drawback of the current MBHP_USB* modules) Per chip you will get 5 physical MIDI IOs (means: 0.90 EUR per IO port - compare this with commercial interfaces! :)). The dedicated Windows driver makes it multi-client capable. Under MacOS the interface is multi-client capable by default. Package: TQFP32 (SMD, but can be soldered with a good soldering iron similar to AN2131SC (-> MBHP_USB)) So, please add your name and the quantity of chips to this list -> http://www.midibox.org/dokuwiki/tk_gm5_bulkorder First come, first serve! We need n x 250 chips, if more than 250, but less than 500 chips are preordered, you need to wait for the next run Best Regards, Thorsten.

SDCC limits it to 8 bit (unfortunately) Initially I considered to propose a union (sometimes also called aggregate), because access to individual bits is much faster (single assembler instruction) But for your usecase it doesn't help, because you don't access the bits directly, but via an index (button number variable) - unions cannot be accessed this way (in other words: you have to statically specify the bit number/union element which should be accessed) Best Regards, Thorsten.

Hey, is this already the final pic? The panel looks more beautiful than expected from the first pictures! Definitely a reference design for small & still ergonomic solutions :) Best Regards, Thorsten.

Blogged :)

Easy: we would re-implement your project, make it much better, publish the sources and allow everybody to sell the devices for a better price at EBay ;) Don't know, if anybody would feel motivated to support somebody, who doesn't give something back to the community... there are enough forums, where you can discuss with professionals, so why do you search for help in an hobbyist forum, if you don't share the same spirit? Best Regards, Thorsten.

No, there isn't a better way. But you could optimize the handling by storing 8 solo button states per byte. To set a solo flag, use cur_but_solo[button >> 3] |= MIOS_HLP_GetBitORMask(button); To clear a solo flag, use cur_but_solo[button >> 3] &= MIOS_HLP_GetBitANDMask(button); To check a solo flag, use if( cur_but_solo[button >> 3] & MIOS_HLP_GetBitORMask(button) ) { ... } // no typo, use OR mask instead of AND To output 8 flags to LEDs, use MIOS_DOUT_SRSet(sr, cur_but_solo[button >> 3]); // will copy 8 bits to a shift register etc... The MIOS_HLP* functions are equivalent to (1 << (button & 7)), but much faster! Best Regards, Thorsten.

Alright, thats what I expect. Init() will be called before the copyright message (and before the LCD initialisation), whereas DISPLAY_Init() will be called after the copyright message Best Regards, Thorsten.

Fine! :) It's strange, that the wrong font is used for the copyright message, according to the code it should work. Are you sure? For the reboot message it's clear, but there is no solution, as the font is not statically assigned anymore, but under control of your application. However, since the message is only displayed after code upload, and not under normal circumstances, it should be acceptable, no? Best Regards, Thorsten.

Seems that there is an error in the .lkr script. Does it work, when you replace: CODEPAGE NAME=page START=0x3000 END=0x7FFF by CODEPAGE NAME=page START=0x3000 END=0xFFFF Best Regards, Thorsten.

I cannot say exactly, what will happen with my copyright message. The new font should be selected before it is print... or do you see a different text? Did you already try this out, or was it just a question? Now, it doesn't matter anymore where the font is located (it will be located by the linker automatically...) The new upper address is 0xffff. Best Regards, Thorsten.

Sieht nicht gut aus! :-( Koenntest Du bitte zum Vergleich mal die posix_bin Tools ausprobieren? Kopiere das Verzeichnis nach C:\posix_bin Oeffne die Kommando-Zeile, und tippe set PATH=C:\posix_bin;%PATH% Nun sollte "make" funktionieren. Ich gehe davon aus, dass Du GPUTILS bereits installiert hast. Falls nicht, bitte vorher erledigen, und dann erst die Command Shell oeffnen Gruss, Thorsten.