TK.

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.

Twin-X made a special arrangement with his provider, so that we can temporary use the "preview URL" until the DNS entries of midibox.org are changed (Sidenote: a provider who gives such a support even on Sundays is really recommendable) IMPORTANT please remove your bookmarks which are linking to the 69.56.171.55 IP, and use http://forum.midibox.org instead. The path to all midibox.org pages will be different after the DNS change. References from ucapps.de and from forum articles will be updated automatically. Best Regards, Thorsten.

due to a copy error I released the wrong version of mkmk.pl - it's corrected in the *b.zip release (links above are modified) Note also that the C wrapper contains a bugfix for the MIOS_TIMER_Init() and _Reinit() function - don't use the old wrapper anymore Best Regards, Thorsten.

Hi, you can ignore this mismatch, in the .hex file all unimplemented bits in the config sector are 1, but the PIC returns 0 for such bits Best Regards, Thorsten.

Hi Jeff, the SR handler activates the write line for 1.2 uS to ensure that the data word will be taken. This doesn't ensure that data will be written twice, but fortunately the SID registers are not sensitive to write events. Means: it doesn't make a difference if a value is written multiple times so long it doesn't change Best Regards, Thorsten.

I've implemented the makefile generator, which should help to make the build process compatible to Unix and all Windows versions. It's now part of following packages: http://www.ucapps.de/mios/sdcc_skeleton_v1_0b.zip http://www.ucapps.de/mios/midibox_mm_v2_0b.zip http://www.ucapps.de/mios/analog_toolbox_v1_1b.zip Ian/Pilo: could you please test the Makefile under Mac/Linux? Gerald: could you please check it with your windows version? Best Regards, Thorsten.

Hi Pilo, it's very dangerous to call DIN_NotifyToggle from an interrupt service routine. One point is, that it will be called anyhow - it's called from the mainthread on any change in DIN registers. Another point is, that SR_Service_Finish() could interrupt a function from the mainthread which uses the same resources like your (misused) DIN_NotifyToggle routine. Suggestion: within the interrupt service routine you should only store the pin values in an array, which contains so much bytes like required for your matrix (note that one byte contains 8 bits: for 8 DIN pins) Add another array to notify changes. Just set the appr. bit within the array to 1 once a DIN value has been modified from the ISR Then write a new function which is called from Tick(), and which checks for the notifier. If it is set, clear the bit and call DIN_NotifyToggle with the appr. arguments. Note: any modifications on the notifier array from the main thread should be atomic. Means: this (small code part --- not the whole routine!) should not be interrupted. Interrupts can be disabled with "INTCONbits.GIE = 0;", and they can be enabled again with "INTCONbits.GIE = 1;" Another remark: I would write such code in assembler, and would call a C function on any DIN changes. SDCC produces very large code on array accesses, you can propably boost your DIN matrix handler by factor 10 and more, when you are implementing the handler in assembly language. An example is already given in the sm_example1, it calls the SM_NotifyToggle function, from there you could branch to a C function (see MIOS wrapper code how to do this) Best Regards, Thorsten.

Thanks for the input! Due to the crappy support of Makefiles in a windows environment (e.g. GNU make cannot reference external commands without absolute path), I will propably write a makefile generator which generates a simpler make.bat as the one currently used (because it doesn't work under Win98 and WinME), and a Makefile for Unix/Mac Best Regards, Thorsten.

A nice solution - but take care: if something is blocking the mainthread (e.g. an incoming MIDI stream), it can happen that the "row" number has been changed before DIN_NotifyToggle() is called. However, for simple applications (which don't use the MIDI merger or which are not heavily loaded by other tasks) such corner cases propably never happen Best Regards, Thorsten.

Hi Zeh, I've some plans for a non-blocking BankStick Write function (and a Status function which helps to determine if a write is ongoing), which will allow to save data in background without affecting the realtime performance. Not only in MBSEQ, but also in MBSID and MBFM. But this will require a lot of (small) changes in the application, and heavily testing, therefore I guess it's better when I will do this - maybe during my next vacation Best Regards, Thorsten.

Detented and Undetented Rotary encoders with 16..32 pulses per rotation are ok. I would suggest to buy them from voti.nl (search for M-SW-ROT), you won't find encoders for the same low price in Germany, so - it's worth to pay the shipping costs, and Wolder normaly delivers within 1..2 days Best Regards, Thorsten.

Hi Kurt, MB64 cannot emulate the Logic Control Protocol - however, without the large display it doesn't make much sense anyhow, and most MIDI software provides a good integration of such a generic controller that you are planning to build. I would suggest to add at least one DINX4 module (or one 74HC165 on a breadboard) for at least 8 buttons. This allows you to control special functions of your sequencer (e.g. Play/Stop/Record/...) Also Solo/Mute buttons can be very useful Best Regards, Thorsten.

Hallo Axel, bei mir ist das Brummen erst mit der optimierten Schaltung voellig verschwunden Gruss, Thorsten.

Hallo, in der main.asm Datei der MIDIbox64 Applikation gibt es einen Schalter names "DEFAULT_ENABLE_PAGE_HANDLING". Diesen auf 1 setzen. Nun kannst Du mit dem Meta Event "FF 05 xx" zwischen bis zu vier "Pages" umschalten (eine Page besteht aus bis zu 16 Potis) Fuer zwei Seiten muesstest Du also auf einen Taster "FF 05 00" legen, und auf den anderen "FF 05 01" Die CC Events der ersten Seite legst Du (bspw. in midibox64.ini aus dem mk_syx.zip Packet) auf Poti Eintrag 1-9, die anderen CC Events auf Poti Eintrag 17-25 Gruss, Thorsten.

Hallo Zeh, ich habe nichts gegen solche Fan-Shirts, nur wuerde ich eher midibox.org favorisieren, zumal wir ja mittlerweile ein huebsches Logo haben (das es auch im Vektorformat gibt) - mit diesem T-Shirt sollte man mal auf der naechsten Frankfurter Musikmesse durch den Behringer Stand gehen.. ;-) Gruss, Thorsten.

It should work again Best Regards, Thorsten.

Richard has built an eye-catching black/red box to control Traktor. He wrote:

Once again a great box, made by our "c64 case fetishist" d2k! :) He wrote:

Yes, it does! :) Best Regards, Thorsten.