TK.

First of all I strongly recommend you to work through the tutorial lessons under http://www.ucapps.de/mios32_c.html Step by step you will get some very useful hints about the mechanisms provided by MIOS32 and FreeRTOS Once you reached tutorial #12 you should get a clear explanation how to scan multiplexed pots. Yes, you could use this code as a template. But you shouldn't start reading there - just start at #01 to understand the basics. Best Regards, Thorsten.

You guys are so ill! :ike: no, the frog is sent in a small parcel Yes, once the next heap of pictures is online :) Best Regards, Thorsten.

Beta18d is available now. The follow button should work now, the "save session" function has been optimized, and there are no SD card errors anymore when using the "Save As" function (stack was overwritten on long filenames) Best Regards, Thorsten.

It depends on your usecase - if you only want to send/receive some MIDI events with pots/buttons/LEDs/encoders, a small application can quickly be compiled based on the tutorial examples. If you want to change your MB64 configuration w/o a computer, a user interface like known from the MB64 firmware will be required, and the re-implementation of this would take "a bit" longer. Best Regards, Thorsten.

A link for those who don't already know Aris' Synthfrog Blog :) http://www.synthfrog.com/braska-travels/2010/mr-braska-at-midibox-headquarters/ Best Regards, Thorsten.

Yes, an additional circuit would help. The most simple solution (for me) would be to outsource the task on a PIC16F88, and to access the results via IIC. But for users this would mean that a PIC burner is required to program the (minimal) firmware into the PIC (update via MIDI not possible), therefore I'm still hoping for a more elegant solution. Best Regards, Thorsten.

Hi, the touchsensors are currently (*drumroll*) the big blocking point for me - I don't want to release a MIOS32 based MBLC without this feature, on the other hand I still haven't found an acceptable solution to control touchsensors from a STM32 on a reliable and not CPU time consuming way. :-/ Best Regards, Thorsten.

See this thread: There is a new application which allows to format the SD Card - hopefully it helps. Best Regards, Thorsten.

Thanks! :) I fixed this, follow button should work with the next release Best Regards, Thorsten.

Voltages are looking good, and it shouldn't be an issue that the voltage at J2 is a bit lower than 5V In order to understand the problem a bit better, I would like to know why the output voltage of the 74HC595 is ca. 0.6V lower than Vdd Such as a diode is connected in forward direction to the output? Did you really try a direct connection between DIN and DOUT pin without any other components connected to these pins? And are you using pull-up or down resistors on the DIN pins? Best Regards, Thorsten. P.S.: to confirm that it should work: Wilba's MBSEQ V4 frontpanel is stuffed with LED/button matrices, also my BLM project is working correctly with a STM32 based core.

The interesting point is, that nobody has noticed this bug before, although it exists for all MBSID devices excluding SammichSID (which uses a different matrix handling) ;) Ok, I pirated Wilba's signature and changed the email address ;) It's already in the repository, a precompiled fix will be part of RC36 Best Regards, Thorsten.

Finally I noticed the bug (with the help of this prominent guy ;) and fixed it. Best Regards, Thorsten.

Hi Sam, thats indeed strange - it makes sense to do some initial checks to ensure that the DIN register is powered correctly. E.g., it could be, that due to a missing Vdd connection to the DIN module the SRs are powered indirectly via the pull-up resistors of serial clock inputs, and this would cause such effects. Compare Vdd at MBHP_CORE_STM32::J2:Vd of the core module and MBHP_DINX4::J1:Vd of the DIN module. If the core voltage is higher (e.g. 5.0V?) then it makes sense to try a direct connection between MBHP_CORE_STM32::J2 and MBHP_DINX4::J1 just to check if this helps. If yes: then the problem is related to a missing (or bad) Vd connection. Check also that the R31 resistor array (4x220 Ohm) is stuffed and that the J25 jumper selects 5V. Best Regards, Thorsten.

Indeed an interesting result! Could you please add a "benchmark" command (*) ? :) Best Regards, Thorsten. (*) e.g. generate a 1 MB file. Measure the time how long it takes to write and to read the file. Thereafter copy the file and measure the time again. At the end we will know the read and write performance + the handling performance on copy operations

Fine :) Yes, the checks for a consistent session are a bit pedantic, but only people who worked with previous beta versions are affected. Good that you found a solution by yourself. :) Meanwhile I migrated most of my songs. The manual copy operations were time consuming, but less effort than writing an UI menu to automate this... I can only recomment to all beta testers: forget the old workflow, always create a new session when you are starting with a new song - this ensures that you will never overwrite an important pattern (like it happened to me some time ago). It's also important to start with A1 patterns, and it's helpful to create some phrases in Song S1 so that you can quickly switch between the intended pattern combinations (important to get an oversight if you don't remember the "flow" anymore). I also noticed another issue with FatFs - sometimes (rarely) "SaveAs" is finished after 1 second, but actually no pattern has been copied into the new directory. I've enabled some debug messages in the hope that I'm able to catch enough informations if this should happen again (at my side). Best Regards, Thorsten.

Servus, das interne PIC EEPROM ist viel zu klein um mehrere Baenke zu speichern, du benoetigst also einen BankStick. Um zwischen den Baenken umzuschalten muesstest Du den Tastern eine sog. "Special Function" zuweisen. Die verfuegbaren Funktionen sind hier aufgelistet: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox64e%2Fdoc%2Fmidibox64e_sfb_table.txt AIN (analog input): kann es sein, dass Du DIN (digital input) meinst? Gruss, Thorsten.

Copy fails because the FIL structure is created locally (accordingly it will allocate stack memory) Stack is reduced to 1024 bytes, but each FIL allocates more than 512 bytes, therefore the function doesn't work deterministic anymore (or just crashes) Solution: declare the FIL structures outside the function ("static FIL fsrc, fdst:") Best Regards, Thorsten.

I moved your posting to the right location, because in the MBSEQ V4 thread nobody can read about the history... FatFs reports error status 13, which stands for invalid file system. So, neither FatFs nor DosFs are able to read this SD Card, therefore no hope for this strange format. Phil prepared a new application which allows to format SD Cards, you could beta test this one. Best Regards, Thorsten.

Should work now: we reached beta18c ;) Best Regards, Thorsten.

I uploaded another update (midibox_seq_v4_0beta18b) which fixes sporadic "FatFs" errors, e.g. after a preset pattern has been stored and a new pattern is selected. Best Regards, Thorsten.

Beta18 is now available: o the current patterns/mixer map/song/groove templates will be cleared before a new session is created. o last patterns now correctly selected after startup [/code] Best Regards, Thorsten.

I can reproduce this and will create an update soon Best Regards, Thorsten.

Beta17 is now available for download: o implemented "Sessions" concept. Now you can change between different setups stored on a single SD Card o Sessions can be opened/saved/created in the main menu (press EXIT button) o your old session isn't lost, it's just at the wrong place. To take over this session: - enter MSD mode (UTILITY->DISK) - create a backup of all *.V4 files on your PC (recommented for Beta17!!!) - create a /SESSIONS directory if it doesn't exist yet - create a session subdirectory (8 characters maximum) if you name it "DEFAULT", it will be loaded after startup! - copy following files: MBSEQ_B1.V4, MBSEQ_B2.V4, MBSEQ_B3.V4, MBSEQ_B4.V4, MBSEQ_S.V4, MBSEQ_G.V4, MBSEQ_C.V4 - create a second session subdirectory - copy following files: MBSEQ_B5.V4, MBSEQ_B6.V4, MBSEQ_B7.V4, MBSEQ_B8.V4, MBSEQ_S.V4, MBSEQ_G.V4, MBSEQ_C.V4 - rename these files to MBSEQ_B1.V4 to MBSEQ_B4.V4 - don't copy MBSEQ_HW.V4 (always read from root directory) - remove the copied *.V4 files from root directory, or move them to another directory for backup - unmount the SD Card on your computer - wait until MSD mode is disabled! - press EXIT, thereafter OPEN the session by pressing GP button 9 o changed default track configuration to 256 steps/4 parameter layers since it's more useful in most cases [/code] To give you a full overview I created a dedicated manual section for this topic: http://www.ucapps.de/midibox_seq_manual_sessions.html Other parts of the manual have to be overworked to cover the changes. Note that I haven't "stress tested" the code yet - means in other words: there could be bugs. I will do this in the next days (by creating some nice Sessions :)) Please help beta testing - if the sequencer should crash or behave strangely, please describe the scenario in a way which allows me to reproduce the issue. Best Regards, Thorsten.

I also assumed that this could be a software bug and quickly tried to reproduce this on my MB-6582 after the initial posting of jbartee, but without success (there are no artifacts with with the MB-6582 matrix configuration). The matrix control handling is (a bit) different on the original MBSID design, but I haven't found the time to test this with the latest firmware yet. It could take some days... Therefore I haven't replied to this posting yet. It would be helpful if somebody could confirm that he noticed exactly the same issue on his MBSID before I'm spending hours in searching for a bug which probably is related to something we don't know yet (e.g. failed firmware upload or invalid configuration - e.g. DOUT pins mapped to LED Matrix pins)? Best Regards, Thorsten. P.S.: and who buys me a beer? ;)

and me too... ;) The session concept is implemented, and I can't believe it myself: the sequencer is running pretty stable while a new session is created or stored into a new directory. Magic! :sorcerer: This means, that the sequencer doesn't has to be stopped, e.g. you can play a nice bridge while the copy operations are in progress. :) And changing between existing sessions doesn't lead to any hick-ups of course! :) Beta17 will be released tomorrow. Best Regards, Thorsten.