TK.

Hallo Stefan, was hat sich eigentlich mittlerweile beim Merger-Problem ergeben? (http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=german;action=display;num=1096807147) Gruss, Thorsten.

ok, so lets assume that it is a stupid error - maybe the reister addresses declared in app_defines.inc are overlapping the C variables? You can check this in the projects.map file, where all addresses are listed. Best Regards, Thorsten.

Hi Nikolai, I remember that the generic remote of Cubase SX is not so well maintained by Steinberg like before. In particular versions one or two functions are not working, in following versions they are fixed but other functions are failing... :-/ Best Regards, Thorsten.

Hi Tim, could you please add this info to the HowToConnectLCD page of the Wiki? Best Regards, Thorsten.

Smash sent me the S&H chips + other stuff some months ago - the package took very long through the customs (ca. 2-3 weeks), but I haven't payed VAT Best Regards, Thorsten.

Copy&Paste from an email to d2k: Currently my MIDIbox FM looks like MBSID Step A, I will probably use a 2x40 LCD in the final version. Due to the flexible concept the display size doesn't matter during the developing phase. A Master/Slave concept like MBSID is not planned and not required, because the application already provides a multitimbral mode with 5 common MIDI channels (Mono/Legato/WT/Poly) + one drum channel The "instruments" can be assigned to 4 audio outputs. 128 Patches are already available (I converted the GM set from the Linux driver) All OPL3 parameters can be modified Development of software based sound engine (Portamento, 2 LFOs + 1 EG + AOUT + 7-track/32-step wavetable sequencer per channel) not started yet - however, the sounds are already impressing :) Plans for complete control surface not before december, I want to create some own sounds before, in order to find out the best usage concept. Best Regards, Thorsten. Addendum: if somebody cannot resist to build more than one MIDIbox FM, then the additional units can receive premade sounds from the master module. It's similar to MIDIbox SID, but w/o realtime control for the slaves

I don't think that another IC will give you better results, because the propability that they are not working is very very low. It's difficult to give you some additional tips so long you don't describe what you've already done. E.g., you are writing that "there doesn't seem to be a short", but you are not writing how you've ensured this. Therefore its unclear if it makes sense to give you some tips for measuring the module, or if the problem could be somewhere else. Best Regards, Thorsten.

Hi, first question: did you also try to control the filter without the joystick? E.g. with the datawheel from the filter menu, or via CC? I'm asking because the AIN driver for MIDIbox SID is totally unsupported and therefore could have bugs Another question: are both SIDs selected on the control surface? For simultanous changes the SID1 and SID2 LED should lit (press both buttons at the same time to select the two SIDs) Best Regards, Thorsten.

Hi, you could have the same problem like Twin-X had with his DIN module, see http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=troubleshooting;action=display;num=1096139044;start=28#28 (Reply #28 ) Don't rotate the ICs, this could destroy them! Yes, the DOUT module works also when only one chip is stuffed. Best Regards, Thorsten.

no, I'm not speaking about softcores, they mostly allocate too much macro cells, or the performance is not good enough. Best Regards, Thorsten.

Hi Pilo, well, what should I say to this statement? I don't know your code ;-) no, because matrices are always very hardware dependent and require customizations which are better located in the application, because parametrized code would be too slow. MIOS already provides a hook which allows to prepare the DOUTs before they are updated. However, currently it is not possible to use this hook in C... I know... this will be added to the C wrapper once I find the time. you can use two seperate DIN/DOUT chains, one for the standard MIOS stuff, one for the button matrix stuff. You only need to change the pinning in sm_fast.inc This would be the most performant solution Best Regards, Thorsten.

An extraordinary MIDIbox SID made by Bill More pictures of his DIY stuff can be found under http://www.mylgd.com/public/?rep=.//Photo/Bill/diy

Hi Seppoman, so long the AIN handler is disabled, 128 bytes are free for the application which could be used as alternative RAM storage (0x380-0x3ff). You could store the modified WT data there. The WT sequencer (sid_wt.inc) has to be changed, so that it loads the step information alternatively from RAM. The CS_MENU_MS_Update_WT_Buffer in cs_menu_ms.inc has to be changed, so that it doesn't store the modified data in the buffer, but directly at the appr. RAM address. The CS_MENU_MS_Update_WT_EEPROM function has to be disabled, and CS_MENU_SaveBank in cs_menu.inc has to be changed so that WT data is transfered from RAM to EEPROM if this function is not used to copy data, but to store a new patch Best Regards, Thorsten.

Bingo! Yes, it's the OPL3 :) I've started with a very basic driver which allows to trigger some notes, but - please be patient - a first version won't be released until end of this year. I need this time to find an optimal user interface and an optimal sound architecture (like Duggle mentioned: even more interesting sounds can be expected once the parameters are modulated via LFOs/ENVs/Wavetables). The prototype is not the final one. The selfmade 14.318MHz oscillator will be replaced by an integrated one, the LM314 by a TL074 for high quality sounds, I will add a second YAC512 for two additional audio channels (the YMF262 provides 4 seperate outputs), and finally I want to put this on a PCB. Hopefully the background noise disappears then (I think so...) Here a new example (the last for this month) - drums can be accessed via MIDI now - the bass is a killer! :-) http://www.midibox.org/midibox_fm/mbfm_demo2.mp3 Pilo: like in the first example the delay/chorus/etc effects are made with external VST effects - sorry, no DSP ;-) Andrew: today I received a AtariST from an ebay auction (for 1 EUR) - looking forward for your YM2149F synth! :) Best Regards, Thorsten. P.S.: please don't start to desolder the SMD chips from old soundcards if you never did this before. I will provide a desoldering guide!

w/o words :-) http://www.midibox.org/midibox_fm/mbfm_demo1.mp3 Best Regards, Thorsten.

Der spezielle Drum Algorithmus in der MB64 arbeitet aehnlich wie von Steff beschrieben (er befindet sich in drums.inc): Allerdings betraegt die Sample Rate lediglich 200 uS, da der AIN Handler von MIOS so ausgelegt ist, dass er die restlichen Tasks moeglichst wenig stoert. Mit einer zusaetzlichen Hardware (einem sog. Integrator) laesst sich das jedoch relaxen, jedoch auf Kosten der Latenz (immerhin noch < 3 mS) Hier noch ein weiterer Link zum Thema EDrums: http://edrum.midibox.org Admir hat sich auf das Thema spezialisiert und hat eine hochoptimierte Firmware programmiert. Gruss, Thorsten.

Die Freeware Version vom Keil C Compiler erlaubt lediglich eine binary-Groesse von maximal 4k, und die werden bereits von der MBHP_USB Firmware belegt. Der AN2131 hat insg. nur 8k, viel mehr ist also auch nicht mehr drinn Gruss, Thorsten.

Hi Dan, without a lot of changes in MIOS this isn't possible. A more flexible solution which allows to select either DIN registers or J5 pins would slow down the performance too much at a very sensitive part of the ISR. Best Regards, Thorsten.

Hi Dimitris, I changed the mapping in v1.5, and the new one matches with the diagram. I made this since it's more useful for my own hardware. You can always change the mapping in lc_io_table.inc if you want Best Regards, Thorsten.

See http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=troubleshooting;action=display;num=1097358846 Please don't spread the questions to a certain issue over different articles, it makes it impossible for us to gather all informations about a problem, and it makes the maintenance of this forum difficult. Best Regards, Thorsten.

See http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=troubleshooting;action=display;num=1097358846 Please don't spread the questions to a certain issue over different articles, it makes it impossible for us to gather all informations about a problem, and it makes the maintenance of this forum difficult. Best Regards, Thorsten.

See http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=troubleshooting;action=display;num=1097358846 Please don't spread the questions to a certain issue over different articles, it makes it impossible for us to gather all informations about a problem, and it makes the maintenance of this forum difficult. Best Regards, Thorsten.

Hi, midio128.syx or relay.syx doesn't contain the application code, but only the configuration data. You've to upload the main.syx file of the MIDIO128 application package first (-> see http://www.ucapps.de/mios_download.html). Thereafter the DINs will send MIDI events, and the appr. LEDs will light on a pressed button (and they are also controllible via MIDI) With the .syx files of the mk_syx package you will be able to change the MIDI events which are related to the buttons/LEDs Best Regards, Thorsten.

Welcome back, Sly! :) Ich kann nur von meinen Erfahrungen mit Frontpanel Designer berichten: zunaechst einmal sollte man die Masseinheit auf Zoll umstellen, und die Rasterung auf 0.1 Zoll. Dadurch wird das Partitionieren erheblich einfacher, da der Abstand zwischen zwei Gitterpunkten einem Loetpunkt auf der Lochrasterplatine entspricht. Nun kann man die Encoder/Buttons/LEDs, usw. schonmal auf die Platine stecken und muss nur noch Loecher zaehlen. Manchmal, bspw. bei LEDs, macht es Sinn, die Aufloesung auf 0.05 Zoll zu stellen, da sie sich zwischen zwei Loetpunkten befinden. Den Durchmesser der Bauelemente ermittelt man am besten mit einem Messschieber, so etwas gibts im Dreierpack fuer 3 EUR beim Praktiker (oder bei Obi...) LCDs: mit dem Lineal ausmessen, im Frontpaneldesigner eine neue Flaeche und die dazugehoerigen Bohrungen erstellen. Ja, es ist ziemlich schwer. Ich drucke mir ein fertiges Layout aus, klebe es zusammen (falls es sich ueber mehrere Seiten verteilt), schneide die Loecher und Flaechen mit einem scharfen Messer aus, und lege es ueber die Bauelemente. Diese habe ich bis dahin bereits fix und fertig auf die Lochrasterplatinen geloetet. Meistens stellt sich dann heraus, dass sich das eine oder andere spaeter nicht montieren laesst, oder nicht in das Gehaeuse passt. Dann muss nachgebessert werden. Nach 3-5 Iterationen klappt es dann meistens. Danach noch mindestens dreimal ueberschlafen, und dann erst bestellen (oder selber machen)! Gruss, Thorsten.

Of course, I don't want that users get ripped off, but independent from the terms in any license, people will always find a way to bypass the rules. The circuits of MBHP are small and common, they can be easily modified to create something which is not covered by the license. It's only a question of knowledge and effort. So, how can people be protected from such "bad guys"? We have to keep an eye on public platforms like forums, ebay, etc... and we can warn the potential customers if possible. The guys won't get support from us - thats all we can do. On the other hand: if somebody is able to sell assembled MBHP PCBs for a reasonable price, if he works together with Mike and/or SmashTV (in order to keep up the existing infrastucture), when he spends the same effort in customer support like SmashTV, then a collaboration is possible. As I mentioned before: in some years we possibly rely on such a service. And a inexpensive alternative solution is a good protection against overpriced ripped designs. Yes, it's a field programmable gate array. Don't be afraid of being triggered with such a new wanna-have in the next 2..3 years - I think that the current platform is sufficient for my own plans until then. But once I feel frustrated enough about the limitations of a 8-bit microcontroller, and once I see that the use of state-of-the-art technology for non-electronic experts is feasible, I will switch. A FPGA has the advantage that it is a very generic device, which allows to do a lot of very different things with the same hardware. It's so flexible, that very dedicated units can be implemented without much effort, which are doing tasks with best execution time (nanosecond accurate), e.g. functions for scanning buttons/encoders/pots, serving LED matrices, etc... but also complex waveform generators (-> synthesizers), audio processing units, sequencer engines or just serial interfaces (you want to have 256 MIDI In/Out Ports? no problem ;-) ). Even a customized CPU could be programmed into the array, but due to the implementation effort and number of required gate functions/memory, it's mostly easier to use a seperate microcontroller connected to the FPGA. The current disadvantage is, that development environments for FPGAs are very expensive, but this could change in the next years once FPGAs get more populated. My dream solution is a FPGA with integrated CPU, clocked with 100 MHz minimum, low-cost programming interface and free available verilog or VHDL compiler/simulation/synthesis tools - let's see... we are young, we have time :) Best Regards, Thorsten.