TK.

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.

Well, it was silent around Swinkel's SwinSID project in the last weeks, but this doesn't mean that we gave up - far from it! Meanwhile this project is probably the most powerful AVR based DIY synth you can find in the web! :) And it's especially a very interesting extension for MIDIbox SID - either as SID replacement, or sound extension (each core can control two SIDs and one Stereo-SwinSID in parallel). I finally wrote down my personal impressions: SwinSID Review + Sound Demos New schematic, a PCB layout and the firmware will be published soon. Thanks to Swinkels for giving us this new toy! :) Best Regards, Thorsten.

Hi, just listining to your tracks - I like them, very original ideas, interesting sounds, and impressing that you did this with a single SID! :) It happens due to the ADSR bug of the SID. You will notice a very ugly random delay between 0 and ca. 30 mS whenever Attack, Decay and/or Release is >0 In addition, it can cause that the envelope doesn't restart. In MBSID V2 this has been solved by adding a workaround option to the drum engine. The ABW function delays all notes by a static delay of 30 mS. During this time, the ADSR will be reset for a proper restart. The delay has to be compensated in the audio software (if other instruments are played in parallel) It's basically the same approach which is used by C64 based trackers. Best Regards, Thorsten.

In general it has to be considered, that constant definitions (EQU) can either be addresses or just values which are used for different purposes. The assembler doesn't make a difference here. In distance to "#define", which you will also find sometimes in my applications, an EQU statement makes the definition public over the whole code. The assembler will replace the name by the constant definition during a second pass. A #define statement works only "below" the statement - therefore I'm only using it when I'm sure that it is defined early enough (inconsistently) MIOS_BOX_CFG0: yes, an address in data RAM MIOS_ENC_SPEED*: these are values which are used in mios_tables.inc (encoder speed modes) MIOS_GLCD_FONT: yes, thats an address in program memory Best Regards, Thorsten.

Changed the comment: // Up to 4 DOUTX4 modules (=16 shift registers = 128 digital outputs) can be connected // set the maximum number here - it doesn't really hurt! MIOS_SRIO_NumberSet(16); [/code] Best Regards, Thorsten.

Hi Lesss, I'm still thinking about a possible reason, but still haven't got any idea, what could cause such a hangup. Only, but unlikely reason could be, that one of your synths starts a SysEx stream with F0, which never stops (no F7 and no other Status Byte) Does it also happen, when the cables at the two MIDI inputs are swapped? Best Regards, Thorsten.

Hallo Pascal, Ja, aber nur bedingt. Im Bassline-Modus kannst Du bspw. zwei unabhaengige Basslines ansteuern (auch - und vor allem - mit dem internen Sequenzer) Im Multi-Modus dann sogar alle 6 Oszillatoren getrennt, oder Polyphon, mit eigenen LFOs und Huellkurven. Im Lead-Modus gibt es jedoch keine Trennung - stattdessen wurde sie auf Stereomodulation optimiert. Entsprechende Effekte lassen sich also supereinfach realisieren. Wenn Du also von 4 Mono-Kanaelen spricht, meinst Du sicherlich die Verwendung der Lead-Engine fuer komplex modulierte Sounds. Das geht nicht (dafuer ist nicht genuegend Rechenpower da, hierfuer benoetigt man einen zusaetzlichen Core). Andererseits kann man wiederum auch mit der Multi Engine sehr schoene Klaenge produzieren, die vielleicht sogar fuer Deinen Verwendungszweck besser geeignet sind, weil sie nicht so dominant (-> fett) klingen. Durch die Reduzierung der Modulationsmoeglichkeiten ergibt sich also ein ausgeglicheneres "Gesamtbild" Gruss, Thorsten.

Habe das gestrige Posting noch mit rot markierten Bemerkungen versehen. Gruss, Thorsten.

Ich habe heute ein wenig mit verschiedenen Leitungslaengen und Terminierungs-Moeglichkeiten herumexperimentiert, und dabei quasi ueber das Thema Reflektion reflektiert. Um eins vorwegzunehmen: ich nehme die einige meiner gestrigen Aussagen zurueck - sie basierten auf falschen Annahmen. Werde sie auch gleich nochmal entsprechend im Posting markieren. Hier die heutigen Erkenntnisse in einer "Diashow": Hier ist lediglich ein DOUTX4 Modul ueber ein kurzes Flachbandkabel (ca. 10 cm) am Core angeschlossen. Der obere Kanal zeigt das SCLK Signal am CORE Modul, der untere Kanal das gleiche Signal am "Ende" (J2) des DOUTX4 Moduls. Und hier die Flanken nochmal vergroessert. Steil und zackig! Von den kleinen Ueberschwingern darf man sich nicht zu sehr verwirren lassen - hierbei handelt es sich bereits um eine Reflektion, doch eher um eine der harmlosen Art, solange der High-Pegel nicht 3.7V unterschreitet, und der Low-Pegel nicht 1.3V ueberschreitet. Sie wird auch teilweise von meinem Oszilloskop hervorgerufen - das hat uebrigens nur 20 MHz Bandbreite, ist also nicht optimal geeignet um hochfrequente Schwingungen anzuzeigen. Alles was hier rund ist, koennte in Realitaet wesentlich rechteckiger aussehen. Nunja... Nun habe ich ein zweites DOUTX4 Modul hinter das erste angeschlossen, und zwar ueber ein Kabel mit 1.5m Laenge. Diese eher unrealistische (weil nicht empfohlene) Laenge ist mit Absicht so gewaehlt, um die Reflektionseffekte zu verstaerken. Andererseits: wenn man 4 DINX4 und 4 DOUTX4 Module hintereinander schaltet, sieht es wahrscheinlich aehnlich aus - je nachdem, wie SCLK vernetzt ist. Diese Ueberschwinger sind zwar extrem, sorgen jedoch noch nicht zu Problemen, da die 74HC-Eingaenge eine Hysterese haben. Der ca. 1V Ueberschwinger am Low-Pegel liegt auch noch unterhalb der minimalen Eingangsspannung, und weit entfernt von der Schwellspannung (Threshold) Trotzdem sind die Ueberschwinger unschoen (auch aus EMV Gruenden) - deshalb habe ich ans Ende der Leitung ein Poti angeschlossen, und es so eingestellt, dass die Ueberschwinger moeglichst minimal sind, doch die Spannung am Eingang nicht zu stark beeinflusst wird. Der optimale Daempfungswert war dann so ca. 270 Ohm. Zur Beeinflussung der Spannung am Core Modul: die Milchmaedchenrechnung "zusaetzlich verbrauchter Strom ist I=U/R, er vervielfacht sich, je mehr Leitungsenden man terminiert" geht hier nicht auf. Denn der Ausgangstreiber des PIC Pins hat ja auch noch einen Innenwiderstand, der den Strom zusaetzlich begrenzt. Das heisst: je niedriger der Terminierungswiderstand, desto mehr sackt die Spannung ein. Der maximale Strom liese sich ausmessen (PIC Pin kurzschliessen), habe ich aber nicht getan. Nun kommen wir zu Seppomans Vorschlag, das Leitungsende mit C+R (100 pF + 100 Ohm) gegen Masse zu terminieren. Wir sehen erstmal keine dramatische Verbesserung gegenueber dem Fall ohne Terminierung. Das ist auch der Effekt, den ich bisher immer gesehen habe (und deshalb nicht weiter ueber AC Terminierung nachgedacht habe) Doch nun kommts! Eher unabsichtlich habe ich C+R gegen +5V angeschlossen, und ploetzlich sah das Signal schon ganz anders aus! Das war mir bisher entgangen! ;-) Was man auch sieht: die Signallaufzeit wird so gut wie gar nicht beeinflusst, wie befuerchtet. Es spricht also nicht viel dagegen, saemtliche DIN und DOUT Module hintereinander zu haengen, und zusaetzliche C+R einzufuegen, solange man es nicht uebertreibt. Ich habe auch mal verschiedene R und C Werte ausprobiert. 100 Ohm + 100 pF hat sich als gute Kombination fuer verschiedene Leitungslaengen erwiesen. Im Gegensatz zu meiner urspruenglich vorgeschlagenen Loesung muss man also nicht verschiedene Widerstandswerte ausprobieren, sondern faehrt mit diesem R+C wohl ziemlich gut. Warum AC Terminierung gegen +5V besser funktioniert. Ich gebe das Spekulieren auf! Vielleicht weil SCLK die meiste Zeit auf 0V liegt, und sich der R+C Zweig gegen 5V aufladen kann, so dass bei einer steigenden Flanke kein kompletter Aufladevorgang stattfindet. Man kann beobachten, dass die Daempfung langsam abnimmt, je laenger der 1 MHz Burst anhaelt - das kann aber auch ein Trugschluss (oder Messfehler) sein. Doch nun mal ein Vergleich mit einer wesentlich unrealistischeren 6 Meter Leitung im parallel geschalteten DIN Zweig: Bei einer fallenden Flanke sind die Ueberschwinger so heftig, dass sie fuer digitale Eingaenge wie zusaetzliche Takte aussehen (Schwellwert wird mehrmals ueberschritten). -> die LEDs fangen an zu flackern, und die Taster/Encoder verhalten sich nicht mehr deterministisch. So sieht das dann mit einer 150 Ohm Terminierung aus (die erwies sich als "optimal") - das Signal ist trotzdem nicht mehr brauchbar. Und so schliesslich mit 100 Ohm/100 pF AC Terminierung - hier geht noch was! Fazit: Seppoman hat im grossen und ganzen Recht - AC Terminierung ist besser und sogar universeller (Probieren mit verschiedenen Widertandsgroessen entfaellt) Terminierung mit 220..330 Ohm Widerstand hilft in den meisten Faellen ebenfalls, ist aber nur als Uebergangsloesung zu empfehlen, wenn man gerade keine Kondensatoren zur Hand hat. Die Widerstaende liegen schon eher herum (da bspw. die meisten Module damit bestueckt sind) es spricht nichts dagegen, eine lange Kette aus DIN und DOUT Modulen zu bilden, es kann sogar vorteilhaft sein, wie ich mittlerweile gelernt habe (verschiedene Zweige fuehren zu unterschiedlichen Wellenwiderstaenden, die man irgendwann nicht mehr in Griff bekommt) die von mir vorgeschlagene sternfoermige Verdrahtung von SCLK geht auch, sollte aber nur angewendet werden, wenn die Leitungen in etwa gleich lang sind (schwierig) eine professionelle Loesung wuerde so aussehen: fuer jeden SCLK Zweig einen eigenen Buffer hernehmen - Buffer nicht hintereinanderschalten, das wuerde das Signal nur unnoetig verzoegern. manchmal - aber nicht immer - funktioniert AC Terminierung nur dann zufriedenstellend, wenn man R+C gegen +5V (Vdd) schaltet Gruss, Thorsten.

The problem is, that in live situations you sometimes want to handle control elements with both hands. E.g., adjusting CutOff before enabling a LFO->CutOff connection, and adjusting CutOff again once you enabled the connection. Check out my YouTube videos to see what I mean! ;) Currently you would have to cross your arms to do this. Best Regards, Thorsten.

This remembers me on my very first MIDIbox, which was built into a satellite receiver as well! :) http://www.ucapps.de/midibox/midibox_innen.jpg Best Regards, Thorsten.

I push the matrix buttons with my left hand - it doesn't require so much practice to master this ;-) Best Regards, Thorsten.

Hi Crypto, could it be, that the core sends a lot of MIDI events (instead only one) when triggering the pin which shows #128 on/off? It seems that either the SC or RC clock line is not connected correctly. You can check them visually first - if you don't find the error, follow the tips of this troubleshooting page: http://www.midibox.org/dokuwiki/din_module Best Regards, Thorsten.

Thats a good starting point! :) Note that 0x000..0x002 is reserved for MIOS internal variables, and 0x03..0x0f is allocated by MIOS_PARAMETER[123], TMP[12345] and IRQ_TMP[12345] So, free application space starts at 0x010 Best Regards, Thorsten.

The vertical buttons of the modulation matrix are at the wrong side. It's the same issue as bugfight already pointed out for the LCD menu interface: your right hand covers the matrix when you want to push the buttons - it's especially critical for the matrix, as you need to use your thumb and index finger (hope that this is the right name) accross the LEDs to enable/disable a matrix connection. Best Regards, Thorsten.

AC Terminierung ist sicherlich die bessere Alternative, erfordert jedoch wesentlich mehr Bauteile, Mess- und Denkarbeit, als Du in Deinem Posting zugibst. ;) /edit: stimmt nicht - sie laesst sich sogar einfacher handhaben 150 Ohm sind sicherlich zu niedrig, aber in Deiner Aussage befinden sich zwei Denkfehler. Das kritische Signal ist der Shift Clock (SCLK), da er mit hoher Frequenz (ca. 1 MHz) getaktet wird, und Setup/Hold Verletzungen an den seriellen Eingaengen zu vermeiden sind. Wenn die SRIO-Kette nicht bedient wird (ca. 80% der Zeit), steht SCLK jedoch auf 0V Folglich liegt am Abschlusswiderstand die meiste Zeit keine Spannung an -> es fliesst kein Strom. /edit: war ungenau formuliert - es fliesst meistens kein Strom. Ausserdem fehlte der Hinweis darauf, dass der Strom - wenn er denn mal fliesst - durch den Innenwiderstand des Ausgangspins begrenzt wird Zweiter Denkfehler: Terminierung bedeutet, dass der Abschluss-Widerstand dem Wellenwiderstand angepasst wird. Der Wellenwiderstand haengt im Wesentlichen von den Verbindungskabeln zwischen den Modulen (R/L/C), den Leiterbahnen auf den Modulen (R/L/C), und der Eingangsimpedanz der 74HC Bausteine (R/C) ab. Die Ausgangspins des PICs "sehen" also bereits eine Impedanz. Wenn der Abschlusswiderstand richtig vermessen ist, wird der Wellenwiderstand zu 0. Somit wird der Ausgangspin des PICs nicht zusaetzlich belastet. /edit: falsche Aussage, haette mal nachrechnen sollen ;) Das grosse Problem an der Geschichte ist, dass wir es hier nicht mehr mit definierten Verhaeltnissen zu tun haben. Die Impedanz der Kabel/Leiterbahnen laesst sich nicht so ohne weiteres berechnen, zumal sie bspw. nicht nur von der Laenge, sondern auch vom Kabelmaterial abhaengt. Deshalb hilft hier erstmal nur eine professionelle Messvorrichtung, oder "trial&error" /edit: "trial&error" wohl nur notwendig, um C+R entweder gegen Masse, oder +5V auszuprobieren Bei der AC Terminierung geht man davon aus, dass sich R+C am Ende der Uebertragungsleitung, jedoch *vor* dem Eingangspin befindet. /edit: stimmt, ist aber nur fuer den Idealfall wichtig. Ich wusste nicht, dass es manchmal gegen +5V wesentlich besser funktioniert Man muesste also an jedem Modul-Ausgang einen Buffer setzen, und an jedem Modul-Eingang R+C in Serie. Wenn man das nicht macht, wird die Signallaufzeit durch den C zusaetzlich verlaengert - man macht es also noch schlimmer. /edit: stimmt, deshalb die Buffer - wenn ueberhaupt - nur am Ausgang des PICs anschliessen. Wie bereits oben erwaehnt: 150 Ohm ist sicherlich zu wenig. /edit: notwendig bei superlangen Flachbandleitungen (ab 5 m?) Das ist ein guter Punkt - klingt plausibel! Zumal ich meine eigenen Prototypen meistens wild verdrahtet habe, das SCLK-Signal der DIN/DOUT Register ist also nicht strikt in Serie verdrahtet, sondern eher sternfoermig vernetzt. Das koennte erklaeren, warum ich selbst von dem Effekt noch nicht betroffen war. Ganz schlecht, denn die SCLK Frequenz ist so bemessen, dass bei 2*16 hintereinander geschalteten DIN/DOUT Chips die Setup/Hold-Zeiten an den IOs noch sicher eingehalten werden. Das bedeutet: wenn die SCLK-Leitung in einer langen Kette zu den 32 Shift Registern gefuehrt wird, muesste ich die Frequenz verringern. So koennte man Control Surface + Synth Engine nicht mehr mit einem einzigen Core zu betreiben, denn die CPU waere zu sehr damit ausgelastet, die Schieberegister zu bedienen. /edit: die zusaetzliche Laufzeit ist im Vergleich zur Frequenz minimal, und somit ignorierbar Interessant waere es zu wissen, ob folgende Konfiguration besser funktioniert: sternfoermige SCLK Verdrahtung von Core zu den DOUT/DIN Modulen mit einer eher defensiv gewaehlten AC Terminierung (bsp. 47 pF + 47 Ohm) an den Modul-Eingaengen. /edit: schwieriger zu handhaben - Leitungen muessen gleich lang sein Ich moechte natuerlich nicht ausschliessen, dass ich nun voellig falsch liege - doch Deine Argumente klingen in meinen Ohren (und mit dem Wissen, das ich mir vor 15 Jahren mal zwangsweise aneignen musste, aber schon laengst wieder verdraengt habe ;)) nicht schluessig. /edit: tja, das meisste habe ich wohl tatsaechlich vergessen - haette die Skripte nicht wegwerfen sollen ;) Mir ist auch bewusst, dass die von mir vorgeschlagene Loesung nicht ideal ist, doch sie fuehrt offenbar mit wenig Ausprobiererei und ohne grossen Hardware-Aufwand zum Erfolg, laesst sich einfach nachvollziehen und erfordert kein Elektrotechnik-Vordiplom zur Ausfuehrung. ;) /edit: AC Terminierung fuehrt eher zum Erfolg, wenn man die Kondensatoren griffbereit hat Gruss, Thorsten.