TK.

Very clever! Thanks for the inspiration! :) Very difficult, as CC processing consumes too much time. But I will think about a "slow-path" solution. Best Regards, Thorsten.

The SID volume can only be controlled with 4 bit resolution, in addition you will notice a crackling sound (which was mis-used in the past to play samples) So, controlling the volume is no suitable option. You could control the cutoff frequency though. Or an external VCA controlled via an AOUT module (-> expensive, but you asked for this) Currently CC#11 isn't assigned to any parameter (for good reasons, because controlling the 4bit volume could be annoying), but you could do this in src/sid_cc_table.inc If you are using the Multi Engine, the note stack allocation algorithm will cleverly assign voices automatically like a polyphonic instrument :) The multi engine allows you to assign voices to different MIDI channels, so that no second MBSID is required. E.g. you could assign the three voices of the "left channel SID" to MIDI channel #1, the other three voices of the "right channel SID" to MIDI channel #2 Thats possible as well, the Multi Engine is very flexible! Best Regards, Thorsten.

Beta42 is available now (with less features than planned, but I thought that it would be better to release the bugfixes with higher priority) MIDIboxSEQ V4.0beta42 ~~~~~~~~~~~~~~~~~~~~~ o Handling of Start/Stop/Pause button changed for Slave and Auto Mode to allow proper synchronisation to the measure when multiple sequencers are playing together. Whenever a MIDI clock is received: - the STOP button won't stop the sequencer, but just disables the output of all tracks (like a Mute). The step progression continues to run. - the START button won't start the sequencer immediately. Instead MBSEQ will wait for the next measure and then enable track output again. - the PAUSE button will enable/disable track output, but the track progression continues to run. In order to notify that track outputs are disabled, the START/STOP/PAUSE LED flashes to the beat. o Added Live page. The page can be entered by pressing UTILITY -> Live (GP Button #11) Inside this page notes (and drum instruments) can be played with the GP buttons. In addition the 4 MIDI IN Busses for Transposer/Arpeggiator/Live Playing can be configured like in the MIDI page. Following Live Play parameters are available: - track selection - track mute/unmute - Octavewise transpose - Velocity (only used for GP button keyboard) - FTS (Force-To-Scale) - FX on (enables Humanizer, LFO, Limiter and Echo) Note: the Echo effect will only work when the sequencer is running! o parameter layer mutes are now also working for velocity/length/probability/delay/roll/roll2 o Echo Fx now also works with "zero delay". In conjunction with the Note incrementer and (optionally) force to scale this results into a "poor man's chord" mechanism. ;-) o Move function works beyond step 16 as intended again [/code] Sorry, I wasn't able to reproduce this I tried to improve this a bit, but without much luck. The problem: Cubase sends the note event after the MIDI clock event, accordingly the transpose function will restart the track after MBSEQ processed the first step. In Logic I'm able to apply a negative delay to the events which are sent to MBSEQ, this solves the issues at my side. This is the recommended approach anyhow, you would do the same when controlling (for example) the arpeggiator of an external synth which is synchronized to the MIDI clock. Best Regards, Thorsten.

Progress - hooray! :) Since Nils is currently too busy for handling this bulk order, Marco aka. Schrittmacher will take over the (very time consuming!) task. He will contact all people in the list today or tomorrow. Best Regards, Thorsten.

Hooray! :thumbsup: Best Regards, Thorsten.

These is really a special setup! :) I wrote a small application which demonstrates how a MIDIbox Link Endpoint can be handled: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fquickies%2Fmidibox_link_ep%2Fapp.c Most important part is the filter handling: ///////////////////////////////////////////////////////////////////////////// // This hook is called when a MIDI package has been received ///////////////////////////////////////////////////////////////////////////// void APP_MIDI_NotifyPackage(mios32_midi_port_t port, mios32_midi_package_t midi_package) { // toggle Status LED on each incoming MIDI package MIOS32_BOARD_LED_Set(1, ~MIOS32_BOARD_LED_Get()); // MIDIbox Link Endpoint Handling: // activate filter when 0xf9 has been received // deactive filter when 0xfe has been received // this is only done for UART ports if( (port & 0xf0) == UART0 ) { if( midi_package.evnt0 == 0xf9 ) { midibox_link_filter_uart |= (1 << (port & 0xf)); return; // control word received: don't forward, exit! } else if( midi_package.evnt0 == 0xfe ) { midibox_link_filter_uart &= ~(1 << (port & 0xf)); return; // control word received: don't forward, exit! } // exit as long as filter is active if( midibox_link_filter_uart & (1 << (port & 0xf)) ) return; // filter active... } // forward any UART to USB0 if( (port & 0xf0) == UART0 ) { MIOS32_MIDI_SendPackage(USB0, midi_package); } // forward USB0 to UART0 if( port == USB0 ) { MIOS32_MIDI_SendPackage(UART0, midi_package); } } [/code] The forwarding method has to be adapted depending on how you organized your MIDI setup Best Regards, Thorsten.

I haven't added this feature to MIOS32 since multiple MIDI INs are available, so that chaining isn't really required anymore. Instead you can use a starlike wiring. To give you a more sufficient answer, I would need to know, how many cores are you planning to connect together? Best Regards, Thorsten.

I will add mutes for these parameter layer assignments as well, shouldn't be a big task, and it seems to be useful :) Best Regards, Thorsten.

This seems to be a bug in SID_RND_GenerateOsc you could try to debug this in src/sid_rnd.inc, or just wait for the next release :) Best Regards, Thorsten.

Especially stupid posts shouldn't be removed to avoid that other people are doing the same stupid errors. (and this happens more often than doing unstupid errors! ;) Best Regards, Thorsten.

Looks good Best Regards, Thorsten.

It's strange that Windows asks you to reboot the PC, this never happened at my side with USB MIDI devices (regardless if GM5 or my own USB projects are used). But I must also say, that I typically test the devices under WinXP and Win7 only, no Vista (are you using Vista?) It's normal that the GM5 status LEDs only is lit as long as the USB MIDI driver hasn't connected to the core - thereafter the LED turns off. It seems that your Windows connects very fast - thats ok! The MIDI IN/OUT LEDs are flickering randomly at power-on, this also seems to be ok... In order to ensure that the problem isn't related to your synth: could you please try a loopback test? (e.g. with MIOS Studio) Try it also with the GM5 windows driver, just to exclude that any other driver on your PC modified the original USB MIDI driver Microsoft (e.g. some people noticed this with a Logitech Webcam driver) Best Regards, Thorsten.

Sweet DIY project! Congratulations! :) Best Regards, Thorsten.

Nice - this will be a no-brainer! :) (especially since the delay parameter is already mapped to allow insertion of new values between existing values) Best Regards, Thorsten.

ST provides a very useful documentation for these functions: STM32F10x reference manual: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/REFERENCE_MANUAL/CD00171190.pdf Chapter 9: General Purpose and alternative-function IOs The functions and parameters are documented in the source code: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fdrivers%2FSTM32F10x%2Fv3.3.0%2FSTM32F10x_StdPeriph_Driver%2Finc%2Fstm32f10x_gpio.h http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fdrivers%2FSTM32F10x%2Fv3.3.0%2FSTM32F10x_StdPeriph_Driver%2Fsrc%2Fstm32f10x_gpio.c Best Regards, Thorsten.

Cool! :) I merged the topics and moved the article to MIOS Programming This means that the same pin number is passed for different multiplexer groups, is this ok for you? It could make sense to forward the mux variable to the function which handles the buttons (if required), e.g. if you want to send Note events over different channels. Best Regards, Thorsten.

I'm glad that it's (almost) working! And thanks for the beers! :) Yes, the DIN buffer copy routine has a typical copy&paste error - it copies mios32_srio_* variables, although app.c uses local variables called srio_* Update is here: http://www.ucapps.de/tmp/fast_srio_scan_v0_3.zip Changes: before muxctr is incremented, I store the previous counter value in a temporary variable: u8 prev_muxctr = muxctr; if ( ++muxctr >= 4 ) { muxctr = 0; } [/code] DIN buffer copy and change detection: [code] // copy/or buffered DIN values/changed flags of previous scan int i; for(i=0; i<MIOS32_SRIO_NUM_SR; ++i) { srio_din_changed[prev_muxctr][i] |= srio_din[prev_muxctr][i] ^ srio_din_buffer[prev_muxctr][i]; srio_din[prev_muxctr][i] = srio_din_buffer[prev_muxctr][i]; } I've no explanation why J5 input #11 doesn't work - did you replace the "#if 0" by "#if 1" to enable the if condition? #if 1 if (MIOS32_BOARD_J5_PinGet(11) == 0) { //test for mode 1 MIOS32_BOARD_J5_PinSet(muxctr + 4 , 1); //jm set keyboard mux pin on mode 1 } #endif [/code] Best Regards, Thorsten.

Ok, it's clear now. So, I added the DIN handling: http://www.ucapps.de/tmp/fast_srio_scan_v0_2.zip Thats the last change I've planned to make - I haven't checked if DIN values are handled correctly, but as mentioned: it's just a demo for possible optimizations. 8 SRs are scanned in ca. 8..9 uS. The period is slightly jittering by ca. 1 uS, but this should be acceptable. It never takes longer than 10 uS The DIN_Handler calls APP_DIN_NotifyToggle with following parameters: u32 pin = MIOS32_SRIO_NUM_SR*8*mux + 8*sr + sr_pin; u32 pin_value = (srio_din[mux][sr] & (1 << sr_pin)) ? 1 : 0; APP_DIN_NotifyToggle(pin, pin_value); [/code] You have to decode the pin number again in this hook, or alternatively define another hook (if this is easier for you) which has the mux number as additional parameter. DOUT pins have to be set/cleared by writing directly into the srio_dout[mux][sr] array. Hope it works! Best Regards, Thorsten.

Hm... maybe it's better to give you a half-ready demo for discussion, because some points are not clear to me. You will find the sources under http://www.ucapps.de/tmp/fast_srio_scan_v0_1.zip Optimizations: instead of patching code into original MIOS32 routines, I started to copy the relevant SRIO/DIN/DOUT parts into app.c - typically this gives more freedom and a better oversight (use MIOS32 code only as a template) the SRIO_Handler prepares the next SRIO transfer, when it's finished the DMA IRQ will call SRIO_Handler again -> it's triggered periodically the RC pin is only toggled once between the transfers - thats a trick! While it captures new DIN values, it also captures the DOUT values at the same moment. I optimized some bits of mios32_spi.c, please update the repository gap between SRIO transfers: only ca. 5 uS anymore (but will be a bit longer once DIN values are stored before next transfer) SPI pins configured for Push-Pull with *strong* drivers (should be faster than weak drivers) J5 pin accesses now done directly via SFR write operations (less readable code, but in total the SRIO_Handler runs ca. 2 uS faster) prepared TASK_DIN_Handler which is running in background and which will check for pin changes in an endless loop. It can be interrupted by higher-prio MIOS32 tasks. Using a task instead of an interrupt routine makes much more sense here, as MIDI transfers could be blocking (e.g. if UART fifo is full) - maybe you already noticed this effect - interrupts should be executed as fast as possible and they shouldn't block for more than 10 uS (maximum 100 uS) Although the DIN handling (check for pin changes) hasn't been implemented yet (I can do this once the approach is clear), I guess that the typical scan speed for 4*8 SRs will be ca. 200 uS if SRs are clocked with 16x prescaler Now my question: why do you need such a high scan speed, although you are only using a common UART to send MIDI values? Sending a MIDI event which consists of 3 bytes takes 960 uS, by using running status optimization (channel number doesn't change) 640 uS So, does it really make sense to scan faster? Due to the reduced MIDI speed (as long as you are not using USB) you wouldn't notice an effect. Or wouldn't it make more sense to slow down SRIO for more robustness, and/or use common MIOS32 access functions (e.g. for J5) to make the source code more readable? Best Regards, Thorsten.

I'm going to write a demo application for you and already optimized a lot of things. More infos in ca. 30 minutes Best Regards, Thorsten.

thats true if you are the only person who maintains the project. From my experience it won't work once somebody else (e.g. a programming newbie) tries out some modifications, it could cost him multiple hours to debug this, or he just gives up. In newer projects (e.g. MBSID V2.. which actually isn't so new anymore) I'm using such page checks as well, and throw an #error message on overlaps, but usually I try to avoid such dependencies whenever possible with the drawback that it will cost some additional cycles. However, I don't want to say that you should use a different (more time consuming) method now, I only want to explain why I'm a bit more careful meanwhile. Additional CPU cycles will be compensated by less support effort. ;) Best Regards, Thorsten.

Thanks for the work! Although I've currently too much other interests, it's nice to see the progress. IIC MIDI isn't identical to USB MIDI, it's just similar to USB MIDI and gives us some freedom for extensions ;-) The advantage of a state machine: if it's already there, it's easy to add commands with more than 3 bytes. If it's clear that more than 3 bytes will never be transfered per command, you could also use 0x1 (which is reserved according to the USB MIDI spec) This is the result of reused code from an old PIC16F project that I wrote more than 10 years ago, and a newer project that I wrote on a PIC18F The capabilities of a PIC16F are very limited, e.g. there is no tblrd* command which would allow to directly read from flash. But I wanted to use the same tables like on my MBHP_USB_MIDI_PIC project. Alternatively we could use lookup tables similar to this one: MIDI_MTC_NextExpectedByte andlw 0x07 addwf PCL, F retlw 0xf0 retlw 0x7f retlw 0x7f retlw 0x01 retlw 0x01 retlw 0x00 ; dummy retlw 0x00 ; dummy retlw 0x00 ; dummy [/code] which works much faster. But it has the disadvantage that it has to be ensured that the code is located within a 256 byte page (which mostly results into more cluttered sources), and that it will only run on a PIC16F this way. For PIC18F a similar approach is possible with a trick, but it would consume more cycles than a tblrd* So, it was a difficult decision to find a good compromise, and at the day I wrote the firmware I thought it would be better to make it better portable to PIC18F derivatives as I wasn't sure if PIC16F will be sufficient. Best Regards, Thorsten.

The MB808 is pure assembly code and doesn't require a C compiler. In order to build a new .hex file on a Windows PC, you have to install gputils and MinGW (as a Unix replacement to execute the Makefile) On a Mac or Linux PC, you only have to install gputils. Then go into the application directory and type make -> done It should even be possible to create .hex files without the Makefile mechanism (so that you don't need MinGW), just execute the commands directly in a command shell or from a .bat file: gpasm -p p18f4620 -I./src -I ./include/asm -I ./include/share -I ./modules/app_lcd/dummy -I ./modules/iic_midi -I ./modules/aout setup_808_mbseqv3_hardware.asm gpasm -p p18f4620 -I./src -I ./include/asm -I ./include/share -I ./modules/app_lcd/dummy -I ./modules/iic_midi -I ./modules/aout setup_808_mbseqv3_tk.asm gpasm -p p18f4620 -I./src -I ./include/asm -I ./include/share -I ./modules/app_lcd/dummy -I ./modules/iic_midi -I ./modules/aout setup_808_tk.asm gpasm -p p18f4620 -I./src -I ./include/asm -I ./include/share -I ./modules/app_lcd/dummy -I ./modules/iic_midi -I ./modules/aout setup_808_default.asm gpasm -p p18f4620 -I./src -I ./include/asm -I ./include/share -I ./modules/app_lcd/dummy -I ./modules/iic_midi -I ./modules/aout setup_808_with_swingpot.asm [/code] thats all! MPLAB isn't supported, and I don't see the need for this (too cumbersome and error prone) Best Regards, Thorsten.

Der Taster wuerde problemlos funktionieren, doch ich halte ihn fuer ueberteuert, und er nimmt vielleicht auch zuviel Flaeche ein. Mein persoenlicher Favorit ist diese Loesung: Diese Taster/LED Kombination ist auch nicht schlecht: http://www.omron.com/ecb/products/pdf/en-b3w-9.pdf Doch das sind natuerlich keine Edelstahl Taster... Gruss, Thorsten.

Btw.: there is a hidden feature in the MIOS32 implementation: inside the MIOS terminal, type "!" followed by any characters, they will be directly sent to SpeakJet This could be a helpful for finding nice phrases before they are hardcoded into the application (the function is located in terminal.c) See the SpeakJet datasheet for available codes. I remember that there was a dictionary for SpeakJet codes somewhere in the web, you could integrate it into the app as well Best Regards, Thorsten.