TK.

Although I don't really like issues without plausible explanation, I've to say: let's wait until somebody else notices a similar issue under different circumstances which gives me the required input to determine the actual root cause. Best Regards, Thorsten.

Thanks Rowan! And I must say that it's nice to see that you are successfully using your MBSEQ V4 based on a STM32F4 and with 4 Novation Launchpads, although I don't use this setup at my side. :) To everybody: meanwhile I fixed a glide mode bug reported by jjonas, and another bug for drum tracks (parameter display sometimes doesn't work correct, e.g. if Roll parameters are changed). Please find the pre-release under http://www.ucapps.de/mios32/midibox_seq_v4_088_pre2.zip Probably I will release an official v4.088 version this sunday, please help me to test if Glide and Drum mode are still working as expected (because a lot of changes had to be done in order to solve both issues properly) Best Regards, Thorsten.

Hi Carl, it looks like this is only a static pulse waveform with attack 0, decay 112, sustain 80, release 72 So: no wavetable required. The previous steps apply the so called ADSR workaround, MBSID will do this automatically with the ABW flag set in the CFG page. It will cause a +20 mS delay like in the original tune that you've ripped. Unfortunately not so nice for live playing - dammed SID! Blame Commodore that they never initiated a SID redesign to fix the bug :-/ Best Regards, Thorsten.

Merry Christmas! :santa: Thanks to all donators! The money will be invested into special PCB prototypes to give you some kind of reference design instead of my usual breadboard work (which works for myself, but doesn't help you to reproduce the circuit on a comfortable and less error-prone way). Last community-invested work was the MBHP_LINE_DRIVER boards: http://www.ucapps.de/mbhp_line_driver.html Best Regards, Thorsten.

I just remember that some applications (such as the bootloader update application) have an inbuilt LCD interconnection test. After upload, just enter the "testlcdpin" command in MIOS terminal to get a list of available options. By setting the pin to logic-0/1 you will be able to measure if all connection are working properly. Best Regards, Thorsten.

Wow! :hyper: Thank you for sharing this moment with us! Best Regards, Thorsten.

I'm glad that you managed to solve this critical part - your core has the latest and greatest firmware now, and additional issues (noticed by other users in the past) should be solved with this update! :smile: There is no need to recompile the firmware, this is only intended for developers. The configuration has to be done in the MBSEQ_HW.V4 file as explained here: http://www.ucapps.de/midibox_seq_manual_hw.html It requires a working SD Card connection via J16. The LCD should work without any configuration. The MBSEQ firmware has an inbuilt test function which allows you to check the connections, just enter "testlcdpin" in MIOS terminal to get a list of available commands which allow you to set a certain pin and to measure the expected voltage with a multimeter. Best Regards, Thorsten.

MIOS32_IRQ_Install, the ISR handler together with some EXTI register configurations should be sufficient. I don't see the need for MIOS32_IRQ_DeInstall() Best Regards, Thorsten.

Hi Paul, I guess that a very old bootloader version is running on the core, therefore please try to update to the latest bootloader V1.018 the following way: enable bootloader hold mode with a jumper on J27 (it's located between the two J15A/B sockets) re-power the core module, re-start MIOS Studio upload the mios32_bootloader_update_v1_018 application if successfully uploaded: remove the J27 jumper wait until the update happened (see README.txt of this application what should happen) power-off the core power-on the core, it could be that your OS (Windows?) needs some time to re-install the USB driver, because the USB device characteristics have changed in newer bootloader versions start MIOS Studio Now you should be able to upload newer applications which are available at the MIOS32 download page. Best Regards, Thorsten.

Hi Yogi, using an external interrupt will be the right choice. I can't give you a ready made example for this yet, but according to the STM32F4 reference manual all 140 GPIOs can be mapped to the EXTI unit (see chapter 10.2.5, External interrupt/event line mapping), so that any free GPIO pin can be used to trigger EXTI interrupts. I'm planning to use this function soon for the DIN Sync inputs of MBSEQ - so sooner or later I can give you more information and even a programming example if required. Best Regards, Thorsten.

Interesting, I didn't know this failure more yet. Yes, if course - the two RC pins should be separated, there shouldn't be a short between the two pins. You can doublecheck this by removing the STM32F4DISCOVERY board. If there is still a short, check the appr. solder joints Best Regards, Thorsten.

Currently I've only one simple explanation for this issue: your GP button don't work properly anymore, it seems that the contacts are defective. E.g. you are writing "often the pressing+holding the GP button also gives you some note" This indicates, that the GP button function has been triggered twice. Are you using the 612-TL1100 switches from Mouser? I'm using the same (with Wilba's Frontpanel), and after some years and a lot of usage some buttons behaved erratic, so that I replaced them completely. It was a lot of work to desolder the buttons, but it was just necessary. You can doublecheck the need for a replacement the following way: Edit the MBSEQ_HW.V4 file with the MIOS Studio Filebrowser. Add a # before each BUTTON_GP* parameter to disable the button assignments: # SR Pin #BUTTON_GP1 M5 0 #BUTTON_GP2 M5 1 #BUTTON_GP3 M6 0 #BUTTON_GP4 M6 1 #BUTTON_GP5 M7 0 #BUTTON_GP6 M7 1 #BUTTON_GP7 M8 0 #BUTTON_GP8 M8 1 #BUTTON_GP9 M4 0 #BUTTON_GP10 M4 1 #BUTTON_GP11 M3 0 #BUTTON_GP12 M3 1 #BUTTON_GP13 M2 0 #BUTTON_GP14 M2 1 #BUTTON_GP15 M1 0 #BUTTON_GP16 M1 1 store the file. Thereafter enter "reset" in the MIOS terminal to take over the new configuration. After reboot press the GP buttons and check the messages in the terminal. E.g. pressing the GP1 button should only show a single: [718809.425] [SEQ_UI_Button_Handler] Button SR:28, Pin:0 not mapped, it has been pressed. and depressing the button should show: [718809.969] [SEQ_UI_Button_Handler] Button SR:28, Pin:0 not mapped, it has been depressed. If you get multiple messages, you know that the button needs replacement. Or alternatively work with the SELECT button in future (because it seems to work reliable at your side). Note: after this experiment, remove the "#" characters before the BUTTON_GP* parameters to undo the changes. Best Regards, Thorsten.

Hi John, I'm relieved that there is a plausible explanation for this behaviour. :smile: Best Regards, Thorsten.

Great! :) It's documented here: http://www.ucapps.de/mios_bootstrap_newbies.html You can check if the pin #40 repair works by connecting the LCD, because Pin #40 is the D7 dataline to the LCD Best Regards, Thorsten.

I've never seen this before! It seems that communication with the SD Card is working, but it doesn't behave like a common SD Card. E.g. the CID contains some manufacturer informations, and the CSD some implementation parameters - they can be retrieved. Would it be possible to try out a different SD Card from another manufacturer? Can also be a very cheap one. <= 4 GB cards should be preferred, Best Regards, Thorsten.

Works flawlessly at my side. Just to ensure: first you press the GP button, then you enter the notes on the keyboard to record a chord, right? How does it behave if you activate the recording function with the SELECT button, select a step with the up/down buttons (or the datawheel) and then record some notes into the step? Best Regards, Thorsten.

Achtung: im mbseq_v4_dio_wilba_layout.pdf file waren die LED Matrix Spalten gespiegelt, ich habe das jetzt korrigiert. Die GP Duo-LEDs werden auf D3..0 ausgegeben. Gruss, Thorsten.

Very nice melody - it has a certain christmas melancholy! :smile: This issue is related to a corner case that I actually knew, but ignored so far as I thought that it's only an exotic case which wouldn't happen during daily work with the sequencer. However, with the new recording function it can happen quite often! It happened whenever the glide function was activated to stretch the notes to the next step until a new note was played. In this case, all previous notes were cleared (note off events sent) and new note(s) were played. But of course, in this recording the intention was to keep the notes which have been recorded again. I (hopefully) managed to solve the complicated corner case, please try this version: http://www.ucapps.de/mios32/midibox_seq_v4_088_pre1.zip Additional hints: if you want that the chord is re-played whenever the gate has been set, enable the sustain function in the MODE page. Alternatively disable the glide function for step 11 in the Length parameter layer (change the length to < 100%) However, with V4.088 the "re-played" notes should be kept so that these measure are not required. But they make sense if the sequence is played by piano-like sounds which fade out quickly. Best Regards, Thorsten.

V4.087 is available: MIDIboxSEQ V4.087 ~~~~~~~~~~~~~~~~~ o new page: "Track Instrument" Can be selected with MENU->EVNT->Trk Inst (GP #8) or from the main page (after Track Event item) Allows to configure the MIDI port, channel and instrument name. o the new Track Instrument page also allows to select Program Change and Bank (Low/High byte) If activated, these parameters will be sent when the sequencer is started and on pattern changes. Please note: a program and bank change can stall your synth so that the first note could be delayed! Use this function only when the device can handle patch changes quickly! o added CV_GATE_SR1 and CLK_SR to MBSEQ_HW.V4 config This is the prefered option to add CV gates and DIN clock/start signals to your MIDIbox SEQ in future. See also updated http://www.ucapps.de/midibox_seq_manual_hw.html o 8 individual DIN Sync clock outputs with individual divider and pulsewidth values are provided now. A clock output can optionally be turned to a Start/Stop output. The outputs are available at the configured CLK_SR DOUT shift register pin D7..D0 (D7=first output, D6=second output, etc...) The clock parameters can be configured in the CV configuration page. o Mixer page: channel events can be dumped by pressing the corresponding GP button. This also allows to prepare different mixer setups, sending to the same channel, triggered by a GP button o Mixer page: press SELECT to activate/deactivate "live sending" mode (values are sent while moving an encoder) o Mute page: the synchronized mute/unmute option can be temporary overruled by activating the FAST button function o improved step recording display for drum tracks o Selected Datawheel mode in edit page now stored/restored to/from SD Card o STM32F4: support for bootloader "enforce_usb_device" flag Best Regards, Thorsten.

Although it seems that the requestor (benwa) has vanished and nobody else wanted to try this frequently requested feature, it's now released in V4.087 "as is" in the hope that I don't needs changes which conflicts with the updated documentation. Best Regards, Thorsten.

Datawheel mode is now stored in V4.087 Best Regards, Thorsten.

Option 1 is now implemented in V4.087 Best Regards, Thorsten.

Option 1 and 2 are now implemented in V4.087 Best Regards, Thorsten.

I need your session files to explain the reason (and give some hints how to avoid this). Could you please attach the session directory in a .zip file to this thread? Best Regards, Thorsten.