TK.

And I got the OLEDs today. Observations: - same behaviour at my side when OLEDs connected to a STM32F4 core - OLED was working when I connected a common LCD to J15B instead of the second OLED - both OLEDs are working together on a LPC17 core In the app_lcd driver I found the difference between STM32F4 and LPC17: for LPC17 the pins which drive E/RW/RS are always configured in Push-Pull (PP) mode, for STM32F4 these pins are configured for Open-Drain mode (they are pulled to the LCD voltage with external pull-up resistors). The LPC17 variant was actually a workaround for a weakness in the LPC17 microcontroller. However, I added a new CLCD type "CLCD_PP" which will configure the pins in Push-Pull mode instead of Open Drain Observations: - OLEDs still failing at 5V LCD voltage - but OLEDs are working at 3.3V LCD voltage! -> solution found! :-) And an explanation as well: the datasheet specifies an VIH (input high) level of 0.9 * VDD, which can't be achieved via the pull-up resistors when more than one OLED is connected to the same pin. By reducing VDD to 3.3V, and setting the pins in the "stronger" push-pull mode, the spec isn't violated anymore accordingly displays are working properly. @cube48: I will send back the OLEDs tomorrow, you may receive them saturday - be prepared for a nice weekend! :-) The new CLCD_PP type has to be configured in the bootloader with "set lcd_type CLCD_PP". As long as no new bootloader has been released, you can also set it with "set lcd_type 0x02", which has the same effect. In addition, you will need a new MBSEQ V4 release which will be available saturday as well - maybe together with the screen saver ;-) Best Regards, Thorsten.

No other idea; try to find out the logic behind the observed behaviour. In order to transfer 16 bits (= 2 * u8) just call the MIOS32_SPI_TransferByte function two times between the RC1 activation/deactivation. You are already doing this in the code that you've showed in the first posting. Btw.: the PGA2311 specifies 8 bits per volume level, but your value only ranges between 0..127 (=7 bit) This is not the reason for the behaviour, but it makes sense to change the range from 0..255 anyhow Best Regards, Thorsten.

It depends on the microcontroller which is connected to the SPI device. Modern microcontrollers are typically supplied at 3.3V, but they have 5V tolerant inputs -> no voltage reduction required. For level shifting (3.3V -> 5V) a 74HCT based buffer is sufficient, see also the MBHP_CORE_STM32F4 schematic (http://www.ucapps.de/mbhp/mbhp_core_stm32f4.pdf) where I'm using a 74HCT541 to shift the outputs levels of two independent SPI ports from 3.3V to 5V I don't know any MIDIbox which requires more than 5V at the SPI port ;-) Best Regards, Thorsten.

Do you want to connect it to a MIOS32 based core? In this case the solution would be easy: use J16 for 3.3V supply, or J19 for 5V supply Best Regards, Thorsten.

What is the screensaver doing, just printing some text on the screen? The existing MBSEQ V4 boot screen might be a nice solution for this; just to turn it on after a configurable time until a control element is moved. Actually the idea of this pseudo-graphic during boot is borrowed from the screen saver of a Waldorf Micro Q, I already considered to use it as a real screen saver as well :) Best Regards, Thorsten.

Than lower than better. ;-) But don't spent too much time on this optimization step, it can be counter-productive. No good idea, take separate parts to avoid any dependency. 0 (so that the previous seed won't be overwritten) Best Regards, Thorsten.

There is always room for improvements ;-) E.g. you are writing: //exit if there's no chance of robotizing anything if( ! tcc->robotize_active || tcc->robotize_probability == 0 || ( !tcc->robotize_vel && !tcc->robotize_len && !tcc->robotize_note && !tcc->robotize_oct && !tcc->robotize_skip_probability && !tcc->robotize_sustain_probability && !tcc->robotize_nofx_probability && !tcc->robotize_echo_probability && !tcc->robotize_duplicate_probability ) ) return returnflags; // nothing to do This kind of check isn't required, because with the tcc->robotize_active switch you've already ensured that the function doesn't consume time if it isn't activated. It will only be enabled if the user intends to use the function, and then it's unlikely that he doesn't set one of the parameters. Please reduce this check to "if( !tcc->robotize_active || !tcc->robotize_probability )", this should be sufficient. Yes, it makes sense to reduce the number of SEQ_RANDOM_Gen() calls It will return a 32bit number Since you need a range from 0..1023 (=10 bit), you could extract 3 random numbers out of the 32bit value It doesn't make sense to work with 64bit numbers here... Best Regards, Thorsten.

I appreciate this project a lot - finally a standardized controller surface :smile: Please add more buttons and LEDs, you can never have enough to switch between different functions on your synth, to trigger something (like a .NGR script), or whatever. I don't see a way for MBCV V2 support, but I also don't find it necessary. I think it's better to work on a dedicated solution for MBCV V2 instead. MBCV V2 uses a special LCD driver mode which allows to access a 2x20 CLCD and 4 OLEDs from the same core. This is a dedicated hack and neither universal (e.g. it isn't supported by MBNG) nor scalable (1 CLCD and 4 OLEDs is the limit for MBCV V2, and the OLEDs can only be used as scopes) Best Regards, Thorsten.

If you send me the OLED displays, I can analyse the problem at my side and ensure future compatibility. Of course, I will send them back after testing/troubleshooting. Best Regards, Thorsten.

Looks like this could work. Only the BLM port is problematic, because actually this is one of the MIDI IO ports for which you've already 2 MBHP_MIDI_IO boards. Best Regards, Thorsten.

Unter http://www.ucapps.de/mios32_download.html gibt es eine iic_midi Test-Applikation, die evtl. weiterhilft (siehe README) Gruss, Thorsten.

I guess that the chips expects the MSB first, which means that the byte has to be mirrored. Please try: MIOS32_SPI_TransferByte(2, mios32_dout_reverse_tab[Sendbyte]) this should do the trick that's the normal shift register behaviour, it can't shift out the value which is currently shifted in. It will be shifted out with the next transaction. Best Regards, Thorsten.

You shouldn't change anything in the mios32_midi.h file! And please never start such modifications outside your own application to prevent a big disaster ;-) The "midi_package.chn == 9" is part of your own code. I'm surprised that you can't find it there - just search this keyword in your initial posting. It's even part of the subject. I proposed that you replace the 9 by Chn10 to improve the readability, nothing else. Just try it out - it works! :smile: Best Regards, Thorsten. P.S.: I will avoid to give you background informations in future, they confuse you too much.

It should be possible to disable SysEx in the Virus TI configuration. See also http://www.peter.boda.sk/download/Virus_TI_Manual.pdf Page 131, "MIDI Control" - keyword SysEx Best Regards, Thorsten.

See http://www.ucapps.de/midibox_ng_manual_fs.html Please read everything from the top to the "Remote me" topic; these are important background informations. Instead of the "EVENT_BUTTON ... fwd_id=LED:1" configuration you could directly specify EVENT_LED of course (like in the "Dim me" example, just without "dimmed=1" Best Regards, Thorsten.

Powerful! :) Best Regards, Thorsten.

The router doesn't support more sophisticated filter functions. I've no simple solution for this yet. Best Regards, Thorsten.

Search for mios32_midi_chn_t in this file (CTRL+F, then enter this keyword into the search mask of your web browser) Again: this file is included by default (via mios.h), you can just use the enum as shown in my example. Btw.: you don't need to copy&paste such code into the posting, please reference it with the SVN link: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Finclude%2Fmios32%2Fmios32_midi.h Best Regards, Thorsten.

I don't know a good reference for such topics, I just observe and decide, and if I'm unsure, I measure ;-) After a successful build you will find an assembler listing under project_build/project.lss which gives some useful information, e.g. how many assembly instructions are generated by a C construct. Makes sense to check this file from time to time... Cortex-M has special instructions for these math operations, therefore no need to be worried about this. Depends on the implementation and available alternative methods. E.g. sooner or later I will optimize the large switch statements in seq_cc.c by a lookup table. I did something similar in MBCV V2 (-> http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fprocessing%2Fmidibox_cv_v2%2Fsrc%2Fcomponents%2FMbCv.cpp ) with great success. But it's not worth the effort for switch statements below 30..40 items, and I don't think that you've to consider this in your code domain... If I see something "which hurts", I will optimize it sooner or later and show you the improved version. Best Regards, Thorsten.

Very nice! Sounds like you had a lot of fun! :phone:

:thumbsup:

Die Belegung fuer F1..F4 ist schon sehr individual, das musst Du selbst herausfinden. ;-) Ich verwende SCRUB sehr haeufig - nicht fuer die SCRUB Funktion selbst, sondern vor allem die MENU+SCRUB Funktion, mit der man den Loop-Modus umschalten kann. Gruss, Thorsten.

Fine! :) Best Regards, Thorsten.

MIDI Channels are counted from 0 If you don't like this, you could use the mios32_midi_chn_t based enums (which are defined in mios32_midi.h) in your code. They are available by default, just try it out: replace if( midi_package.chn == 9){ by: if( midi_package.chn == Chn10){ Best Regards, Thorsten.

Cool, thanks for the changes! :smile: First of all: I gave you access to the (hidden) Programmers Lounge. Here are the informations about SVN write access to the repository: It makes sense that you upload your changes directly to the repository - I can always switch back to an earlier version if I'm not happy with the changes. ;-) I also added a new type in seq_robotize.h which simplifies the access to robotizer flags: typedef union { u8 ALL; struct { u8 SUSTAIN:1; u8 NOFX:1; u8 ECHO:1; u8 DUPLICATE:1; }; } seq_robotize_flags_t; Sustain: search for tcc->mode.SUSTAIN, just OR this flag with the robotizer flag: (tcc->mode.SUSTAIN || robotizer_flags.SUSTAIN) Don't put temporary flags into the CC array, it's better to keep them in the local stack like it's currently done. From time to time it makes sense to check the performance impact of your code. Go to the INFO page (Main menu, GP#16), the Stopwatch will display the consumed time for each SEQ_CORE_Tick() The maximum value will be captured and can be cleared by pressing GP9 button in this page. Currently the function consumes +30 uS on a STM32F1 if a single track is playing. It could be improved. E.g. I noticed that you reverted an important change that I made: you are writing for example: if( ( (s16)SEQ_RANDOM_Gen_Range(0, 31 * 31) <= tcc->robotize_oct_probability * roboprob ) && robooct ) { // Octave Event but it's better to write: if( robooct && ( (s16)SEQ_RANDOM_Gen_Range(0, 31 * 31) <= tcc->robotize_oct_probability * roboprob ) ) { // Octave Event so that SEQ_RANDOM_Gen_Range() won't be called if robooct isn't activated Same for robonote, robovel, robolen The copy of tcc-> variables into local variables isn't really necessary: roboprob = tcc->robotize_probability; robovel = tcc->robotize_vel; robolen = tcc->robotize_len; robonote = tcc->robotize_note; robooct = tcc->robotize_oct; roboskip = tcc->robotize_skip_probability; robosustain = tcc->robotize_sustain_probability; robonofx = tcc->robotize_nofx_probability; roboecho = tcc->robotize_echo_probability; roboduplicate = tcc->robotize_duplicate_probability; because the impact of indirect addressing isn't so high compared to other things (such as function calls) I would remove this - it makes the code more difficult to maintain. Best Regards, Thorsten.