TK.

Hallo Tino, Hoerst Du das Brummen eigentlich auch dann, wenn der SID nicht im Sockel eingesteckt ist, und Pin #27 stattdessen auf Masse liegt? sehr sehr seltsam - die Verbindungen zum SID scheinen ja in Ordnung zu sein. Falls Du besonders wagemutig bist, koenntest Du Pin #27 des (wieder im Sockel eingesteckten) SIDs hochknicken, und den Audio In Deines Mixers ueber einen 100 nF Kondensator direkt mit diesem Pin verbinden. Nur mal so zum testen - ich rate auf meiner Webseite zwar davon ab (da Buchi auf seiner Webseite bspw. schreibt, dass er auf diese Weise schonmal einen SID fritiert hat), doch ich selbst habe den SID Anfangs genauso betrieben, und es hat ihm "nicht weh getan". Falls Du auf Nummer sicher gehen moechtest, muesstest Du den SID in einem C64 ausprobieren (ist er mittlerweile angekommen?) ja, es handelt sich hierbei um einen Emitterfolger (Spannungsverstaerkung 1:1) passt schon Gruss, Thorsten.

Hallo, ja, das ist normal. D7 ist die letzte Leitung, die vom 74HC595 bedient wird, CS# wird direkt angesteuert Auch der Pfeifton waehrend der Reset-Phase ist normal - er deutet schonmal darauf hin, dass die Audio Stufe scheinbar funktioniert. Auf die SysEx-Daten brauchst Du nicht zu achten, das sind die Patches, die an die Slaves gesendet werden, wenn die CS Option aktiviert ist (der Master weiss ja nicht, ob diese wirklich angeschlossen sind, deshalb sendet er auf Verdacht einfach die Konfiguration raus) Wenn Du die Applikation frisch aufgeladen hast, solltest Du den Default-Patch aus dem internen EEPROM hoeren (Puls auf MIDI Kanal 1) Da die Daten/Addressen wohl richtig angesteuert werden, macht es auf alle Faelle Sinn, den SID mal direkt vom PIC zu takten (wie zuvor vorgeschlagen: Oszillator vom SID trennen und den CLK pin mit PIC pin #17) Brummen/Rhythmische Geraeusche: evtl. gibt es ein Problem mit der Masse (bspw. eine Masseschleife zwischen Netzteil und Audio Eingang des Mixers, bzw. der Soundkarte?), die zusaetzlichen Stoergeraeusche sind bis zu einem gewissen Grade normal beim SID (Technologieprobleme und Designfehler im SID Silicon, die sich von Aussen nicht beheben lassen); der Stoerabstand sollte sich jedoch beim 8580 im Bereich < -60 dB befinden. Was die Stoergerausche betrifft, so kannst Du die besten Ergebnisse mit dieser Schaltung erzielen: http://www.ucapps.de/mbhp/mbhp_4xsid_c64_psu_optimized.pdf, sie erfordert jedoch das Original C64 Netzteil - beachte vor allem die Fuehrung der Masse/+5V/14V Leitung Gruss, Thorsten.

- short circuits - swapped control lines - unconnected control lines - swapped LED polarity - application switches on all LEDs - or all the other errors which have been made by people in the past (just use the search function of this forum) Best Regards, Thorsten.

Hi Steve, the upcoming v1.7303 supports an alternative "low cost" AOUT module, the beta version is already available on request (see other threads) Yes, the AINs are routable through the LFOs, see change logs Best Regards, Thorsten.

Ja, das ist kein grosses Problem. MIOS bietet verschiedene Hooks, die aufgerufen werden, wenn bspw. ein Poti bewegt wurde, ein MIDI byte oder ein komplettes MIDI Event empfangen wurde, usw. Wenn Du bspw. ein Program Change Event auf Kanal 1 (-> C0 xx) erwartest, dann sieht der Code in main.c wie folgt aus: ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when a complete MIDI event has been received ///////////////////////////////////////////////////////////////////////////// void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { if( evnt0 == 0xc0 ) { tue_was_mit_c0(evnt1); // evnt1 contains the program change value } } [/code] Wenn das Program auf Potis reagieren soll, erweiterst Du den AIN_NotifyChange hook: [code] ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when a pot has been moved ///////////////////////////////////////////////////////////////////////////// void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) __wparam { switch( pin ) { case 0: // tue dies break; case 1: // tue jenes break; default: // tue gar nichts } } (vorher muss natuerlich noch in Init() die Anzahl der Potis und die Aufloesung festgelegt werden...) am besten schaust Du Dir mal die C Beispiele an (viele gibt es noch nicht, aber das wird sich irgendwann aendern ;-) - vielleicht kannst Du ja irgendwann einmal Dein eigenes Programm als Beispiel bereitstellen?) Gruss, Thorsten.

wenn das komplett in Assembler programmierte MIOS nicht die gesamte Verwaltung der MIDI streams und analog/digital IO uebernehmen wuerde, waere C mit Sicherheit zu langsam. Doch um diese Low-Level Driver musst Du Dich eigentlich nicht mehr kuemmern, im C Programm werden die einzelnen "Datenstroeme" nur noch umgesetzt (also bspw.: Endlosregler gedreht -> Absolutwert speichern -> MIDI Event senden), hierbei brauchst Du erstmal keine Performance-Schwierigkeiten zu befuerchten, solange sich die Datenmengen in Grenzen halten (und wenn es dann doch mal mehr zu verwalten gibt, kannst Du immer noch Inline Assembly Code in die C-Funktionen reinsetzen). Gruss, Thorsten.

Hi Alkex, I would suggest to store such data into EEPROM instead of Flash - in flash you can only write 64 bytes at once, and it reduces your code space. EEPROM is byte writeable, and the usage of MIOS_EEPROM_Write and MIOS_EEPROM_Read is much easier (no RAM buffer required) the EEADR 0x60..0xff are not used by the MIDIO128 application yet Best Regards, Thorsten.

sweet! :) I will add a change into the next MBSID release, so that the edit LEDs goes automatically into "flash" mode once a CC is received via MIDI, so that it won't be required anymore to change a parameter manually before enjoying the animations (and the game) Best Regards, Thorsten.

We all remember the legendary "Der Brat 1000" (-> http://69.56.171.55/~midibox/forum/index.php?topic=3651.0) This is the small version "Der Brat. 50" - the ideal mobile solution for jamming together with friends ;-) Seppoman wrote:

This is the MIDIbox SID of Fabian - he built it into an old case of an "electrical thermometer". He wrote (in german - use http://babelfish.altavista.com for translation)

Hallo Frank, bei graphischen LCDs muessen die Y-Offsets anders eingestellt werden. Am besten machst Du die Aenderungen wieder rueckgaengig, und aenderst die Offsets in main.asm wie folgt: #if DEFAULT_LCD_SIZE == 3 ; 4x20 #define DEFAULT_YOFFSET_LINE0 0x02 #define DEFAULT_YOFFSET_LINE1 0x42 #define DEFAULT_YOFFSET_LINE2 0x82 #define DEFAULT_YOFFSET_LINE3 0xc2 #define CSMD_YOFFSET_LINE0 0x00 #define CSMD_YOFFSET_LINE1 0x40 #define CSMD_YOFFSET_LINE2 0x80 #define CSMD_YOFFSET_LINE3 0xc0 #endif [/code] danach werden die Menueseiten nach wie vor nur zentriert dargestellt. Lediglich innerhalb des Display-Menues wird der Bildbereich komplett ausgenutzt (vor allem auf Seite 3) Gruss, Thorsten.

all I can provide is this code: void ENC_NotifyChange(unsigned char encoder, char incrementer) __wparam { unsigned int value; // encoder number 0, 2, 4, 6, 8, 10, 12, 14: VPOT // encoder number 1, 3, 5, 7, 9, 11, 13, 15: Fader replacement if( encoder < 16 ) { if( !(encoder & 1) ) MM_VPOT_SendENCEvent(encoder >> 1, incrementer); else { // add incrementer to absolute value value = MM_MF_FaderPosGet(encoder >> 1); if( MIOS_HLP_16bitAddSaturate(incrementer, &value, 0x3ff) ) { // send fader event MM_MF_FaderEvent(encoder >> 1, value); } } } // encoder number 16: datawheel else if( encoder == 16 ) MM_VPOT_SendJogWheelEvent(incrementer); else { // here you could handle additional encoders } } [/code] Best Regards, Thorsten.

Hi Julian, how did you check if the CC are received by the MBSID? If you want to check the displayed value on the LCD, you have to enable edit mode, otherwise the control surface doesn't take these changes (this is for a non-destructive automation from a MIDI host) Best Regards, Thorsten.

with the SDCC based version it is possible, yes maybe this could work, but the additional ledring (or better: ledbar) handler has to be implemented by yourself. However, with the C version it isn't so difficult Best Regards, Thorsten.

Hi, vmidibox only uploads the configuration data, this has nothing to do with .hex files Did you upload the MIDIbox V2.4 application before? Best Regards, Thorsten.

Here some quick snapshots, how the MBLC emulation looks on the MIDIbox SEQ hardware. 8 encoders are used as "V-Pots", the remaining 8 encoders as Motorfader-replacement (mostly controls volume). The Jogwheel function is available (17th encoder), and there are 3 button layers to which the LC commands are assigned (of course, it is possible to add even more buttons (up to 128-2*17 = 94 button functions) and LEDs (up to 128), and to customize the button/LED in order to assign LC commands like desired - the MIDIbox LC application is really flexible :) And it provides a "general purpose" mode with 128 additional MIDI parameters Common view (the tracks are selected with the Bank +/- buttons) View of a VST plugIn: Editing VST parameters: The screens look a little bit scrambled. The reason is, that it has to be stretched from 2x55 to 2x80, so that the displayed parameter labels and values are exactly above the appr. V-Pots. There are 4 different display modes with alternative views, e.g. one where the 2x55 display is centered (no scrambling) Best Regards, Thorsten.

yes Best Regards, Thorsten.

For sound engine hacks the SE option already exists (it provides 7 flags, one is allocated for the TB303 option, the others are free yet) - see http://69.56.171.55/~midibox/forum/index.php?topic=4447.0 The MIDI Clock Out option uses an existing register which already stores the three sync flags for LFO/ENV/WT, 5 flags are free. As mentioned above, the option itself consumes 4 assembly instructions, thats ok for a general option. Best Regards, Thorsten.

Hi Julian, It's disabled when you are trying to "get" a bank within a bank window, because this is the context which only allows to request patches. Banks can only be requested from a library window. Great! I'm planning to publish a new library with a second preset bank once the TB303 option has been released :) Best Regards, Thorsten.

Ok, MIDI clock output can be enabled with Parameter #125 ("MIDI Sync"), bit 3 in the next release Best Regards, Thorsten.

Hi Rowan, thank you, I will check it this weekend :) Best Regards, Thorsten. P.S.: have a nice flight - if you are flying via Singapore, don't waste your time with the microKontrol, but enjoy the city instead! ;-)

Hi Luke, MB64E can "only" receive the parameters of the currently selected bank. Means: 128 encoder values and 64 button (LED) values. Each bank is divided into groups. With 32 rotaries you have four groups, which can be selected with "Special Function Buttons" (see sfb table) There are several "workarounds" which could be used: if your host application provides a function which sends the status of all control elements (faders/pots/buttons...) via MIDI, then just trigger this function and the Encoder positions/LEDs will be updated. This is how my MB64E interacts with Logic Audio, it has the big advantage that LEDs/Encoder positions will be updated even after I loaded a new song - for myself this is very important, therefore I never thought about the capability to store even more parameters in RAM, since this wouldn't really be a perfect solution you could enable the auto-snapshot function which stores and restores the whole "scene" when you are switching between different banks in the last time it very often turned out that people don't really need the high flexibility of MB64E, but just want to use their MIDIbox to interact with a host application. This means that normaly encoders only have to send 7-bit or 14-bit events, the buttons should send Note events. If the appr. CC#s and Notes are statically defined (e.g. Encoders always send/receive CC or NRPN, Buttons always send Note On/Off), an alternative application could be realized which only supports predefined events, but can handle with up to 640 encoder parameters and 1024 LED values at the same time! Whats the oppinion of the community, is there a need for such a "generic" controller (in my eyes it's a primitive application, but it seems that this is exactly the need for most of you?) Best Regards, Thorsten.

This doesn't answer the question: why do you need a MIDI clock output, what do you want to do with this clock exactly? Why do you think that a master clock, sent by the SID, is better than clocking the SID as slave? Best Regards, Thorsten.

You are writing this in a form where it could be assumed that you are an expert in this area - the YAC is not a common linear DAC, it's provides a 10-bit mantissa and 7-step exponent (best for high dynamics), the analog output range is 16-bit. Can you please determine the exact benefit with this type of DACs? what are the experimental results? Did you notice any disturbing parameters during your experiments which haven't been mentioned at the website from where you copied this text? Best Regards, Thorsten.

Hi Julian, please send me your patches, once they are well sorted :) this dummy device always exists due to conceptional reasons in JSynthLib - it doesn't affect the SID to the first SID, device ID 0, because only this SID has a BankStick You could also use device ID 1, but in this case it would only to possible to write into the EEPROM (single patch), and not to transfer a whole bank Another problem is, that JSynthLib doesn't really support the access to multiple devices from a single editor (yet), the current solution is a dirty workaround, and the use is complicated (conceptional problem, no way to improve this without changes in the core library) If you want to send a patch to the first SID slave (device ID 1): of course Open a new Library, then click on Patch->Get In this menu you are able to select the Bank. Very important: this is not supported in JSynthLib versions < 0.20 because at this time the multiple BankStick option was not supported by MIDIbox SID ;-) So, please use this version: http://69.56.171.55/~midibox/jsynthlib/JSynthLib-0.20.0_midibox_mod1.jar.zip Another tip: if you only want to rearrange the patches, it makes sense to use TL's Patch Manager instead - the handling is much more comfortable: http://www.automatic-brain.de/midibox/ Best Regards, Thorsten.