TK.

Since not only the DOUT, but also a transistor driver is involved, you have to build up a (small) part of the circuit. Best Regards, Thorsten.

This example just doesn't exist yet, and it will never be created for DOSFS since FATFS is much better. Tutorial #19 has to be overworked since it implies that DOSFS is the preferred choice (which isn't the case). This is the most simple code snippet which writes a file to SD Card: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v4%2Fcore%2Fseq_file_g.c Best Regards, Thorsten.

Basically I'm using the same algorithm that I described under http://www.ucapps.de/mbhp_mf.html The biggest differences compared to the previous solution: Duty cycle has much higher resolution for more precise motor speed control Duty cycle depends on distance between current and target position -> than closer the target position, than slower the motor separate values for upward/downward movements, now for each motorfader individually. This is important to ensure that even after years all motors are running synchronously, because some get a bit slower, some others are still fast (the same problem which probably Alex noticed) Following picture shows how precisely a fader can be positioned now This is a ALPS RSAON11M9 fader at 5V. It overshoots the target position at t=100 mS, but can be precisely repositioned at t=180 mS to exactly the middle value (512) Such a control wasn't possible with the old solution. For those who prefer slow faders: just reduce the Max Duty Value :) Best Regards, Thorsten.

Funktioniert tatsaechlich! Danke - Tip des Monats! :) Gruss, Thorsten.

The big problem is, that you neither mentioned in the subject, nor in your first posting that you are working with MIOS32! It makes a big difference compared to MIOS8 (and the slow PIC) - please consider this next time. The MIOS32_SRIO_ScanStart() function is normaly called from vApplicationTickHook, which is a RTOS hook that is called each mS. See also http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fprogramming_models%2Ftraditional%2Fmain.c It isn't possible (resp. recommended) to change the interval of the timer which is used by FreeRTOS, but you could simply call MIOS32_SRIO_ScanStart from an own timer service routine. In order to disable the default handling, add "#define MIOS32_DONT_SERVICE_SRIO_SCAN 1" to your mios32_config.h file Now you can call the function from an own timer. The general usage of a MIOS32 based timer is explained here: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F007_mios32_timer%2F In order to speed up SPI transfers, it makes sense to reduce the number of SRs which have to be serviced, this can be done with "#define MIOS32_SRIO_NUM_SR <actual-number-of-sr>" in mios32_config.h Best Regards, Thorsten.

Hallo Stephan, ich gehe davon aus, dass Du nichts vertauschen musst. Falls die Tasten falsch gemapped werden, kann man die Notenwerte ja einfach in der Software umkodieren. Hier liegt nun die reduzierte Firmware - sie sieht sehr uebersichtlich aus ;-) http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fblm_scalar_4x8x8_buttons%2F Unter http://www.ucapps.de/mios/blm_scalar_4x8x8_buttons_v1.zip habe ich Dir ein fertiges Binary abgelegt, damit Du die Firmware gleich mal ausprobieren kannst. Gruss, Thorsten.

Hallo Stephan, die DOUTs muessen in diesem Fall invertierte Werte ausgeben, dies wird mit BLM_SCALAR_CATHODES_INV_MASK=0x00 eingestellt. Ich werde Dir morgen eine spezielle Firmware zusammenbasteln, denn die verfuegbaren Defines (die in blm_scalar.inc ausgewertet werden) sind nicht immer selbsterklaerend. Gruss, Thorsten.

Hi, the interconnection test isn't prepared for PIC18F4685; you also need a special modification in the MBFM firmware to get access to the OPL3 module. As I'm planning to upgrade my own MBFM to PIC18F4685 soon, I will be able to adapt the applications so that you are able to continue. Best Regards, Thorsten.

Thats fine for me, just try it :) Best Regards, Thorsten.

Hi Marxon, STM32F103RC has only 128k internal flash - this isn't enough. You could order the chip from Farnell.de or a reseller if you are not allowed to buy directly from Farnell. Best Regards, Thorsten.

Hi Axel, welcome back! :) By enabling the MIDI merger it will be possible to chain MBHP_MF_V3 with a common core module. The "Faked Logic/Mackie Control" Mode will handle the Pitch Bender Events. So: a Core32 won't be required, you can re-use your existing hardware and just only have to replace the MBHP_MF_V1 module. Best Regards, Thorsten.

Hallo Stephan, evtl. musst Du bei Deinem Webbrowser den Refresh-Button druecken; ich habe die blm_scalar Applikation erst vor zwei Stunden dort eingebunden (vorher war sie nur im Repository verfuegbar). Die fuenfte Matrix laesst sich im Makefile wie folgt deaktivieren: BLM_SCALAR_DEFINES += -DBLM_SCALAR_DIN5 0 [/code] Zum SVN: das Repository wird nicht mit dem Webbrowser, sondern mit einem speziellen SVN Client heruntergeladen. Falls Du unter Windows arbeitest, ist Tortoise die erste Wahl: http://tortoisesvn.tigris.org/ Weitere Infos stehen unter: http://www.midibox.org/dokuwiki/doku.php?id=windows_toolchain_core Gruss, Thorsten.

Let's hope that Skra will finish his FPGA project (he is also member of this forum), usually he goes very deep into details: http://skrasoft.com/blog/?cat=31 Best Regards, Thorsten.

Thanks for the feedback - the first impression is always the most important one! :) I need this behaviour very often, e.g. when doing small changes in a pattern from any menu page to store the changes from the main menu, and to switch back to the page. There is no other button which would allow this. Just align your habits and press EDIT to exit the main menu instead ;) Since I don't use these buttons very often, it's very likely that I forgot to add the appr. code in seq_ui_*.c Could you please give me a list of pages where these buttons don't work? I know! :) Makes sense, I added this to the TODO list. thats strange - I checked the code and found that it even will be checked twice (one redundant line ;)) - but I don't see the reason why this button shouldn't work. I will test this with my HW soon. An interesting perspective (side view) which can only be realized with a VFD! :) Best Regards, Thorsten.

Hallo Stephan, zu 1: hierfuer gibt es bereits einen fertige Driver, er findet bei der BLM16x16+X Verwendung, und bedient defaultmaessig 5 8x8 matrizen. (Download hier, suche nach blm_scalar) Das besondere an diesem Treiber ist, dass er eine C Schnittstelle bietet, so dass man die zu sendeten MIDI Events relativ einfach selbst anpassen kann - siehe auch das main.c file: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fblm_scalar%2Fmain.c Eine 16x16 Matrix halte ich fuer ungeeignet, da sich hiermit die Latenz verdoppelt. Zu 2: bei der BLM_SCALAR sind die uebrigen DIN Register frei belegbar. Die 5. 8x8 Matrix liefert Dir bereits 64 weitere Eingaenge, es bleiben 11 DINs uebrig. Evtl. koennte man den Treiber auch so konfigurieren, dass noch mehr Matrizen gescannt werden (bin mir gerade nicht sicher, ob das problemlos funktioniert) Zu 3: funktioniert mit dieser Variante nicht, deshalb findest Du auch keine Hinweise in der Dokumentation. Gruss, Thorsten.

I haven't compared this with my RSAON11M9 faders yet, but I've the impression that the new method leads to better results, not at least because the increased PWM resolution allows more exact control over the speed so that probably *any* fader will reach the target position w/o overshoots. The "sine" function of the MBFM tool moves all faders concurrently with slow target position changes -> this is the noise test -> this allows to optimize parameters for less noise. Can't say more about this topic yet - after this posting I stopped the development, and I will continue in some days. Thereafter more details. Best Regards, Thorsten.

When you compare the MBHP_MF_V2 schematic with MBHP_MF, you will notice that the motor control pins are now directly connected to the PIC. The same can be done with the old module - just remove the two 74HC595 chips and use a 16-wire ribbon cable for direct connections between MBHP_CORE and the TC4427 based H-bridges. You should also add the status LED, and a 470 Ohm resistor between the MF potentiometer (P1) and ground for improved voltage control. Note that the MBHP_MF_V2 firmware hasn't been released yet, it needs some more work until it will run perfectly. If nothing unexpected happens I will release it in ca. 2..3 weeks Best Regards, Thorsten.

Instead of buying a 47 Ohm resistor you could also connect two 100 Ohm resistors in parallel -> this will result into 50 Ohm, which is ok for testing. Best Regards, Thorsten.

Maybe you are playing one or more keys on an external keyboard at the same time? Because pattern changes are not only controlled by the matrix buttons, but also by received MIDI Note On/Off commands. To doublecheck that this behaviour isn't related to a hardware issue, I would propose to unplug the MIDI IN cable after you've ensured that there is no actively played MIDI key. Alternatively you could select another MIDI channel and/or reduce the keyboard zone for the drum instruments (ENS->INS) Thereafter press and depress the PLAY button - this will initiate an internal "all notes off" - just to ensure. Best Regards, Thorsten.

Always nice to see what you guys are doing - interesting show! Happy new Year, Simone! :) Best Regards, Thorsten.

Maybe you soldered the buttons with the wrong orientation (rotated by 90° - thats hard to do, but not impossible ;)) Jeppe: could you please attach a photo to give us a better impression about the issue? Best Regards, Thorsten. P.S.: happy new year to those who live in the GMT+10 timezone! :sorcerer:

Hi Kris, I would propose to test the SC and RC connections between the first and second DINX4 module with the SRIO interconnection test (-> http://www.ucapps.de/mios_download.html ) (see README.txt for further instructions) The SI connection between the first and second board can only be checked with a multimeter, e.g. with a beeper function: remove the last chip of the first DINX4 module, and the first chip of the second DINX4 module, thereafter "beep" the connection between the SER input of IC4 (first DINX4 module) and the QH output of IC1 (second DINX4 module). If this still doesn't help to locate the error, it would be interesting if the second module is working when it's connected directly to the MBHP_CORE module (-> swap first and second DINX4 module) Best Regards, Thorsten.

There is currently no advantage if you build this incomplete (!) version - the project is stalled as long as no STM32 derivative with 512k flash and simultaneous access to CAN and USB interface is available. The V3 firmware was only "prove of concept" and some personal C++ practice. It could take another year until it will be continued - or maybe I should just cancel it and focus a new synth? :ahappy: Best Regards, Thorsten.

It's probably a wrongly configured encoder type. MB64e uses MIOS_ENC_MODE_NON_DETENTED while MBFM uses MIOS_ENC_MODE_DETENTED2 by default. According to Peter MIOS_ENC_MODE_DETENTED3 is the more suitable one for STEC12E0x Yod: do you already know how to change the setup_mbfm_v1.asm file and recompile the application? (see also README.txt) Best Regards, Thorsten.

Relevant for MBSID V1 (not MBSID V2!): - setup_*.asm (the setup file you are using) - src/mios_tables.inc - src/cs_menu_io_tables.inc - src/cs_menu_enc_table.inc There are some comments in these files which you have to read to understand the configuration options. Once the firmware has been recompiled, just upload the resulting .hex file via MIDI like you did before. Best Regards, Thorsten.