TK.

Axel: danke fuer den Input, er hat mir mein Weltbild wieder geradegerueckt ;-) Sly: in main.asm das #define LCD_USE_SECOND auf 0, und #define LCD_EMU_COL auf 40 setzen Ich habe es mit dieser Konfiguration jedoch schon lange nicht mehr ausprobiert, es koennte sein, dass in lc_clcd.inc das Layout angepasst werden muss. Gruss, Thorsten.

Hi Dan, naming the buttons is not possible w/ the old MIDIboxes due to conceptional reasons... but should be possible with the MIOS version Best Regards, Thorsten.

Hi Mike, did it work with another MIDIbox? In this case it must be a wiring error -> check the connections again and again and again Best Regards, Thorsten.

Hi Sly, I haven't found the time to re-create the diagram (I'm too frustrated that I deleted the file by fault... :-( ) Please: don't connect any fader if you are not sure about the pinning in order to avoid any risk of damage. One simple exchange of two pins could fry the fader -> trashcan Once I've more time again (2-3 days) I will inform you about the correct wiring. In the meantime you should connect the analog inputs to ground. Best Regards, Thorsten.

Hi, this isn't an OS specific job, but just an option which could be added to any application. The 24LC256 types made by Microchip offer 3 additional CSx inputs which could be used to select the EEPROM. There are two ways to use these signals, the easiest would be to connect every single CS0 to a free DOUT, and the other 2 pins to ground. The DOUT can be controlled from the application with the MIOS_DOUT_PinSet function, and this function could be triggered by a MIDI event (see *_mproc.inc) Best Regards, Thorsten.

Thanks for your understanding! Yes, holidays would be nice ::) Best Regards, Thorsten.

Thanks for your understanding! Yes, holidays would be nice ::) Best Regards, Thorsten.

Hi Steven, currently only the displaytech 240x64 is supported, for other GLCD types special drivers have to be implemented. I'm still waiting for three different graphic LCDs which I will receive from users in the next days/weeks. Every new up&running LCD will be announced here. Yes, the LC application works with graphical and character LCDs. The same informations will be displayed on 4 different display pages, which can be selected by special function buttons - however, the layout is different ;-) And everybody is free to change the page layouts for his personal needs. I will create some new screenshots of the character LCD option soon, so that the difference is clear. Best Regards, Thorsten.

I neither have a personal interest in a SW60XG, nor for a digital output, nor for an analogue sampler ;-) Best Regards, Thorsten.

I neither have a personal interest in a SW60XG, nor for a digital output, nor for an analogue sampler ;-) Best Regards, Thorsten.

Hallo, Deine Pot-Eingaenge haengen in der Luft, deshalb sendet die Box Zufallszahlen. Falls Du noch keine Fader hast, schliesse die 8 analogen Pins (J5) einfach an Masse Gruss, Thorsten.

Ich sage einfach mal: egal ;-) Die kleinsten Widerstaende (0.25 Watt) reichen allemal. Die Sternschaltung ist nur fuer analoge signale relevant, um Jitter zu vermeiden. Bei digitalen Signalen ist es egal, woher die Masse kommt. Widerstands-Arrays lassen sich problemlos einsetzen (spart Loetaufwand) Gruss, Thorsten.

Das LCD selbst verbraucht so gut wie keinen Strom, aus dem Datenblatt ist ja zu entnehmen, dass der Wert bei ca. 1 mA liegt. Bei Graphic-LCDs sind es maximal 10 mA. Die Hintergrundbeleuchtung verbraucht dafuer umso mehr Strom - siehe Datenblatt: typischerweise 200 mA. Mit dem Backlit-Poti kann man den Strom wiederum reduzieren, das Backlit wird dabei dunkler. Gruss, Thorsten.

Hi Lo, unfortunately there is currently no way to configure the applications w/o the assembler. Creating a GUI is a lot of effort and should not be started before the features are frozen... for myself it would be a "creativity blocker" if I would have to adapt a GUI to new features with every new release. yes, a MBMF port is planned, it will be compatible with the PIC16F solution so that Serge's Editor can be reused. The pot on the MF board has to be adjusted, yes. The MF calibration app allows you to find the perfect settings for: MF board voltage, motor speed for up/down movements, MF deadband, AIN deadband. The deadband itself is just the value range in which changes are ignored. For example, if the analog input has some noise which causes jitter, you can increase the deadband in order to filter the unwanted changes. With an increased deadband value you also decrease the resolution. For a 10-bit value a deadband of "0" is recommented. For a 7-bit MIDI value, a deadband of "7" is perfect (just try it to find out the difference). The PIC16F firmwares are working with a deadband of 7 by default. MF deadband is nearly the same - it means that the fader will only be moved if the new position is above or below the current position +/- deadband value Best Regards, Thorsten.

Hi Lo, unfortunately there is currently no way to configure the applications w/o the assembler. Creating a GUI is a lot of effort and should not be started before the features are frozen... for myself it would be a "creativity blocker" if I would have to adapt a GUI to new features with every new release. yes, a MBMF port is planned, it will be compatible with the PIC16F solution so that Serge's Editor can be reused. The pot on the MF board has to be adjusted, yes. The MF calibration app allows you to find the perfect settings for: MF board voltage, motor speed for up/down movements, MF deadband, AIN deadband. The deadband itself is just the value range in which changes are ignored. For example, if the analog input has some noise which causes jitter, you can increase the deadband in order to filter the unwanted changes. With an increased deadband value you also decrease the resolution. For a 10-bit value a deadband of "0" is recommented. For a 7-bit MIDI value, a deadband of "7" is perfect (just try it to find out the difference). The PIC16F firmwares are working with a deadband of 7 by default. MF deadband is nearly the same - it means that the fader will only be moved if the new position is above or below the current position +/- deadband value Best Regards, Thorsten.

Hi Lo, a port of all existing PIC16F firmwares to MIOS is planned, so that the configuration will be as easy as with the old firmwares. But it could take some weeks until I will find the time for this step Best Regards, Thorsten.

Hi Lo, a port of all existing PIC16F firmwares to MIOS is planned, so that the configuration will be as easy as with the old firmwares. But it could take some weeks until I will find the time for this step Best Regards, Thorsten.

No problem... in the meantime I made some music with the PIC18F based SID and noticed no malfunction anymore. Working with the minimal control surface already makes more fun than using the editor, but I think that I should start with the complete control unit now for even more fun ;-) Best Regards, Thorsten.

yep

The only way to verify the crystal is to use an oscillator and a scope, or to ask the manufacturer :-/ However, the PIC should run with a different frequency, that means: a LED hooked to MIDI Out should flicker during startup. Just only the MIDI receiver will not regognize the MIDI events because of the baudrate mismatch. Capacitance of the crystal: doesn't really matter here, it's only relevant for radio applications. 15 pF are fine Best Regards, Thorsten.

Hi, unfortunately Reichelt doesn't offer rotary encoders :-( An orderling list can be found under MBHP->MIDIbox16E->Design Best Regards, Thorsten.

Currently we have two possibilities to create arpeggios: set the arpeggio rate > 0 and play a chord (up to 4 notes are provided). Note that every oscillator has an own arpeggiator, so with the control surface you should select OSC "123" together and set the rate for all three oscillators to the same value use the wavetable sequencer to modulate the transpose CC - in this way an arpeggio can be played with one finger yes, MIDI clock sync for both, arpeggiator and wavetable sequencer, is planned :) Best Regards, Thorsten.

In theory it should be possible to access the card with the planned bridge, but I cannot support this from the software side, since I don't own this card Best Regards, Thorsten.

In theory it should be possible to access the card with the planned bridge, but I cannot support this from the software side, since I don't own this card Best Regards, Thorsten.

Yes, you make it more difficult than it is! ;-) Since you are not sure about the electronic details, my suggestion is that you shouldn't try to left out any component of the core modules in order to avoid trouble. E.g., from the electrical point of view, there is no difference between a master and a slave core (or did I ever write something about this?) - once you've built the modules, you are free to experiment with the setup in order to find the perfect combination. Best Regards, Thorsten.