TK.

yes, it's pure SID sound. I added a feedback pot to the first bassline (controlled from the middle octave of the keyboard) for increased resonance and distortion. Enabling the EXT + LP + BP flag of the filter is doing the trick. In addition there are some external EQs, a compressor and a delay for each channel of course... You could use a reduced MB64 with some buttons and pots/faders as keyboard replacement :) Best Regards, Thorsten.

This time the "making off" has been recorded on video - hope that it inspires you :) FrgdErwTJ5o Best Regards, Thorsten.

P.S.: bei der Erst-Installation muss die Firmware noch via MIDI auf die Slave-Cores geladen werden. Gruss, Thorsten.

Hallo Suital, die Meldung "CAN Bus Errors" bei selektiertem SID1 deutet darauf hin, dass der Master seine eigenen Packete nicht empfangen hat. In diesem Fall geht das CAN Interface in den Passiv-Status, um das Netzwerk nicht weiter zu stoeren. Ueberpruefe mal die Polaritaet der Dioden (in Wilba's Schaltplan D1_CORE1, D1_CORE2, ... genannt), sowie den Pull-Up Widerstand R80 (1k) Gruss, Thorsten.

another thought: what is the required setup time between data port and enable signal? Does it work better when some NOPs are inserted between the access to data port (movwf USER_LCD_LAT_D) and busy bit polling routine? I guess, that your PC toggles the enable line with a much higher delay Best Regards, Thorsten.

Hi Wicked1, this seems to be a documentation error - the trigger layer LEDs are located at TMP4,4 ... TMP4,6 Bes Regards, Thorsten.

Hi Jaywar, no, it isn't required to recompile code. No, this isn't a common problem. The root cause has to be found. First question: you wrote that the MIDI In of your PC is connected to the MIDI Out of the IIC Module. But has the MIOS installation been prepared for communication with the IIC module? This has to be done by changing the PIC ID header. If this hasn't been done by SmashTV, you need to do this by yourself by using the change_id application (-> upload the iic_midi_10.hex file). So long the IIC module is not accessed from MIOS, use the MIDI Out of your core module. If you already did this, then check the J3 jumpers of your IIC_MIDI module - the have to be stuffed (closed) to select device ID 10. Best Regards, Thorsten.

Great to hear that it is working now! :) Best Regards, Thorsten.

Hi Rutger, currently an ensemble can only be selected from control surface. A change takes very long (ok, long is relative: ca. 250 mS), during this time additionally received MIDI data could get lost. Therefore I'm not sure if it is a good idea to provide such a function. Another issue: which MIDI channel should be used? And which MIDI event? Program Change and Bank Change are already allocated... Best Regards, Thorsten.

thats fine, the modules are working. Core MIDI In data is not forwarded to the IIC slaves (see also main.c) Concerning the LEDs: the anodes (-> larger legs) are correctly marked with a "+" sign, I think the detail which confuses is the wrong orientation of the LED footprint Best Regards, Thorsten.

This requires some more experiments in order to understand, what is going on. Some thoughts: spaces will be inserted after (or before?) the same character combination independent from the delay. ASCII codes: F->G 1) 0x46 -> 0x47 J->K 2) 0x4a->0x4b L->M 3) 0x4c->0x4d N->O 4) 0x4e->0x4f R->S 5) 0x52->0x53 T->U 6) 0x54->0x55 Binary codes (only lower nibble) 1) 0110 -> 0111 2) 1010 -> 1011 3) 1100 -> 1101 4) 1110 -> 1111 5) 0010 -> 0011 6) 0100 -> 0101 Noticable similarities: When it happens, Bit #1, #2 and #3 don't change, only Bit #0 toggles Is this really deterministic? E.g., what happens when you are printing FGFGFGFGFG And what happens, when you are printing NGNGNGNGNG? does the same happen with fgfgfgfgfg and ngngngngng? Best Regards, Thorsten.

Could you please read your mail again and correct it? There is no difference between the code I initially gave you (and from which I think that it is a suboptimal solution), and the code you copy&pasted into your mail. yes, thats what the code is doing, but it isn't a consistent solution. E.g., if the track should record arp events, you will hear totally different notes instead of the arp events. Therefore I think it's better just to let transposer/arpeggiator enabled, but not to change the scale/chords during recording. Best Regards, Thorsten.

das reicht auch fuer diesen Monat! ;-) Gruss, Thorsten.

It's very unlikely that the caps are causing such an issue. In order to see a picture of "VIELSCHICHTKONDENSATOR", visit www.reichelt.de and type this keyword into the search mask - they are looking similar to tantulum caps I'm using the same caps - but as mentioned before: the cap type doesn't matter here, they don't have essential functions. Best Regards, Thorsten.

Ooops, I did it again ;-) Best Regards, Thorsten.

I spent some thoughts on this issue, and came to the conclusion, that your proposed solution just goes into the wrong direction. It's much easier (and especially consistent) to prevent, that incoming note-on events will be forwarded to the arpeggiator/transpose function while record mode is active. Therefore I added following abort condition to seq_midi.inc, SEQ_MIDI_NoteOn function: SEQ_MIDI_NoteOn SET_BSR SEQ_BASE ; prepare BSR for SEQ register access movf MIOS_PARAMETER3, W ; branch to NoteOff if velocity is zero skpnz rgoto SEQ_MIDI_NoteOff ;; prevent that incoming note-on events will be forwarded to transpose/ ;; arpeggiator function while record mode is active BIFSET SEQ_MODE1, SEQ_MODE1_RECORD, BANKED, return [/code] This one will be part of the next release. Best Regards, Thorsten.

It would be interesting, if an AVR port of an application like MBSID V2 is possible without limitations. E.g., due to the reduced instruction set of AVR, I would expect a higher memory consumption. Also the direct way how PIC addresses RAM leads to a different (more efficient) programming model. However, I'm also sure that it is a very time consuming task, especially when you need to dig through foreign code in order to understand each detail and design consideration. It's mostly less time consuming to build up something from scratch. Best Regards, Thorsten.

Hi, no, I haven't tried this yet, but a code- and performance comparison based on a real (and very complex) project like MBSID V2 could be very interesting. Best Regards, Thorsten. P.S.: for those who could think that I'm considering to use AVR in future: don't worry, my own plans are to migrate the MBHP/MIOS to a 16bit or 32bit controller in mid term, therefore I still don't consider to use a different 8bit controller for my projects.

Der Ansatz ist um Grunde richtig - erstmal alles in C einhacken, und die Performance kommt beim Buegeln. ;-) MIOS ist nach wie vor komplett in Assembler geschrieben, das Interfacing zu SDCC erfolgt ueber einen Wrapper. Mit C kann man auf keinen Fall die gleiche Performance erwarten - vor allem das Stack- und Heaphandling wuerde sehr viel Zeit kosten, und es wuerde auch nur noch ein HW-Pointer zur Verfuegung stehen... beim AVR sieht das natuerlich anders aus, doch Wunder sind hier nicht zu erwarten. C Code baut nun mal auf bestimmte Methoden auf, die zwar universell, doch nicht immer optimal sind. Gruss, Thorsten.

Yes, it really looks like something is wrong with IC3, or around IC3 (open connection, or short) It isn't possible to check the crystal without a scope. It could make sense to measure voltages around the OPL3 and DAC chip, but since these are mostly digital waveforms, you won't read any meaningful values, it can only give (an expert) a hint, if for example a connection is available between one pin to another. Sorry, I can also not say exactly the expected voltages for the OPs without opening my case. Is there anybody who has an opened case and could do the measurements? Best Regards, Thorsten.

Nice work! Btw.: your MIOS installation is outdated (MIOS V1.9 instead of v1.9f) ;-) Best Regards, Thorsten.

Hi, no, a glide function for analog outputs is not supported yet. But a "smoothing" function for CCs is on my ToDo list, it could also be provided for notes which are sent to the AOUT interface Best Regards, Thorsten.

Hi, wouldn't this be even more confusing, e.g. when you are changing tracks within the record menu? The tracks could output wrong (untransposed, or non-arpeggiated) notes which are out of scale - this isn't a consistent behaviour... However, in order to bypass the track mode checking for all selected tracks, following branch has to be inserted in seq_core.inc, line 1334, below the "check for transpose or arpeggiator function" comment: BIFCLR SEQ_RECORD_MODE, SEQ_RECORD_MODE_STEP, BANKED, rgoto SEQ_CORE_Clk_SendEvent_NoRec call CS_M_HLP_ChkTrkSelected bz SEQ_CORE_Clk_SendEvent_NM_Ply SEQ_CORE_Clk_SendEvent_NoRec [/code] Best Regards, Thorsten. P.S.: due to the inconsistent behaviour, I won't add this change to the MBSEQ release.

Hi, I'm sure that serge's SysEx loader is not compatible with MBSID V2, I'm surprised that it was more successfull than using MIDI-Ox. Maybe the output buffer size in MIDI-Ox is too small? I'm using a buffer size of 1024 bytes, but maybe your MIDI interface requires at least the size of a single patch dump (patch dump size is 1036 bytes). 2048 should be a save value. A 24LC256 provides only 32k EEPROM memory, the patch size (don't mix this with SysEx dump size - it's a different coding) of MBSID V2 is 512 bytes, accordingly only 63 patches can be stored (the first patch is located in internal EEPROM). I just tried to upload the presets into a 24LC256, and noticed following effect: the upper 64 patches will always be stored into the patch A001 position (internal EEPROM) - I would expect that they will be rejected with an error response. Sometimes storing patches into internal EEPROM takes longer than 750 mS, therefore you will sometimes receive MIDI overflow error response. However, the missing rejection is a minor issue, but it will be fixed with the next release candidate. I guess that patch A002-A064 have been uploaded correctly? With a 24LC512 you will be able to upload the whole bank Best Regards, Thorsten.

Here some infos about measuring current: http://www.hobby-electronics.info/course/html/ch02s05.html It helps you to determine, which part or module consumes most of the current. E.g., for a single core module w/o LCD backlight and without DIN/DOUT module I would expect a current drain of about 50 mA, with backlight maybe 150..200 mA - this can be measured at port J2 (if you are using the optimized PSU circuit) or at J1 (if you supply the core module on the common way). You need to disconnect one cable (use the +5V line), and insert the multimeter there as a "bridge". By connecting the DIN module, the current drain shouldn't increase - if it increases, it indicates that there is a short somewhere around the 74HC165. This can be visually checked at the bottom of the PCB (search for soldering clumps, etc.) Best Regards, Thorsten.