TK.

This sounds very good! I will announce this in the news section. Once more than 10 people were able to burn their PIC successfully with this programmer, I will discontinue the MBHP_JDM and strongly recomment this much simpler one! Best Regards, Thorsten.

Hi, of course, they are. But which application do you mean exactly? The configuration is sometimes different. Best Regards, Thorsten.

Hi, I',m not sure if a LVP programmer is really helpful, since it will disable pin RB5 for common use. This means that you won't be able to drive a LCD. I'm also not sure about the error messages. The .hex file is definitely not corrupt, it is generated from the official assembler from Microchip, and it works with the PICstart programmer (the official PIC burner from Microchip...) as well as with IC-Prog. So I guess that the Briccoli software has an imperfection, maybe it's better to ask the name of this program for help. Best Regards, Thorsten.

Hi, maybe a problem with the power-supply? Maybe the voltage level doesn't raise to 5V fast enough before the core starts to run? What does happen if you upload an application? MIOS should reset and the upload request string should appear like on a power-on. Best Regards, Thorsten.

Hi Pay_c, nice that it works :) The gatelength is only fixed in threshold mode, since Layer C contains the threshold level in this case. Just switch to Layer C during editing and you will see what I mean - with different levels you are able to define several "morphing states" between two patterns, and the states are controlled with the modulation wheel. It isn't possible to provide the length as fourth layer due to the fixed data structure and really tough timing requirements for 16 tracks (threshold morphing was just a craze of me and I thought it's better to implement it so than to left out this idea). If you want to vary also the gatelength, then use the smooth mode. Best Regards, Thorsten.

Which details do you mean exactly? Best Regards, Thorsten.

Ok, then I will just give you an example for a meta event: open mb64_meta.inc, search for "MB64_META_Handler_10" and replace it by: MB64_META_Handler_10 ;; do nothing if button released (button value == 0x00) movf MIDI_EVNT_VALUE, W bz MB64E_META_Handler_10_End ;; increment variable incf MY_BUTTON_TOGGLE_STATE, F ;; reset to zero if value >= 5 movlw 0x05 IFGEQ MY_BUTTON_TOGGLE_STATE, ACCESS, clrf MY_BUTTON_TOGGLE_STATE ;; send value movlw 0xb0 call MIOS_MIDI_TxBufferPut movlw 0x10 call MIOS_MIDI_TxBufferPut movf MY_BUTTON_TOGGLE_STATE, W call MIOS_MIDI_TxBufferPut MB64_META_Handler_10_End return This will send CC#16 with values 0, 1, 2, 3, 4, 0, 1, 2, ... every time you press the single button. Thereafter locate the variable to a free address, open app_defines.h, search for an unused address (lets say 0x03c) and write: MY_BUTTON_TOGGLE_STATE EQU 0x03c The meta event has to be assigned to the button with 1 = F0 10 7F @OnOff You could also assign it directly in the source code (see mb64_presets.inc), this saves some effort. There are several ways to implement this for more toggle buttons, the most simple way is to add a dedicated meta function for each one. For this, you have to enhance the lookup table at the beginning of mb64_meta.inc BankStick: each bank contains a complete setup (SysEx dump). If no LCD is available, you could also switch between the banks with a Program Change event over MIDI Channel 16 (coming from external), or you could assign some buttons to special functions like described here: http://www.ucapps.de/midibox/midibox64_sfb_table.txt You are right, without a LCD it isn't easy to understand all the possibilities of the application! Best Regards, Thorsten.

You've to type "java JSynthLib" (<- with capital letters) or just "run", if you would use the updated JSynthLib package like suggested above. Best Regards, Thorsten.

Nice to hear that your core was running immediately! :) The problem with SysEx support is, that the .syx generator has to be aligned with the application every time you make changes in the configuration tables. Every new or changed function leads to special effort, and once people are using the script and saving their tables in this fixed format, it will be much harder to implement changes. So, it could make sense to create a comfortable SysEx configuration mechanism once this application has reached a state where you are sure that it won't get dramatic changes anymore (after one year or so...), but before it would be wasted time. Especially when you take into account that the configuration within an assembler file (-> see midio_presets.inc) is also simple and that the upload of new code just takes some seconds - it's just another way to define the setup. By using additional constant definitions and macros, the assembler file could look very similar to the midio128.ini file, only drawback is that the user has to download the assembler tools (see http://www.ucapps.de/howto_tools_mpasm.html) Best Regards, Thorsten.

Hi Seppoman, of course, everything is possible, but the trade off isn't so high. You definitely need a seperate uC which does nothing else then to generate the waveform(s) and to send them to the DAC channel(s). Kilian Leonhardt realized this with a multi chip solution - with success, but it took him one year (-> http://www.rozzbox.de). I think a really powerfull feature is the possibility to add analog waveform generators/filters/LFOs/ENVs/etc... to the SID, and this is already possible with the current MBSID implementation, you only have to use it Best Regards, Thorsten. P.S.: my plan for end of this year is to start with MIDIbox FM, an OPL3 based synthesizer with FM synthesis - just to let you know that I don't feel boring ;-)

Der Vorteil an RS ist, dass die einfach alles haben, und der Nachteil, dass die Komponenten zu Apothekenpreisen ueber die Theke gehen :-( Gruss, Thorsten.

Hi, you don't need a meta event, you only have to specify different "velocity" values for the note which controls the radio button section. And you have to set the button mode to "OnOnly", so that no Note Off (with zero velocity) is sent when the button is released. Example (in midibox64.ini format). I'm assuming that the radio button group is assigned to Note Number 0x30 (C-3). Of course, you can do the same with CC's... # The first five Buttons control the Shaper mode 1 = 90 30 00 @OnOnly 2 = 90 30 20 @OnOnly 3 = 90 30 40 @OnOnly 4 = 90 30 60 @OnOnly 5 = 90 30 7F @OnOnly Best Regards, Thorsten.

You will find the "run.bat" file only in the special MIDIbox SID release with the updated driver module for MBSID V1.6 See http://www.ucapps.de/midibox_sid.html, search for "Updated version of JSynthLib" Best Regards, Thorsten.

So long it's ok for you to modify the table directly in the source code, and don't rely on any SysEx editor or mk_xxx_syx.pl script, it isn't so much effort. At least 16k internal flash are still unusued in the sm_example2 application, this means that you could define up to 2730 complete "On" and "Off" events (2 * 3 bytes) in the same way like in the MIDIO 128 project (see midio_presets.inc, search for "MIDIO_Presets_OffsetOut"). A table of 1024 On/Off entries allocates 6*1024 = 6k bytes I will create the other drivers next weekend. Best Regards, Thorsten.

Hi, oops! This is caused by a incomplete 16bit addition. Bugfix: open "midio_midi.inc", search for following lines: MIDIO_MIDI_PrepareDINEventOff ;; off event: add 3 to address movlw 0x03 addwf MB_ADDRL, F MIDIO_MIDI_PrepareDINEventOn and exchange it by: MIDIO_MIDI_PrepareDINEventOff ;; off event: add 3 to address movlw 0x03 addwf MB_ADDRL, F movlw 0x00 addwfc MB_ADDRH, F MIDIO_MIDI_PrepareDINEventOn I will upload a new MIDIO128 release soon. If you have a special whish for this release (minor feature which could be useful for you), just let me know :) Best Regards, Thorsten.

Hi Xile, you have to set the "MIDIbox-to-COM" flag in the ID header of the PIC, so that the alternative baudrate is selected after power-on. This is explained at the http://www.ucapps.de/mios_bootstrap.html page. Yes, you have to use a 1:1 cable, the same like for the JDM. See also the http://www.ucapps.de/mbhp/mbhp_ltc_orderlist.txt Best Regards, Thorsten.

Thank you, Pay_c :) To the first issue: maybe the fixed gatelength is too long, you can change it in seq_morph.inc, line 71. Try "movlw 0x10", this should avoid legato. Best Regards, Thorsten.

Hallo, alles deutet darauf hin, dass etwas mit der SCLK oder RCLK Leitung nicht stimmt. Entferne mal alle ICs aus den Sockeln, schalte Dein Multimeter auf Widerstandsmessung (oder falls es einen Durchgangspiepser hat, dann nimm den), und miss die Verbindungen zwischen PIC Pin #21 und #22 und den 74HC165 Pins #1 und #2 durch. Zwischen diesen beiden Leitungen darf kein Kurzschluss bestehen. Sie duerfen auch nicht mit Masse oder 5V verbunden sein, das laesst sich mit dem Multimeter sehr schnell ermitteln. Am besten druckst Du auch mal die Schaltplaene aus, das erleichtert die Orientierung. Gruss, Thorsten.

Since these applications are very complex, it isn't possible to combine them to one firmware. But you are able to swap between the applications in between 10 seconds, just upload the appr. .syx file I would suggest to build the hardware based on the MIDIbox SEQ plans. The MB64E package comes with a prepared setup which runs also with this hardware. And a Logic/Mackie Control emulation setup is also planned. Best Regards, Thorsten.

I've noticed that the .syx file within the sm_example wasn't up-to-date, so please download the new package. It's now possible to use a scanmatrix with diodes in the other direction by swapping the column and row lines, and by setting SM_SWAP_CR to 1 in sm_simple.inc Best Regards, Thorsten.

John, thats a very good explanation about the SRIO driver - we should add this to the Wiki once it's available. Jim: maybe the best documentation is just to write a report who you've realized your project (with a lot of pictures). I guess that not only the scanmatrix driver is for interest, but also the hardware around it. Here is an example: http://mmd.foxtail.com/Tech/mvdReijden.html Yes, you can use the analog input driver in parallel. It runs in background and doesn't add that much jitter. Ok, here some news: today a friend brought me a keyboard from an older synth so that I was able to test the new, optimized scanmatrix driver: The contacts are realized with springs - thats a big advantage, because this allowed me to verify the debouncing routine. The DIN/DOUT register is soldered on a breadboard: The new driver can now be found in the MIOS download section (sm_example2_v1.zip). I've measured the capturing cycle for 64 nodes with a scope, it's 80 uS, so much less than expected! :) Jim: which MIDI events should be sent by the various buttons? Best Regards, Thorsten.

Currently the matrix driver uses the general timer interrupt driven SRIO handler which has been designed for the common approach for up to 128 digital INs and OUTs, the target was to capture as much registers as possible with lowest system load, so that a lot of other tasks can run additionally without affecting the realtime behaviour: in between 1 mS all tasks should be finished. The handler is called every millisecond and consumes ca. 16 uS for each DIN/DOUT shift register pair, makes ca. 128 uS for 16 DIN/DOUT registers. The DIN and DOUT registers are captured/loaded in parallel, the DOUT data gets valid after the DINs are captured, therefore it doesn't make a big difference how much DINs and DOUTs are chained, the longest chain defines the overall delay. If the core has nothing else to do than to scan a matrix and to receive/transmitt MIDI events, it makes sense to bypass the common driver and to write a dedicated one which isn't called periodically, but every time when nothing else is to do (means: from USER_Tick - the mainprogram) By doing so, an overall latency of ca. 8*20 uS can be achieved for a 8x8 matrix, maybe 16*80 uS for a 16x32 matrix Some Jitter has to be expected, caused by the MIDI handlers (they are buffered and therefore don't stall the system) and for the debouncing counters which still require a timer interrupt, but this isn't a big problem when we are speaking about a latency of much below 200 uS My suggestion: discuss about some useful hardware setups and draw the schematics. Once they are available, I will program the drivers for you. My own effort is low, since all routines do already exist, I only have to rearrange them... my effort would be higher if I would also have to documentate the stuff ;-) Best Regards, Thorsten.

A very noble MIDIbox controller made by Josh aka Jost (Michigan, US)! He wrote:

Hallo Lemonhorse, das AOUT Modul gibt es sogar bereits in Mikes Elektronikshop, ich bin lediglich noch nicht dazu gekommen, es zu dokumentieren, da es soviele Konfigurationsmoeglichkeiten gibt. Den Schaltplan findest Du hier: http://www.ucapps.de/mbhp/mbhp_aout.pdf, das Bild vom Prototypen hier: http://www.ucapps.de/mbhp/mbhp_aout.jpg Die Filterschaltung werde ich nicht layouten. Ja, die Schaltung ist leicht modifiziert, dazu kann vielleicht Hallucinogen etwas schreiben (von ihm habe ich die Bauteile und den Schaltplan erhalten) AOUT und SID: ja, die Pinbelegung steht in sid_aout.inc Momentan geben die acht Kanaele die Werte der vorhandenen Modulationsmatrix aus (also Pitch V1/2/3, PWM V1/2/3, Filter), sowie den Resonanzparameter. Langfristig plane ich eine eigene Modulationsmatrix fuer alle acht Kanaele. Das wird eine reine Softwareaenderung, das CS muss hierfuer nicht erweitert werden (die LEDs zeigen entweder die normale, oder die AOUT Matrix an, mit einer speziellen Tastenkombination kann man dann zwischen den beiden Anscihten umschalten) Gruss, Thorsten.

Hi Jim, for somebody with programming experiences it should be very easy to adapt the code to any hardware constraints he want. But a user-friendly configuration would make the whole thing more complex, that means: slower (reduced performance due to variables) and error-prone (normaly every possible configuration should be tested in reality) I would suggest that we define three or four useful setups, for which I could provide the source codes. The "scanmatrix drivers" have to be tested by somebody else. Everything else will lead to a configuration disaster ;-) Best Regards, Thorsten.