TK.

The stopwatch is only working with 16bit resolution (on a STM32), this is limited by the timers which are available on STM32. However, later you want to measure the delay for multiple keys in parallel, using the stopwatch for such a purpose is the wrong way. (I proposed it since I guessed that you wanted to measure delays for experimental reasons - but now I'm thinking a step further) It would be better if you would capture a timestamp instead. E.g. you could use a MIOS32_TIMER based interrupt, which increments a u32 variable each 100 uS (I think that this resolution is good enough for your purposes). See http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F007_mios32_timer%2Fapp.c for a programming example. Instead of the pwm_* counter stuff, you would declare a static volatile u32 timestamp; [/code] variable in the app.c header, and you would write: [code] static void PWM_Timer(void) { ++timestamp; } in the PWM_Timer function, which is called each 100 uS Now you have to capture the current timestamp when the first switch is activated just store the current value in an array - the array has to be dimensioned based on the number of switches you want to handle, e.g.: static u32 switch_timestamp[64]; // for up to 64 switches [/code] Execute this in your handler when the first switch is activated: [code] if( pin_ix < 64 ) // just to ensure that the access is within the array switch_timestamp[pin_ix] = timestamp; When the second switch is activated, you can determine the delay with: u32 delta = timestamp - switch_timestamp[pin_ix]; [/code] This gives you the number of timestamp ticks. The appr. time is delta * 100 uS Best Regards, Thorsten.

Hi Johnc, no, I'm not planning to create new MIOS8 based applications anymore, adding the new features to the old platform is impossible. :-/ Best Regards, Thorsten.

Ja, das ist richtig. Hier nochmal zum Vergleich: http://www.ucapps.de/mbhp/mbhp_scan_matrix1.pdf Doch warum nimmst Du eine Z-Diode und keine ganz normale Silizium-Diode, so wie 1N4148? Du kennst den Unterschied zwischen einer Diode und Z-Diode? Wo liegt bei Deiner Z-Diode die Sperrspannung? Gruss, Thorsten.

You can download it from this page: http://www.midibox.org/logo_competition/ Best Regards, Thorsten.

Wie hast Du denn die Pull-Up Widerstaende an den DIN Eingaengen, sowie die Dioden an den Buttons verschaltet? Gruss, Thorsten.

You are right, I forgot this detail. I checked the voltages on the output channels of my TLV5630 and can confirm that they range from 0..4V yes, correct. You could also check what happens if C10 is removed - does this increase the voltage? Desoldering is easy if you use solder wick: http://www.ehow.com/video_4435740_use-solder-wick-remove-solder.html Best Regards, Thorsten.

You can contact SmashTV for the current .brd file (he improved it meanwhile) Best Regards, Thorsten.

I got the PCB files from Nils, and will handle the order next week (I'm too busy this week) Best Regards, Thorsten.

Btw.: I've worked on MIDIO128 V3 in the last days. It runs on a MBHP_CORE_LPC17 module and will provide such nice features like: - storing/restoring presets on SD Card - integrated MIDI file player (files played from SD Card) - support for USB MIDI - support for up to 3 MIDI IN/OUT ports - support for OSC over Ethernet - optional user interface which can be directly connected to the core (no additional shift registers required): http://www.ucapps.de/mbhp/mbhp_scs_proto2.jpg - device can also be configured from the MIOS Terminal in MIOS Studio - preset files can be edited as a spreadsheet in Excel (or OpenOffice) Adding a 32x32 matrix driver would be a simple task for me, so if you are interested I could add this option Best Regards, Thorsten.

Great! :) Best Regards, Thorsten.

You are right, the selected sections are copied into SEQ_SELECTED_ABCD and played immediately. A synchronization mechanism isn't implemented, but it should be so difficult to add this. It's now in the Wishlist: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_808%2FCHANGELOG.txt Any other (simple to implement) feature request? Best Regards, Thorsten.

Finally an useful feature which was easy to implement. :) MIDIboxSEQ V4.0beta46 ~~~~~~~~~~~~~~~~~~~~~ o added multi copy function: press MENU+COPY to export all selected tracks into the /PRESETS folder on SD Card. The resulting files are named COPY[track].V4T (the [track] numbers are independent from the actual track position) o added multi paste function: press MENU+PASTE to import "COPY[track].V4T" files from the /PRESETS folder into all selected tracks, starting from COPY1.V4T to (up to) COPY16.V4T o use these new functions to quickly copy&paste tracks between patterns and sessions, to create temporary backups, to duplicate tracks, or whatever. Note that you can also import these COPY[track].V4T files from the MENU->Event->PRESETS menu, e.g. to exclude certain parts of the preset o buttons of Wilba's Frontpanel are now debounced [/code] Best Regards, Thorsten. /edit: re-released at 21:15 since only the visible track was exported into the COPY*.V4T files

I did the same checks and can confirm, that all modes lead to the same effect (the phases are relevant once serial data is read). To summarize: channel 0..2 are not working at all. If we would have a bitshifting problem, I would expect that channel 4 would show the same effect channel 3..8 output a voltage which is much higher than REF - I would expect a value between 0V and the reference voltage /edit: range between 0..2*REF ok the REF voltage is lower than expected it seems that the serial transfers are working, because some outputs are changing their value, but not within the 0...REF range My current assumption: the DAC output pins are (or were) short-circuited. It can't be excluded that this fried the chip (partly), but it makes sense to continue the analysis. Which values do you measure on the DAC output pins if all jumpers and OP amps are removed? Best Regards, Thorsten.

Wenn ich Deine Notizen richtig interpretiere, dann sendet die rechte Seite der Matrix auch dann nichts, wenn die Shift-Register Zuweisungen getauscht werden, richtig? Dann ist hier sehr wahrscheinlich die Hardware falsch verdrahtet - die richtige Verdrahtung kannst Du Dir auf der linken Seite abschauen. Gruss, Thorsten.

Did you load the same patch into all 4 cores? Best Regards, Thorsten.

With a bit of luck it will work on your WinXP PC with MIOS32 Bootloader V1.4: But I fear that it won't help, as the WinXP issue on HP computers also happened with other generic USB MIDI interfaces in the past. Best Regards, Thorsten.

Beta 45 is available: MIDIboxSEQ V4.0beta45 ~~~~~~~~~~~~~~~~~~~~~ o USB update for MacOS 10.7 Lion o Chords displayed correctly when a velocity layer is edited [/code] The scrub enhancement will need some work, as you won't notice any effect on the display if the sequencer is not running. The loop improvements for different track modes needs even more work. And session copy/create progress still not displayed Best Regards, Thorsten.

A new bootloader version for MIOS32 is now available under http://www.ucapps.de/mios32_download.html It got an important update for MacOS 10.7 Lion - without this update, the USB MIDI port won't be available anymore, since MacOS tries to handle it like a CDC device. Even if you don't use MacOS the update makes sense, as it contains some minor improvements which I added in the last months. If you've already installed Lion and don't have an alternative computer with Mac OS 10.4/5/6, Windows or Linux available, an update is only possible via the common MIDI interface (port 1) Best Regards, Thorsten.

Thanks for the input! Just for the records: In aout.h you will find a "#ifndef AOUT_SPI_OUTPUTS_OD" statement, which allows you to overrule the default setting in mios32_config.h Thats the reason why I proposed to add it there. Biggest advantage: if I ever update the aout.h file, you don't need to merge your local modifications. Thats an error, I removed the "status |=" It still looks like words which are sent to the device are shifted by one bit. But now we know that the voltage range is very likely not the problem. Could you please do another experiment: try different SPI transfer modes: Replace: status |= MIOS32_SPI_TransferModeInit(AOUT_SPI, MIOS32_SPI_MODE_CLK0_PHASE0, MIOS32_SPI_PRESCALER_4); [/code] by: 1) [code] status |= MIOS32_SPI_TransferModeInit(AOUT_SPI, MIOS32_SPI_MODE_CLK0_PHASE1, MIOS32_SPI_PRESCALER_4); 2) status |= MIOS32_SPI_TransferModeInit(AOUT_SPI, MIOS32_SPI_MODE_CLK1_PHASE0, MIOS32_SPI_PRESCALER_4); [/code] 3) [code] status |= MIOS32_SPI_TransferModeInit(AOUT_SPI, MIOS32_SPI_MODE_CLK1_PHASE1, MIOS32_SPI_PRESCALER_4); And check if any mode sets the VREF output (pin #16) to 2.05V Some of these transfer modes don't make sense, the intention of this experiment is to get a better understanding in which direction we have to continue the analysis. Best Regards, Thorsten.

NEWSFLASH: I installed MacOS Lion today, and noticed exactly the same problem at my side with the STM32, but also with the new LPC17 module! Funny, no? ;) MacOS reports that it tried to enumerate a CDC device (virtual COM port) - I remember that I fixed the descriptors so that the module is able to support USB-MIDI and CDC... let me check if it works better with a USB MIDI only descriptor. Best Regards, Thorsten.

Ah - now I got it, and corrected the schematic! I'm sorry that this mistake caused trouble at your side! :-/ Best Regards, Thorsten.

It behaves like the serial transfers are not working correctly (e.g. each word shifted by 1 bit) Therefore I'm asking you again: another interesting experiment (I'm very interested on the results): configure the J19 pins in push-pull mode. This can be done by adding following defines to your mios32_config.inc file: #define AOUT_SPI_OUTPUTS_OD 0 [/code] (recompile the application). Thereafter change the J26 jumper so that 3.3V are output at J19:Vd - the TLV5630 can work at this voltage range, and by using the pins in push-pull mode the SCLK signal should look "cleaner" than in open drain mode, pulled to 5V. Even if this doesn't solve the problem, it would be interesting to know if you can see the SCLK on your scope now I don't think that trying another driver will really lead to better results. Please help me to understand the problem at your side by following the instructions that I'm giving you. Each topic which you are skipping leads to an unclear picture at my side, and this makes it really difficult to help you remotely. Best Regards, Thorsten.

This is very strange, because the LEDs and buttons should be connected to the same common lines (blue lines in the mbhp_blm_map.pdf file), accordingly there is no reason why the LEDs should be mirrored. Could I have a look into your PCB layout? Modification: // extra row LEDs led_mod_ix = 4; led_row_ix = 1 + ((note >> 1) & 6); led_column_ix = note & 3; if( note >= 0x68 ) led_column_ix ^= 3; // mirrror LEDs 9..12 and 13..16 modify_led = 1; [/code] Best Regards, Thorsten.

Each velocity assignment allocates 3 bytes for CC assignment, initial value and depth. But the patch memory has only 4 bytes free. :-/ Best Regards, Thorsten.

I already see a lot of exceptions in the code to get this properly working %-) will be fixed will be changed (starting the sequencer was my intention, but your argument not to do this is stronger) Short note from my side: the progress is currently not displayed if a new session is created, or an existing session is copied. It looks like the sequencer hangs up - but in fact only the LCD won't be serviced until the operation is finished. This should be fixed in the next release. Best Regards, Thorsten.