TK.

Great, fine! :) Verbose Level 3 generates an extra message for the case that the decoding routine filters out DIN events, so that they are not displayed. It's mainly for people who want to re-use the code, but have to change the decoding. Best Regards, Thorsten.

Press the MENUEXIT button and scroll with the datawheel to the end of the list. CV Configuration is the page before the ethernet configuration. There is no special button combination available to enter this page. Best Regards, Thorsten.

Hi Robin, I finalized the application (at least for my side): - velocity delay values now defined as variables, so that they could be changed during runtime - DOUT now always latched after SRIO scan, because I've a better feeling when outputs are already stable before DINs will be latched some 100 microseconds later - VERBOSE_LEVEL set to 1 for best performance (increase it to 2 or even 3 to get more debug messages) Could you please confirm that the "final" version works properly at your side before adding your changes? For finding the best matching values, the usage of a pot would be perfect. Alternatively you could add a CC handler which receives delay values from an external MIDI controller (disadvantage: only values from 0..127 could be sent) Or an "input terminal" could be implemented which allows to receive commands from MIOS Studio - but this wouldn't really be worth the effort, although you like geeky solutions! alright, done. Thanks! :) Yes, I hope that other people feel inspired and provide customizations for their own systems. Once you've finished your program, we could release it in a different folder as an additional example. Btw.: I'm planning to rename this thread in some days, because the topic "SRIO, DOUT, DIN, 16 bit , 8bit Confusion" doesn't match anymore. Best Regards, Thorsten.

Gridracer.Karma -= 1; Just kidding! You can still feel welcomed for reporting any anomaly that you noticed, you found a lot of issues in the past! :) Grizz: I'm still puzzled about your issue and don't have an answer. There is neither an additional pin, nor something else which would be special. I know that you already checked the SPI connections... so, everything should be fine. On the other hand I improved the initialisation part of the AOUT driver that is integrated into MBSEQ. It should work more robust now - therefore it will be interesting if this already solves your issue. Best Regards, Thorsten.

Du bist wirklich ein Klugscheisser! Gruss, Thorsten.

The default 750 mS delay between SysEx blocks is probably not high enough - the actual programming time depends on the initial content of your EEPROM (BankStick) and the CPU load which is caused by the currently active patch. If you upload the patch again, programming time should be much shorter, as MIOS only overwrites EEPROM pages which are different from the new content. Maybe I should change the default setting in MIOS Studio to 1000 mS to avoid such upload errors. On the other hand: if you would use the MBSID Editor, a patch upload wouldn't depend on such mysterious delay values as the next patch won't be sent before the previous had been acknowledged by MBSID -> most robust solution -> go for it! :) Best Regards, Thorsten.

Hi, You haven't mentioned how you uploaded the patches. Maybe there was an error during transfer which you haven't noticed? If you are using the MBSID Editor a message should pop up. However, it would be interesting if it works if you upload the patches again? Best Regards, Thorsten.

Welcome back! :) No, it neither has been skipped, nor it has been changed. Could you please check that the BUTTON_BEH_ALL variable is set to 1 in your MBSEQ_HW.V4 file? BUTTON_BEH_ALL 1 [/code] it only affects the currently selected layer as expected/suggested. Could you please describe me how I can reproduce this misbehavior with a freshly initialized track? If it only happens with one of your already existing tracks, could you please export the track to a preset file and attach it to this thread? Best Regards, Thorsten.

Thanks! I optimized the loop again, now we are counting from -1 to 15, and handle row==-1 as an "initial state". This leads to better readable code. Could you please try again? I hope that I haven't added another error. Velocity curve: I entered your measuring results into a spreadsheet and assumed, that each "level" reduces the velocity value by -30 (just an assumption) It turned out that the curve is pretty linear: So, instead of using heavy mathematical stuff (like log() or exp()), it could be sufficient to change KEYBOARD_DELAY_FASTEST and KEYBOARD_DELAY_SLOWEST into variables, and to switch between two value sets with a switch. Best Regards, Thorsten.

Bei 100 AUD muss man so oder so Zoll/Mwst. bezahlen, egal ob es ein Geschenk ist oder nicht. Gruss, Thorsten.

Kleine Anekdote, als ich die MB-808 Platine erhielt: Zollbeamter: ist das eigentlich Elektronik oder Bastelmaterial? Ich: ich moechte mir damit ein Musikinstrument bauen. Zollbeamter: sagen sie das doch gleich, Musikinstrumente haben einen anderen Zolltarif. Es stellt sich dabei heraus, dass es der guenstigere Tarif war ;) Gruss, Thorsten.

yes - are you still doing any modifications (e.g. the "row-=1" workaround)? Because row=0xff will never be passed by the SRIO handler, it should work with this change! Best Regards, Thorsten.

Hi Robin, could you please try again with the version I released at 18:34 (CET) (somehow I knew that you will face the error before I come back from a nice walk in the autumn sun ;)) Improved velocity support once pins are mapped correctly again. Thereafter you can integrate your own code. Best Regards, Thorsten.

P.S.: I changed the scan loop again, so that RC is also pulsed after SRIO shift. Approach: - latch DIN values - read DIN, shift next DOUT pattern - latch DOUT values - period it is possible to omit the second pulse (as we did before), but first I would have to know if the current version is working correctly! (as I cannot try it with real hardware, there is always the risk that I overlook something...) Best Regards, Thorsten.

Du hast wahrscheinlich ein Standardschreiben bekommen, in dem immer nach einer Rechnung gefragt wird. Wenn die Lieferung wirklich ein Geschenk war (kommt bei mir des oefteren vor), lasse ich mir vom Absender den Warenwert per EMail bestaetigen (dabei kann man ja ruhig mal ein wenig abrunden...) - die Zollbeamten geben sich damit zufrieden, und berechnen dann auf diesen Wert Zoll und Mehrwertsteuer. Falls Dir das zu heikel ist, zeige ihnen die PayPal-Rechnung und gib an, dass sich der Absender bei der Deklarierung der Ware wohl vertan habe... Gruss, Thorsten.

Hi Robin, I think that I found the reason why the row index started from 1 instead of 0. Before the first row was scanned, the selection pattern for row=0 was shifted into the DOUT registers, but it hasn't been latched. Accordingly, the first DIN scan started with the selection pattern for the last row (row=15, which is not connected at your side) Now I'm pulsing RC before the scan is started. At the beginning we will have two pulses, one to latch DOUT values, another to latch the DIN values of the selected row - this is correct and no programming error. so that we would get a notification about the potential programming error. You could please specify the measured delay instead of the velocity value? Because the velocity value is already a result of the formula which applies the delay value. We want to replace this formula, therefore we need the input parameter. Best Regards, Thorsten.

At least the MIOS32 implementation of the BLM_SCALAR driver provides equivalent functions: extern s32 BLM_SCALAR_PinSet(u32 colour, u32 pin, u32 value); extern s32 BLM_SCALAR_DOUT_PinGet(u32 colour, u32 pin); extern s32 BLM_SCALAR_DOUT_SRSet(u32 colour, u32 sr, u8 value); extern u8 BLM_SCALAR_DOUT_SRGet(u32 colour, u32 sr); [/code] they don't exists for the MIOS8 variant as I was too lazy for doing this. However, you've direct access to the LED arrays: [code] extern unsigned char blm_scalar_row_red[5*8]; extern unsigned char blm_scalar_row_green[5*8]; which works much faster anyhow. let's assume the pin number is stored in a 16bit variable: unsigned short pin; pin = 0; // as an example) [/code] then you can set a "green" LED with: [code] blm_scalar_row_green[pin >> 3] |= MIOS_HLP_GetBitORMask((unsigned char)pin)); and clear a "green" LED with: blm_scalar_row_green[pin >> 3] &= MIOS_HLP_GetBitANDMask((unsigned char)pin)); [/code] Best Regards, Thorsten.

Hi Robin, as mentioned earlier, you will have to change your hardware connections to get the pin numbers matching again. Previously the first pin was in row 1, although the software already started to count from row=0 (so, it was the second row) Just check your DOUT connections, all pins have to be shifted by one. Alternatively try following change: // will be called on button pin changes (see TASK_BLM_Check) void BUTTON_NotifyToggle(u8 row, u8 column, u8 pin_value, u32 timestamp) { row -= 1; // we don't know why rows are starting from 1 on Robin's Hardware [/code] Best Regards, Thorsten.

I updated the files so that they are matching with your pin table. And I copied the .doc file into the doc/ folder. Probably you have to change some matrix connections on your hardware if this hasn't been done yet. To determine a suitable logarithmic curve it would be interesting which delay you measure for different pressures, e.g. "hard", "normal", "semi", "soft", "very soft" - and which velocity values should be output in such cases. Best Regards, Thorsten.

Seems that you haven't installed the arm-none-eabi-gcc toolchain yet. See also this document: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fdoc%2FMEMO resp. this Wiki page: http://www.midibox.org/dokuwiki/doku.php?id=installing_gnu_on_osx Best Regards, Thorsten.

Following variables have to be set in addition: export MIOS32_FAMILY=STM32F10x export MIOS32_PROCESSOR=STM32F103RE export MIOS32_BOARD=MBHP_CORE_STM32 export MIOS32_LCD=clcd [/code] Best Regards, Thorsten.

Hi Robin, I'm glad that the code is working, although I never had the chance to test it by myself. Your descriptions and comments made it easy to follow the progress remotely! :) Using different methods (e.g. faster scan speed, faster update cycle, using DMA) will lead to a lot of extra work for that I think it isn't really worth the effort! From my experience I can already say that this won't improve the results, and Duggle confirmed this in his comment. By scanning the complete matrix within 1 mS you've already a very optimized version, with common MIOS32 SRIO driver it would normaly take 16 mS (since a single DIN pair of the matrix would be scanned each mS) which is slower than the shortest possible delay. Now you've a version which scans faster than the shortest delay. To your table: could you please also count the pin numbers from 0 instead from 1? This would simplify the documentation as well, because currently I had to add some comments into the source code to explain the difference, which might be confusing. Starting note: ok, will be changed to 0x15 Velocity curves: good point! It could make sense to apply a logarithmic curve, so that short delays lead to higher differences than long delays - I will check later today (or tomorrow) if it's possible to calculate the curve during runtime instead of using a pregenerated table to allow finetuning w/o recompilation. Best Regards, Thorsten.

Yes, exactly! :) I'm using following formula to determine the velocity value: // determine velocity depending on delay int velocity = 127 - (((delay-KEYBOARD_DELAY_FASTEST) * 127) / (KEYBOARD_DELAY_SLOWEST-KEYBOARD_DELAY_FASTEST)); // saturate to ensure that range 1..127 won't be exceeded if( velocity < 1 ) velocity = 1; if( velocity > 127 ) velocity = 127; [/code] So, the minimum and maximum delay is scaled to a velocity value between 1..127 The constants are defined in the header: [code] #define KEYBOARD_DELAY_FASTEST 3 #define KEYBOARD_DELAY_SLOWEST 100 If you notice different min/max delays, just change these constants (and let me know so that I can insert them into the original file) Note that you could try to play a software synth with your keyboard now. It's also possible to control a common MIDI device, just replace: #define KEYBOARD_MIDI_PORT DEFAULT [/code] by: [code] #define KEYBOARD_MIDI_PORT UART0 and MIDI events will be sent to the MIDI OUT1 port of the MBHP_CORE_STM32 module. Best Regards, Thorsten.

Note Off events: stupid error from my side, these events should be sent now. Velocity: it would be important to know which delays have been measured (messages should be short enough now) Best Regards, Thorsten.

Ok, it seems that the code is working (are MIDI events sent? The MIDI IN Monitor of MIOS Studio should show them), just the debug message which will show the delay was too long. Could you please try the updated version? Best Regards, Thorsten.