TK.

Ok, you tried to build the application based on the old approach, but this doesn't work anymore as stated above. The make.bat file, the makefile generator + all the other tools which were used in older projects are obsolete - just start with the project setup in http://www.ucapps.de/tmp/ks0108_c_example.zip Best Regards, Thorsten.

Ok, so the coding examples under http://www.ucapps.de/mios_c.html are a good starting point. And the ready made Traktorizer Firmware of course (which only supports two decks so far I know, but switching MIDI channels for the additional decks shouldn't be so difficult - especially since the app is written in good readable C code) -> http://www.midibox.org/dokuwiki/doku.php?id=traktorizer_by_mte Best Regards, Thorsten.

Hehe ;) Yagosan: du kannst den PIC auch gerne zum Onkel Doc-tor schicken :) Doc: bitte den Flashinhalt vorher auslesen, in eine .hex Datei schreiben, und mir per email zuschicken. Gruss, Thorsten.

MIOS_MIDI_TxBufferPut() Achso, AVR und irgendeine Library, die Du irgendwo aus dem Web gefischt hast... Gibt es keine uart_putc() funktion, die bspw. das Versenden von uart_putc(0x90); uart_putc(0x3c); uart_putc(0x64); erlaubt? Schonmal in den Source code geschaut, wie uart_puts() die einzelnen Bytes versendet? Gruss, Thorsten.

And another huge & great looking MIDIbox LC has been born! :) MTE wrote:

Works fine at my side under DOS and Mac OS Could you please copy&paste the whole output of the make command? Best Regards, Thorsten.

Hallo, das liest sich so, als waere der Bootloader nicht richtig installiert. Denn wenn der PIC mit Spannung versorgt wird (TEST_CORE4 und 5), und der Quarz richtig angeschlossen ist (TEST_CORE2), dann sollte zumindest die LED am Tx Ausgang flackern (TEST_OUT1) Schicke mir mal den PIC + Rueckporto zu (meine Adresse findest Du im uCapps.de Impressum) Gruss, Thorsten. P.S.: Mit TEST_CORE5 ueberprueft man uebrigens, ob die Masse richtig angeschlossen ist, und es waere sehr unwahrscheinlich, dass die Diode (TEST_CORE7) defekt ist - zumal sie keine Auswirkung auf den MIDI Out hat. Eine Diode kann man uebrigens mit einem Multimeter testen (Widerstandsmessung: Durchlass nur bei richtiger Polung)

I think it's difficult to give you more explicit help, so long we don't know more about your skills. :/ Have you ever programmed in assembly language before? Then some (a lot!) modifications of MB64E application is the way to go. I could list the functions, but I wouldn't be able to hack down the code w/o testing it on the hardware. C skills available? Then it could be better to setup a new C based application which is perfectly tailored for your usecase (this might be much easier than doing changes in the MB64E application) Do you have a lot of time to get into the programming topic? Then we could start to give you more help into this direction. Or you are searching for a solution w/o doing the programming by yourself: then you will have to contact somebody, who did something similar in the past (unfortunately, not all customized projects are documented, only the forum search function will help to locate the people) Best Regards, Thorsten.

A pin-wise reassignment is simply not supported by the code, and it wouldn't be so easy to add such a function (especially to find a way which makes it easy for newbies to change assignments - just see, how confused you are already about the SR wise re-assignments) So, I think it's easier and less time-consuming to fix the solderings Best Regards, Thorsten.

Cur/CAs will be fixed with the next release. You mean a "peek" function, which is sometimes found on other synths to check the value. Normaly "peek" is activated with a special button, or button combination. I guess, that this would be better than ommiting the first Inc/Dec (where a second Inc/Dec could quickly follow if you move the encoder too fast) Best Regards, Thorsten.

I'm not sure if it depends on the BankStick. :/ Here an approach which should work under all circumstances: instead of hassling with SysEx requests and functions which are overwriting the previously written value, just define the MIDI channel directly in the CS_MENU_BANK_RestoreCfg function, and you are done :) Code: S_MENU_BANK_RestoreCfg movlw 0x05 ;; for channel 6 movwf CS_MENU_SID_M_CHN ;; used as SID master MIDI channel return ;;; rest of original code... [/code] Best Regards, Thorsten.

"B6 5B" is sent by the 7th AIN - seems that there is a problem with the pot connected to this input. Best Regards, Thorsten.

The MB808 variant of seq_enc.inc contains a function for a tempo encoder, which maybe can be re-used (I haven't tried it). The encoder pinning has to be added to the encoder table in setup_*.asm Some additional code is required to forward encoder movements of the additional encoder to the SEQ_ENC_Tempo function. This is usually done in main.inc, USER_ENC_NotifyChange Best Regards, Thorsten.

The MIDI channels are stored in EEPROM, but there is a sideeffect with the control surface handler. I assume, that you uploaded "setup_6581.hex" or "setup_8580.hex" instead of "setup_6581_without_cs.hex" or "setup_8580_without_cs.hex" The CS will load the MIDI channel selections of master and slaves from BankStick, and overrule the previously stored EEPROM settings Solution: open cs_menu_bank.inc, search for "CS_MENU_BANK_RestoreCfg", and add " return" below this label (the spaces are important) S_MENU_BANK_RestoreCfg return [/code] Thereafter rebuild the .hex files Or: upload a precompiled "*_without_cs.hex" variant (this will also disable the LCD, therefore the code modification is maybe the prefered solution) Best Regards, Thorsten.

I noticed, that the document is incomplete, because meanwhile we can select the channels of all three oscillators seperately. The change will take place with the next patch change. Here the update: g) F0 00 00 7E 46 <device-number> 0D 02 00 <OSC1 channel> F7 F0 00 00 7E 46 <device-number> 0D 01 00 <OSC2 channel> F7 F0 00 00 7E 46 <device-number> 0D 00 00 <OSC3 channel> F7 Change the MIDI channel Value 00 (for Channel #1) .. 0F (for Channel #16) is expected. Note that the channels of the oscillators can be changed seperately. In normal cases, all channels should be set to the same value. The values are stored in EEPROM, accordingly there must be a delay of at least 5 mS between each SysEx command, otherwise data gets lost The change will take place with the next Patch selection. E.g., you could send a program change (e.g. C0 <patch>) after the SysEx commands. Example for configuring MIDI channel #16 on SID1: F0 00 00 7E 46 00 0D 02 00 0F F7 F0 00 00 7E 46 00 0D 01 00 0F F7 F0 00 00 7E 46 00 0D 00 00 0F F7 C0 00 [/code] Best Regards, Thorsten.

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