TK.

Ich habe schon befuerchtet, dass dieser Wunsch irgendwann einmal kommen wuerde. Befuerchtet deshalb, weil es relativ schnell implementiert, nicht jedoch dokumentiert ist. Und wie schon so oft, wird es mal wieder ein ominoeses Flag geben, was im Nachhinein zu einer Menge Kommunikationsaufwand fuehren wird... es sei denn, irgendjemand geht endlich mal eine ausfuehrliche Dokumentation an. Fader: 10cm, Alps! Gruss, Thorsten.

Hi Alex, the center position is reached with "En 00 40" En: Pitch Bend event, Channel n 00: the low-byte (7-bit) 40: the high-byte (7-bit) Best Regards, Thorsten.

Ich koennte in die C basierende Version einen "Soft-Takeover" modus wie bei der MB64 einbauen, damit liessen sich die Parameterspruenge vermeiden. Soft-Takeover bedeutet, dass der Fader solange keinen neuen Wert sendet, bis die neue Position erreicht ist - die Position, die vom Host vorgegeben wird, um (normalerweise) den Motorfader zu bewegen... Gruss, Thorsten.

Hallo Chris, es gibt mittlerweile eine C basierte Version der MBLC, die das ersetzen der Fader durch Encoder erlaubt. Die Grundkonfiguration ist an die MIDIbox SEQ Hardware angepasst - kommt also mit relativ wenigen Buttons und LEDs aus. Im Gegensatz zur original Mackie/Logic Control gibt es bis zu drei Button/LED Layer, auf denen man die verschiedenen Funktionen legen kann. So kann man bspw. im ersten Layer jeweils 8 mal mute und solo legen, und auf den zweiten 8 mal den VPOT button und "select", auf den dritten Layer acht mal "record" und vielleicht nochmal den select... wie man will. Auch die anderen Funktionen lassen sich so unterbringen. Die wichtigsten Funktionen kann man also im ersten Layer unterbringen, alle anderen im zweiten und dritten verstecken. Noch etwas zum Ersatz der Fader durch Encoder: ich persoenlich wuerde auf Fader nicht verzichten wollen. Statt Motorfader koenntest Du auch nichtmotorisierte (billig-)Fader verwenden... kommt auf die Host-Applikation an. Cubase unterstuetzt soviel ich weiss noch nicht mal alle Buttons... eine Auflistung aller verfuegbaren Funktionen findest Du in lc_dio_table.h grundsaetzlicher Tip: baue die Schaltung erstmal ohne Gehaeuse auf! So kannst Du die LED/Button Belegung noch nach Deinen persoenlichen Vorlieben optimieren, bevor es an die Frontplatte geht. ja, die Belegung findest Du in lc_dio_table.c, bzw. lc_dio_table_mbseq.c Gruss, Thorsten.

Hi, thats it - for the first core you have to program a routine which sends the strings via MIDI, for the second core a routine which decodes the incoming strings and displays them on the LCD Best Regards, Thorsten.

Great :) Best Regards, Thorsten.

thats not true, you only have to read the ChangeLog of MBSID: o experimental AOUT support (7 CV out assigned to the existing outputs of the modulation matrix, 1 channel to the filter resonance parameter). For the final version it's planned to integrate the AOUT into a seperate modulation matrix, and to add new CC's to a seperate AOUT channel [/code] For your specific usecase it means: you can control the external filter with the same CCs/LFOs/ENVs, which are assigned to the internal SID filter (this filter can be switched off). Improvements are planned, but it can take some months, since they require a new PIC (with more memory - PIC18F4620), which is currently not usable due to a silicon bug (see MIOS ChangeLog) However, this doesn't mean that it wouldn't be possible to control external filters --- and in my oppinion, the current implementation is already very powerful (in the meantime I don't use the MBSID without external filter anymore) There is also a new beta version available (see MBSID board) which provides an alternative "low-cost" AOUT module, see changelog of midibox_sid_v1_7_303beta9: [code] o "ENABLE_AOUT 2" selects a low-cost AOUT module (currently it only outputs CutOff as 12bit value, once I got the Curtis chips I will do some experiments with 8bit CutOff and 8bit Resonance) The low-cost AOUT module is based on Karl Dalen's schematics: http://69.56.171.55/~midibox/forum/index.php?topic=4037.0 Best Regards, Thorsten.

With MBSEQ you really can send any MIDI stream you want: Start sysex - thats the 0xf0 Manufacture ID - thats a number which you can get from the manual of your TX81Z Device ID - thats a number which you can get from the manual of your TX81Z What Im changing - thats normaly MIDI_EVNT1 Value from the slider * - thats normaly MIDI_EVNT_VALUE End of message - 0xf7 of course --- and not only this. When you select the "controller mode" for one track, you have one row where you can change SysEx parameters statically if you want (e.g. basic sound settings which belong to the pattern) Best Regards, Thorsten.

Hi Rowan, search in the web for "DIY vu meter", most of them are based on the LM3915, which only provides 10 LED outputs. But two of them can be cascaded in order to get up to 20 outputs Best Regards, Thorsten.

You should direct such "feature requests" to the creators of Live/Traktor. A MIDI controller cannot control anything which is not supported by the host software Best Regards, Thorsten.

for which function? Best Regards, Thorsten.

Hi Martin, the tables in "mios_tables.inc" are not used by the MB64 application, instead the MIDI events have to be defined (on a normaly more comfortable way) in the midibox64.ini file (see mk_syx.zip package), or with Serge's editor You could also change the MIDI event assignments on the LCD menu of course --- thats described in the tutorial http://www.ucapps.de/midibox64_tutorial.html On a note event, MB64 only forwards the velocity value to the AOUT module. The reason for this "poor" support for note events is, that in practice you definitely want to have gate triggers and a note stack for improved live playing capabilities. Note stacks are only supported by MIDIbox CV. The AOUT/SHX8 handler of MB64 focuses mainly on CC parameters use MIDIO128 for the second core, the configuration is easier (see mk_midio128_syx.zip) Best Regards, Thorsten.

I hope it! :-) Well done! Best Regards, Thorsten.

Hi John, yes, it's possible to send SysEx by doing some small code modifications. Just open the "midi_evnt.inc" file and search for MIDI_EVNT_Send_Fx --- this code normaly forwards MIDI events to the AOUT module. You can remove this code, and replace it by a routine which sends any MIDI stream you want. Example: MIDI_EVNT_Send_Fx ;; send a sysex stream (example code) movlw 0xf0 call MIOS_MIDI_TxBufferPut movlw 0x11 call MIOS_MIDI_TxBufferPut movlw 0x22 call MIOS_MIDI_TxBufferPut movlw 0x33 call MIOS_MIDI_TxBufferPut movf MIDI_EVNT1, W ; Layer A value call MIOS_MIDI_TxBufferPut movf MIDI_EVNT_VALUE, W ; Layer B value call MIOS_MIDI_TxBufferPut movlw 0xf7 call MIOS_MIDI_TxBufferPut rgoto MIDI_EVNT_Send_End [/code] You could also select different SysEx strings (for different synths) with the remaining "MIDI channel" (which is stored in MIDI_EVNT0, but not used here). And you could calculate a checksum if required... etc Best Regards, Thorsten.

I think that the best central ground point is between the modules. Means: the point where the ground cables to the modules and jacks are as short as possible. However, it won't bring you that much improvement if you are changing the wiring now, it's just a general hint. absolutely, it is necessary. Add especially the so called "bypass caps" to all modules (especially CORE/SID/DOUT), not only the el-caps, but also the 100 nF caps (see also the most current MBHP module schematics). This should help to reduce the noise According to the datasheet the output range is up to 3V, when all oscillators are active and in phase Input voltage: ca 1V, impedance: 150k Best Regards, Thorsten.

Hi Oliver, according to the datasheet, the output voltage is up to Vcc+0.3V (but it can be assumed: Vcc == 5V). So, it could be that there is a problem with the connections. If you still notice the flickering values, you have to reduce the resolution of the AIN driver. The easiest way is to increase the value which is passed to MIOS_AIN_DeadbandSet (7 means: 7bit resolution, 15 means: 6bit resolution) Best Regards, Thorsten.

Hi Luke, in main.asm, you have to set "ENABLE_MOTORDRIVER" to 0, this disables the motor control. Best Regards, Thorsten.

this is not a joke. As you can see in the MIOS ChangeLog, the operating system is already prepared for large flash devices. This will open a lot of new possibilities without switching to a new platform. The only problem is currently, that all new silicons have a bug which prevents me to run MIDI properly. I fear that it will take at least until next year, until an update is available, but then the fun begins (not only for MBSEQ, but also for MBSID, MBFM, etc :) Best Regards, Thorsten.

hast Du einen Verdacht, wie es dazu kommen konnte? Vielleicht sollte man mal dokumentieren, was man mit einem PIC auf keinen Fall anstellen sollte Gruss, Thorsten.

Hi Martin, this could be a feedback loop, do you notice the same effect when you disconnect the MIDI Out line? Best Regards, Thorsten.

Hi Søren, thanks for the compliments, nice to read that there are also people who enjoy the programming capabilities (and not only the available applications :)) An application upload only overwrites the memory blocks which are allocated by the new program. If the program accesses blocks which are outside this memory range (perhaps due to a programming error), you could notice such effects. I would suggest to open the main.lst file, and to search for MIOS_LCD_PrintString, MIOS_LCD_PrintPreconfString and MIOS_LCD_PrintMessage- ensure that TBLPTRL and TBLPTRH are configured correctly before these functions are called. If the table pointer is not initialized, it could point to any location within the flash Best Regards, Thorsten.

Except for Vs and Vd these are HF waveforms which can only be checked with a scope (the values displayed by your measuring instrument are useless in this case). The connections can be checked with the mbsid_interconnection_test_b Best Regards, Thorsten.

The idea is clear, but if this would be possible, it would already be available MBSEQ is not a 64 step sequencer, providing multi-note events was already made in a very uncommon way, providing seperate mutes would require for a completely different concept (not only the programming would be different, but especially the user interface!) However, I've already noticed this for my MBSEQ V3 wishlist - things which are currently not working perfectly, will work with this new main version. Other planned features: up to 256 steps per track, loop points within tracks, more random capabilities, preconfigured arpeggio algorithms, premade tracks which can be linked to the pattern (groovebox like handling), etc... Hardware will be completely re-usable, PIC needs to be exchanged (PIC18F4620, once a bugfree silicon is available), maybe a 512k or 1MB external RAM module has to be added Best Regards, Thorsten.

You don't need to stop the sequencer in order to save a pattern, but under special circumstances it can stumble for ca. 1 ms to max. 250 mS, if too much data has been changed at the same time (compared to the overwritten pattern) However, no events get lost, and the BPM timer will still be on-sync, thats guaranteed by a special counter algorithm. Means: if the sequence was stucked for some mS due to a save process, events which where not played at this time will be played "at once", and the sequencer will continue as normal. Best Regards, Thorsten.

Hi, it depends on your MIDI-CV interface. If it provides a special trigger which is activated on overlapping notes (sometimes called "Sus-Key"), then it will work from a common note track - this is the way how portamento is triggered on common synthesizers (mostly it's a special option which has to be enabled seperately). Alternatively you could also control the portamento effect from a second track via CC Best Regards, Thorsten.