TK.

I've created a short but useful perl script which can be used to generate an unlimited number of random patches. This script and 32 example banks (-> 4096 Patches) are now part of the preset library. -> http://www.ucapps.de/midibox_sid/preset_patches_20050123.zip (400k) Here some randomly picked random patches from a randomly selected bank (20) -> http://69.56.171.55/~midibox/midibox_sid/mbsid_demo_random_patches.mp3 (7.1 MB) (mostly the note C-3 is played, only in one case I've played a short tune (couldn't resist)) The perl script can be found in the random/ directory, so that you can create even more patches. Experts should try to change the constraints in order to have some more directive results. 4 Patches of js are now also part of the library Have fun! :) Best Regards, Thorsten.

Just gone through the synth-diy mailings, now it's clear what you mean with "SynthDIY Soddy" - I mixed it with "shoddy" ;-) Best Regards, Thorsten.

*grin* just compare the number of code lines against the number of bugs ;-) The only thing which makes me worry each time is that now we will notice an increased number of postings where people assume software bugs before they start to check their hardware. From my experience it will take 3-4 months until MIOS applications have reached the known confidence level again ;-) There are too much favourite MBs in the different categories, but last year no MIDIbox reached the originality of PulseBox16 (for the guys who don't remember the best design ever, here the design: http://homepage.ntlworld.com/keith.williamson/pb16--ad.jpg and here what the press said: http://homepage.ntlworld.com/keith.williamson/ecobox/images/midibox_mag.jpg) Best Regards, Thorsten.

Hi, 1) setup_mbseq_v2.asm: change MIOS_ENC_MODE_DETENTED to MIOS_ENC_MODE_DETENTED2 (this will be the default setting in the next release) 2) there is a known problem with such artifacts (see the (short) buglist), but they don't happen like described. This could be related to a problem with the DINs 3) use the MIDIO128 application (buttons send one note event, encoders send two note events) 4) bad solderings 5) bad solderings Best Regards, Thorsten.

Hallo Stefan, Du hast das Speicherlimit erreicht. Mehr passt nicht mehr in den PIC (woher kenne ich das Problem nur... ;-)) Ich habe vor ein paar Wochen ein paar neue Funktionen in die MB64E Applikation eingebaut (u.a. den sogenannten Patch Mode), in dieser Version wird es nicht mehr moeglich sein, die Parameter-Labels im internen Memory zu speichern. Das funktioniert dann nur noch mit BankStick - dadurch konnte ich nochmal 8k freimachen, die wahrscheinlich auch Dir sehr hilfreich sein werden. Eine Beta Release gibt es via EMail-Request Gruss, Thorsten.

Hallo, hier ist alles beschrieben: http://69.56.171.55/~midibox/forum/index.php?topic=3693.0 die aeltere SDCC Version werde ich heute Abend noch auf den neuen Server aufladen. Die aktuelle SDCC release ist immer noch ziemlich buggy (sporatische Abstuerze unter Windows), aber die Entwickler arbeiten dran Gruss, Thorsten.

Hi Dominik, it is possible by writing an own display driver (-> app_lcd.inc) and connecting the chip select lines to some free pins. It requires ca. one day of programming work when you know where the changes have to be made. If you've never implemented a driver for a graphical display before, it can take much longer... Best Regards, Thorsten.

Hi Dominik, you can add this additional LED for each meter by changing the pattern table in lc_meters.inc. The anodes of these LEDs have to be connected to a free pin of the second shift register which is used by Meters/LEDrings. So long you don't want to change the DOUT pin for the overdrive LEDs (currently D4), you could change the pattern in the following way: ;; 16 entries for meter pattern (can be changed if more LEDs connected) ;; note: the 12th LED (overdrive) will be inserted automatically in LC_METERS_PatternSet dw b'0000000000000000' dw b'0000000000000001' dw b'0000000000000011' dw b'0000000000000111' dw b'0000000000001111' dw b'0000000000011111' dw b'0000000000111111' dw b'0000000001111111' dw b'0000000011111111' dw b'0000000111111111' dw b'0000001111111111' dw b'0000011111111111' dw b'0001011111111111' dw b'0001011111111111' dw b'0001011111111111' dw b'0001011111111111' [/code] In this case the 12th LED has to be connected to D3 of the second shift register Best Regards, Thorsten.

The resolution shouldn't be a problem, the timing conditions are very relaxed in your code. Maybe I will find some time tomorrow to try this out. Best Regards, Thorsten.

Hi mb944, what a fancy project! :) I just have tested MIDIO128 on my MIDIbox SEQ and noticed exactly the same behaviour. This shocked me a little, because I don't remember that this problem occured during the implementation of the last changes. After some debugging I finally found out that in app_defines.inc the "MB_STAT_FETCH_DIN_REQ" flag is assigned to the same bit like "MB_STAT_DISPLAY_UPDATE_REQ" (a totally unexpected error) and this causes the flickering. So, when you change this flag to 1 and recompile the code, it will work. It will also work when you set the "DEFAULT_FORWARD_IO" option to 0 in main.asm (you have to do this anyhow), thats possibly the reason why there were no complaints about this error in the past, because most people don't use the forwarding option, this is only for testing the DINs/DOUTs Ok, and I found out why I never saw this problem: it was one of the last changes which I've tested on my MIDIbox LC which has a graphical display. Since characters are printed out slower than on a common LCD, the possibility that the wrong bit assignment affects the DOUT is much lower Best Regards, Thorsten.

Hi Robin, the 4byte jumptable macro is only required if you are using 32-bit instructions like "goto". So long you are using "rgoto" (an instruction which allocates 16-bit=2 bytes), the JUMPTABLE_2BYTES macro is sufficient. Please use JUMPTABLE_2BYTES (number-of-entries) instead of JUMPTABLE_2BYTES_UNSECURE (like the the firmware), otherwise you have to take care that the jumptable index never exceeds the table In "midio_presets.inc" you will find the "MIDIO_Presets_DIN_MODES" label, thereafter some table entries for the modes. Note that the mode is encoded in a special form (to save memory). Each hex-digit stands for one DIN pin, this means that up to 16 modes (0..F) are possible Best Regards, Thorsten.

Hi oszilla, 1000 different things... it's time to test your modules step by step. First I would suggest the upload of another application which simplifies the debugging Start with the MIDImon to check the MIDI input Thereafter use MIDIO128 to check the DIN/DOUT Results? Best Regards, Thorsten.

Hi Twin-X (my hero!) maybe "random patches" sounds like a feature which is easy to implement. But in fact a real useful random generator requires a lot of programming effort - and - a sophisticated user interface. Because you don't really want to have everything random, this would lead in most (99%) cases to unusuable patches, and/or to settings where you don't hear anything. A good random generator allows to set constraints for each parameter (min/max values), an even better generator allows dependencies ("if LFO5 depth > 30 then LFO6 depth < 30"). I fear that there is not enough memory free for such a function, it's possibly better (and much much easier) to program this as an external program (for the PC, with a nice GUI, etc...) Best Regards, Thorsten.

You've checked the voltages long time ago, but are you sure that each connection is still in place? I mean: sometimes people don't solder all components/cables well enough, bad junctions can cause random effects. You wrote that you got the correct messages through MIDI during the MIOS/application upload. But now you don't get any MIDI message on startup anymore, is this correct? Could it be that the bad junctions are around the oscillator, or the MIDI Out Port? The MIDI troubleshooting guide helps you to analyze such problems: http://www.ucapps.de/howto_debug_midi.html Best Regards, Thorsten.

Yes, the transistor should be sufficient (it's a similar circuit like in the original C64 design). I don't know why an OP amp should be better in this case, maybe it's better to contact Buchi directly in order to get an sufficient answer Best Regards, Thorsten.

This is exactly the way how I would do it :) Best Regards, Thorsten.

I'm also not completely satisfied with the layout and still searching for all the new switches and levers ;-) Best Regards, Thorsten.

Thanx to Twin-X we have the possibility to test a new server -- which is very fast! :) I've installed a temporary forum so that we can test the connection from different locations: --> http://forum_test.midibox.org I've also uploaded some .mp3's to test the bandwidth, the maximum download speed I've reached was 124 kb/s (this is the limit of my ADSL line) --> http://69.56.171.55/~midibox/midibox_fm/mbfm_demo1.mp3 --> http://69.56.171.55/~midibox/midibox_fm/mbfm_demo2.mp3 --> http://69.56.171.55/~midibox/midibox_fm/mbfm_demo4.mp3 --> http://69.56.171.55/~midibox/midibox_fm/mbfm_demo5.mp3 Please write down your impressions here. If the server is working ok, I will move the original forum to the new location this weekend. Best Regards, Thorsten.

Great! :) Best Regards, Thorsten.

USER_DIN_NotifyToggle can be found in main.asm To the other problem: here is the explanation: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=troubleshooting;action=display;num=1094414018;start=1#1 Best Regards, Thorsten.

Hi, I also don't like those synths with a deep hierarchical menu structure, where you have to click-click-click through thousands of menues. But for MBFM (and MBSID) it's a different situation: there is only a small number of menus (well sorted), and it provides a lot of special function buttons (for MBFM e.g. 4 instrument select/OP select + 24 menu view buttons + one sortcut button + 8 softbuttons) for quick access to all parameters. Best Regards, Thorsten.

Hallo, ich kenne leider keine Buecher, die einen direkten Einstieg ermoeglichen. Es gibt Buecher ueber die PIC Programmierung (siehe MIDIbox Wiki), doch die alleine werden nicht weiterhelfen, und im Endeffekt sind vielleicht 10% des Inhalts wirklich fuer Dich relevant. Ich wuerde folgendes empfehlen: versuche es erstmal mit C (siehe Infos zum C Wrapper im MIOS Programming Board), so kannst Du erstmal mit den Hooks fuer Display/MIDI-Ausgabe und Button/Encoder/Poti-Eingabe herumspielen. Dies sollte es Dir ermoeglichen, die Zusammenhaenge zwischen dem Betriebssystem und der Applikation "spielend" zu erlernen. Wenn C irgendwann einmal langweilig werden sollte, koenntest Du Dir unter http://www.piclist.com die Assembler Tutorials anschauen. Gruss, Thorsten.

Nobody can tell me that Twin-X's offer doesn't sound attractive! :-) I'm just starting to upload a test version of the forum to his server. Once it is accessible for everybody, I will shutdown the current site and transfer everything to the new location, so that it is possible to test it for one week or so. If everything runs smooth, midibox.org will switch completely to Twin-X's server Best Regards, Thorsten.

ready for sending your ears into sound heaven :) Best Regards, Thorsten.

Hi, you could assign these buttons to the appr. special functions (a list can be found here: http://www.ucapps.de/midibox/midibox64_sfb_table.txt) But this has to be done in each bank. Ok, or you could call the MB64_SFB_Handler_02 function from MIOS_DIN_NotifyToggle, but this requires some additional code. I cannot provide working code for this solution before this weekend, so maybe it's better when you are using the already existing possibilities. Best Regards, Thorsten.