TK.

It won't help to bring the voltage even closer to 12V For me this case is open until anybody else was able to reproduce this - as mentioned above, it's easy to verify that the software writes the correct values into SID registers. It could make sense to check this with 8580 or 6582 if available (but this will require to change the voltage/filter caps) Best Regards, Thorsten.

Thats an intensive effect and I cannot believe that nobody discovered this before (I wasn't able to reproduce this) For me it sounds like the internal SID filter stage isn't balanced This can happen if the 6581 is supplied with a voltage (much) lower than 12V, e.g. 9V - or if you are using the wrong (or unequal) filter caps Please check this first. If you want to check the software, you could read out the filter values which are written into the two cutoff registers by sending F0 00 00 7E 40 00 0D 02 00 06 15 00 00 00 02 00 00 00 00 F7 with MIOS Studio as illustrated in this snapshot: It also shows the corresponding assignments of the filter values with the register readout. In this example, I changed cutoff from 7FE to 805 and requested the cutoff values after each step by sending the sysex string described above. Note that the SID filter works at 11 bit only, but MBSID uses 12bit. Combined with the calibration routine the next MSB will be reached at 801 and not 800 - thats no bug (correct by construction), and under proper conditions it will never result into an audible effect (like on your MP3s) Best Regards, Thorsten.

Please post: - a patch in .syx format (just open the SysEx tool of MIOS Studio, enable receive mode, press SHIFT+Dmp on your MBSID to send the patch) - an audio sample in .mp3 format - the exact filter settings in ensemble FIL page Best Regards, Thorsten.

I just have noticed, that the arpeggiator doesn't work with Input ports set to "All", you have to select a dedicated port. I will fix this in the next release It works when a dedicated input port is selected, with and without T/A split Yes, you will have to activate T/A split and send the root note with the lower keys (either from a keyboard or from a second loopback track), and the chord with the upper keys. Use track transpose to correct the octaves. The "loopbacked chord track" should be in transpose mode Alternatively you could transpose the "loopbacked chord track" from a second loopback track via CCs. This makes sense if you prefer an independent transpose. You could play certain tracks on Bus2, 3 or 4, and use the MIDI router to forward the MIDI stream to a physical MIDI device. This gives you more flexibility, e.g. you can change your MIDI wiring without changing the track configurations, just adapt the global MIDI router settings. It's an expert feature only. Best Regards, Thorsten.

The upgrade path is simple: build a MBFM w/o control surface (MBHP_CORE and MBHP_OPL3) only, and control it from the Java editor until the "remote access" solution is available. You can already use a PIC18F4685 instead PIC18F452 with the existing firmware w/o changes. Later two data lines to OPL3 (D2 and D3) have to be connected to some other IO pins, since RB2/RB3 will be allocated by CAN. But no other changes will be required (no additional devices, etc) Best Regards, Thorsten.

It's very likely that MBFM V2 will run on a STM32F05 based core, and that it will provide a more modern sound engine + UI (e.g. with graphical LCD option, perhaps also with touchscreen) It's likely that it will be controllable from the MBSID V3 CS and VST/AU It's even likely that for an easy adaption the OPL3 will be controlled via PIC18F4685/CAN like the SIDs It's unlikely that I will provide an option which doesn't rely on a STM32F105 based core. Best Regards, Thorsten.

Aha, Du bist also ein Flachloeter. ;) Das klappt mit meiner ERSA Loetspitze 832SD (Bleistiftform) uebrigens definitiv nicht, und schon gar nicht wenn sich die Pads nicht direkt am Rand befinden. Da braucht es schon ein paar Minuten, bis die Bauteile (vor allem MIDI Buchsen und VRs) sauber verloetet sind, und sie werden dabei sehr heiss. Mit einer breiten Loetspitze muss man nur mal eine Sekunde lang antippen, schon ist das Loetzinn sauber verflossen. Ich berfuerchte ja, dass viele Leute dieses Problem haben, und dass es deshalb sehr oft zu verkohlten PCBs oder kalten Loetstellen kommt. Gruss, Thorsten.

Zu den vollflaechigen Loetpads ein Kommentar: ich fand das beim Loeten auch immer aergerlich, doch es gibt hier eine Fraktion, die sich vehement dagegen wehrt, sog. Thermals in das Layout einzubauen. Doch dann ist mir neulich eher durch Zufall aufgefallen, dass sich die Massepads supereinfach verloeten (und auch wieder entloeten) lassen, wenn man da einfach mal mit einer breiteren Loetspitze rangeht. Mittlerweile vermute ich, dass die besagte Fraktion zu den heimlichen Breitspitzloetern gehoert, und dass es deshalb angeblich "nie probleme beim Verloeten" gibt. Gruss, Thorsten.

Ich finde die Idee genial! :) Gruss, Thorsten.

Roger's proposed solution is attractive, because it doesn't require a PIC programmer. On the other hand using a small PIC16F88 would be better for those DIY people who prefer easy to handle DIL packages. Djamon: your proposal to use a "discrete circuit" sounds simple, but it's much more complex (and therefore more error prone) than using other solutions I had in mind. E.g., instead of a NE555 timer, I could simply use a timer output pin of STM32 to generate a pulse. By using a transistor it could be easily converted to 5V in push-pull mode. The pulse has to be generated before DIN inputs will be captured. This backup solution will allocate some resources of the STM32, such as one GPIO pin and a timer. It will require some SRIO driver changes (pulse has to be triggered before DIN values are captured, implementation should be completely interrupt driven), and it will be difficult to identify a GPIO pin which isn't used yet (at least by MBLC), and can be controlled by a timer peripheral which isn't used yet and won't be used by future enhancements. This backup solution will require some conceptional work at my side, for which I don't have the time yet (project overflow). Using a PIC16F88 would be a solution where I could already say today, that it will perfectly work without conflicts. Therefore this is the only solution today where I could say: yes, I can do it this way without much effort (especially since I've enough spare PICs) Best Regards, Thorsten.

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.