TK.

You have to send the SysEx command which matches with the MIDI channel you want to use, e.g. for MIDI Channel 3, send only: F0 00 00 7E 4B 00 06 70 00 10 02 00 F7 and nothing else - don't send all commands I listed - I hope that you get the point ;) I assume that you are using the MBSID V2 firmware, for V1 it's different. If you expect more help, you need to specify some more details, because the method described above works fine at my side, and I doubt that anybody but me can help you on such excotic topics ;) Best Regards, Thorsten.

So long the SysEx editor is not finished, it only works with direct SysEx accesses, e.g. sent with the SysEx tool of MIDI-Ox The SysEx parameters are documented here Changing the MIDI-Channel of SID1, Instrument 1: F0 00 00 7E 4B 00 06 70 00 10 00 00 F7 for Channel #1 F0 00 00 7E 4B 00 06 70 00 10 01 00 F7 for Channel #2 F0 00 00 7E 4B 00 06 70 00 10 02 00 F7 for Channel #3 F0 00 00 7E 4B 00 06 70 00 10 03 00 F7 for Channel #4 F0 00 00 7E 4B 00 06 70 00 10 04 00 F7 for Channel #5 F0 00 00 7E 4B 00 06 70 00 10 05 00 F7 for Channel #6 F0 00 00 7E 4B 00 06 70 00 10 06 00 F7 for Channel #7 F0 00 00 7E 4B 00 06 70 00 10 07 00 F7 for Channel #8 F0 00 00 7E 4B 00 06 70 00 10 08 00 F7 for Channel #9 F0 00 00 7E 4B 00 06 70 00 10 09 00 F7 for Channel #10 F0 00 00 7E 4B 00 06 70 00 10 0A 00 F7 for Channel #11 F0 00 00 7E 4B 00 06 70 00 10 0B 00 F7 for Channel #12 F0 00 00 7E 4B 00 06 70 00 10 0C 00 F7 for Channel #13 F0 00 00 7E 4B 00 06 70 00 10 0D 00 F7 for Channel #14 F0 00 00 7E 4B 00 06 70 00 10 0E 00 F7 for Channel #15 F0 00 00 7E 4B 00 06 70 00 10 0F 00 F7 for Channel #16 F0 00 00 7E 4B 00 06 70 00 10 00 10 F7 to disable instrument Best Regards, Thorsten.

Ja, oder vielleicht auch auf 220 Ohm - darunter wuerde ich nicht gehen Bitte halte mich auf dem Laufenden - vielleicht sollte ich Dir auch mal einen Optokoppler von mir zuschicken, denn es wuerde mich sehr interessieren, ob es wirklich daran liegt. Gruss, Thorsten.

Hi Robin, USER_Tick will be called by MIOS in an endless loop, so yes: it will be called several times until you power-off the core. Beside of USER_Tick, several other handlers will be called consecutively, e.g. the DIN and AIN input checking routine, the MIDI parser, the MIOS_DISPLAY_Tick routine, etc... and once the execution of these handlers has been finished, the sequence re-starts at USER_Tick This method is also called cooperative multitasking So long the other handlers are idle (no DIN/AIN change, no incoming MIDI events, no LCD output, etc) USER_Tick will be called with a period of 20 uS, which is pretty fast! :) In this case, the other tasks will be blocked. The max. acceptable delay depends on your application. There is only one strict requirement: it should never take more than ca. 20 mS, because if the MIDI parser is not called within this time span, the MIDI IN buffer could overrun Note also: than longer USER_Tick takes, than longer the slack time of the other tasks If my own applications, I'm trying to reduce the max. execution time of USER_Tick to less than 1 mS If it takes longer, I program the functions which are handled by USER_Tick in a way that they will be processed step by step with each call of USER_Tick - example: when I'm checking if a new (of up to 8 ) BankStick has been connected to the core module, I'm only checking a single BankStick with each USER_Tick execution. I'm using a counter which is incremented and reset if >= 8 each time my BankStick handler is called, and this counter addresses the BankStick which should be checked. This easy method reduces the execution time of USER_Tick dramatically, and therefore improves the overall performance of the application. Best Regards, Thorsten.

It's ok to create an own setup file, I think that the process to add it to the Makefile(.orig) needs to be documented Best Regards, Thorsten.

Ich habe das letzte mal vor zwei Jahren an der Applikation herumgebastelt, weiss nicht ob das so ohne weiteres geht, habe aber auch keine Lust, mich damit auseinanderzusetzen. Wegen des zusaetzlichen Speicherbedarfs muesste man wohl auf einen PIC18F4620 umsteigen. Die V2.0 wird demnaechst sauber im SVN Repository released - ab dann koennen andere Leute daran weiterarbeiten :) Gruss, Thorsten.

Hi, the MBSID code is located here, and the SID transfer routine in sid_sr.inc, but I guess that it won't really help you. The synth engine which handles the gate is interrupt driven (-> sid_se*.inc), and very complex Did you already solve the issue? If not, I can give you some more explicite hints. The "Pops" could be related to the ADSR bug, which require you to handle the gate very carefully (more infos if still required), and the non-working voices could be related to an erroronous filter assignment configuration Best Regards, Thorsten.

Bingo! My first assumption was, that it came from "Decent" - the other game I played for hours ;) Best Regards, Thorsten.

the message make: *** No rule to make target `setup_6581.hex', needed by `all'. Stop. [/code] is normal if you deleted the setup_6581.asm file So, I think that your tool setup is working perfectly, the mistake was to remove files of the original release. Background: Makefile includes Makefile.orig, and in this file you find following line: [code] all: cleanall setup_6581.hex setup_8580.hex setup_tk.hex setup_mb6582.hex The rules for creating .hex files is located in include/makefile/asm_only.mk # rule for all .asm file(s) # output: .hex file %.hex: %.asm gpasm $(GPASM_FLAGS) $(GPASM_INCLUDE) $(GPASM_DEFINES) $< [/code] It tells us: whenever a rule ("all") depends on an .hex file, the .hex will be built from an .asm file In other words: if "setup_6581.hex" is specified in the dependency list, you need the appr. .asm file as well My proposal: don't remove files - just let them in the directory - otherwise you have to delete dependencies in the Makefile (or Makefile.orig) Best Regards, Thorsten.

Fortsetzung hier: http://www.midibox.org/forum/index.php/topic,11159.0.html

Could you please type following commands, and copy&paste the results here? [tt] D:\>[red]set PATH=D:\posix_bin;%PATH%[/red] D:\>[red]set PATH[/red] Path=D:\posix_bin;C:\Programme\Perl\bin\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\P rogramme\Intel\DMIX;C:\Programme\Gemeinsame Dateien\Roxio Shared\DLLShared\;C:\Programme\Java\jdk1.5. 0_10\bin;C:\Programme\QuickTime\QTSystem\;C:\Programme\SDCC\bin;C:\Programme\gputils\bin PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH D:\>[red]cd midibox_sid_v2_0_rc18[/red] D:\midibox_sid_v2_0_rc18>[red]make[/red] rm -rf *.cod *.lst *.err rm -rf *.hex gpasm -p p18f4685 -I./src -I ./include/asm -I ./modules/j5_io -I ./modules/aout setup_6581.asm gpasm -p p18f4685 -I./src -I ./include/asm -I ./modules/j5_io -I ./modules/aout setup_8580.asm gpasm -p p18f4685 -I./src -I ./include/asm -I ./modules/j5_io -I ./modules/aout setup_tk.asm gpasm -p p18f4685 -I./src -I ./include/asm -I ./modules/j5_io -I ./modules/aout setup_mb6582.asm D:\midibox_sid_v2_0_rc18> [/tt] (replace "D:\posix_bin" by the directory, into which the posix_bin package has been copied) Note that gputils has to be in the path as well - this has already been done by the gputils installer, don't remove this entry! Best Regards, Thorsten.

Ok, wirklich seltsam (aber auch interessant), dass das Problem mit verschiedenen Keyboards auftritt. Vielleicht sind die 6N138 von einem anderen Hersteller, und haben deshalb leicht unterschiedliche elektrische Eigenschaften. Ein aehnliches Problem hatten wir damals beim CNY17-II, doch mit diesem Optokoppler war es noch viel extremer. Das ist eigentlich egal, 1.2k parallel zu 1k ergibt ca. 550 Ohm - das passt schon. Ich werde bei Gelegenheit verschiedene Leute bitten, die 470 Ohm Variante mit ihrem Setup auszuprobieren. Auf Dauer macht es sicherlich Sinn, standardmaessig einen Pull-Up zu verwenden, der mit allen 6N138 Typen kompatibel ist. Gruss, Thorsten.

Ok, super! Es ist nicht das erste mal, dass der Pull-Up Probleme macht. Welches MIDI Keyboard verwendest Du eigentlich? Gruss, Thorsten.

Danke - wie gut dass ich einen Fehlercode fuer "UART Frame Errors" eingebaut habe, der wird hier naemlich gemeldet (Fehlercode #12) - somit ist es kein Softwareproblem. Das MIDI Signal kommt nicht sauber am Rx-Pin an. Probiere mal folgendes: - Optokoppler austauschen (nimm bspw. den vom IIC1 Modul) - R6 vom Core Modul (1.2k) gegen kleineren Widerstandswert austauschen (bspw. 470 Ohm), oder einfach einen 1k Widerstand (oder aehnlich) parallel zum 1.2k schalten - Optokoppler entfernen, und IIC::J4:MI mit CORE::J11:MI verbinden - Keyboard am MIDI In des IIC1 Moduls anschliessen Die Ergebnisse sollten mir genuegend Hinweise fuer die genaue Ursache geben Gruss, Thorsten.

Schade, dass man sich die Signale nun nicht mal mit einem Oszi anschauen kann... Probiere mal verschiedene Widerstandswerte aus, und terminiere zusaetzlich die DIN Kette Gruss, Thorsten.

R2, R12 und R9 sind also auch angeschlossen? Und alle Slaves haben eine eigene MIOS Device ID? (01/02/03)? Was passiert eigentlich, wenn Du die PICs in eine funktionierende MBSID einsteckst (Du hast ja einige zur Auswahl...) Gruss, Thorsten. P.S.: letztes Posting heute - also nur keine Eile beim Testen ;)

Nein, von extern kann man die Slaves nicht neu suchen, weil das normalerweise auch nicht notwendig ist. An den CAN-Routinen habe ich schon seit ca. einem Jahr nichts mehr geaendert, und Du bist eigentlich der einzige, der damit Probleme hat (oder haben die Routinen ein Problem mit Dir? ;-)) Evtl. sind die Slaves nicht rechtzeitig empfangsbereit, so dass der Master sie trotz Retry-Mechanismus (der ca. 10 Sekunden laeuft) nicht findet. Vielleicht hast Du irgendeinen wichtigen Pull-Up an den Slave-Core Modulen vergessen? Welche Bauteile hast Du weggelassen? Gruss, Thorsten.

Das Ausgangsposting steht unter http://www.midibox.org/forum/index.php?topic=11154.0 - dieses Gehaeuse muss gefeiert werden! :) Wegen des MIDI In Problems: es ist nicht auszuschliessen, dass es sich hierbei um ein Performanceproblem irgendwo in der Firmware handelt - das sich aber sicherlich loesen laesst. An manchen Stellen habe ich in letzter Zeit keine Ruecksicht auf Geschwindigkeitsoptimierung genommen. Ich selbst verwende den ersten MIDI In momentan nur fuer den MIDI Clock, der Traffic haelt sich also in Grenzen. Ich versuche morgen mal, das irgendwie zu reproduzieren Eine frage noch: werden eingehende MIDI Events an die Ausgaenge weitergeleitet? Gruss, Thorsten.

Wow, das Gehaeuse ist wirklich beeindruckend! Einen Schreiner haette ich auch gerne in meiner naeheren Bekanntschaft! :) Ich schiebe das Posting mal in die "MIDIbox of the Week" Sektion, das MIDI In Problem koennen wir in einem seperaten Thread versuchen zu loesen. Gruss, Thorsten.

RC18 is out now, which got some improvements and bugfixes, but also some new preset patches. There are no "placeholders" in the vintage bank anymore - time to start the next bank!!! :) From the ChangeLog: o modulation matrix: comparison operators >, < and = now return 0 instead of full negative value if comparison is false o changed SusKey handling, so that it also works in Mono mode (previously it was only working in Legato mode) o SusKey and Legato flags now accessible in Bassline CFG menu o Individual Attack/Decay/Release Curve assignments now accessible in Multi/Bassline ENV menu o Trigger Matrix: since the BPM clock generator concept has been changed in one of the previous releases, we now have a Clk/6 and Clk/24 trigger instead of Clk/4 and Clk/16 o LFO and ENV MIDI sync working properly again o portamento omitted after patch change when first key is played [/code] From the presets/README.txt [code] o replaced Placeholders A035 and A036 by new Drum Kits o replaced Placeholders A037..A044 by new trigger and modulation matrix examples o Patch A089-A91 (not working "Miami1"..3) replaced by "SEQ Bass 4"..6 o Patch A103 and A104 (not working "WT Pseudo S&H") replaced by "Sample&Hold 1" and 2 o Patch A107 (not working "WT Flip LFO") replaced by "Poly Trancegate" Best Regards, Thorsten.

Suppa! :) Best Regards, Thorsten.

This is the MIDIbox made by Sylvain - I especially like the knobs (no, not because of the colours ;))

Thank you! :) Best Regards, Thorsten.

Meanwhile the price for the uC Hacker's kit is US $470 - this might sound too high, on the other hand (IMHO) it's worth the money. The boards are excellently constructed (e.g. the driver board is a 4-layer design), and they are essential to get a stable and nice looking device :) Yes! :) Btw.: the original stribe works with Atmel chips ;) I don't know a distributor, Phineus directly contacted the manufacturer (see http://www.midibox.org/forum/index.php/topic,10308.0.html) Best Regards, Thorsten.

Yes, it's described here: http://www.midibox.org/dokuwiki/midibox64_e_patchmode Best Regards, Thorsten.