TK.

Hi, this is possible via the MIOS BankStick/EEPROM dump function (see http://www.ucapps.de/mios/mios_backup.txt) Best Regards, Thorsten.

Ok, ist eingebaut. Und als kleines Schmankerl gibt es noch eine neue Input Source im MIDI Router dazu ;) Gruss, Thorsten.

If the clock is not distributed properly, further analysis on other signal lines doesn't really make sense - the ICs won't behave deterministic anymore. Here a snapshot of the SC (shift clock) of my MBSEQ, where much more shift registers are connected (due to the Duo-LED/button matrix) At the top the 500 uS/div view, at the bottom the zoomed 1 uS/div view The matrix is connected via a 50 cm ribbon cable to the DIN/DOUT modules, but even this length doesn't hurt So, it seems that the clock is loaded by something which should not be there, like a short on any module or a damaged ribbon cable? Best Regards, Thorsten.

I've added the code for triplets - the implementation of the feature itself was quite easy, but it was difficult to overwork the menu layout so that the new mode can be selected in an intuitive way - however, I think that I found a good solution (now different timebases are available at the right side, like 8, 8T, 16, 16T, ...) The feature + user manual update will be available with the next release (it's already available on request, but I haven't tested if the rest is still working...) Best Regards, Thorsten.

I tried this some time ago, but the handling was so bad, that I skipped this feature. Such an "auto-follow" is especially *not* useful for editing, because when you move an encoder at the same moment where the sequencer automatically switches from one to another page, you will modify the wrong step. A solution for this issue would be a special detection, which ensures that the page is not switched while you move an encoder, but this is complicated and would blow up the code too much (-> high danger for new bugs) Best Regards, Thorsten.

Pin 9/10 is the serial bus - the "idle" level is either 0 or 1, depending on the output value of the next shift register in the chain. The input level at the end (you noticed "no signal") is the last input in the chain, it should always be 1, because of the pull-up termination. Since MIOS doesn't scan the shift registers permanently, but only each mS, I would say that this behaviour is normal More interesting are the RC/SC signals from the core to all 74HC165/74HC595. Have a look for the quality of the SC (shift clock) line when the third DINX4 module is connected (it should look digital-like, with sharp edges). Check it especially at the 74HC595 which are going mad - you should still see a proper clock Best Regards, Thorsten.

Thanks for the additional informations! I'm still thinking about what could cause such a behaviour... Are you using 74HC595s or 74HCT595s? It would also be interesting, if the problem is caused by a static or dynamic effect. This can be easily tested with the debug function of MIOS Studio. IMPORTANT: you have to upload a "dummy application" which doesn't frequently modify the DOUT registers - just use the skeleton Thereafter open the debug window of MIOS Studio and enter following functions: With the first two MIOS_DOUT_SRSet functions the pattern of the 16 LEDs can be controlled (0xff means: all LEDs on - try also a running one: 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80, and checkerboard: 0x55, 0xaa) With the third MIOS_DOUT_SRSet function the LED line will be selected. The selected line should get a 0, the others a one. Since I'm not sure if the cathode lines are connected to the upper or lower nibble, just duplicate the number. Valid values for single line selection are: 0xee, 0xdd, 0xbb, 0x77 Best Regards, Thorsten.

There is simply no relation between the MIOS_MPROC_EVENT_TABLE in mios_tables.inc, and the MIDIO128 application. The event table is an expired MIOS feature which I forgot to remove early enough - it is not flexible enough and therefore not used by any of the main applications. MIDIO128 uses its own table format, which is preloaded in midio_presets.inc This table is located in a special flash and EEPROM location (see file header) The structure of this table is fixed, also the size is fixed and cannot be easily extented without compatibility issues The table can be overwritten via SysEx. The mk_midio128_syx.pl script just compiles the table from a text file, generates a binary which can be transmitted via MIDI, and which is received by the MIDIO_SYSEX_Init_DumpWrite function in midio_sysex.inc There is an unusued area within the EEPROM location which could be used for extensions (see midio_presets.inc) - this area can be read with MIOS_EEPROM_Read (address in EEADR) Best Regards, Thorsten.

Ich habe mit den Electribes noch nicht herumgespielt, aber so wie Du es beschreibst, funktioniert auch der Record-Mechanismus der MBSEQ. Noten koennen hinzugefuegt werden, die Gatezeit wird automatisch angepasst - bedingt durch die Art und Weise, wie Noten gespeichert werden. Ich weiss nicht, ob ich Deine Fragen eher als Dokumentationsluecke oder Feature Request verstehen soll... probiere die Aufnahme am besten aus, sobald die MIDIbox laeuft; ich denke, dass sie bereits das kann, was man fuer den Live-Betrieb benoetigt. ;) Gruss, Thorsten.

jep. Du kannst auch jederzeit den Track wechseln, in dem die Aufnahme landen soll. sie startet sobald Du in diesem Menue bist - vielleicht ist die Bedienung zu intuitiv? ;-) Solange Du keine Taste am Keyboard drueckst, wird auch nichts ueberschrieben. Mischen geht ja bei einem Step-Sequencer nicht, es kann nur ersetzt werden. Und zwar immer beim aktuell selektierten Track. Start/Stop/Continuous/Song Position funktionieren ebenfalls ist leider nicht so ohne weiteres moeglich, obwohl - solange es nur um die Keyboard-Eingabe geht, koennte man vielleicht den MIDI In eines MBHP_IIC_MIDI Moduls pollen. Der MIDI Clock muesste jedoch nach wie vor vom Core MIDI In kommen, ansonsten wird der vervierfachte Clock zu ungenau. Gruss, Thorsten.

Hallo, hier der Link zum MPLAB/PICstart workaround: http://www.ucapps.de/mios/mios_bootstrap_picstart_workaround_v1.zip Gruss, Thorsten.

Hi Graham, DOUTs are high-active (5V: LED on, 0V: LED off), buttons are low-active (5V: button depressed, 0V: button pressed). So, yes: for DOUTs a 0 means that the LED is off For DOUT its the flag: MIDIO_CFG0, MIDIO_CFG0_INVERSE_DOUT For DIN: MIDIO_CFG0, MIDIO_CFG0_INVERSE_DIN Yes, it's the right location. After you've copied the new value into TMP1, it should be ok to branch to MIDIO_DIN_OnOff (or to duplicate the "rcall MIDIO_DIN_Hlp_SaveStat" and "rgoto MIDIO_DIN_Send"). SaveStat stores the new value into the MIDIO_DIN_VALUES array, and MIDO_DIN_Send will send the MIDI event Best Regards, Thorsten.

75*2*16 results into a delay of more than 2 mS - I guess that the watchdog will reset the chip in this case. Using MIOS_Delay is not recommented for realtime applications anyhow, it's better to handle this with a timer interrupt. Best Regards, Thorsten.

fixed in a temporary version. If somebody else than Whomper is interested in it, just drop me a mail Best Regards, Thorsten.

Yes. Due to the compressed coding of the AOUT port (each channel has a special purpose), an option for controlling 8 independent CV/triggers via velocity is not available, only via key value. But this can be easily changed in the code if required (I mean: taking the velocity value instead of the key value) In midi_evnt.inc, just change: MIDI_EVNT_Send_AOUT_Note_N ;; Note only movff MIDI_EVNT1, MIOS_PARAMETER1 [/code] by: [code] MIDI_EVNT_Send_AOUT_Note_N ;; special variation: forward velocity to CV instead of note movff MIDI_EVNT2, MIOS_PARAMETER1 The alternative would be to clear the gate Something must happen with it... ;) It would have the advantage, that you will get a seperate CV interface with some additional features, like Mono/Legato mode and key stacks. Such functions are not relevant for a sequencer, but they are useful for live playing. So, a MBCV would be perfect for your synths, and you can control it via a seperate MBHP_IIC_MIDI port. This would require some changes in midi_evnt.inc and the appr. AOUT driver (won't be supported from my side - too much effort) You need a MBHP_IIC_MIDI module. It depends on your synth setup, if a second module is really required (for 16 seperate channels), but I think it's more preferable A connection between MBHP_IIC_MIDI and MBHP_CORE module is also possible via MIDI Link port (this saves one MIDI cable and one optocoupler), but this would make it difficult to program the core module - I can only suggest this to experienced people who have built some MIDIboxes before Best Regards, Thorsten.

I'm a little bit confused now. From your last description everything seemed fine, just only a LED was blinking. I described, under which circumstances this can happen. Now you are writing that you continued with debugging. So, what is the current state? What did I miss? (I'm asking to get a feeling, which additional information could help you) Measuring the LED matrix: you have to take into account, that the "busses" are time-multiplexed. The update frequency is 1 mS, it's hard to measure this correctly with a multimeter. If all LEDs are off in the column, you should measure a constant 0. With all LEDs on, you should measure a constant 5V. In all other cases you will measure something between 0V and 5V A very easy way to debug the matrix is just to disable LED matrix mode in the firmware, and to connect the row which should be measured to ground (all others open). This would also allow you to measure the LED outputs unmultiplexed. But just to highlight again: I'm not sure, if you are hunting for an imaginary problem, which is easy explainable if you would know, how the LEDs are driven in the different menu pages. Btw.: did you upgrade to MBSEQ V3 in the meantime? Best Regards, Thorsten.

There is a very general reason, why graphical LCDs are not supported - they make the application so slow, that the synth won't play properly anymore. And this is definitely not a question of porting the driver and improving the performance - it's already superfast. So, what do you prefer: a geeky graphical display, or an always correctly playing synth? ;) Best Regards, Thorsten.

It could be a NI battery specific problem, I remember that most NI software doesn't forward to parameter names to the host. 64 rotary encoders allocate 128 DIN pins. More pins are not provided, so yes - you need a second core. Just chain them via MIDI (-> see MIDIbox Link) Best Regards, Thorsten.

There is no way to save pins here - increasing the number of multiplexed LED rings would make them much darker. Best Regards, Thorsten.

It's display page 3, you can select it with the button which is assigned to this function (see lc_io_table.inc) Best Regards, Thorsten.

This topic has been moved to MIDIbox SID. [iurl]http://www.midibox.org/forum/index.php?topic=9177.0[/iurl]

Wilba has finally finished his "MB-6582", one of the most professional looking MIDIboxes! It's pure eye candy - not only outside, but also inside the case --- enjoy! :) He wrote:

Nein, denn hinter jedem MIDI In Port steckt ein Optokoppler, in dem sich eine LED befindet. Und die muss mit ca. 5 mA versorgt werden. Deshalb verwendet man Puffertransistoren oder ICs (74HC00), um jedem Optokoppler eine eigene "Stromversorgung" zu geben. Gruss, Thorsten.

In v2.4 it's normaly that one of the LEDs blinks in the BPM menu. So far I remember this was to display the divider for the external clock (there was no place on the 2x16 LCD frame to do this...) There are some more menus where you will notice those blinking LEDs, e.g. pattern selection. In MBSEQ V3 you will see this in every menu, because they are used to indicate the selected menu item. Best Regards, Thorsten.

This reminds me, that I forgot to add a function to control the scale via CC from another MIDI device, or via loopback from a CC layer or from the mixer Yes, it also makes sense to add another option which overrules the global scale from a pattern - this would especially allow to switch between predefined scales by changing to another pattern. I will consider this in the next release Best Regards, Thorsten.