TK.

You can play up to 6 notes. Details are described in the User Manual: Multi Engine Yes, multi instruments in poly mode are automatically assigned to the available oscillators (voice assignment options are described in the user manual as well, search for "VAs"). There are so many options available, that you probably haven't found the right keywords ;) Best Regards, Thorsten.

Beta2 is available now. From the ChangeLog: Song page got a copy/pase/clear/insert/delete function for song steps.[br] Press the SELECT button to select the utility function Copy/Paste/Clear button can be used in song page as well Song/Phrase mode not switched via SONG button anymore (this handling is an artifact from MBSEQ V2/V3)[br] Instead, the mode can be changed with GP encoder #8 or #9 a 16 step selection pattern for the ALL function is now available (only selected steps will be touched by the ALL function).[br] It can be changed by pressing the SELECT button in EDIT page. the 16 instrument labels of a drum track can be edited now a nice graphical logo is now print during startup lower CPU load if no SD Card connected The new pages are also described in the User Manual: Menu pages. Best Regards, Thorsten.

Great input! This simplifies the installation a lot. I will try this out with my system and change the Wiki pages accordingly. Best Regards, Thorsten.

Yes, it's very likely broken now :-( Best Regards, Thorsten.

Christmas lights! :) Best Regards, Thorsten.

The "Virtual MIDIbox" is totally unrelated to your intentions - it allows to configure MIDIbox64 and MIDIbox64E via SysEx, and to "emulate" the configuration. It doesn't really emulate the MIDIbox firmware, and it hasn't been updated since years... The .zip files contain precompiled applications, most of them are in assembly language... In order to change and rebuild assembly code, you have to install gputils and (as a Windows user) MSYS + the "make" command of "MinGW" as explained in the Quickstart Guide: http://www.midibox.org/dokuwiki/windows_toolchain_quickstart As a MacOS or Linux user, you only need to install gputils, everything else is already part of the Unix/Posix environment. For C you would have to install SDCC in addition (which is a simple step) Best Regards, Thorsten.

No, this isn't a bankstick issue. Like on most (PIC based) MIDIbox applications, the first pattern/patch (A1) always points to the internal EEPROM, which can only store a single pattern/patch. Background: the first slot of a BankStick is used to store some format informations and global data tables. Since the BankStick size is limited to 32k/64k, there will always be one pattern/patch less available - unfortunately... This has changed for MIDIbox SEQ V4, where patterns are stored on a SD Card (-> almost unlimited memory) Best Regards, Thorsten.

Understood! :) The reason for this issue is obvious so long you know the backgrounds... as WickedBlade wrote, we are missing a warning or error message here. On the other hand the reason is simply that the appr. copy routine is missing in the initialisation routine of the MIOS wrapper. Here a weblink to the routine: http://www.koders.com/c/fidFB3A119BB435BBFEEB7CD81E221F283A835233DF.aspx But I fear that I won't have the time to integrate and test the _do_cinit() function in the next weeks... note that it will limit the amount of available flash memory (thats another reason why I haven't done this yet). Is there any volunteer who would like to do the work? Best Regards, Thorsten.

Yes, because his array is preloaded with zeroes: static unsigned int clipButtons[8] = { 0,0,0,0,0,0,0,0 }; and this is the default state after MIOS reset. As already assumed, an array located in RAM won't be preloaded. There are two solutions: - either you preload it inside your application from a const table to your RAM table (thats a simple for-i loop in the Init() hook!) - or you search for code in the internet (or SDCC repository) which is doing the copy operation from the C startup routine (I saw something like this in the past, but don't remember where) Anyhow, I think that the first option should give you a working result in 1 minute! Haha! ;) Best Regards, Thorsten.

With static unsigned char matrix[64] = ... your LUT will be located in RAM (the keyword "static" will make the variable local, it doesn't lead to a constant). So far I remember, RAM areas won't be preloaded automatically by the SDCC wrapper. But using (expensive) RAM isn't the right choice anyhow, it's better to store the table in flash. This should be the case if you are writing: const unsigned char matrix[64] = ... Best Regards, Thorsten.

As described at the User Manual: Hardware page, the 4x16 BLM is already supported. For future, I consider to create a new 16x16 button/LED matrix, this time built on a PCB to avoid all the soldering effort. Probably it will be based on MAX7221 chips as serial shift registers and LED driver. Once I have the hardware, I can add a sophisticated SW support. I'm planning a lot of functions for such a matrix, like direct drum track editing (all 16 instruments in a view), direct track mutes editing (all 16 tracks in a single view), setting loop points, alternative pattern selection (as 256 buttons are available), etc... It's even feasible to cascade 16x16 matrices to a giant display ;) MIDI Clock can be sent by any MIDI port, and it can be enabled individually as described at the User Manual: Menu Pages IIC: 4 modules are natively supported, the usage of 8 modules is feasible (with a firmware hack) as described at the User Manual: Hardware page Best Regards, Thorsten.

Ploytec told me, that the legacy USB MIDI driver provided by Microsoft doesn't work with Vista 64bit (thats one of the reasons why they developed an own driver - but it will only work with a GM5). I don't know, if Microsoft supports the legacy driver for the 64bit version of Win7 Best Regards, Thorsten.

Thats the normal behaviour of most 1x16 displays - unfortunately... When you are using the search function of this forum, you will find many postings where people reported the same. What's exactly your boot message? Controller compatibility doesn't ensure, that characters are print at the same position. The character position depends on the way, how the manufacturer connected the LCD row/columns to the controller. However, if you are planning to program your own application, the solution is simple: use 0x00..0x07 to address the left half, and 0x40..0x47 to address the right half. Best Regards, Thorsten.

Will be shipped tomorrow: Khron_X verpeiler roman01 Napiks joeribl gbraad timyo unit-sound Best Regards, Thorsten.

There are (more or less) bad news, but also good news: The PCB fab delivered the old v1_1 layout by mistake. It has no J8 jumper (1) and no ground rings around the USB socket (2). Both are minor improvements, the v1_1 board will work perfectly. (1) requires to solder a cable from pin IO5 (#10) to ground if your interface should be named "midibox.org" instead of "ploytec". The GM5 will work perfectly as "ploytec" device, so that this cable is really optional. (2) has only been added for mechanical robustness reasons. Your board will work without changes, but if you want to improve it, just follow TheProf's instructions The good news: Ploytec is very sorry for this mistake, and the Fab will send us 100 v1_2 PCBs for free! The PCBs will be available in some weeks. If I already sent you a v1_1 board, and you want a replacement (for whatever reason), just contact me and I will send you the new ones (once available). Shipping will be free People who haven't got their order yet, will be asked if they prefer v1_1 or v1_2 (as mentioned above: it will take some additional weeks until the PCBs will be available) I will sell the remaining free v1_2 boards to cover the additional shipping costs, and the rest of the extra money as a donation to finance my upcoming MIDIbox projects. Best Regards, Thorsten.

Hi Solarvent, it really surprises me every time to read from people who use a MIDIbox since years, but never had to ask for help. :) In SmashTV's MIDIbox Shop you will get the PCB + presoldered STM + kit components for ca. 32 EUR But we are missing a lot of components which are useful for MBHP related purposes, like the 3.3V->5V level shifter for two LCDs, two MIDI IN/OUTs, etc. You should also consider, that the STM32 board from SmashTV comes with MIOS32 bootloader, so that the application can be uploaded via USB (no need to use a RS232 bootloader interface in order to program the MIOS32 bootloader into flash) A killer - I guess it's only a STM32F103RB derivative. Not only the flash/RAM is limited. There are only 8 (instead of 16) DMA channels, etc... No, MBSEQ V4 currently requires ca. 200k flash and ca. 60k RAM. For future versions I'm planning to use the complete flash of course. Yes, there is a "MIOS32_BOARD" option for the first Primer, it works but it's just a toy (especially because of the smaller STM32F103RB derivative) An adaption for Primer2 is feasible w/o much effort, but I don't have this board right here. You won't save time and/or money by buying this evaluation board. As Smithy already wrote: you would have to add the additional components (like MIDI ports and 74HC595 based LCD levelshifters) on a prototype board anyhow. Thats basically more effort than soldering a MBHP_CORE_STM32 kit Best Regards, Thorsten.

Will be shipped tomorrow: fussylizard rosch audio-mobster xaoe morganphalen Janis1279 Tamiflu meToo listen202 Protosx Flexinoodle Lorcan zemika bluescreen niietzshe benuron Shortplay kc Pivado cokrax Best Regards, Thorsten.

Alternatively you could just upload the table with MIOS Studio (only a small .hex file has to be uploaded to a specific range). The implementation would be much easier for me, as the infrastructure already exists! Why not creating a modulation path from Key -> Wavetable position ("MOD" flag must be enabled in WTC!), and controlling the finetune parameter from there? The WT can store up to 128 bytes, accordingly you can assign a dedicated finetune value for each key! :) You could also control Detune this way... or any other parameter. Thanks - I will come back to this table once I find the time. Best Regards, Thorsten.

Thank you! :) Wilba handles the Bulk order. Best Regards, Thorsten.

Yes, the module and the optional kit is now available in SmashTV's Shop. :) It won't be available in Mike's shop since it doesn't make much sense to distribute only the PCB w/o presoldered and tested STM32 chip. Have fun! (Looking forward for more videos once your box has been upgraded! :)) Best Regards, Thorsten.

Auch diesen Typo habe ich nun gefixed ;) Ok, habe ich in MIOS und MIOS32 nun ebenfalls eingebaut. Das waere nett - das Tolle an Deiner Loesung ist ja u.A, dass sie sich so einfach dokumentieren laesst! :) Ich werde noch ein wenig warten, bis ich eine neue MIOS Version release - vorher moechte ich mir 100% sicher sein, dass die Aenderung nicht zu neuen Problemen fuehrt. Es ist uebrigens schon abzusehen, dass ein paar Newbies ueber diese Aenderung stolpern werden - bspw. wenn sie eine neu kompilierte Applikation auf einen PIC aufspielen, der von SmashTV mit MIOS V1.9f vorprogrammiert wurde - umso wichtiger, dass alle betroffenen Projekte einen nicht uebersehbaren Hinweis ueber den erforderlichen MIOS Update erhalten. In MIOS32 ist die Aenderung mit sofortiger Wirkung gueltig ;) Gruss, Thorsten.

Waehrenddessen habe ich die Aenderung auch in MIOS32 eingebaut: mios32_enc.c if( (enc_state_ptr->state == 0x01 && (enc_type & (1 << 4))) || (enc_state_ptr->state == 0x07 && (enc_type & (1 << 5))) || (enc_state_ptr->state == 0x0e && (enc_type & (1 << 6))) || (enc_state_ptr->state == 0x08 && (enc_type & (1 << 7))) ) { // DEC ... } else if( (enc_state_ptr->state == 0x02 && (enc_type & (1 << 0))) || (enc_state_ptr->state == 0x0b && (enc_type & (1 << 1))) || (enc_state_ptr->state == 0x0d && (enc_type & (1 << 2))) || (enc_state_ptr->state == 0x04 && (enc_type & (1 << 3))) ) { // INC ... } [/code] Sieht schon wesentlich kompakter aus, und funktionierte deshalb auch auf Anhieb mit meiner MBSEQ V4! :) So sieht uebrigens der vom Compiler generierte ARM Assembler Code aus: [code] if( (enc_state_ptr->state == 0x01 && (enc_type & (1 << 4))) || 801d56c: f818 2007 ldrb.w r2, [r8, r7] 801d570: f002 030f and.w r3, r2, #15 ; 0xf 801d574: 2b01 cmp r3, #1 801d576: d102 bne.n 801d57e <MIOS32_ENC_UpdateStates+0x9e> 801d578: f014 0f10 tst.w r4, #16 ; 0x10 801d57c: e00d b.n 801d59a <MIOS32_ENC_UpdateStates+0xba> 801d57e: 2b07 cmp r3, #7 801d580: d102 bne.n 801d588 <MIOS32_ENC_UpdateStates+0xa8> 801d582: f014 0f20 tst.w r4, #32 ; 0x20 801d586: e008 b.n 801d59a <MIOS32_ENC_UpdateStates+0xba> 801d588: 2b0e cmp r3, #14 801d58a: d102 bne.n 801d592 <MIOS32_ENC_UpdateStates+0xb2> 801d58c: f014 0f40 tst.w r4, #64 ; 0x40 801d590: e003 b.n 801d59a <MIOS32_ENC_UpdateStates+0xba> 801d592: 2b08 cmp r3, #8 801d594: d13b bne.n 801d60e <MIOS32_ENC_UpdateStates+0x12e> 801d596: f014 0f80 tst.w r4, #128 ; 0x80 801d59a: f000 808a beq.w 801d6b2 <MIOS32_ENC_UpdateStates+0x1d2> (enc_state_ptr->state == 0x07 && (enc_type & (1 << 5))) || (enc_state_ptr->state == 0x0e && (enc_type & (1 << 6))) || (enc_state_ptr->state == 0x08 && (enc_type & (1 << 7))) ) { // DEC ... } else if( (enc_state_ptr->state == 0x02 && (enc_type & (1 << 0))) || 801d60e: 2b02 cmp r3, #2 801d610: d102 bne.n 801d618 <MIOS32_ENC_UpdateStates+0x138> 801d612: f014 0f01 tst.w r4, #1 ; 0x1 801d616: e00d b.n 801d634 <MIOS32_ENC_UpdateStates+0x154> 801d618: 2b0b cmp r3, #11 801d61a: d102 bne.n 801d622 <MIOS32_ENC_UpdateStates+0x142> 801d61c: f014 0f02 tst.w r4, #2 ; 0x2 801d620: e008 b.n 801d634 <MIOS32_ENC_UpdateStates+0x154> 801d622: 2b0d cmp r3, #13 801d624: d102 bne.n 801d62c <MIOS32_ENC_UpdateStates+0x14c> 801d626: f014 0f04 tst.w r4, #4 ; 0x4 801d62a: e003 b.n 801d634 <MIOS32_ENC_UpdateStates+0x154> 801d62c: 2b04 cmp r3, #4 801d62e: d140 bne.n 801d6b2 <MIOS32_ENC_UpdateStates+0x1d2> 801d630: f014 0f08 tst.w r4, #8 ; 0x8 801d634: d03d beq.n 801d6b2 <MIOS32_ENC_UpdateStates+0x1d2> (enc_state_ptr->state == 0x0b && (enc_type & (1 << 1))) || (enc_state_ptr->state == 0x0d && (enc_type & (1 << 2))) || (enc_state_ptr->state == 0x04 && (enc_type & (1 << 3))) ) { Im Endeffekt benoetigt der Cortex M3 ca. 90 Bytes zur Auswertung, und der PIC 106 Bytes. Hier laesst sich vielleicht noch etwas rausholen, doch dann wird der Code wirklich unlesbar... Gruss, Thorsten.

Habe die Aenderung nun an meiner MBSID (DETENTED2) gestestet, und einen weiteren Tippfehler gefunden. Nun funktioniert es! Es zeigt sich mal wieder, wie fehleranfaellig Assemblercode beim RabidRapid Prototyping ist... Gruss, Thorsten.

Haette den Code vorher vielleicht doch nochmal ausprobieren sollen - ich habe ihn nach einer zweiten visuellen Kontrolle abermals geaendert, ihn jedoch nach wie vor nicht getestet - dafuer bist Du ja da ;) Der Typo: das TABLAT, <bit> war nach IRQ_TMP4, <bit> gerutscht. Das kommt davon, wenn man am kleinen Notebook Bildschirm tippt... Gruss, Thorsten.

P.P.S.: Du musst nochmal updaten, da war noch ein Schreibfehler...