TK.

Hast Du die D0..D3 Pins nicht angeschlossen? (Sie duerfen beim PIC18F4685 nicht angeschlossen werden, es wird nur ueber das 4-pin Interface kommuniziert). Ausserdem solltest Du schonmal den Pull-Up und die Diode fuer das CAN Interface anschliessen, ansonsten koennte der Core abstuerzen (und die Wahrscheinlichkeit fuer den Absturz haengt von der verwendeten Firmware Variante ab...) Gruss, Thorsten.

Was passiert, wenn Du das DIN Modul abklemmst? Du musst uebrigens nicht alle 5 Leitungen von Core:J9 abloeten, es reicht Core:J9:DI (Dateneingang) Gruss, Thorsten.

Hi, MIDI Router is a C based application. I guess that you want to indicate the beat based on the received MIDI Clock, right? So, just do the modifications in router.c: hook the code into the ROUTER_Rx_xxx function of the MIDI In Port which receives the MIDI Clock. Add a counter which is incremented on each incoming MIDI clock event (evnt0 == 0xf8) Reset this counter on each incoming MIDI clock start event (evnt0 == 0xfa) or once the counter is >= 24 (-> 24 MIDI clocks = 1 beat) Assumed, that you connect the LED to PIC Pin RC0, you can turn the LED on with PORTCbits.RC0 = 1, and turn it off with PORTCbits.RC0=0 So, turn it on whenever the counter is 0, and turn it off whenever the counter is != 0 Best Regards, Thorsten

you are right! On the other hand: when the encoder is moved, the CS handler will jump into the appr. menu page as well. It isn't a perfect handling for jumping between different menu pages (as values are slightly changed), but in practice it doesn't really hurt (especially because CutOff/Resonance/LFO Depth/Rate are high-resolution values) Best Regards, Thorsten.

Very good work! I should add a special page to the user manual to introduce such layout ideas, because many thoughts went into such designs which should be highlighted. I would prefer such a centered arrangement as well, so that the 5 encoders directly correlate with the displayed values. This would be especially important for the "display" layer. Coding: changes have to be made in cs_menu_enc.inc, cs_menu_enc_table.inc, cs_menu_buttons.inc and cs_menu_leds.inc I would propose to play a little bit with the existing code (e.g. change the order of encoders) to get a feeling about how difficult it is. There is no 1-2-3 documentation available, sorry. Best Regards, Thorsten.

I wrote down my thoughts on the MB808 firmware. Since it's mainly directed to people who already own a MB808 PCB, the discussion is started in the eight-oh-eight forum: http://eight-oh-eight.org/phpbb2/viewtopic.php?p=2047 Note that this application will be useful as low-cost and easy-to-built MIDI drum machine as well! But primary focus is to get the max out of the beautiful MB808 :) (I locked this "link article" to avoid multiple threads about the same topic) Unlocked article, since v1.0 has been reached Best Regards, Thorsten.

The LCD output is controlled by the host (DAW) software. Once it found your "Mackie Control", you should see some meaningful messages. Best Regards, Thorsten.

Bei der MBSEQ sind die Encoder auch so nah beieinander - hier musste ich ebenfalls einen Kompromiss eingehen, und das passt schon irgendwie. Ja, die Laschen bei den Pollin-Gehaeusen sind wirklich aergerlich! :-/ Gruss, Thorsten.

It's really a riddle... Just to get some more hints: could you please do some continuity checks with your multimeter (if it has a "beeper" for such checks, it would be perfect). For such a check, the SID chips and the PIC should be removed from the sockets (not required for the other chips). Don't check on the J15/J10, but put the probers directly into the empty socket holes. - check that the continuity between PIC Pin RD4 and (Right-)SID Pin CS# - thereafter the continuity between PIC Pin RC5 and (Left-)SID Pin CS# Thereafter check that there is no continuity between: - PIC Pin RD4 and ground (Vs) - PIC Pin RD4 and +5V (Vd) - PIC Pin RC5 and ground (Vs) - PIC Pin RC5 and +5V (Vd) - PIC Pin RD4 and RD4 - SID Pin CS#and ground (Vs) (check on both SIDs) - SID Pin CS# and +5V (Vd) (check on both SIDs) - Between the two SID Pin CS# This test should ensure: - that the CS# line is connected correctly (no open wire) - that there are no shorts between PIC and SID Pins against each other or Ground/+5V Best Regards, Thorsten.

In such a case, it wouldn't play any sound at all. The CS# line is triggered whenever a SID register should be changed. No CS# connection -> no register change CS# lines connected to the same output pin of the PIC -> each SID will get the same register changes You mentioned, that with the modified testtone application the volume level is lower. It would be lower, if the audio outputs of both MBHP_SID modules are merged (-> mono), and one SID doesn't play anymore - like in the modified testtone application. Your issue is really strange, I don't have an explanation for this (yet) From where did you get the PCBs? Or is the circuit built on a prototyping board? And just to ensure: did you already check the power supply voltages (0V/5V) at each 74HC595 and the SID? Just to ensure, that they are supplied correctly. If this wouldn't be the case, and if they would get their power from somewhere else (e.g. from the data lines), a lot of strange things could happen ;) Best Regards, Thorsten.

Ok, so now we know that it is probably not a problem at the digital side. Could you please describe, how you are testing the audio outputs? Are they connected to a mixer? Best Regards, Thorsten.

Ok, now a version I tested on my own MBSID testtone_only_r_channel.zip testtone_only_r_channel.zip

Sorry, I overlooked that the CS# lines are low-active Please try the new .hex

I tried different buffer sizes, but finally I decided to use 64 bytes because of following reasons: - in chapter 5.8.3 of USB2 spec it's stated, that "The USB defines the allowable maximum bulk data payload sizes to be only 8, 16, 32, or 64 bytes for full-speed endpoints and 512 bytes for high-speed endpoints" This is a weak requirement, as they don't specify the minimum package size, but to be at the secure side, at least 8 bytes should be prefered as maximum size . 64 bytes are used in the the USB midi spec descriptor example, and it cannot be excluded that any OS gets use of this possibility in order to gain bandwith. So, why reducing the USB slave capabilities? - it cannot be excluded, that the legacy driver wants to send more than one MIDI event package, if it is directed to multiple "midi cables" (= MIDI Out Ports), or if MIDI events are sent to more than one "cable" concurrently for best synchronous timing (e.g. MIDI Clock distributed to multiple devices). Same question: why reducing the USB slave capabilities? Since the transmission of 64 bytes doesn't really hurt (in distance: it could improve performance), I don't see a reason for reducing the EP buffer size Best Regards, Thorsten.

With Java (where memory consumption doesn't matter), you could maybe also do it the following way: convert the decimal value of each 8bit byte into binary strings, and concatenate them one after another to a long, new string. Thereafter split the string into chunks of 7 characters, and convert back binary->decimal to get the 7bit value. Pseudo code: string := "" foreach byte string := string + decimal_to_binary(byte) while lenth(string) && (length(string) >= 7) { SendMIDI(binary_to_decimal(string[0:6])) string := string[7:end] } (this is no official programming language, I only want to demonstrate the algorithm...) Best Regards, Thorsten.

Hi Steve, I can confirm this - the byte count always corresponds with the "bytes per packet" definition, which has been made in the OUT endpoint descriptor. I guess that the actual package size is full under control of the USB host, so it might be a windows specific issue. I believe that the unused buffer area will always be patted with 0x00, because I never noticed something else (e.g. artefacts from previous transfers) In my own class driver, zero packages will be simply ignored: ; -------------------------------------------------------------------------- ; IN: expecting pointer to Tx packet in FSR2 ; OUT: request retry if ZERO flag set! USBCLS_MIDISend movf INDF2, W ; ignore zero packages andlw 0x0f bnz USBCLS_MIDISend_Ok [/code] However, I see the point, that it makes CIN=0 packages useless for future extensions. Best Regards, Thorsten.

Hi, the compile procedure has been simplified - we are not using MPASMWIN anymore, but GPASM So, after you installed GPUTILS, just doubleclick on the "make.bat" file, that is part of the release package. More infos: http://www.midibox.org/forum/index.php/topic,10552.0.html http://www.ucapps.de/howto_tools_gpasm.html README.txt of the release package Best Regards, Thorsten.

Could you please try the "testtone" application in the attachment? It should only output a 1kHz wave at the right channel, the left channel should be silent Can you confirm this? Best Regards, Thorsten.

Individual access to the second (right channel) MBHP_SID module is only possible, when the MBHP_SID::J2:SO input is connected to J14 of the core module. See also http://www.ucapps.de/mbhp/mbhp_8xsid_c64_psu_optimized.pdf, green wires Best Regards, Thorsten.

There is a Java based scrambling routine in the MIOS Studio package - but it doesn't descramble. Unfortunately Java is not like e, where you can easily define a bitvector with unlimited length, pack the 8bit value array into this vector, and unpack a 7bit value array from the vector. Thats basically the approach. In "e" a single line of code, in Java/C... hm... perhaps some more. Best Regards, Thorsten.

Since it isn't the first time you forgot to mention such important details, here a reminder: - when reporting an issue, always check it with the latest firmware (currently: RC17) - if you are not able to use the latest firmware for any reason, please mention this in your posting - please describe the effects you've noticed in a way, which makes it easy for somebody to reproduce the issue If it's too difficult in english, just write in the german section, thats ok from my side. Best Regards, Thorsten. RIOFAQMARKER

How did you measure the RC (=LD) line, with a multimeter, or with a scope? Because the RC signal is a very short pulse, which toggles each mS Here the link to the troubleshooting guide: http://www.midibox.org/dokuwiki/din_module?s=dinx4 The srio_interconnection_test allows you to check, if the signals are still available at the 74HC165, or if there are shorts. Also the midio128 check could make sense - just to ensure that there isn't a usage issue with MBCV Best Regards, Thorsten.

Yes, this should be easy to integrate A new version can be expected in ca. 2-3 weeks :) Best Regards, Thorsten.

Works fine at my side, which engine are you using? Best Regards, Thorsten.

P.S.: so long the module is not available, you can control J5 outputs the following way from C: Add ADCON1 = 0x07; TRISA &= 0xd0; TRISE &= 0xf8; to the Init() hook Now you can toggle the pins with PORTAbits.RA0 = ... PORTAbits.RA1 = ... PORTAbits.RA2 = ... PORTAbits.RA3 = ... PORTAbits.RA5 = ... // no typo! RA4 is allocated by IIC PORTEbits.RE0 = ... PORTEbits.RE1 = ... PORTEbits.RE2 = ... Please let me know if it works (it's untested) Best Regards, Thorsten.