TK.

Here are some pictures of Phonauts Red/Black MIDIbox SID. It took him 1.5 years to finalize the MIDIbox, but as you can see: it works, and the result looks just great! :) He wrote

Hier ist der Thread: http://www.midibox.org/forum/index.php?topic=7308.0 Gruss, Thorsten.

Hallo Thomas, das ist auch nicht so... von aussen betrachtet (ich kenne Deinen restlichen Code nicht), verhaelt sich die Routine so, wie wenn intercom_count auf 6 stehen bleiben wuerde, kann das sein? Wann wird die Variable hochgezaehlt? Gruss, Thorsten.

I wouldn't write this assembler, this won't change that much for such a short routine, maybe it currently takes ca. 10 uS, this is nothing - so why spending the effort? It can take hours or days to get this working together for somebody w/o mixed C/assembly skills - just see moxi's thread about the AOUT_LC integration into analog toolbox. It maybe makes sense to optimize the way how you are addressing the bits - but in C. E.g., it seems that your track triggers are counted from MSB first (mask_current_trk = 0x80 >> trk). This is very uncommon and produces unnecesary code, regardless if written in C or assembler. If you would organise it with LSB first, you can use the MIOS_HLP_GetBitANDMask function (which is assembly optimized) and you will get the result much faster: -> mask_current_trk = MIOS_HLP_GetBitANDMask(trk); The same for the step bit: mask_current_step = MIOS_HLP_GetBitORMask(pos[trk]&0x07); There isn't really much more to optimize...

Really great work, AC! Seems that you are one of the first guys who really makes complete applications from scratch :) Could you please try following experiment: the transfer buffer of MBHP_IIC_MIDI has 96 bytes, which means: it can collect more data than Speakjet can process. Assumed that there are handshaking problems (D2/CTX line), a buffer full event could be prevented at the Speakjet side by making the transfer buffer of MBHP_IIC_MIDI smaller. Because in this case, the IIC slave will send retries until the buffer is free again, and this means that the PIC will also wait, so that no data can get lost. Many words, small change: open uart.asm and set UART_TX_BUFFER_SIZE to 0x10 or 0x20 ... what happens? (I never tried this, but currently don't have that much time to do my own experiments. I will be one of the first users of your app! :) Best Regards, Thorsten.

In MBSEQ V2 a mute bit really means muted, and not gated. Therefore it's inverted. In MBSEQ V3 gates are part of the trigger layers, and they are not inverted. In MBSEQ V2 the upper 3 bits of the 7-bit word are ignored and are sometimes randomly set depending on the previous pattern data, and the 8th bit is always 0, otherwise it wouldn't be possible to send the data within a SysEx stream (data between F0 and F7 must be 7-bit values) must be a programming issue in your changes... Best Regards, Thorsten.

I don't find this so strange - i is an unsigned variable, it can never be < 0 Therefore the behaviour of: for(i=0; i<0; ++i) is undefined and heavily depends on the C compiler implementation (a good C compiler prints a warning in this case) Best Regards, Thorsten. P.S.: yes, those missing brackets are not uncommon, all of my students @work are making this error once during their practical year ;-)

Hi *, MIOS V1.9c is now available for download; this version got a small but useful improvement in the button debouncing routine: debouncing can now be enabled without disadvantages when rotary encoders, LED matrices or timing accurate digital outputs (e.g. 1 mS drum triggers) are scanned by the serial IO chain. Here a short list, under which circumstances an update to MIOS V1.9c makes sense (ok, normaly it always makes sense!) MIDIbox64: debouncing enabled, but no rotary encoders and no timing critical digital outputs - therefore update not required MIDIbox64E: debouncing not enabled due to connected rotary encoders and led rings - with MIOS V1.9c you could optionally use it MIDIbox LC: debouncing not enabled due to connected rotary encoders and led rings - with MIOS V1.9c you could optionally use it MIDIO128: in the past it was suggested to disable debouncing if timing accuracy where desired at the digital outputs (e.g. 1 mS drum triggers) - now debouncing can be optionally used. But please note, that the debouncing routine of MIOS is a real cheap implementation, since it suspends the scanning of all digital inputs (except for encoder inputs) at the same time. This means: buttons are not debounced individually to save RAM MIDIbox CV: debouncing is enabled, update only recommented if source code has been enhanced by CV gates/triggers via DOUT MIDIbox SID: debouncing not enabled due to connected rotary encoders - with MIOS V1.9c you could optionally use it MIDIbox FM: debouncing not enabled due to connected rotary encoders - with MIOS V1.9c you could optionally use it MIDIbox SEQ: debouncing was wrongly enabled, with the result, that encoders with >= 24ppr produced jumping values when rotated too fast. Update to MIOS V1.9c recommented [br]The change in MIOS_MIDI_InterfaceSet/MIOS_MIDI is only relevant for MBSEQ V3 users Download: http://www.ucapps.de/mios_download.html (press the refresh button of your browser if you don't see the mios_update_v1_9c.zip file) Best Regards, Thorsten.

Eigentlich nicht - alle benoetigten Bauteile habe ich auf der MIDIbox FM Seite aufgefuehrt. Wenn jemand etwas vermisst hat, habe ich es stets der Liste hinzugefuegt (wie bspw. nun bei den Dioden). Gruss, Thorsten.

Hi Thomas, which SDCC version are you using? 2.6.0 sometimes behaves strange, 2.5.0 works ok - undefined snapshot versions (with immediate bugs) shouldn't be used. What happens when you are adding following code to the switchLEDs function: void switchLEDs(unsigned char pattern, unsigned char and){ unsigned char i; unsigned char pos; MIOS_MIDI_BeginStream(); // for debugging MIOS_MIDI_TxBufferPut(0xf0); for (i = 0; i < 8; i++){ MIOS_MIDI_TxBufferPut(32 + i); // for debugging MIOS_DOUT_PinSet1(32 + i); MIOS_MIDI_TxBufferPut(MIOS_DOUT_PinGet(32 + i)); // for debugging } MIOS_MIDI_TxBufferPut(0xf7); // for debugging MIOS_MIDI_EndStream(); } [/code] Best Regards, Thorsten.

In memorian to the last spam posting we got this article hasn't been deleted ;-) Best Regards, Thorsten.

Well, you are touching the memory boundary, thats the issue I had many times before, each time I wanted to add new features I had to optimize the code in order to free some bytes. In the meantime, the MBSEQ V2 has been optimized so often, that I would say, it doesn't make sense - especially for a programmer newbie - to work on this. The memory map can be found in main.lst (at the bottom) However, in general I strongly recomment the use of a PIC18F4620, and the use of the MBSEQ V3 firmware. This firmware has so many new features you really need for a good drum machine (e.g. 3 assignable trigger layers - e.g. for gate/accent/roll, 32 steps per track, tracks can be played at up to 96 ppqn, all tracks in RAM, cache mechanism for best performance, track direction progression parameters, more randomness, MIDI/AOUT port routing), that I don't understand, why you are still considering to extend MBSEQ V2. The only thing you would have to do is to overwork the menu screens, so that they are working with a 2x16 LCD. For this I assume an effort of about 3 months for somebody who hasn't worked with assembly code before. Btw.: here the current changelog http://www.ucapps.de/tmp/mbseqv3_changelog.txt Best Regards, Thorsten.

Providing CC names shouldn't be a big problem :) Best Regards, Thorsten.

Hi Ralf, with MIOS Studio you can execute MIOS functions - which means, it is possible to enable the normal MIDI merger mode by calling MIOS_MIDI_MergerSet(1) from the debug window. You have to do this for both cores (device ID 00 and 01) Btw.: the problem with the flickering LED matrix when debouncing is enabled is fixed now (-> MIOS V1.9c) :) Best Regards, Thorsten.

Eine LED ist eine "Light Emitting Diode", angedeutet durch die zwei Pfeile nach aussen. Hast Du eigentlich noch ein paar LEDs uebrig, dann koenntest Du auch diese anstatt von 1N4148 verwenden. Ist zwar eine ziemlich exotische Loesung, doch es funktioniert und spart Versandkosten. ;-) Wenn die LEDs zweimal ihren Strom durch einen 220 Ohm Widerstand beziehen wuerden, waeren sie wesentlich dunkler. Ein Vorwiderstand ist jedoch zwingend notwendig, ansonsten wuerde es die LEDs schon beim ersten Einschalten zerfetzen. Gruss, Thorsten.

means: you are using an old release of MBSEQ which was working with MIOS < V1.9, where the bootloader was located at 0xfc00-0xffff. This code line was intented to produce a compiler error in order to prevent, that somebody tries to overwrite a memory range which cannot be overwritten anyhow. Solution: so long you are using MIOS V1.9 and Bootloader V1.2, you can remove this "protection". Better Solution: use MBSEQ V2.4b or c, where this protection already has been removed. Best Regards, Thorsten.

I'm nearly through the whishlist and recorded a video again to show the progress. This video is a Thank you to Stryd_one for typing in all the scales! :) -> Following features are demonstrated: 0:00 Chord Mode 2 with Force-to-Scale (played by a MicroQ) 0:13 Solo off, tracks are playing additional Drums and Bass. Both are provided by Reaktor, the drums from an modificated "Massive Environment", which can listen to MIDI, and the bass from the Tritium synth, made by Stephan V. (-> User Library) 0:20 Internal loopback, track 1 feeds the Transposer, which is normaly played by an external keyboard. It feeds the base note of the "Force-to-Scale" function as well. 0:28 Switching between different patterns during live playing 0:39 MIDIbox SID plays an additional synth line 0:48 Track Direction Progression Parameter (at the end: 5 forward, 3 back) 1:02 MIDIbox SID solo 1:13 Snare is added (wasn't planned, but at the end I think it was ok) Selected steps of the snare are triggered randomly 1:23 Internal loopback from a second line, where 16 given base notes + octave transposes are selected randomly 1:32 Some of the MIDIbox SID steps get a glide 1:46 Step by step some tracks are added again (mutes deactived) 2:06 Bass goes solo 2:15 Some notes are added to the bass line - thanks to force-to-scale (the "Dim Whole" scale is selected here), it always matches, regardless in which direction the encoders are tweaked 2:44 MIDIbox SID, later the bass and the tranposer line are going solo 3:01 solo gets deactivated, all unmuted tracks can be heart 3:09 thats all :) Here the same recording again as MP3: http://www.midibox.org/midibox_seq/mbseq_v3_demo3.mp3 Best Regards, Thorsten.

Touch sensors are enabled, it should work with any DIN pin, therefore no new binary is required I wouldn't be so easy for me anyhow. I'm writing from my laptop, I would have to turn on my PC, compile, transfer to laptop, uploading via ftp, etc... a procedure of about 15 minutes. So, if you have more whishes for changes (e.g. you have to change the encoder type), it would be better if you would re-assemble the file by yourself. It's very easy! Just copy the setup_midibox_catdog.asm file into the folder where MB64E is located, use MPASMWIN like described at my homepage to build a .hex, and upload the new .hex file Best Regards, Thorsten.

Alright, so you need to adapt the encoder type at the bottom of the *.asm file. The encoders have to be connected to the 8th shift register (last one of the second DINX4 module) Best Regards, Thorsten.

Nein, die Dioden werden genauso wie die Buttons nicht mitgeschickt. Es handelt sich hierbei ja auch um einen Sonderfall fuer die MIDIbox FM, bei keiner anderen MIDIbox sind (bis jetzt) Buttons zu einer Matrix zusammengeschaltet. Im Grunde handelt es sich hierbei um eine Sparmassnahme. Ich stand vor der Entscheidung, entweder ein weiteres DINX4 (oder DINX1) Modul hinzuzufuegen, oder die Taster so trickreich zusammenzuschalten, dass nur ein Input Pin benoetigt wird. Ich habe mich fuer letztes entschieden, auch wenn die Loesung etwas komplizierter ist (ich habe schon befuerchtet, dass irgendwann jemand darueber stolpern wird)... aber es funktioniert! Gruss, Thorsten.

ok, aber das ist doch genau der Encoder, dessen Pinning im Schaltplan dokumentiert ist (in diesem eingerahmten Kaestchen). Die Verschaltung in Worten: wenn Du von oben draufschaust, und die Pins ebenfalls nach oben zeigen, dann befindet sich Masse am linken Pin, D0 (jeder Dateneingang mit gerade Nummer) in der Mitte, D1 (jeder Dateneingang mit ungerader Nummer) am rechten Pin. Hier habe ich ja bereits geschrieben, dass es vielleicht jemand anderes beschreiben muss, wenn der Schaltplan und diese Erklaerung unklar ist: Die 4 Buttons fuer die Zeilen werden an einem Pol zusammengeschlossen, und an J8:D1 gefuehrt. Die gegenueberliegenden Pole werden ueber Dioden (bspw. 1N4148) an J4:D2-D5 des DOUT Moduls angeschlossen oder... was genau ist hier unklar, dann kann ich es vielleicht nochmal genauer erklaeren. nein, es sind normale Dioden (siehe Wikipedia fuer eine genaue Erklaerung). Das gleiche Bauteil befindet sich bspw. am MIDI In des Core Moduls. Mir ist aufgefallen, dass ich diese Dioden nur im Schaltplan, nicht aber in der Partlist erwaehnt habe - mein Fehler - werde ich hinzufuegen Gruss, Thorsten.

A MBHP version would have the advantage, that it could be adapted to other synths as well... and it doesn't require an EPROM burner ;-) Best Regards, Thorsten.

Thanks for testing! Is it working? Then I can create the complete update package.. Best Regards, Thorsten.

cheers :) Best Regards, Thorsten.

Yes, it's a typing error so, you get this with MIOS_LCD_PrintPreconfString? Then there is an error in the wrapper as well Best Regards, Thorsten.