TK.

mostly clever usage of envelopes and LFOs are doing the same, sometimes even better than manual edited curves. You can control the ENV/LFOs parameters from MBSEQ V3 very easily. E.g., one single track can control three CC's at the same time, or you can assign a track to Note/Velocity and an additional CC (in this case, the length is statically). If this CC controls a modulation source of the synth, you are fine in most cases. I know, this doesn't help for all cases. But it's an alternative solution of which you propably haven't thought before... Best Regards, Thorsten.

Currently I don't have an imagination, how this should be realized user friendly... I mean: how should the user customize such a "screen and button layout" (step assignments to LCD and buttons), and would he really use it, or would he prefer the standard way because the configuration is too difficult and bad documented? So, if you could give me an exact usage example, how to configure this with the existing MBSEQ hardware (which menu, which encoders/buttons/etc...) I could think about how much effort it would be for me to integrate this. But at the end I think, that I never would use this by myself. So, there must be strong arguments for such a feature! ;-) This doesn't match with the concept and won't work. You can only quantisize with the given resolution while recording live, everything else will consume more memory than planned. Calculation example: currently a pattern consists of 4 tracks, there are 32 steps and 3 layers, makes 384 bytes. There are a lot of parameters for each track, which allocate 128 bytes in addition. So, a whole pattern takes 512 bytes. Accordingly, 64 patterns can be saved in each 32k BankStick, and 128 in each 64k BankStick. This is acceptable, and it can be especially handled very *very* fast now with the PIC18F4620 (in addition I integrated a cache mechanism, so that even the BankStick fetching time cannot be regognized anymore :)) But now your idea to save 16 values per step. This would mean, that each pattern has to allocate 16*384 + 128 = 6272 bytes, accordingly only 5 patterns (instead of 64!) could be saved in a 32k BankStick. And in addition, the step values couldn't be stored in RAM anymore. This is the biggest advantage of the v3 version, your idea would lead to the same situation like with v2 Hope that this makes my point of view more clear... Best Regards, Thorsten.

...and you've measured the voltage again when the SID is in the socket? I only ask to double check this, because - as mentioned above - when e.g. the voltage for a 6581 is lower than 11V, the SID behaves exactly like you've described. With the MBSID and the testtone application... Best Regards, Thorsten.

My thoughts: building a dedicated PCB for mounting two SIDs is much more error prone than building two MBHP_SID modules, because you will have more than 15..16 (or so) connections to the IC socket + an additional CS signal. Instead, two MBHP_SID modules are more compact, and you can stack them ("doubledecker") in order to save space in the case (it works, I already tried this in my C64 case to estimate, if I can build 8 SIDs into the case, or if I need to design a new PCB). Note that the second module doesn't need to be populated completely (the 12V/9V circuit can be used for both, or for all SID in the case modules). So, you would even don't save money when building an 2*SID adapter instead of using an additional MBHP_SID module, it would only increase the propability for loose contacts. Best Regards, Thorsten.

Just open mb64_midi.inc, search for "MB64_MIDI_SendButtonEvent". Here you can make your enhancements, because this functions knows about the button number, it prepares the MIDI event, and forwards it to MB64_MIDI_Send On the other hand: if you neither use the LCD menus (and therefore miss most of the specific MB64 features like MIDI learn, onscreen event editing, morphing), a C application is much easier for that what you are planning to do, and I guess that your work will be much better re-usable for other users. Because a) it's a nice programming example, b) C is easier to read and modify, c) you will see, that the program itself only consumes 2..4k at the end (you don't need most of the MB64 stuff), and d) you don't need to ask me where to find certain parts of hooks, switches, levers, etc... this is also time consuming for myself. So, it would propably be easier for both sides if you would build up an application from scratch. Best Regards, Thorsten.

P.S.: see map.h of the "analog_toolbox" application

Never add such custom functions into MIOS, it makes your application incompatible. Just write the function into a seperate .c or .asm or .inc file, this can be distributed very easily. On the other hand: in my own applications, I don't call functions for such special conversions at all. I mostly do the conversion directly, which is faster. In C you only need to write "value >> 2" to get the same effect, so why creating a function? Best Regards, Thorsten.

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.