TK.

Du koenntest auch Reed Relais verwenden, die lassen sich direkt ohne zusaetzlichen Treiber ansteuern. Ich habe das neulich mal ausprobiert, es funktioniert problemlos, und die Relais schalten erstaunlich schnell: http://www.ucapps.de/mbhp/mbhp_doutx1_reed_relays.jpg Gruss, Thorsten.

Hallo SysEx, schau mal bei Conrad - normalerweise ist dieser Laden nicht zu empfehlen (Apothekenpreise!), doch sie haben eine grosse Auswahl an Taster. Gruss, Thorsten.

See http://www.midibox.org/forum/index.php?topic=7440.0 Best Regards, Thorsten.

Hi, no, it's not possible to use encoders without DIN. But you don't need to build a PCB, just mount it on the same vectorboard to which the rotary encoder/button is mounted - the 74HC165 is just a small chip and costs about 0.35 EUR - no need to provide alternative solutions Best Regards, Thorsten.

Hallo Thomas, es wuerde mich wirklich sehr wundern, das wuerde die Performance von MIOS Applikationen ziemlich beeintraechtigen, und ich muesste das E Signal wackeln sehen, wenn ich es mir mit dem Scope anschaue - tut es aber nicht. Du koenntest ja mal spasseshalber auf MIOS_LCD_TypeSet(7, 0, 0) umschalten, und dann in mios_wrapper/app_lcd.inc die Debugmeldungen einbauen. Dann muesste man sehr genau sehen, wann der Cursor gesetzt wird Eine clevere Loesung! Ich wuerde so etwas jedoch lieber auf Applikationsseite belassen - ganz unter dem Motto "Never change a running system". So kann man den Retryalgorithmus anpassen, ohne dass MIOS noch weitere Parameter zur Verfuegung stellen muss. Gruss, Thorsten.

One thing that I've learned in the last years is: than earlier you are making changes on the hardware to improve the system, than less the effort at the end. You definitely want to do this sooner or later ;-) However, so long you are using C, I would propose to use an constant array of 8 bytes instead of a DSEQ_GetStepORMask(0) function - table accesses are faster, since there is no overhead for saving/restoring the stack. Best Regards, Thorsten.

And here the MIDIbox SID in a 19" case made by Twin-X! :)

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.