TK.

Yes, I know what you mean - I'm still thinking about a good solution. A simple workaround could be, that the CS jumps to the root page whenever a SID core is selected, which is running with a different sound engine. But the perfect solution would "remember" the menu pages of the different SIDs. Note that the MBSID V2 already provides all controls for such a special MIDIbox. For example, it is possible to add analog faders/pots to the analog port for controlling the knob functions as an alternative way to the "OSC Assign" layer (-> rotary encoder), which provides the typical CutOff/Resonance/EnvMod/Depth/Accent knob as well. It's even possible to select the sequences from control surface by using the matrix selection buttons. I prefer the usage of a MIDI keyboard, not only because there are more keys and the selection is somehow faster, but also because it allows me to control sound parameters via velocity. They keyword is NRPN, and the usage is explained in mbsidv2_parameter_chart.txt with some examples. If it isn't clear enough, I would propose to open a new topic and ask there for more specific infos. Best Regards, Thorsten.

yes, I used the slightly modified "Drum Kit 2" preset + the sequences, which are part of the patch. Best Regards, Thorsten.

In lc_leds.inc, you have to search for the keywords "CATHODES" and "ANODES". Below these lines, add " comf MIOS_PARAMETER1, F" to invert the pattern. Note that there must be a whitespace (space or tab) between the first column and the "comf" instruction, otherwise the assembler will interpret the instruction as a label, and fail. Best Regards, Thorsten.

I think that the common gatelength function is exactly what you need. E.g., at 120 BPM a single 16th note can control the length from 5 mS to 125 mS in steps of 5 mS By using the global clock divider in the BPM menu, or a local clock divider in the track div menu, you can scale the length by a certain factor. If you are using 4 (as an example), the resulting gate length would be 20 mS .. 500 mS in steps of 20 mS. So, this approach is sufficient for gate lengths > 1 mS, only disadvantage: the length depends on the BPM rate. But I guess that it won't be a big problem for you to re-adjust the gatelength in layer C whenever the BPM rate is changed dramatically. Best Regards, Thorsten.

Why do you want to use triggers instead of the normal gatelength (which depends on the BPM rate, and which is fineadjustable in 24 steps for each 16th note) Best Regards, Thorsten.

Moment, you mean the length of the 1 ms triggers, right? This length cannot be modified, because it directly depends on the SRIO chain sample rate. As described in my first answer of this topic, the current implementation doesn't allow to vary the length. And a solution is really not so easy, otherwise I would spend an hour and hack it into the firmware for you... Best Regards, Thorsten.

Thanks for the compliments! :) I put the drum and bassline patch into a package and wrote a README.txt which describes the setup requirements + workflow. Have fun -> http://www.ucapps.de/midibox_sid/mbsidv2_bassline_demo3_patches.zip Best Regards, Thorsten. P.S.: meanwhile I modified the firmware, so that patch dumps, which are sent from the control surface (-> Shift menu), contain the edit buffer of the selected SID (previously only the dump of SID1 was sent, and it contained a bankstick write request) - so you can upload these patches without the danger of overwriting a BankStick location. This change will be available with RC14 Best Regards, Thorsten.

It's normaly in Layer C Best Regards, Thorsten.

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.