Duggle

What is the "SCS hardware" ? (I don't know what project you're talking about.)

Google Advanced search is my friend :-) http://www.midibox.org/dokuwiki/doku.php?id=wilba_mb_seq_construction_guide

I've just received my lovely SEQ control surface PCB from SmashTV's shop. It says on the back of the PCB: "MB-SEQ Control Surface PCB © 2009 Jason Williams". Where is the assembly info for this? (I cant seem to find it anywhere) I would really prefer not to have to reverse engineer to assemble this:-)

I'm using it with Windows 7 x64. I'll set up and compile with alternate #define's as suggested. The fact that no device was visible with the Korg drivers is a concern. I'll it try again with more ports enabled.

Yes, I have got the router to work. I think I understand now... it should be really good! Unfortunately, the upgraded driver (Korg) does not expose any midi devices with my LPC17 based seq. It shows "KORG MIDI Device" in device manager, but no ports are available to applications. Would be really nice to have multiple USB midi ports!

It is definitely possible to connect a much larger number of shift registers than just 16 chips. The problem is not the speed of the microcontroller: in the blog article I have 30 chips connected (using as STM core 60% as fast as LPC17). This is by no means an upper limit either. The 16 chip limit is advised due to typical poor signal integrity of typical midibox wiring! e.g.putting a 100R resistor in series with the source driver can improve situation dramatically. keep the SCLK, SDATA, SRST the same length close to each other. (The SCLK is the important one, in terms of integrity problems)make the ground plane or ground return path run close to these signals to minimize the area of the created loop.use a source termination resistor of say 100R If you have a CRO you will be able to verify the affect of each of these measures, if not, just do it that way anyway.

The midi connections I'm using successfully with my SeqV4L: Keyboard attached to MIDI IN1MIDI Clock source attached to MIDI IN2MIDI OUT1 attached to synthMID OUT2 forwarding the MIDI Clock to other gear. I'd really like to use USB1 to send Sysex to my synth. Can I use the router functionality to achieve this? If I change my wiring so that MIDI IN2 is free to attach to the synth MIDI OUT could I route the return Sysex from synth to USB1? What "set router" command arguments do I use? If I issue the command: "set router 1 USB1 all MID1 all" I get response: "Unknown or invalid MIDI output port!" I'm lost with how to use the router :-( Finally, is there any way to use USB2,3,4 under windows 7? Here's the current router config: [4069.595] router [4069.596] MIDI Router Nodes (change with 'set router <in-port> <channel> <out-port> <channel>) [4069.596] 1 SRC:Def. off DST:OUT1 off [4069.596] 2 SRC:Def. off DST:OUT1 off [4069.596] 3 SRC:Def. off DST:OUT1 off [4069.596] 4 SRC:Def. off DST:OUT1 off [4069.597] 5 SRC:Def. off DST:OUT1 off [4069.598] 6 SRC:Def. off DST:OUT1 off [4069.599] 7 SRC:Def. off DST:OUT1 off [4069.599] 8 SRC:Def. off DST:OUT1 off [4069.599] 9 SRC:Def. off DST:OUT1 off [4069.599] 10 SRC:Def. off DST:OUT1 off [4069.599] 11 SRC:Def. off DST:OUT1 off [4069.599] 12 SRC:Def. off DST:OUT1 off [4069.599] 13 SRC:Def. off DST:OUT1 off [4069.599] 14 SRC:Def. off DST:OUT1 off [4069.600] 15 SRC:Def. off DST:OUT1 off [4069.601] 16 SRC:Def. off DST:OUT1 off [4069.601] [4069.601] MIDI Clock (change with 'set mclk_in <in-port> <on|off>' resp. 'set mclk_out <out-port> <on|off>') [4069.601] USB1 IN:on OUT:on [4069.601] USB2 IN:--- OUT:--- [4069.601] USB3 IN:--- OUT:--- [4069.601] USB4 IN:--- OUT:--- [4069.601] MID1 IN:on OUT:on [4069.601] MID2 IN:on OUT:on [4069.603] MID3 IN:on OUT:on [4069.603] MID4 IN:--- OUT:--- [4069.603] IIC1 IN:--- OUT:--- [4069.603] IIC2 IN:--- OUT:--- [4069.603] IIC3 IN:--- OUT:--- [4069.603] IIC4 IN:--- OUT:--- [4069.603] OSC1 IN:on OUT:on [4069.603] OSC2 IN:off OUT:on [4069.603] OSC3 IN:off OUT:on [4069.603] OSC4 IN:off OUT:on

Test the LEDs for brightness before you worry about an NPN transistor (unless you just want to do this). In theory you could have 2 series circuits (R+LED+LED) in parallel with 17.5mA in each. That will be annoyingly bright and very close to the limits of the LED.

Yes, LEDs wired directly in parallel don't work reliably. Normally LED's driven as a group are wired in series with a single resistor. The problem with that here is supply rail +5V will be less than the sum of the forward voltage of the LED (4*1.8>5) So 4 circuits ( of R and LED) in parallel is the go. If 5mA is bright enough (usually is for an indicator) then you don't need a transistor. Alternatively (getting pedantic) 2 circuits ( of lower R and 2*LEDs in series)!

O.k, I've set up the tools and can assemble midimerger_pic18f_with_bootloader.hex Is there some transparent change I can to that will make it so that MIOS Studio parses the hex file o.k?

Is it possible that this happened when I flashed MIOS1.9g ?So if I am running with 1.2 now, then it is a bug in MIOS Studio 2.3 causing this? [edit]I can confirm that the midi router 1.1c flashes fine with Mios Studio 2.3 [p.s] I am (still) unable to flash MidiMerger though.

O.k, (after discovering MIOS Studio routing dialogue!:-) Starting upload of midimerger_pic18f_without_bootloader.hex Hex file contains code in MIOS range, forcing reboot for upload via 1st level bootloader! The reboot request will lead to an error acknowledge, please ignore! Waiting for upload request... Received error code 01: Less bytes than expected have been received This was an expected error - please ignore! Received Upload Request Sending block #1 00000000-000000FF Received error code 05: Write access failed (invalid address range) .. .. Sending block #1 00000000-000000FF Received error code 05: Write access failed (invalid address range) Aborting after 16 errors

Not really sure what you mean. I'm using MIOS Studio (I dont have a burner). From MS I've attempted to flash both the "with" and "without" bootloader hex files. In both cases MS shows similar error messages reproduced above. I think my problem may a be that I have an earlier (somewhat incompatible bootloader 1.1B) in the chip.

(Unfortunately) there are changes to MIOS32 files necessary (albeit minor changes) but allow for compatibility by using mios32_config.h switches: The modified mios32 files are attached below. I've highlighted the changes in this post for explanation. They consist of dout driver modification (mios32_srio.c,.h) and array access (mios32_dout.c,h). The application specific layer above this e.g void SetLed(u32 LedIndex, u32 Level) is written by you! #define MIOS32_USE_PAGED_DOUT #define DOUT_NUM_BUFPAGES 4 This means that 4 pages are used e.g an LED may be off, or have a brightness of 1,2,3 or 4. In mios_srio.h (file is attahced) the array is declared: #ifdef MIOS32_USE_PAGED_DOUT extern volatile u8 mios32_srio_dout_bufpages[DOUT_NUM_BUFPAGES][MIOS32_SRIO_NUM_SR]; #endif mios32_srio.c (file is attached with this post ) for reference I'll highlight the changes here: Define two dimensional array: #ifdef MIOS32_USE_PAGED_DOUT volatile u8 mios32_srio_dout_bufpages[DOUT_NUM_BUFPAGES][MIOS32_SRIO_NUM_SR]; #endif ... // inside s32 MIOS32_SRIO_Init(u32 mode) array is initialised: for(i=0; i<MIOS32_SRIO_NUM_SR; ++i) { #ifdef MIOS32_USE_PAGED_DOUT for(j=0;j<DOUT_NUM_BUFPAGES;++j) mios32_srio_dout_bufpages[j]=0; #endif mios32_srio_dout = 0x00; // passive state (LEDs off) mios32_srio_din = 0xff; // passive state (Buttons depressed) mios32_srio_din_buffer = 0xff; // passive state (Buttons depressed) mios32_srio_din_changed = 0; // no change } Now the guts of it all in s32 MIOS32_SRIO_ScanStart(void *_notify_hook) where the next page is indexed, and it's address loaded into the DMA process: current_bufpage=(++current_bufpage)%DOUT_NUM_BUFPAGES; //roll through page range u8 *dout_address = (u8 *)&mios32_srio_dout_bufpages[current_bufpage][0]; //set pointer // start DMA transfer MIOS32_SPI_TransferBlock(MIOS32_SRIO_SPI, dout_address, (u8 *)&mios32_srio_din_buffer[0], MIOS32_SRIO_NUM_SR, MIOS32_SRIO_DMA_Callback); Now in mios32_dout.h the paged array access functions are dedclared (for some reason I included NR (not bit reversed) versions of these functions as well): extern s32 MIOS32_DOUT_SRSet_Paged(u32 pg, u32 sr, u8 value); extern s32 MIOS32_DOUT_SRGet_Paged(u32 pg, u32 sr); extern s32 MIOS32_DOUT_SRSet_Paged_NR(u32 pg, u32 sr, u8 value); extern s32 MIOS32_DOUT_SRGet_Paged_NR(u32 pg, u32 sr); The paged array access functions as they appear in mios32_dout.c: #ifdef MIOS32_USE_PAGED_DOUT s32 MIOS32_DOUT_SRGet_Paged(u32 pg, u32 sr) { // check if SR available if( sr >= MIOS32_SRIO_NUM_SR ) return -1; return mios32_dout_reverse_tab[mios32_srio_dout_bufpages[pg][MIOS32_SRIO_NUM_SR - sr - 1]]; } s32 MIOS32_DOUT_SRSet_Paged(u32 pg, u32 sr, u8 value) { // check if SR available if( sr >= MIOS32_SRIO_NUM_SR ) return -1; mios32_srio_dout_bufpages[pg][MIOS32_SRIO_NUM_SR - sr - 1]=mios32_dout_reverse_tab[value]; return 0; } // NON REVERSED (range check on SR also removed) s32 MIOS32_DOUT_SRGet_Paged_NR(u32 pg, u32 sr) { return mios32_srio_dout_bufpages[pg][MIOS32_SRIO_NUM_SR - sr - 1]; } s32 MIOS32_DOUT_SRSet_Paged_NR(u32 pg, u32 sr, u8 value) { mios32_srio_dout_bufpages[pg][MIOS32_SRIO_NUM_SR - sr - 1]=value; return 0; } #endif So now the more application specific part you have to write for yourself for example: void SetLed(u32 LedIndex, u32 Level) would copy a bit pattern into the pages at LedIndex according to Level. These routines can be used to drive matrix arrays by having a column/row mask on each page. This can be combined with PWM/PDM values as well for e.g RGB full colour array! Please note these modified files need to replace the existing ones. The mios32_config.h config switches mean that other applications will compile and run as before. Take care that you merge any changes (although unlikely) to these mios32 files. Perhaps Thorsten can suggest a better way of managing this? mios32_srio.h mios32_srio.c mios32_dout.h mios32_dout.c

I've turned an old core from SmashTV (CORE R3) with a 18F452 into a midi merger. The PIC has a sticker from SmashTV that says MIOS_BOOTRAP_V1_1B. In mios studio the core responds to query: Operating System: MIOS8 Board: MBHP_CORE or similar Core Family: PIC18F Application is up & running! I have successfully upgraded mios by uploading mios_v1_9g_pic18f452.hex But when I try to upload by selecting midimerger_v1_5\midimerger_pic18f_with_bootloader.hex it shows: Reading midimerger_pic18f_with_bootloader.hex midimerger_pic18f_with_bootloader.hex contains 830 bytes (5 blocks). Range 0x00000000-0x00002fff (12288 bytes) - MIOS8 area Range 0x00003000-0x000007ff (4294957056 bytes) - PIC Flash Range 0x00300000-0x003000ff (256 bytes) - LPC17 Flash Press start button to begin upload. When I click "start" I get: Reading midimerger_pic18f_with_bootloader.hex Trying to contact the core... midimerger_pic18f_with_bootloader.hex contains 830 bytes (5 blocks). Range 0x00000000-0x00002fff (12288 bytes) - MIOS8 area Range 0x00003000-0x000007ff (4294957056 bytes) - PIC Flash Range 0x00300000-0x003000ff (256 bytes) - LPC17 Flash Hex file contains invalid ranges for MIOS8! Unfortunately I don't have a PIC Burner. Is there a way I can update the Bootloader with MIOS Studio? (assuming that is the problem.)

For convenience I simply downloaded this Virus B bank off the Access website: (attached rar file containing *.syx) Let me know if this is adequate for your purposes. Thanks. HS Virus B - Bank F.rar

Yes, its clearer to me now, the 4L is a 2 track, 2 channel looper, which is fine. I can experiment with multi-timbrel single channel multi's on my virus B/C synths. I will look at the throughput with a midi logger, but it appears that short SysEx messages I am sending from my keyboard (e.g to change patch of a multi part ) are being filtered out by the SeqV4L. Does or can the 4L pass through SysEx?

I've just built my SEQV4L and it's amazing to use! I am a little surprised however, it seems to support only one midi channel (at a time). It seemed to me from Thorsten's demo, that he started off with a synth bass sound and proceeded to add keys with a different sound. The midi forwarding seems to translate multi channel inputs into the one, selected channel. Have I missed something? Is the idea to used keysplits in the driven synth to organize different sounds on the one midi channel? Would it be difficult to modify the firmware so that events on the input retain their original midi channel in the sequencer?

The Virus B and/or C are good candidate? Can I help with this?

If using RGB Leds, I suggest that you experiment with the different value of R,G, and B current limiting resistors before soldering 100's of resistors for LEDs. I think the sensitivity/brightness of the Red, Green, Blue is usually not matched. With, for example, only 8 levels of brightness digitally, it is best if you can normalize the RGB colour balance with the resistors. Basically with all RGB LED's "on" you want to see pure "white"! I'll post the code to this thread in a day or two. (I don't have access ATM).

Yes, it is possible to implement PWM on a Core32 on any number of LED's with absolutely negligible CPU overhead. In terms of performance, the frequency of PWM is 1/(NumberLevels*DoutPeriod) . With the standard 1ms DOUT refresh rate and 8 brightness levels gives 1/(8*0.001)=125Hz NumberLevels does not include OFF so this example may be considered as 9 levels. The method involves a 2 dimensional array: think of it as DoutArray[ PageIndex][LEDIndex] The DMA interrupt routine simply increments PageIndex 0 to 7each interrupt. The DMA process automagically shifts out the LEDIndex values to the DOUT chain. Of course when a LED has it's brightness changed there are a number of array accesses executed by the write function. These can be done in a low priority task, however probably not even necessary. When there is no change there is no CPU load. With this scheme it is beneficial to used PDM (Pulse Density Modulation) this means distributing the on/offs across the cycle e.g 50% brightness is 0x0x0x0x rather than 000xxxx etc,etc. It results in less possibility of perceptable flicker. In fact here is the thread that explored this idea. (I have code I can share if anyone is interested)

If you load the SEQV4 firmware into your core you can play with it. From memory you hold down a special key with other keys to issue action on the seq. IIRC its documented in uCApps or in the source code.

Does anyone know of places to buy keybeds? Actually, these look pretty good:http://www.doepfer.de/zubeh_e.htm 100Euro for 49keys is less than I expected. They are Fatar. Any others?

Hi Lars, use a multimeter to measure the range of resistance between the wiper and each of the other 2 terminals. If the resistance goes from "close to zero" to "some maximum" on one terminal and the opposite (measuring between the wiper and the other terminal) then it will work fine attached to 5V for midibox without needing to modify firmware. Cheers

I've ordered a control panel pcb and am looking forward to building this myself.From my reading so far, a sequence can have up to 64 steps (4 bars of 4/4) but if you wanted e.g 2 bars of 7/8 you would select 28steps for the sequence. In this way a rather large gamut of time signatures/bars combo's is possible. Certainly the SEQ's have midi mapped control functions, I'd be surprised if SEQ4L does not have it already.