TK.

Could it be, that this issue is just only related to your AlphaTrack controller? Why does it send MIDI messages to MBCV? Shouldn't Logic filter those events? Best Regards, Thorsten.

Read this page: http://www.ucapps.de/midibox_seq_manual_in.html Especially "Initial Setup for Wilba's Frontpanel" But the remaining informations could be helpful as well. Best Regards, Thorsten.

Are you able to create a .mid file which plays back the exact sequence that is causing this problem, so that I'm able to reproduce it at my side? (a Logic .lso File would work at my side as well) Best Regards, Thorsten.

Yes, MONO mode is fine for sequenced parts. You could also use LEGATO mode if you don't want a re-trigger on overlapped notes, but this won't solve your problem. For some reasons the MBCV doesn't receive the Note Off events for played Notes. Could it be that you are sending a Program Change to MBCV which changes the MIDI channel or keyboard splitzone configuration while some Notes are still played? This could lead to such an effect. You could filter Program Change events which are sent to MBCV in your Logic environment to check this. Btw.: this seems to be a problem which never happened before with your setup, right? This would just second the assumption, that it is related to a MBCV configuration change at the wrong moment. A possible workaround (in the firmware) could be to empty the note stacks on program changes. But first I would like to know, if this is really the reason... Best Regards, Thorsten.

This could happen if your MBCV is in Mono mode (so that a Note Off will re-trigger the gate), and when your host sequencer sends a Note On, but never the corresponding Note Off event. Since you probably don't know, which Note Off event is missing: could you please check, if the gates can be deactivated by sending Note Off events for all Notes? (with Logic, you could create a track, open the pianoroll view, insert 128 short notes for all keys, and play this track). This should also help to determine, which note actually has been played (but never released) unintentionally. Your observations will be helpful to find a solution (e.g. a workaround in MBCV firmware) - currently I've no idea what is going on with your sequencer. Best Regards, Thorsten.

It is neither required to use a timer, nor to program this in assembly code. Just use the SR_Service_Prepare() hook, which is called each mS before the shift registers are loaded. Inside this hook, use a counter (a global variable), whenever it reaches a certain value (e.g. 200 for a 200 mS delay), apply an inversion pattern on all DOUT bits which should flash. Step by step (in the hope that it's understandable): define a global variable somewhere in the header of your application: // 8bit variable (range: 0..255) unsigned char flash_ctr; [/code] And insert following code into the ServicePrepare hook: [code] void SR_Service_Prepare(void) __wparam { if( ++flash_ctr >= 200 ) { flash_ctr = 0; MIOS_DOUT_SRSet(0, MIOS_DOUT_SRGet(0) ^ 0x01); } } This will: - read the 8bit value of the first shift register (#0) - XOR the value with 0x01 (means: first DOUT pin will be toggled) - write back the value into the first shift register - this will be done each 200 mS Examples for XOR patterns: 0x01: will toggle 1st LED 0x02: will toggle 2nd LED 0x04: will toggle 3rd LED 0x08: will toggle 4th LED 0x10: will toggle 5th LED 0x20: will toggle 6th LED 0x40: will toggle 7th LED 0x80: will toggle 8th LED To toggle multiple LEDs, just OR the values, e.g.: (0x01 | 0x80): will toggle the 1st and 8th LED The brackets are important!!! Or if you got practice, just write this into a single value without OR operation: 0x55: will toggle 1st, 3rd, 5th and 7th LED Ok, now you want to make the flash pattern variable and control it from another MIDI device. Define another global variable: unsigned char flash_pattern; [/code] (initialize it with 0x00 in the Init() hook) Modify the SR_Service_Prepare() hook the following way: [code] void SR_Service_Prepare(void) __wparam { if( ++flash_ctr >= 200 ) { flash_ctr = 0; MIOS_DOUT_SRSet(0, MIOS_DOUT_SRGet(0) ^ flash_pattern); } } Thats all. Now you can set a specific bit of the 8bit pattern (e.g. from the MPROC_NotifyReceivedEvnt() hook when a certain MIDI event has been received) with: // it is assumed that dout_pin is in the range of 0..7 flash_pattern |= MIOS_HLP_GetBitORMask(dout_pin); [/code] and you can clear it with: [code] flash_pattern &= MIOS_HLP_GetBitANDMask(dout_pin); Next step: you want to flash more than 8 LEDs - it's time to use an array, e.g.: // prepared for all 128 DOUT pins unsigned char flash_pattern[16]; [/code] (initialize all array elements with 0x00 in the Init() hook) Modify the SR_Service_Prepare() hook the following way: [code] void SR_Service_Prepare(void) __wparam { unsigned char sr; if( ++flash_ctr >= 200 ) { flash_ctr = 0; for(sr=0; sr<16; ++sr) MIOS_DOUT_SRSet(sr, MIOS_DOUT_SRGet(sr) ^ flash_pattern[sr]); } } Setting/clearing a specific bit will require following code: // it is assumed that dout_pin is in the range of 0..127 flash_pattern[dout_pin >> 3) |= MIOS_HLP_GetBitORMask(dout_pin); [/code] and you can clear it with: [code] flash_pattern[dout_pin >> 3] &= MIOS_HLP_GetBitANDMask(dout_pin); Have fun by doing some more experiments! :) Best Regards, Thorsten.

A new version is available (RC33) (sorry, no alternative frequency table yet...) ChangeLog: o built for MIOS V1.9g (or higher) to support new encoder types. Rotary encoders won't work with older MIOS versions! Note that MIOS only has to be updated on the master SID, as encoders are not connected to SID slaves anyhow. o a new LED matrix visualisation mode for sammichSID has been added which is selected with DEFAULT_LEDMATRIX_MODE 2 - Lead and Bassline engine: 6x8 LEDs show VU meters for OSC frequency - Multi and Drum engine: 6x8 LEDs show animated VU meters for OSC triggers - ASID player mode: 6x8 LEDs show animated VU meters for OSC triggers o animated VU meters are a bit faster now o a special configuration file and prebuilt binary for sammichSID is now part of the release package -> setup_sammich_sid.hex [/code] Please update your MIOS installation before uploading this new version! Fortunately a MIOS V1.9g update is only required for the SID master core, since no rotary encoders are connected to the slaves. Best Regards, Thorsten.

Hi Whomper, in V3.4f banks can be selected via CC: http://www.midibox.org/forum/index.php/topic,12668.msg121884.html#msg121884 Best Regards, Thorsten.

V3.4f is finally available. From the ChangeLog: o built for MIOS V1.9g (or higher) to support new encoder types. Rotary encoders won't work with older MIOS versions! o Groove function now takes the global step has reference instead of the local step. This results into better results on a non-linear step progression. o Bank of group #1-#4 can now be selected via CC#116..CC#119 o due to various user requests, the previously introduced "set/clear all trigger" function has been disabled by default. It can be enabled again with the DEFAULT_BEH_ALL_WITH_TRIGGERS switch in setup_*.asm 0: only parameter layers are modified by ALL function 1: all trigger and parameter layers are modified by ALL function [/code] Please update your MIOS installation before uploading this new version! Best Regards, Thorsten.

A new MIOS8 release is available. Due to compatibility reasons an update is strongly recommented if you are planning to upload an application which uses rotary encoders, otherwise the encoders won't work correctly! Details: The encoder driver has been overworked based on proposals from Avogra (thank you!) Now it can even handle excotic encoder types without changes in MIOS code. MIOS_ENC_MODE_DETENTED4 and MIOS_ENC_MODE_DETENTED5 have been added. MIOS_ENC_MODE_DETENTED4 should be used for the so called "cheap Panasonic encoders" which are available at www.pollin.de The performance of the encoder driver has been improved as well. The new method required a change of the MIOS_ENC_MODE_NON_DETENTED and MIOS_ENC_MODE_DETENTED* definitions, which unfortunately makes all previously released applications incompatible. Accordingly, all applications have been re-released. The new binaries can be downloaded from the MIOS download page: http://www.ucapps.de/mios_download.html (if you don't see the new files, just press the refresh button of your webbrowser) In order to update MIOS, please upload the <derivative>/midi/mios_v1_9g_<derivative>.hex file of the mios_v1_9g.zip package first, thereafter the .hex file of the application. Informations for programmers: The only files which need to be updated are $MIOS_PATH/include/asm/mios.h and $MIOS_PATH/include/c/cmios.h These files are part of the new mios_base_v1_1 package. If you are working with the SVN repository, just start an automatic update (e.g. under Mac/Linux: go into the trunk directory and type "svn update ."), otherwise download the .zip file. The next MIOS8 update can be expected in ca. 2 years - as usual ;) Have fun! Best Regards, Thorsten.

Thats a good one. When I compare the generated _output/main.asm file with and without the cast, I don't see any difference in the assembly code. Are you sure that you haven't changed something else in addition? Best Regards, Thorsten.

A cast shouldn't be required... which SDCC version are you using? Best Regards, Thorsten.

Such informations are really relevant if you post this in a new thread! Why not using one of your older threads in the C section, so that everybody knows the history? This would result into more explicit help... However, the received events are neither defined in pot_event_map, nor button_event_map. Thats strange. It would be insteresting which events are sent when you are writing: void DIN_NotifyToggle(unsigned char pin, unsigned char pin_value) __wparam { // a button has been pressed, send Note at channel 1 MIOS_MIDI_TxBufferPut(0x90); // Note at channel 1 MIOS_MIDI_TxBufferPut(pin); // pin number corresponds to note number MIOS_MIDI_TxBufferPut(pin_value ? 0x00 : 0x7f); // buttons are high-active } [/code] Best Regards, Thorsten.

I would propose to test the shift register connections as described here: http://www.midibox.org/dokuwiki/doku.php?id=din_module Best Regards, Thorsten.

This time it took a bit longer due to vacation... Shipped today: strogon14 ezChris papapoulp JustPhil thedishmop Lumstar sneakthief freddy matoz lead bromide Will be shipped once I got the v1.2 boards: mattflo Xem m00dawg afx cinhcet (Waiting for money) roger (Waiting for money) Waiting for the money: diggi jbaldwinroberts Morten Best Regards, Thorsten.

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.