TK.

Some of you might remember following entry in the wishlist: ----------------------------------------------------------- MBSID Control Extension: as discussed in http://www.midibox.org/forum/index.php?topic=5680.0, but I think that I will overwork the concept so that it is also useful for the other subsystems. This control extension is something like a "breakout box", which is dedicated for easy editing of bass- and drumline sequences. For the MBSID-Lead and MBSID-Multi subsystem it could be used as simple keyboard, for mutes/solo or for quick patch changes. We will see. I propably won't start with this extension before next year - first I want to see MBSID V2 completely working. ----------------------------------------------------------- My statements are still valid, but I'm still not sure about the best solution which fits for all needs. E.g., what I don't like on your proposal is, that a 4x16 LED matrix is not sufficient. Just think about all the possible setups. There is a 8 track drum sequencer, which controls 16 instruments. Accordingly, the LED matrix should consist of 16x16 LEDs - but are the increased frontpanel costs really reasonable? And what about the remaining 3 SIDs which can run the same, or any other engine? How should they be handled? Thats really difficult to decide. E.g., the for basslines and drum engines which are running in parallel it would be important that sequences can be switched back and forth without using an "instrument" button - means: all sequences directly accessible. Like demonstrated in bassline demo #3 where I'm using a common MIDI keyboard for this. In addition, it's possible to control sound parameters with key velocity, which might be a strong requirement for a control extension - if it should replace the already working MIDI keyboard solution (?) - as well. Another idea: if an additional PIC is used to control the extension, it could be connected to MBSID via CAN interface and act as additional bus master. This would not only allow to access MBSID, but also other MIDIboxes, like for example MB-808? And to give you more insight into my secret plans ( ;-) ): one of the next things I want to evaluate is MIDI-over-IP, since it's natively supported by MacOSX, and not only useful for sending MIDI control data, but also to handle the OSC protocol (useful for windows users as well, e.g. Reaktor supports OSC). So, the control extension could provide an ethernet option as well. And this would make it to a real universal solution, which is worth the DIY effort. Best Regards, Thorsten.

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.