TK.

Hi DocBrown, my hope is, that Microchip will provide a revision sooner or later, so that the IIC_MIDI workaround won't be required anymore. Two months ago they finally accepted the bug and documented it into the errata sheet - more than one year after I reported it... now they are under pressure to fix this bug, otherwise the main customers could jump away from PIC based microcontrollers. So - such a PCB would only increase the number of core module variants, and would make the support even more difficult. Best Regards, Thorsten.

Nein, kann nichts passieren. Der Takteingang liegt zur Haelfte der Zeit sowieso auf 5V ;-) Gruss, Thorsten.

Just remove the two first (!) rrf's + the "andlw 0x7f" Best Regards, Thorsten.

I'm not the owner of the MIOS Studio page, and Adam seems to be in holidays Best Regards, Thorsten.

No, I mean the pins of the jack. When you look into the schematic: http://www.ucapps.de/mbhp/mbhp_core_v3.pdf you will notice that it displays the rear view. Maybe you've mixed this with the front view? This happens very often, therefore I can just recomment: make a quick try and swap the pins - it has helped in most cases in the past. Best Regards, Thorsten.

Thanks :) Yes, You Tube is a nice way for sharing videos, on the other hand I have to take care, that people don't get the wrong impression. E.g., one guy assumed that the timings of MBSEQ are unstable, either because of the sounds that I used (some can only be heart in the bass range, you won't hear them with laptop speakers), or because of the unusual combination of shuffle and step jumps which I only used to demonstrate the possibility for finding a groove just by tweaking the step progression parameters. And the other point is, that some people assumed that I'm selling this stuff. Thats also the reason why I've (maybe temporary, maybe forever) changed the layout of the ucapps.de mainpage. The Synth patch is #102 (Whats that?") of the MBSID preset library, it's basically a synched sound, where two oscillators are tuned -24 semitones and modulated by a LFO. In addition, I'm using different portamento values for each voice, which makes the transitions between two notes more interesting. 2: no, I cannot support 32 knobs or buttons - than more of such control elements, than worse the timings. I already spent a lot of effort to keep the timings stable (preemptive multitasking, tilewise LCD updates, etc...), and I measured and optimized the responses via scope. -> before this leads to an endless discussion again: more is not possible, not with a 8bit microcontroller. Maybe with a 16bit or 32bit controller, but let's discuss about this in 3 years or so... ;-) Currently you have to switch between step 1-16 and 17-32 with a double click on the edit button. In addition, the sequencer can optionally (!) switch to the second page automatically while these steps are played. This is an option, since sometimes it's better not to switch back and forth... LFO: this will be a feature of stryd_one's sequencer, no? I'm not sure, do you mean interpolation between the steps (e.g. 8 contemporary values sent between two steps for smooth CC sweeps), or do you mean stepwise playing (like it is already implemented?). I fear that interpolation can cause so much MIDI traffic, that the note could be delayed unintentionally. My focus was always on best timings, such features could falsify the results. I can have it back in my mind if a see a chance, but currently I'm busy enough with other stuff (and with some vacation :)) Something what I could add very easily is the possibility to generate waveforms and to store this automatically into the CC slots. E.g., a sine which goes over 32 steps, or two periods, or four periods, etc... here I must say: I like this idea (so long interpolation between the steps is not required). Alternatively it will be possible to record CC sweeps anyhow (live recording is already in the whishlist) Best Regards, Thorsten.

Have you ever tried to swap the pins on the MIDI jacks - just to be shure that you haven't misread the original schematic? Just a question (it is described in the MIDI troubleshooting guide, but although you've mentioned this, I'm not sure if you really did all the tests) Best Regards, Thorsten.

Are all *LEDRING* settings assigned to 0 (disabled)? Best Regards, Thorsten.

Before you are doing this, one hint. Even you mentioned, that you've measured 11.8V (so ca. 12V) between ground and Vdd, do it again when the SID is plugged into the socket. Because the effect you are describing is exactly the effect when the Vdd voltage is too low (I just remembered this) - it can for example happen, when the 78L12 is soldered in the wrong direction. Please compare it with the pictures on the MBHP_SID page. Don't try another orientation when you are unsure (it could damage the SID), just compare and measure. Best Regards, Thorsten.

This requires a different mapping routine. I cannot give you the code immediately, but I can give you a more simple starting point: remove the whole code of MB64_LED_Update, and write: MB64_LED_Update SET_BSR MB64_BASE ;; we don't want to overwrite MIOS_PARAMETER1, save it in TMP3 movff MIOS_PARAMETER1, TMP3 movff MB64_BUTTON_VALUES_SR0, MIOS_PARAMETER1 movlw 0 call MIOS_DOUT_SRSet movff MB64_BUTTON_VALUES_SR1, MIOS_PARAMETER1 movlw 1 call MIOS_DOUT_SRSet movff MB64_BUTTON_VALUES_SR2, MIOS_PARAMETER1 movlw 2 call MIOS_DOUT_SRSet movff MB64_BUTTON_VALUES_SR3, MIOS_PARAMETER1 movlw 3 call MIOS_DOUT_SRSet movff MB64_BUTTON_VALUES_SR4, MIOS_PARAMETER1 movlw 4 call MIOS_DOUT_SRSet movff MB64_BUTTON_VALUES_SR5, MIOS_PARAMETER1 movlw 5 call MIOS_DOUT_SRSet movff MB64_BUTTON_VALUES_SR6, MIOS_PARAMETER1 movlw 6 call MIOS_DOUT_SRSet movff MB64_BUTTON_VALUES_SR7, MIOS_PARAMETER1 movlw 7 call MIOS_DOUT_SRSet ;; restore MIOS_PARAMETER1 from TMP3 movff TMP3, MIOS_PARAMETER1 return [/code] Now I guess it's easier to do modifications. Best Regards, Thorsten.

I haven't checked your main.asm, since I don't own your hardware... I've only checked if the .syx can be generated and uploaded, and if all changes take place. But there isn't that much which could be made wrong. The special function buttons should be assigned to non-existing DIN pins if not used - e.g., just assign them to 128, with 0 the first button won't work Best Regards, Thorsten.

I think the right place is TC_ENC_SendMIDI in tc_enc.inc Best Regards, Thorsten.

Are you able to receive "snail mails"? Then you could send me the SID for testing together with the return postage Best Regards, Thorsten.

Both. From the physical side, MIDI is an asynchronous data stream without handshaking. This means: there is a fixed baudrate, and a receiver cannot hold the transfer if it is not able to handle it immediately. So, now think about what happens when two MIDI streams should be merged and output over the same interface with the same bandwidth. Once the bandwidth of both input streams is greater than 50% (which is the case for the LC protocol when meter values are permanently updated), the typical bottleneck issue will pop up. So, this issue can either be bypassed by parsing the streams from a Core which has direct access to multiple MIDI inputs, or by sending the data to the core with an interface which is faster than MIDI (e.g. IIC) The use of a USB chip has the advantage, that USB itself has a much higher bandwidth, and it's also possible to provide multiple MIDI In "cables" (virtual devices) for the host application. Problem: MIOS is not compatible to USB PICs, so everything has to be developed from scratch, you can expect ca. 1..2 years effort for this. The use of multiple MBHP_IIC_MIDI interfaces has the advantage, that this is a known stable hardware, the development effort is much lower (maybe 2..3 months for somebody with programming skills, assumed that he has the hardware already available) yes... Yes... as mentioned above, there are solutions, even with MIOS. I only hope that your question doesn't mean "if it is possible -> TK: implement this!". So, it has to be done by somebody with time, motivation and knowledge (I mainly don't have the >time< to help here, too much other interesting projects are running in parallel) Best Regards, Thorsten.

No, but I know companies which first develop a graphical simulation/emulation in a simple programming language (e.g. visual basic or Java). This has the advantage, that many people can review the concept with a common computer before the hardware will be developed. Best Regards, Thorsten.

Do you mean the frontpanel, or the interface logic (button/LED/encoder handling + LCD menu pages, etc) For frontpanels I'm normaly using "Frontpanel Designer", which is freely available at the website of Schaeffer Apparatebau. The result doesn't look so colourful like known from other panel drawings I found here in the forum, but the big advantage is, that it's more realistic (you can print out the panel and compare it with the real dimensions of the parts which should be used), and not at least it can be easily ordered (no doubleeffort, one-click-buy ;-) Best Regards, Thorsten.

Mapping can be so easy when you just modify the existing functions. Let's say, you want to toggle between LED 1-32 and 33-64 - this requires, that the appr. LED patterns 1-32/33-64 are mapped to the same shift registers in main.asm: #define DEFAULT_DOUT_SR_PIN_01_08 1 #define DEFAULT_DOUT_SR_PIN_09_16 2 #define DEFAULT_DOUT_SR_PIN_17_24 3 #define DEFAULT_DOUT_SR_PIN_25_32 4 #define DEFAULT_DOUT_SR_PIN_33_40 1 #define DEFAULT_DOUT_SR_PIN_41_48 2 #define DEFAULT_DOUT_SR_PIN_49_56 3 #define DEFAULT_DOUT_SR_PIN_57_64 4 [/code] Now you have to modify the LED update loop, so that it either starts with the first shift register, or with the 5th shift register depending on the state of your shift button. In addition, the loop has to handle 4 instead of 8 shift registers: [code] ;; ------------------------------------------------------------------ ;; now transfer the LED values to the appr. DOUT registers ;; ------------------------------------------------------------------ TABLE_ADDR MB64_LED_DOUT_MAP lfsr FSR0, MB64_DATA_BUFFER clrf TMP1 ; used as loop counter ;; BEGIN MODIFCATION (add offset depending on shift button) IFCLR SHIFT_BUTTON, 0, rgoto MB64_LED_Update_SRLoop_NoShift MB64_LED_Update_SRLoop_Shift ;; shift button active -- add offset of 4 to FSR0 pointer movlw 4 addwf FSR0L, F ;; and add it to the table pointer as well TABLE_ADD_W MB64_LED_Update_SRLoop_NoShift ;; END MODIFCATION MB64_LED_Update_SRLoop ;; we are using the MIOS_DOUT_SRSet function ;; copy value to MIOS_PARAMETER1 movff POSTINC0, MIOS_PARAMETER1 ;; copy mapped DOUT shift register to WREG tblrd*+ ;; skip if DOUT disabled incf TABLAT, W bz MB64_LED_Update_SRLoopNext movf TABLAT, W ;; execute DOUT SR set function of MIOS call MIOS_DOUT_SRSet MB64_LED_Update_SRLoopNext ;; loop until last SR (#7) reached incf TMP1, F ;; BEGIN MODIFCATION (was: IFCLR TMP1, 3, ...) IFCLR TMP1, 2, rgoto MB64_LED_Update_SRLoop ;; END MODIFCATION (here I assume, that the shift status is stored in a variable with the name "SHIFT_BUTTON", bit number #0, and that it is located within 0x00...0x7F (access range), e.g. at 0x70. Your variable has propably another name, just change the code accordingly. So: 4 lines of additional code + one modified line (lost in the deep grounds of this forum if never stored in the Wiki ;-) Best Regards, Thorsten.

Hm... to which DOUT Shift Registers are your LEDs connected, and what are your modifications in the .asm file? So far I remember, adaptions have to be made in following lines: ; --> define the DOUT registers which are connected to the LED rings here: ; --> the shift registers are counted from one here - means: 1 for the first, 2 for the second, etc... ; --> please mark unused ledrings with 0 #define LEDRINGS_SR_ENC1_16_CATHODES_1 1 ; first shift register with cathodes of the first 16 LED rings #define LEDRINGS_SR_ENC1_16_CATHODES_2 2 ; second shift register with cathodes of the first 16 LED rings #define LEDRINGS_SR_ENC1_16_ANODES_1 3 ; first shift register with anodes of the first 16 LED rings #define LEDRINGS_SR_ENC1_16_ANODES_2 4 ; second shift register with anodes of the first 16 LED rings #define LEDRINGS_SR_ENC17_32_CATHODES_1 0 ; first shift register with cathodes of the first 16 LED rings #define LEDRINGS_SR_ENC17_32_CATHODES_2 0 ; second shift register with cathodes of the first 16 LED rings #define LEDRINGS_SR_ENC17_32_ANODES_1 0 ; first shift register with anodes of the first 16 LED rings #define LEDRINGS_SR_ENC17_32_ANODES_2 0 ; second shift register with anodes of the first 16 LED rings #define LEDRINGS_SR_ENC33_48_CATHODES_1 0 ; first shift register with cathodes of the first 16 LED rings #define LEDRINGS_SR_ENC33_48_CATHODES_2 0 ; second shift register with cathodes of the first 16 LED rings #define LEDRINGS_SR_ENC33_48_ANODES_1 0 ; first shift register with anodes of the first 16 LED rings #define LEDRINGS_SR_ENC33_48_ANODES_2 0 ; second shift register with anodes of the first 16 LED rings ; #define LEDRINGS_SR_ENC49_64_CATHODES_1 0 ; first shift register with cathodes of the first 16 LED rings #define LEDRINGS_SR_ENC49_64_CATHODES_2 0 ; second register with cathodes of the first 16 LED rings #define LEDRINGS_SR_ENC49_64_ANODES_1 0 ; first shift register with anodes of the first 16 LED rings #define LEDRINGS_SR_ENC49_64_ANODES_2 0 ; second shift register with anodes of the first 16 LED rings ; This DOUT map allows you to customize the MB64E application to different hardwares ; The MB64E dump structure allows the use of up to 64 LEDs, they are grouped to 8 LEDs per shift register ; Define the used shift registers for the LEDs here ; the shift registers are counted from one - means: 1 for the first, 2 for the second, etc... ; mark unused LED groups with 0 ;; NOTE: by default, the first four DOUT shift registers are used for the encoders #define DEFAULT_DOUT_SR_PIN_01_08 5 #define DEFAULT_DOUT_SR_PIN_09_16 6 #define DEFAULT_DOUT_SR_PIN_17_24 7 #define DEFAULT_DOUT_SR_PIN_25_32 8 #define DEFAULT_DOUT_SR_PIN_33_40 9 #define DEFAULT_DOUT_SR_PIN_41_48 10 #define DEFAULT_DOUT_SR_PIN_49_56 11 #define DEFAULT_DOUT_SR_PIN_57_64 12 [/code] So, which values did you specify in your .asm file? Best Regards, Thorsten.

Das ist wirklich eine FAQ, die schon mehrmals beantwortet wurde, deshalb in Kuerze: vor allem bei ungerasterten Encodern kann MIOS die vierfache Aufloesung erzielen (siehe http://www.ucapps.de/mios/mios_encoder_modes.gif), und zusaetzlich gibt es dann auch noch die verschiedenen Speed Modes. Die funktionieren aehnlich wie bei einer Computer-Maus - schiebe die Maus mal langsam ueber den Tisch, der Pfeil wird sich sehr exakt ansteuern lassen. Bewege sie schneller, und der Pfeil huscht mit einer kurzen Handbewegung ueber den gesamten Bildschirm. Dieses Verhalten laesst sich auch bei allen MIOS Applikationen so einstellen und nach persoenlicher Vorliebe anpassen :) Gruss, Thorsten. WIKIMARKER

Maybe there is somebody in your environment or country who owns a C64 and/or a MIDIbox SID? Best Regards, Thorsten.

Short question: are you using the buttons in OnOff, OnOnly or Toggle mode? Because in OnOff they should behave very similar to MIDIO128 (the same routines are used) - the only difference is, that MIDIO128 uses a mixed form of the LED modes - LEDs are turned on/off with the buttons AND via external MIDI events (if enabled) Best Regards, Thorsten.

Some words to the idea of virtual XT's: each Unit requires a dedicated MIDI In/Out pair, this is one drawback, because the Core provides only one MIDI IO. Merging these events with an external MIDI merger (either PC software or hardware based) will lead to new problems, because the MIDI traffic caused by the host when meters are displayed is already so high, that two merged ports would lead to more than 100% of the possible MIDI bandwidth (bottleneck problem). There are solutions to overcome this, e.g. one or more MBHP_IIC_MIDI modules could be used as MIDI IO expander, or a USB connection could be realised. But the implementation effort is very high - to high for somebody, who is already happy with his MIDIbox LC ;-) Panasonic/Alps: the Panasonic faders are really great, but today I would still prefer the Alps faders due to the touch sensor - this is a very important feature, not at least because it prevents that values are sent when the fader is not touched - this allows to increase the resolution (because jittering values are not sent when you don't move the fader), and values are also not send due to case vibrations. Panasonic Faders with touch sensor: this would be ideal! Best Regards, Thorsten.

As mentioned in this posting: http://www.midibox.org/forum/index.php?topic=7104.0, you've propably uploaded an old .syx file, because the conversion lead to an error message. So, maybe your results will be different when you are trying a new .syx Pitch Bender/Aftertouch Events: maybe the MIDI-Ox parameter "SysEx delay after F7" is not high enough, in this case it can happen that invalid data is written into flash. This is a general problem when no BankStick is used (writing into flash takes much longer, and interrupts must be disabled, therefore new data cannot be received). There is a very simple solution (I know this sounds stupid, but it's the easiest one): upload the .syx 2 or 3 times, until it works. A better solution: write a software which waits for the SysEx response from the PIC before sending the next block... just want to say: nobody maintains SysEx upload tools anymore, anybody else has to do this in order to make the configuration more user friendly... As for the jitter: I think it is either related to your PSU (try the one of your MB64), or it is related to the wiring to the core. Maybe you could try out more and report new details, this could lead to a new idea what could go wrong... Best Regards, Thorsten.

Your .ini and .syx file was very helpful to analyse the problem. When you convert the .ini from a command shell, following error will be displayed: ERROR in section ENCS, line 345: MIDIBOX64E only offers 128 pot/encoder entries! This is because of a 129th entry, which is out of range: 129 = B0 16 [00-7F:40] "unused" DEC| This could be the reason why nothing changed, because the old .syx file won't be touched - it was the old one. I removed this "129" entry, and tried it on my MBLC - it worked. The strange thing is, that in your second posting above, there was no "129" entry, but maybe there was another error message? Can you reproduce this? Best Regards, Thorsten.

No, 0.01V are fine ;-) If the interconnection test is working, I cannot say what could cause such an effect. Are you able to test the SID on a C64? Best Regards, Thorsten.