TK.

Hi Andrew, for MIDIbox FM, the same answer is valid like for MIDIbox SID: http://www.avishowtech.com/midibox/wiki/index.php/MIDIboxSIDFAQ#QA25 Best Regards, Thorsten.

Leider nicht... Gruss, Thorsten.

Did you ever check the patches/ directory of the sidv1.7303beta9 release, there are some premade TB303 sequences, just as an inspiration :) In difference to Prophet64, it's also possible to control an external filter with the internal envelopes, this makes the results even more interesting Best Regards, Thorsten.

Wenn Du diese Features nicht vermisst, brauchst Du sie nicht zu beachten ;-) Weitere Details findest Du irgendwo im Forum - leider haben die Leute, die diese Funktionen angefordert hatten, nie eine Dokumentation geschrieben. Gruss, Thorsten.

hierfuer ist leider keine 1-2-3 Loesung vorgesehen (weil es eigentlich ziemlich unueblich ist...). In Dscr.a51 muss man alle Datenbloecke, die mit *Ex2 und *Em2 Lables markiert sind rausnehmen, ausserdem muss an einigen Stellen (die ich nicht auswendig kenne) die Anzahl der "Pins" (Endpoints) aendern. Die Details kann man im midi10.pdf File nachlesen, das es irgendwo unter http://www.usb.org zum downloaden gibt. In Appendix B steht eine Beispielkonfiguration fuer ein 1x1 Interface, das Du eigentlich nur 1:1 abtippen musst... Gruss, Thorsten.

Sternfoermig, wie im Verschaltungsplan eingezeichnet: http://www.ucapps.de/mbhp/mbhp_4xsid_c64_psu_optimized.pdf !=! Gruss, Thorsten.

Ok, what I've seen so far: the note stack for osc1 is located at 0x15c-0x15f: 0150: 00 00 00 00 00 00 00 00 1E 00 00 00 1E 00 00 00 The first position of the stack contains "1E", which means, that note 1E = C-2 is played Unfortunately the logfile doesn't show a Note Off... ok, so let's assume that at this time the MIDI transfer was already stucked. Let's search for more informations... The MIDI In Buffer is located at 0x500-0x53f 0500: 00 00 7E 40 00 0D 02 00 00 00 00 06 00 00 00 00 0510: 00 00 F7 2F 35 B0 2F 35 B0 2F 35 B0 2F 35 B0 2F 0520: 35 B0 2F 35 B0 2F 35 B0 2F 34 B0 2F 34 B0 2F 34 0530: 80 24 00 90 1E 7F B0 2F 34 B0 2F 34 B0 2F 34 F0 The last received events before the SysEx Request (which begins at 0x53f) are: 80 24 00 90 1E 7F B0 2F 34 B0 2F 34 B0 2F 34 80 24 00: thats a note-off message for F#2 90 1E 7F: thats a note-on message for C-2 B0 2F 34: thats CC#47, Dec-Value 52 B0 2F 34: thats CC#47, Dec-Value 52 B0 2F 34: thats CC#47, Dec-Value 52 F0 ...: SysEx message (RAM read) begins here CC#47 (Resonance parameter) is a 4bit SID register, it's located at 0x117, bit 4-7: 0110: 00 08 00 00 F0 03 06 61 1F 0A 00 BC 9D 00 01 02 bit 4-7 of 0x117 is: 6 The 4-bit value of the received CC#52 is: 52 >> 3 = 6 In other words: the last MIDI events which were received by the MBSID are stored correctly. There is an active C-2 note, can you confirm this? Ok, lets search for the logfile entry where F#2/C-2 was sent, and thereafter 3 times a CC#47 with value 52: Hm... and here I have a problem: the last combination I found was: 497465 2 -- 128 42 0 1 F# 2 Note Off 497466 2 -- 144 36 127 1 C 2 Note On 497468 2 -- 176 47 110 1 --- Control Change 497474 2 -- 176 47 110 1 --- Control Cha CC#47 is 110, and not 52 So, I'm missing something in the logfile. Maybe this was also lost... (there is a character limit in the forum) but now you should know, which informations are interesting for me: the events at exactly the point where the note gets stucked However, another point: During the analysis I remembered that a friend has a similar problem with his M-Audio Delta1010 Soundcard/MIDI Interface. Once a lot of MIDI traffic is sent out, the interface stucks and he had to reboot his PC. I don't want to say that you've exactly the same problem (because of two things: you don't need to reboot your PC, and you are still able to send SysEx data)... but driver bugs are things which have to be considered. Therefore not only an updated logfile (which shows the interesting moment) could be useful, but also the results of a loopback test. You can do this in the following way: after the SID stucked, enable the MIDI merger via MIOS-Studio (select the MIOS_MIDI_MergerSet command and send WREG=0x01". Thereafter send some notes to the core module and check if they are received back. Do the same test after power-on of the module (doublechecking) If you don't receive any MIDI data back from the core module when MIDI merger is enabled, you know that your MIDI interface doesn't send any CC/Note values anymore Another point: it could be, that sending a SysEx message "resets" your MIDI interface. In this case following additional tests would be interesting: - enable MIDI merger via MIOS-Studio, thereafter try to get the MBSID stucking again, thereafter check if MBSID still returns the sent events (if not, you are very sure that Notes/CCs are not sent by the MIDI interface anymore) - once MBSID doesn't react anymore, send a SysEx message (e.g. MIDI Merger enable, or RAM read), and thereafter send a Note-Off event of the note which got stuck. If this works, then you know that a SysEx message resets your MIDI interface... in this case I would say, that it is definitely a bug in the driver of your interface Any new inputs? Best Regards, Thorsten.

Again: could you please create a RAM dump? This is a problem which cannot be reproduced on another hardware, therefore the MIDI data alone doesn't help, regardless how long the log file is... -> http://www.midibox.org/mios_studio/mios/gui/help/mios_debug_functions.html SRAM Read, Address 0x000, No. Bytes 0x600 Best Regards, Thorsten.

Thats a very uncritical timing, I've still no explanation. Even if your MIDI interface sends an invalid MIDI frame (e.g. due to a slightly different baudrate, or spikes on the transmission line), the PIC should regognize this, it should set an error flag, which thereafter should lead to a MIDI timeout in MIOS. Could you please try to reproduce this again? Thereafter use the RAM Readout function of MIOS Studio to dump out the RAM content from 0x000-0x600. Please also post the MIDI-Ox Logfile again. This should give me an overview of the system state, when this happens Best Regards, Thorsten. P.S.: your sequencer sends an "all notes off" (CC#123) when you stop it - thats bad for the MBSID, since CC#123 controls Parameter#3 of the wavetable sequencer. However, this is not the problem here... but maybe it's better to turn off (or filter out) this option to avoid interferences with the sound patch

Tja... README.txt Leser wissen mehr... Ja, fuer die PIC16F version ist noch der alte Schaltplan gueltig, also 1:1 Verbindung zwischen SID und CORE. Warum es bei Dir nicht tut? Weiss ich nicht, vielleicht falscher Quarz? MIDI time outs sind bei der uralten PIC16F Version normal, wenn zuviele MIDI Daten aufeinmal empfangen werden, dieses Problem konnte ich erst mit dem PIC18F loesen. Doch solange sich der Datenrate in massen haelt, gibt es eigentlich keine Probleme... Gruss, Thorsten.

Very strange, could you please post a mp3 sample? Best Regards, Thorsten.

Hallo, 1: ohne BankStick gibt es nur einen einzigen Patch, der im internen EEPROM gespeichert ist. Ich habe keine Funktion vorgesehen, diesen Patch vom Control Surface aus zu beschreiben, da die CS Version einfach mit einem BankStick betrieben werden sollte (er ist ja nicht teuer) 2: Ohne BankStick kannst Du jeweils nur einen Patch aus der Preset Library abspeichern, das geht entweder mit JSynthLib, oder mit TL's Patch Manager. 3: ja, der 24C256 reicht fuer 128 Patches, das Sub-D Gehaeuse ist nicht unbedingt notwendig, da man mittlerweile bis zu 8 BankSticks parallel einbauen, und vom CS aus selektieren kann (Achtung: Reichelt verkauft Atmel EEPROMs mit nur 2 Chip-Select Eingaengen, hier kann man nur 4 Chips parallel anschliessen) Gruss, Thorsten.

Hi Matthias, Which PIC feature do you mean exactly? The AIN latency is 200 uS * number of analog channels --- with the MIOS_AIN_DynamicPrioSet feature the latency of the "last changed" inputs can be reduced (but this is only useful for MIDI controllers) You can reduce the latency a lot, when analog channels are not converted timer interrupt driven with low priority (like handled by MIOS), but directly from your main task. The DIN latency is specified with the MIOS_SRIO_UpdateFrqSet function, by default it's 1 mS -> 1 kHz (I guess this meets your requirements ;-) Best Regards, Thorsten.

thats a 6581 typical problem, see also http://www.midibox.org/forum/index.php?topic=5373.0 So, it seems that Kokoon is currently the only one who notice such problems... There is only one scenario where the SID oscillator can lock up, and this happens when noise is selected together with another waveforms. But this illegal mode is prevented by the MBSID firmware, and I'm very very sure that it cannot happen (I'm doing SID sound design very often, I should notify such errors...) A sound sample and the MIDI input trace (via MIDI-Ox) could be interesting. Are you able to reproduce this problem with one of the default patches, or did you create a special patch? Best Regards, Thorsten. P.S.: I will be quite busy in the next weeks, therefore please forgive the high delays between the answers...

Thats a very fair price for such a PSU, which is not only interesting for MBFM users - therefore I move this article to the parts archive Best Regards, Thorsten.

In general you could connect the lower 9V block to the 7805 input, and the combined 18V output to the SID module. Due to the diode bridge, the 7805 will get 9V-2*0.7V = 7.6V, thats perfectly - the 7805 shouldn't get hot with this voltage. Best Regards, Thorsten.

There are a lot of threads about this SID typical issue, it's really a FAQ! At least you can read something about this in the interview with Bob Yannes: http://stud4.tuwien.ac.at/~e9426444/yannes.html There are some 6581 with less noise, but it's hard to identify them - you have to try it out. The issue doesn't exist on the 8580 Best Regards, Thorsten.

Warum oeffnest Du einen neuen Thread? Wuerde es die Uebersicht im Forum nicht erleichtern, wenn Du solche Server-Fragen an einen Thread anhaengen wuerdest, der noch nicht mal ein Tag alt ist? -> http://www.midibox.org/forum/index.php?topic=5343.0 midibox.org ist nun komplett auf den neuen Server umgezogen. Dieser erlaubt leider nicht alles, was frueher moeglich war. Underscores im Subdomainnamen sind bspw. nicht moeglich. Deshalb heisst die neue Seite: miosstudio.midibox.org Gruss, Thorsten.

Yes, JSynthLib works with SysEx... the SID chip shouldn't cause such a problem, because there is no feedback to the core. Means: regardless if a SID is connected or not, the application should never freeze. I've really no idea what should cause such a scenario, just let me some days, maybe I will be able to reproduce this sooner or later... if anybody else but kokoon and pwx is able to stimulate the hang-up, please let me know. Best Regards, Thorsten.

fixed. Gruss, Thorsten.

I wasn't able to reproduce the error yet, maybe it only happens at certain patches? Which patch are you using exactly? Best Regards, Thorsten.

Cool! I haven't expected such an error, I will improve the schematic Best Regards, Thorsten.

Hi Davo, the schematics are free for non-commercial use Best Regards, Thorsten.

Hi Corey, these are interesting questions for a FAQ (FARMARKER) Detuning: OPL3 only supports predefined multiply factors, thats the only way to "detune" the oscillators... I understand under detuning those slight frequency differences between the OPs which could make the results even more interesting (especially for Fx sounds) The drum channel has its own voices, they are handled independently from the instruments Multitimbral: there are 4 instruments and 6 voices, the voices are allocated dynamically. This means, if all 4 instruments are in mono mode, only 4 voices are allocated, 2 are unusued. If one or more instruments in poly mode, they will share the voices (the longest played voice will be dropped first) CC: yes, absolutely live with immediate update on LCD - this feature was one of my main focus Parameters: yes, all are editable via CC. Only difference to SysEx is, that CC listens on a specific MIDI channel. This can cause a problem once two instruments are assigned to the same MIDI channel, you won't be able to edit them seperately. Have fun :) Best Regards, Thorsten.

12.3V is within the allowed voltage range I just got the idea that something else could cause such a problem: the oscillator. The SID won't generate any sound so long no clock is running. Is your module stuffed with an integrated oscillator? Then check the connections around there (it's impossible to measure the frequency without a scope). You could also try to clock the SID from the PIC like described at the MBHP_SID page --- note that the oscillator has to be removed in this case Best Regards, Thorsten.