TK.

My feedback once I'm back from business travel. Best Regards, Thorsten.

My feedback once I'm back from business travel. Best Regards, Thorsten.

I'm surprised by myself: it wasn't documented - I updated the MIDIbox 808 page (OPT page, GP 3 to enable pattern synchronisation, GP4 to enable section synchronisation) Best Regards, Thorsten.

Yes, currently the Ctrlr panel can't be used as patch librarian, I'm waiting for an update as well. Not true, the SysEx implementation of MBSID is *very* flexible! :-) It's possible to send the patch either to a given bank and patch slot, or directly into the edit buffer (so that a patch won't be overwritten, resp. could be stored with the SAVE function from the CS) This is documented here: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fdoc%2Fmbsidv2_sysex_implementation.txt resp. in doc/mbsidv2_sysex_implementation.txt of the installation package that you downloaded. Quick guide (if you don't want to work through this document): The SysEx patch starts with: You can change the bank and patch number directly in the SysEx header, it doesn't affect the checksum. If you want to send the patch directly to the edit buffer (-> no BankStick overwrite), replace the "00" before <bank> by "08" (<bank> and <patch> are ignored in this case) Again, this change doesn't affect the checksum which make manual edits easy! SysEx data can be loaded/modified/sent with the SysEx tool of MIOS Studio. Once the promissed Ctrlr updates are also available for MacOS, I will continue on the panel (I'm also a Mac user...) Best Regards, Thorsten.

Integrating Mackie HUI emulation into the MBHP_MF_NG firmware is on my agenda. Unstable/Jittering values can be caused by a PSU issue, if the voltage gets unstable once the motor is moved and consumes power. If you've access to an alternative PSU, please try it first. Another reason could be too long cables between analog inputs (J2) and fader taps. Make them as short as possible. Even shielded cables could help, but as you can see on my prototype picture, ribbon cables are working as well (although it's an uncommon choice) with an acceptable signal quality: http://www.ucapps.de/mbhp/mbhp_mf_ng_final1.jpg If both tips don't help, you could increase the AIN deadband from 3 to 7 - this reduces the resolution by 1 bit, but it leads to more stable values. And a last tip: if touch sensors are connected, no additional measure is required. Just activate the touch sensor mode which only sends MIDI events when the fader is touched. thanks for the hint! We haven't considered this detail, but it makes sense. I think it's better to clearly separate motor supply lines by analog and touch sense lines, because the motor supply is noisy and could induct some jitter. Best Regards, Thorsten.

Hope that you won't hate me for this obvious question, but just to ensure: you've to connect the MIDI OUT of your MIDI source to a MIDI IN of the merger, did you consider this? Best Regards, Thorsten.

Alright, I've also two SwinSID nanos and will try them soon - it could be that the firmware doesn't support the additional features, or that the parameter mapping has been changed. Best Regards, Thorsten.

;-) The difference between global and static (local) variables is, that the linker will locate local variables at the beginning of the SRAM together with some other, normally less critical, variables of other code modules -> see project_build/project.map Example (array name: xxx) *(.bss .bss.* .gnu.linkonce.b.*) .bss.xxx 0x0000000010000000 0xc project_build/app.o .bss.uxMissedTicks 0x000000001000000c 0x4 project_build//Users/TK/svn/mios32/trunk/FreeRTOS/Source/tasks.o .bss.xNumOfOverflows 0x0000000010000010 0x4 project_build//Users/TK/svn/mios32/trunk/FreeRTOS/Source/tasks.o .bss.pxDelayedTaskList 0x0000000010000014 0x4 project_build//Users/TK/svn/mios32/trunk/FreeRTOS/Source/tasks.o .bss.xSchedulerRunning 0x0000000010000018 0x4 project_build//Users/TK/svn/mios32/trunk/FreeRTOS/Source/tasks.o .bss.uxTasksDeleted 0x000000001000001c 0x4 project_build//Users/TK/svn/mios32/trunk/FreeRTOS/Source/tasks.o .bss.xTasksWaitingTermination 0x0000000010000020 0x14 project_build//Users/TK/svn/mios32/trunk/FreeRTOS/Source/tasks.o .bss.xSuspendedTaskList 0x0000000010000034 0x14 project_build//Users/TK/svn/mios32/trunk/FreeRTOS/Source/tasks.o .bss.pxReadyTasksLists 0x0000000010000048 0x64 project_build//Users/TK/svn/mios32/trunk/FreeRTOS/Source/tasks.o [/code] If the array is declared as global variable, it will be located in a region which contains informations used by MIOS32 functions, such as: [code] 0x0000000010000518 xxx *fill* 0x0000000010000522 0x2 00 COMMON 0x0000000010000524 0x40 project_build//Users/TK/svn/mios32/trunk/mios32/common/mios32_srio.o 0x0000000010000524 mios32_srio_din_changed 0x0000000010000534 mios32_srio_dout 0x0000000010000544 mios32_srio_din_buffer 0x0000000010000554 mios32_srio_din *fill* 0x0000000010000564 0x4 00 COMMON 0x0000000010000568 0x300 project_build//Users/TK/svn/mios32/trunk/mios32/common/mios32_enc.o 0x0000000010000568 enc_config 0x0000000010000668 enc_state COMMON 0x0000000010000868 0x24 project_build//Users/TK/svn/mios32/trunk/mios32/common/mios32_lcd.o 0x0000000010000868 font_bitmap 0x0000000010000874 mios32_lcd_y 0x0000000010000878 mios32_lcd_parameters 0x0000000010000882 mios32_lcd_column 0x0000000010000884 mios32_lcd_cursor_map 0x0000000010000888 mios32_lcd_line 0x000000001000088a mios32_lcd_x This could make the difference. I think that I should isolate MIOS32 variables, and locate them to the beginning of SRAM to reduce the danger for overwritten critical variables on out-of-bounds array accesses. This should make the upcoming diagnosis mode more stable. My hope is that it will be even possible to enter bootloader mode from diagnosis mode, or to enter it automatically after 5 seconds if there is no user interaction anymore (e.g. triggered by a watchdog reset) Best Regards, Thorsten.

The only difference in the 8580 and 6581 setup are the different filter calibration values which are stored in the ensemble during formatting (0..600 for 8580, and 0..FFF for 6581) After formatting you can change the value individually for each SID (event separately for left and right channel) in the FIL page of the ensemble, and store it in the SAV page to make it default after boot. SwinSID: currently I've no idea why it doesn't work at your side. What kind of SwinSIDs are you using exactly, and which firmware version? Best Regards, Thorsten.

"flatting" is the wrong term. You are searching for a mechanism which filters MIDI events when the fader isn't manually touched, right? It's provided with the touch sensor mode. Once you connected the touch sensor, it would send a note event whenever the fader is touched (good for testing) Now change the touch sensor mode to the option named "Like previous, but additionally no fader event as long as sensor not pressed" -> voila! :sorcerer: Best Regards, Thorsten.

This download mechanism isn't supported by our server. Please use the common way via a SVN client, such as Tortiose SVN, instead. The URL is svn://svnmios.midibox.org/mios32 Advantage: it downloads the complete repository and you can keep all files up-to-date with a single command. Best Regards, Thorsten.

MIOS32 hasn't been ported to this controller yet. A good starting point would be to copy mios32/LPC17xx into LPC21xx and to migrate these low-level drivers. programming_models/traditional/startup_LPC17xx.c has to be duplicated as well, you also need a dedicated linker file under etc/ld/LPC21xx/LPC2148.ld Recommended MIOS32 variables: export MIOS32_FAMILY=LPC21xx export MIOS32_PROCESSOR=LPC2148 export MIOS32_BOARD=NAME_OF_YOUR_DEVELOPMENT_BOARD [/code] once you did these initial changes, you will get a lot of #error messages while compiling a simple application, such as apps/tutorials/001_forwarding_midi The error messages give you the hint where adaptions are missing, and if you look how they were implemented for STM32 and LPC17, you should know what exactly has to be done. Best Regards, Thorsten.

Hi, this startup page isn't wrong, it just tells you that the internal patch of bank E is selected. You can change the bank and patch by pressing the first GP button to enter the ensemble menu, then click on SID, select bank A and patch 002 (the first patch stored on BankStick) Exit this page, go to SAV (in the ensemble menu), store the setup -> done. Now your MBSID will start with patch A002 after boot. Best Regards, Thorsten.

Das Umloeten der Dioden ist zumindest die einfachste Massnahme, um die Firmware ohne weitere Tricks (Pull-Downs etc.) ans Laufen zu bekommen. Mittlerweile gibt es uebrigens die V1.004 - sie wurde von Acul erfolgreich mit einem Fatar Keyboard getestet. Auf der MIDIbox KB Seite hat sich auch einiges getan: alle Konfigurationsparameter sind dokumentiert und sollten auch funktionieren. Die Parameter fuer verschiedene Fatar-Keyboards sind exemplarisch aufgefuehrt, den Rest kann man sich (hoffentlich) hinzudenken. Auch das "optimierte Scannen" wird nun unterstuetzt. Ohne Optimierung wird ein 61er Fatar Tastatur in 130 uS gescannt. Mit Optimierung in 65 uS (solange keine Taste gedrueckt ist) Nunja, bei diesen Zeiten sollte man wirklich nicht mehr von Latenzen reden... ;-) Vor allem, wenn man beruecksichtigt, dass das versenden eines MIDI Events ueber einen "normalen" MIDI OUT Port 1 mS dauert. Ueber USB dann wesentlich (ca. 10..100 Mal) schneller. Gruss, Thorsten.

Very strange! DIN and DOUT module is working, but you will get a lot of MIDI events once your BLM is connected. How to check that the BLM application is scanning the keys: disconnect the BLM hardware, and short a DOUT pin with a DIN pin which is normally connected "between" a button. -> only a single MIDI event should be triggered. E.g. take this schematic as a reference: http://www.ucapps.de/mbhp/button_duoled_matrix.pdf Take a cable and connect it with D0 of DEFAULT_SRM_DIN_L and D7 of DEFAULT_SRM_DOUT_CATHODES1 -> do you get a single MIDI event, or multiple events? Try also other pin combinations. If this test is working, then it could make sense to think about unusual things: - maybe the cable between core and BLM is too long? -> What is the cable length? - powering problem once multiple LEDs are turned on? -> do you power the MBHP_CORE_STM32 module from an external PSU, or via USB? -> are you using an externally powered USB hub, or is the module directly connected to your PC? Best Regards, Thorsten.

I guess that you mean that SwinSID doesn't work on the slave cores? Then I've a plausible answer: all cores which should handle SwinSID parameters need the firmware update. Simply use the clone function: power-off your MIDIbox, press&hold the MENU button and power-on again. Once the version number is displayed, the firmware of the master core will be transfered to the slave cores. It doesn't hurt if cores which handle normal SIDs get the changes for SwinSID as well. The synth engine consumes a bit more time, but it's a minimum compared to other options, such as AOUT handling etc. Best Regards, Thorsten.

Here a quick&dirty trick - I think it's the most simple solution in your case: 1) upload the MIDIbox FM application-> this should reformat your BankStick. Wait until it's finished (messages will be print on the LCD) 2) now upload the MIDIbox SID application again -> the BankStick should be reformatted again, but now for the full size Best Regards, Thorsten.

Btw: MIOS32_MIDI_SendDebugString is available now: http://www.midibox.org/mios32/manual/group___m_i_o_s32___m_i_d_i.html#g8356461639d04b1d9c6d16d6ee501277 Bes Regards, Thorsten.

A very interesting topic for me, since I'm also searching for better diagnosis solutions to analyse the stack usage and especially hard faults. Currently only the address at which the error happened will be output (this sometimes only works on a LCD, the message sometimes doesn't reach the MIOS Terminal - this could be solved in future by changing the stack pointer to a safe location, and to run only the important MIOS32 functions anymore (handling MIDI + special terminal commands) Back to topic: each thread has it's own stack, which is configured with xTaskCreate. Example: xTaskCreate(TASK_MIDI, (signed portCHAR *)"MIDI", configMINIMAL_STACK_SIZE, NULL, PRIORITY_TASK_MIDI, NULL); xTaskCreate(TASK_Period1mS, (signed portCHAR *)"Period1mS", configMINIMAL_STACK_SIZE, NULL, PRIORITY_TASK_PERIOD1MS, NULL); xTaskCreate(TASK_Period1mS_LowPrio, (signed portCHAR *)"Period1mS_LP", configMINIMAL_STACK_SIZE, NULL, PRIORITY_TASK_PERIOD1MS_LOW_PRIO, NULL); xTaskCreate(TASK_Pattern, (signed portCHAR *)"Pattern", configMINIMAL_STACK_SIZE, NULL, PRIORITY_TASK_PATTERN, &xPatternHandle); [/code] here the stack size of each thread is the default value (configMINIMAL_STACK_SIZE) which is configured with MIOS32_MINIMAL_STACK_SIZE) I also wrote some more informations about this parameter: [code] // Stack size for FreeRTOS tasks as defined by the programming model // Note that each task maintains it's own stack! // If you want to define a different stack size for your application tasks // (-> xTaskCreate() function), keep in mind that it has to be divided by 4, // since the stack width of ARM is 32bit. // The FreeRTOS define "configMINIMAL_STACK_SIZE" is (MIOS32_MINIMAL_STACK_SIZE/4) // it can be used in applications as well, e.g. // xTaskCreate(TASK_Period1mS, (signed portCHAR *)"Period1mS", configMINIMAL_STACK_SIZE, NULL, PRIORITY_TASK_PERIOD1MS, NULL); #define MIOS32_MINIMAL_STACK_SIZE 1100 This also means, that you could run a thread will a higher stack size, and all other threads with the default stack size to reduce the memory consumption: // run MIDI task with stack size 1500 xTaskCreate(TASK_MIDI, (signed portCHAR *)"MIDI", 1500/4, NULL, PRIORITY_TASK_MIDI, NULL); [/code] Another possibility would be to increase the heap. It's 10k (10*1024) by default, to use 14k instead write: [code] // reserved memory for FreeRTOS pvPortMalloc function #define MIOS32_HEAP_SIZE 14*1024 into your mios32_config.h file. Could you please show me your vTaskList() setup? It would be interesting for me as well - an adapted handler for MIOS32 could be added to modules/freertos_utils/freertos_utils.c, currently it only outputs the runtime stats. In order to find out, how many bytes a thread consumes, just increase the stack size of the particular thread, increase the heap, determine the stack consumption, optimized the configuration. Some more hints (we are almost out of topic now, but I guess that this is interesting to know): With following lines you can determine the stack address in the current function: { int x; MIOS32_MIDI_SendDebugMessage("Stack: 0x%08x\n", (unsigned)&x); } [/code] and will following code you can display the stack (e.g. to display the watermark bytes): [code] { u8 *stackAddress = (u8 *)0x20082460; // e.g. determined with umm_info(1, NULL) u32 stackSize = MIOS32_MINIMAL_STACK_SIZE; MIOS32_MIDI_SendDebugHexDump(stackAddress, stackSize); } Last but not least: I think that I should implement a less costly version of MIOS32_MIDI_SendDebugMessage - e.g. MIOS32_MIDI_SendDebugString - which doesn't consume so much stack by itself, and which allows to output a string with any length Best Regards, Thorsten.

There is only a single USB port, it will open multiple MIDI interfaces on your PC. If you are working on a Mac, and if you downloaded another application before which only specified a single MIDI IO port, you have to remove the old config from the Audio/MIDI Configuration, and re-power the core to get all 4 interfaces. Yes, ALPS STEC12E will work. Best Regards, Thorsten.

Hi, DO was actually a typo. Whenever you see "DO" it means "SO" Whenever you see "DI" it means "SI" I corrected the text in the application and in the README.txt in: http://www.ucapps.de/mios/srio_interconnection_test_v2a.zip I also updated the debugging.png snapshot so that it shows the usage in MIOS Studio 2 (please have a look into this picture) Are you very sure that you measured the right pins, because these values are totally wrong. If yes: we need to know more informations about your hardware, what is different from a common MBHP_CORE module? If no: did you already check the remaining three tests as described in the README.txt? What is the result? It's important to know the voltage readings for all tests when somebody should do remote diagnosis! We can help you with this; using the srio_interconnection_v2a test is the right step, but you have to write down more details for each test, otherwise somebody can only guess what is going wrong here. Best Regards, Thorsten.

Great work! :) I don't have access to an Android device, therefore I can't test it. But I noticed that the MidiServer doesn't run on a Mac, probably there's a conflict with the (too new) Java version that you are using: 01.05.12 19:05:18,106 [0x0-0xd33d33].com.apple.JarLauncher: Exception in thread "main" 01.05.12 19:05:18,106 [0x0-0xd33d33].com.apple.JarLauncher: java.lang.UnsupportedClassVersionError: main : Unsupported major.minor version 51.0 01.05.12 19:05:18,108 [0x0-0xd33d33].com.apple.JarLauncher: at java.lang.ClassLoader.defineClass1(Native Method) 01.05.12 19:05:18,108 [0x0-0xd33d33].com.apple.JarLauncher: at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) 01.05.12 19:05:18,108 [0x0-0xd33d33].com.apple.JarLauncher: at java.lang.ClassLoader.defineClass(ClassLoader.java:615) 01.05.12 19:05:18,108 [0x0-0xd33d33].com.apple.JarLauncher: at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) 01.05.12 19:05:18,108 [0x0-0xd33d33].com.apple.JarLauncher: at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) 01.05.12 19:05:18,108 [0x0-0xd33d33].com.apple.JarLauncher: at java.net.URLClassLoader.access$000(URLClassLoader.java:58) 01.05.12 19:05:18,109 [0x0-0xd33d33].com.apple.JarLauncher: at java.net.URLClassLoader$1.run(URLClassLoader.java:197) 01.05.12 19:05:18,109 [0x0-0xd33d33].com.apple.JarLauncher: at java.security.AccessController.doPrivileged(Native Method) 01.05.12 19:05:18,109 [0x0-0xd33d33].com.apple.JarLauncher: at java.net.URLClassLoader.findClass(URLClassLoader.java:190) 01.05.12 19:05:18,109 [0x0-0xd33d33].com.apple.JarLauncher: at java.lang.ClassLoader.loadClass(ClassLoader.java:306) 01.05.12 19:05:18,109 [0x0-0xd33d33].com.apple.JarLauncher: at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) 01.05.12 19:05:18,109 [0x0-0xd33d33].com.apple.JarLauncher: at java.lang.ClassLoader.loadClass(ClassLoader.java:247) [/code] Best Regards, Thorsten.

Hi Per, I would like to reproduce this, but need more informations. Did you push the "Receive" button before changing the configuration, or did you just send a new configuration without taking care for the previous config? And which MIDIO128 V2 version is installed? The latest release is v2.2c Sidenote: instead of using MIDI-Ox, you could also upload the .syx file with the SysEx tool of MIOS Studio. Best Regards, Thorsten.

It's like you are writing: the two new parameters (SwM and SwP) should appear at the end of the OSC menu. After the modification of the setup_*.asm file, you've to rebuild the application (type make) -> has this been done? And did you upload the new generated .hex file? Best Regards, Thorsten.