TK.

Hi Matteo, There is no need to use MPASM anymore, and it's strongly recommented to publish applications GPASM-compatible in future, so that even Linux and Mac OS users are able to customize an application, and to create a new .hex file. Thats the reason, why I'm planning to re-release all my own applications, which isn't so much effort at all. GPASM is slightly incompatible to MPASM (macro expansion), MPASM is slightly incompatible to GPASM (cannot handle files w/o DOS-style linefeeds, cannot handle filepathes longer than 63 characters). But at the end GPASM brings us more advantages than MPASM. If somebody encounters issues with the usage of GPASM, or with the conversion of an old, selfwritten application, just ask in the Assembler programming section for help. I'm willing to support you during the migration, I could also do this for you (it takes ca. 1 minute) if desired. Best Regards, Thorsten.

Hi, it's shouldn't be so complicated - look at MIDI_EVNT_Send_AOUT in midi_evnt.inc (please download the latest re-release of MBSEQ before doing modifications) Parameters are: MIDI_EVNT0 (either 0x9n or 0xbn for Note/CC; n = channel), MIDI_EVNT1 (note/CC number) and MIDI_EVNT_VALUE (velocity/CC value) Best Regards, Thorsten.

Und hier die Aufloesung: der PIC war nicht richtig programmiert; die Adressen 0x310..0x317 (liegt im Bootloader-Bereich) waren mit 0xff belegt. Gruss, Thorsten.

I give you an hint: update to one of the latest firmware versions. Best Regards, Thorsten.

I gave you permission to upload files. Best Regards, Thorsten.

You could help me by writing a bad feedback on this auction, which points out what he is doing This could even motivate me to spend some time to understand and solve your issue. So, you are the first customer of an illegal sale who expects help from my side, how much additional sparetime do I have to spend for supporting even more people w/ zero knowledge about how to fix the hardware, how to upload a new firmware version, etc... hope that you see the point. Best Regards, Thorsten.

Drum kit and instrument voices are seperated. Each drum has a dedicated voice (no issue here), but the 4 instruments have to share 6 voices. So, it depends on what exactly you are planning to play (poly or mono sequences?). However, maybe better to build a MBSID in addition for more voices and more variation - especially because MBSID has improved inbuilt sequences. :) Best Regards, Thorsten.

Do you mean something like demonstrated in this example: http://www.ucapps.de/mios_c_pic_pin.html Best Regards, Thorsten.

Hi Gene, I hope that you understand, that I'm not willing to help somebody who bought a MIDIbox device from somebody, who never got my permission. It's totally furstrating for me, that there is no chance to stop this (sorry for the harsh word) idiot. He got the money, and we have to support the customers? Not with me! Best Regards, Thorsten. P.S.: it isn't personally against you, you probably didn't know about these illegal sales

This topic has been moved to MIDIbox of the Week. [iurl]http://www.midibox.org/forum/index.php?topic=10547.0[/iurl]

Beautiful! :) My first thought after I saw the yellow-black label: it's perfectly matching with this amp design: Best Regards, Thorsten.

Great to hear, that you finally solved the issue :) Yes, thats normal. You could increase the capacity of C27/C28/C29/C30, but this would filter the "wanted" higher frequencies as well. A better solution could be the usage of a 24 dB (or more) lowpass filter - but this requires some additional hardware (-> expensive solution) Best Regards, Thorsten.

Hi, concerning FM drum kits: you can create 4 additional, more complex, drum sounds by using FM instruments. They can be assigned to the same MIDI channel like the drum kit, and assigned to a special note (or keyboard range) Best Regards, Thorsten.

Just prepare a dedicated basis patch for each engine, and switch to the patch via Program Change. Patches of the preset bank can be used for this, or new ones can be created with the SysEx editor (once available) Best Regards, Thorsten.

did you already change the baudrate? The "to-com" flag has to be set in the PIC ID header. You could do this with the change_id application. Open main.asm, change value of MIOS_TO_COM_FLAG to 1, rebuild the main.hex file with "make", and upload the new .hex file via MIDI. Thereafter the baudrate is changed for LTC interface (communication via MIDI won't be possible anymore) If MIOS has been uploaded correctly (and it seems that this is the case), this display should work fine. See this page for troubleshooting tips: http://www.midibox.org/dokuwiki/troubleshooting_lcd_displays Best Regards, Thorsten.

Typing "mpc pads" into the search function of this forum gives us following result: http://www.midibox.org/forum/index.php/topic,9147.0.html Best Regards, Thorsten.

Just to clarify: when you are standing in the middle of the keyboard, and the LED matrix is at the right side, you want to have the buttons at the right side as well. Same vice versa: LED matrix at the left side -> buttons left side Otherwise your hand will cover the LEDs while pushing the buttons CAD software with virtual reality interface would be nice to visualize such usability issues ;) Best Regards, Thorsten.

Hi Lesss, things are changing fast today ;) I've re-released the merger source code, so that it can be compiled with GPASM instead of MPLAB New release package: -> http://www.ucapps.de/midimerger/merger_v1_4b_18f.zip The modification for the buffer overrun check is already part of this package. But please note, that I assume that more changes are required. For the case that you need to rebuild a new .hex, don't use MPASM anymore, but GPASM instead as described here: http://www.ucapps.de/howto_tools_gpasm.html Best Regards, Thorsten.

In order to get rid of the windows propritary MPASM assembler, I started to migrate MIOS and most of the applications to the GPUTILS toolchain. This freeware is available for all major operating systems (including Windows/Linux/Mac OS), and therefore should allow everbody to customize and rebuild an application without Windows installation. The main reason why this important step had not been done in the last years was the incompatibility of the GPASM macro preprocessor, which is less powerful than MPASM. Especially my beloved IFSET and IFCLR macros are not supported. As a compromise I'm using simple versions of this macro now (e.g. BRA_IFSET, BRA_IFCLR, CALL_IFSET, etc...), and converted the existing source codes to this new scheme with a perl script, and adapted the remaining cases (which were not covered by the automation) manually. These changes are finished now, and instead of providing the quick&dirty conversion script for Unix users, I decided to maintain all existing applications with the new "GPUTILS" style in future. For MIDIbox end-users this change is less dramatical when it sounds above - GPUTILS can be easily installed, thereafter an application can be rebuilt by typing "make" in the command shell (or windows users: by double-clicking the make.bat file). It's simpler and requires less tools than ever before! :) Resources: MIOS Download page (click on the refresh button of your browser if you don't see the new packages): http://www.ucapps.de/mios_download.html GPASM Guide: http://www.ucapps.de/howto_tools_gpasm.html Following projects have already been adapted - the remaining packages will be migrated soon! All of them got a new version number. Only exception: the mios source code package (to avoid additional effort at my side...) change_id_v1_9d.zip magic_midi_delay_v1_5a.zip mbhp_tv_v1_3a.zip midi_benchmark_v1a.zip midibox64_v2_4a.zip midibox64e_v2_2a.zip midibox_cv_v1_2a.zip midibox_fm_v1_1b.zip midibox_lc_v1_6b.zip midibox_mf_v2_2a.zip midibox_seq_v2_4d.zip midibox_seq_v3_2b.zip midibox_sid_v1_7303c.zip midibox_sid_v2_0_rc17.zip midibox_tc_v1_7a.zip midimon_v2_0a.zip midio128_v2_1e.zip mios_v1_9f_src.zip skeleton_v1_9a.zip Best Regards, Thorsten. /Edit: I uploaded all .zip packages again, only change: "make distclean" Makefile rule replaced by "make cleanall", since the name "distclean" could be misleading.

I corrected the mistakes, and re-arranged the labels in the hope, that they are a little bit more readable now. (However, I must admit that it still looks ugly) -> http://www.ucapps.de/mbhp/mbhp_opl3_v1a.gif -> http://www.ucapps.de/mbhp/mbhp_opl3_v1a.brd Best Regards, Thorsten.

It's as simple as I wrote: below the MainLoop label in mainloop.inc, and rebuild a new .hex file as described here: http://www.ucapps.de/howto_tools_mpasm.html I did the modification for you, but please note that this always takes about 10..15 minutes for me, since MPASM doesn't run on my notebook (so, I need to boot the PC, re-assemble, transfer to notebook, transfer to ucapps server, etc...) -> http://www.ucapps.de/tmp/merger_v1_4a_18f_mod1.zip Since more changes are to be expected for finding out the root cause, it would be very helpful if you could try to rebuild the application. Otherwise it will take much longer for both of us to solve this issue. Best Regards, Thorsten.

Hi Lesss, ok, only notes are sent. Meanwhile I looked through the code and noticed, that I added a timeout mechanism which prevents, that even uncomplete SysEx streams could lock up the MIDI forwarding. But I also noticed, that a check for the OERR (Rx buffer overrun flag) of the internal UART is missing. So far I remember, the receiver won't generate a new interrupt anymore on incoming MIDI data so long this flag stays set. Could you please add following code: ;; check for MIDI receive buffer overrun MAINLOOP_UART btfss RCSTA, OERR rgoto MAINLOOP_UART_NoOERR MAINLOOP_UART_OERR bcf RCSTA, CREN ; re-enable receiver movf RCREG, W bsf RCSTA, CREN MAINLOOP_UART_NoOERR [/code] below the MainLoop label in mainloop.inc, and rebuild a new .hex file as described here: http://www.ucapps.de/howto_tools_mpasm.html If this unlocks the receiver, we know that this is the reason. It gives me the required input for planning additional measures - because it must have a reason, why the UART buffer register is not read by the CPU within ca. 640 uS Best Regards, Thorsten.

I especially like the new phone pot! :) Some spontaneous thoughts (you don't need to implement them, just my oppinion): - remove the buttons at the right side of the matrix, it looks ugly - add a button for switching between metering and modmatrix view instead - you will really miss the start/stop button, when you have to press SID1/2/3/4 + the menu button to start all sequencers synchronously - arrange Envelope selections buttons closer to LFO buttons - add an encoder for envelope depth - and if you are searching for a second encoder: envelope decay - add a LED which displays the BPM (should flicker on each beat) Best Regards, Thorsten.

The only way is to create different scenes with static assignments. The MK is very unflexible concerning parameter assignments, e.g. in distance to MB64E in patch mode (as an example), you will loose values when switching between the "parameter views" (scenes) Such an inflexibility is the reason, why people still love Synths with a sophisticated user interface. No MIDI controller can beat this! You will at least miss all the special messages print on the LCD of a MBSID CS Best Regards, Thorsten.

I agree, that they are not directly comparable, but not because AVRx is an hyprid synth (with the SwinSID/MIDIbox SID/AOUT combination you can add analog components as well), but mainly because it's an "all-in-one" solution, and the synthesis concept allows waveform shaping. My oppinion is mainly based on demos and specs (so far provided). E.g., there is no word about the sampling rate at AvrX site, but when I listen to the demo samples, and consider that the CPU is loaded with user interface and modulation tasks in addition, I guess that it cannot be so high. And speaking about "expandable synthesizer platform": I think that SwinSID approach has more potential compared to AvrSynth and AvrX - especially because alternative synthesis/filter/modulation routines can be integrated into the firmware on a straightforward way without taking care for multitasking and complex realtime requirements. You only need to take care, that the new sample word is calculated within 32 uS (=ca. 768 AVR instructions minus IRQ and DAC/Slave transfer overhead). And if 32 uS are too short for certain sound processing algorithms, you are free to reduce the number of oscillators, and/or the sampling rate of course :) I could change my oppinion about the "superiour project" once I read your review! :) Best Regards, Thorsten.