TK.

Hi Chris, if the core sends a lot of MIDI data all the time, you propably forgot to connect all unusued analog pins to ground (-> the AUAIMBCTG rule, see also http://www.ucapps.de/mbhp/auaimbctg.pdf) Yes, such a permanent data stream can lead to a hang up in MIOS Studio - this is java related, the data traffic is just too high for Java Best Regards, Thorsten.

Thank you! I've uploaded the new version to my webpage Best Regards, Thorsten.

These are very strange measuring results, especially the different reference points (Vdd/Vss) irritate me. E.g. for the SC check I'm not sure, if voltages are measured against Vdd or Vss, or if you mixed the reference points so that you always get ca. 5V... Please only measure against Vss (ground) And do this check with and without connected DOUT/DIN modules (without the modules only the selected line should be at ca. 5V, all other lines should be 0V) Best Regards, Thorsten.

The "object file" switch has to be disabled like shown in this picture: http://www.ucapps.de/howto_tools/mpasm4.gif Best Regards, Thorsten.

Scheinbar stehen heute die Sterne besser ;-) An solchen sporatischen Aussetzern sein meistens Programme schuld, die im Hintergrund den Druckerport scannen. Bei mir macht das bspw. der "Dell Network Manager" (war standardmaessig installiert). Es hat mich Tage gekostet, bis ich auf die Idee kam, dass dieses unscheinbare Programm evtl. waehrend des Brennens auf den Druckerport zugreift... :-( Frueher (unter DOS) war alles einfacher! Gruss, Thorsten.

Ich bin mir nicht sicher, ob man die SMDs Chips bspw. durch Ueberhitzung schrotten kann. Bei mir hat es eigentlich ganz gut geklappt, obwohl ich ziemlich unbedarft - und vor allem mit einem untemperierten Loetkolben - an die Sache herangegangen bin (ok, ich hatte mir sicherheitshalber auch gleich 3 alte Soundkarten besorgt...) Das Problem an diesen Chips ist, dass man eigentlich nur mit einem Oszilloskop erkennen kann, ob und was sich noch tut. Deshalb bin ich etwas ratlos, wie man bspw. mit einem Multimeter weitertesten koennte. :-/ Vielleicht solltest Du einfach nochmal ein oder zwei weitere Soundkarten auftreiben, und dann beim Entloeten noch vorsichtiger sein. Ein zweiter YAC512 macht sowieso Sinn. Gruss, Thorsten.

Suche mal in mb64e_midi.inc nach "MB64E_MIDI_SendEncEvent_M3". Hier wird bereits zwischen zwei Werten unterschieden. Ich weiss momentan nicht, ob der Meta Handler ueberhaupt Relative Events erhaelt... wenn der richtige Encoder Modus aktiviert ist, eigentlich schon, aber ich kann es nicht garantieren... Im Notfall einfach den Code unter MB64E_MIDI_SendEncEvent_M3 abaendern, und den 4. Encodermodus (40 +/- 1) aktivieren Gruss, Thorsten.

Hallo, das project.hex file ist fix und fertig compiliert, man muss hier eigentlich nichts weiteres mehr einstellen, oder gar neu kompilieren (das geht mit "make" von der Kommandozeile, erfordert den GNU assembler gpasm) Ich habe das Package nun mal von meiner Webseite heruntergeladen, und das project.hex File mit dem PBrenner v1.4 (*) und dem MBHP_BURNER programmiert - funktioniert. Man merkt das daran, dass beim Einschalten des IIC_MIDI Moduls die gruene LED leuchtet. Die wird vom Programm aus eingeschaltet. Auch die MBSEQ V3 erkennt das Modul. Welchen "Brenner" verwendest Du, und welche Programmiersoftware? Was sagt der Compare/Verify? Ist die Programmierspannung auf 13V eingestellt? Falls das Modul nicht anlaeuft: verwendest Du auch 15pF Kondensatoren an RA6/RA7? Mit 33pF Kondensatoren (wie beim Core Modul) schwingt der Quarz nicht an. Gruss, Thorsten. (*) die aktuelle PBrenner Version laeuft bei mir nicht, meine LPT Karte wird nicht erkannt. Sprut ist informiert, hat mir jedoch bisher noch nicht geantwortet...

Gleich vorweg: ich weiss nicht, was hier schief laeuft - der Sache muss nachgegangen werden! Ich habe nun das Update Package von meiner Webseite heruntergeladen, und die Datei bootloader_v1_2b_pic18f452.hex in einen PIC18F452 Rev.7 gebrannt. Hardware: MBHP_BURNER, Software: P18 V1.7 Und das funktioniert wie erwartet... Es ist hoechst seltsam, dass der alte Bootloader bei Dir funktioniert, und der neue nicht. Was ist anders an Deinem Setup? Welchen "Brenner" verwendest Du, und welche Software zum Programmieren? Welche Programmierspannung wurde angelegt? Hast Du das Programmieren mehrmals ausprobiert? Was sagt der Compare/Verify? Gruss, Thorsten.

After almost one year of conceptional and implementational work, I'm happy to announce the release of MIDIbox SEQ V3.0! :) Details about the project can be found at: the main page: http://www.ucapps.de/midibox_seq.html the hardware options page: http://www.ucapps.de/midibox_seq_options.html the user manual: http://www.ucapps.de/midibox_seq_manual.html [br] Thanks to all who contributed to the project by giving ideas, providing scale tables, joining the beta test or just motiviating me to finish the project. But wait: the project is not really finished, because there is still some free memory in the PIC18F4620 which needs to be filled with some additional features! ;-) Best Regards, Thorsten.

Das ist in dieser Form leider nicht vorgesehen. Ich kann Dir auf Anhieb auch keinen funktionierenden Code geben, muesste erst selbst rumprobieren. Momentan sind zuviele Codefragmente von MBSEQ V3 und MBSID V2 in meinem Kopf... ;) Gruss, Thorsten.

This will be possible with the multi engine of MBSID V2 see http://www.ucapps.de/midibox_sid_v2_wishlist.html Best Regards, Thorsten.

Dann schaut es wirklich schlecht aus! Der SID chip ist defekt :-/ Gruss, Thorsten.

The second SID module is connected to the same pins like the first one, just only the CS# line is connected to J14 of the core module to allow individual accesses All core modules (master/slave) support a AOUT or AOUT_LC module I will implement several options on request. The AOUT gates will be supported of course Currently not, as the PIC18F4685 is not completely software compatible, the RAM area from 0x60-0x7f is not directly accessible. But with some small changes in the code, the MBFM application will run. This is on my TODO list, but currently other things have a higher priority Best Regards, Thorsten.

Thanks for the input, Dave! Ole has already informed me about your posting, your observations are very helpful! Especially because you've encountered exactly the same problem! It seems that Mike has done everything correctly. He sent me a .hex readout of a programmed PIC18F4620, and it matches 1:1. So, I definitely need Ole's PIC in order to continue with the analysis. thats an interesting speculation, as flash memories are sensitive against X-rays. But with todays scanners this shouldn't be an issue anymore, otherwise 1000 of people would lost their MP3 collection when they are scanned at the airport... however, nothing can be excluded. Best Regards, Thorsten.

Wenn Du den Momentanwert, und nicht den im Snapshot abgespeicherten Wert versenden moechtest, muesstest Du in der MB64_PATCH_Send Funktion noch die "call MB64_DUMP_RestorePatch" Anweisung entfernen Gruss, Thorsten.

Hast Du mal das DIN Modul abgeklemmt? Hast Du mal den Patch neu aufgespielt? Gruss, Thorsten.

Hallo, in mb64_patch.inc nach "#if DEFAULT_NUMBER_BUTTONS" suchen, und durch "#if 0" ersetzen Gruss, Thorsten.

It can be assumed, that the PICs from SmashTV are programmed properly, otherwise you wouldn't have MIOS preinstalled - MIOS has been uploaded via MIDI (this is a great quality assurance :)) So, voltages are ok, connections are ok, it must be any other hardware related problem. Maybe the crystal or the 33pF caps? Best Regards, Thorsten.

Hoert sich wirklich seltsam an, so ohne weiteres kann ich mir nicht erklaeren, welcher Parameter hier die Frequenz verbiegt. Du koenntest einfach mal die DIN Module voellig abklemmen (es wuerde ausreichen, den pin J9:SI am Core Modul zu trennen). Ausserdem koenntest Du den Patch nochmal aufladen - vielleicht ist ja nur der SysEx Transfer schiefgelaufen. Gruss, Thorsten.

Die Links zeigen leider ins leere :-( Gruss, Thorsten.

I don't think that the crystal is the problem - you wouldn't be able to upload a program (wrong baudrate) It sounds like a software problem (wrong data conversion), but when I look into the program, I cannot see an error, and unfortunately I'm not able to test this with my own equipment so easily (means: it could take weeks until I find the motivation to open the case and to resolder my AOUT_LC modules, just to test if the conversion is done correctly). On the other hand: are you really sure, that the modules are configured correctly for 2*8 bit mode. What happens when the CV outputs are controlled via CC events? Are you able to sweep over the whole voltage range? (compare with http://www.ucapps.de/mbhp/mbhp_aout_lc_res_options.gif And another note: the Hz/V curve normaly requires a resolution higher than 8bit, otherwise it isn't accurate enough. You could try the 12/4bit resolution (with the appr. setup in main.asm) - this is the one which I've tested on a MS20 I'm also interested in this - or in a substitute for the MAX6007B shunt (I'm not an analog expert) Best Regards, Thorsten.

Very innovative and great presentation! :) I'm curious about the technical details of the hand tracker. Does it allow to scan for different gestures? And is it possible to generate 3d controller informations? Looks like you've invented the "3d beam" :) Best Regards, Thorsten.

Thanks again, Stryd! :) You've included much more scales than really required, they consume a lot of memory. However, so long I haven't reached the max (there are still ca. 6k free) I will left the tables as it is. General info: the user manual is 80% finished, a final release can be expected in the next days. In addition to the new scale tables, it will also get a bugfix for the morphing function Best Regards, Thorsten.

It's a limitation of the program. :-( You have to use TL's Patch Manager instead, but it only runs under Windows Best Regards, Thorsten.