TK.

For the oscillator button, this behaviour has to be explicitely activated. I use the "faster handling" (one 1--, -2-, -3-) instead, and when I want to change multiple OSCs at the same time, I just click on the appr. "general purpose" button in the menu section (which shows the OSC selection as well), and change the desired combination there. This behaviour can be changed in main.asm: ;; if 0: OSC button selects also combined modes (7 states, combined OSCs) ;; if 1: OSC button selects only one of three OSCs (faster handling) #define CS_MENU_OSC_BUTTON_BEHAVIOUR 1 [/code] I hope it's acceptable from your side, when I cannot help that much here. I've already a very reduced sparetime to continue with my MIDIbox projects, and each moment I find some time, I've to decide "should I reply some emails", "should I help some people in the forum", "should I continue with any documention", or just "can I continue with programming something new?" - what would you prefer? It has also to be considered, that writing a really understandable documentation takes 2..4 times longer than just hacking the code. I really know, that for some people it's difficult to understand the whole programming concept since many parts are scattered over different .inc files - on the other side, this is the only possibility for myself to reach such a complexity and variability. So, I think that your question was just because you didn't thought about how much effort a sufficient answer produces at my side. Therefore I give you just the hint: open the main.lst file, which contains the whole assembled code and search for some keywords there (this file is only available when you've started the assembler by yourself, it is deleted on release packages). And if you want to help the community by yourself, document your findings in the Wiki. Another point I want to highlight: writing a complete documentation means for me, that I have to take care that I don't change conceptional thinks too much anymore, because this would either require to write a second documentation about the new implementation, or that the old one is expired, and no new one is available (-> wasted effort) I see this as a inhibition threshold for implementing anything new. E.g. the CS handler like it is currently implemented in MBSID was very different in older releases, I changed most of the functions in order to make it faster, and to reduce the memory consumption. I'm planning a redesign again for MBSID V2 And this is by the way the next point: what happens, if I decide to make a certain button or LED of the control surface more important than it currently is? Do I need to take care for all the variations which could be created in future by different people (variations, which I could never try out by myself), or do I have the freedom to change like I (and most other users) find it optimal? Just my thoughts... hope that this also makes it more understandable, why - in the meantime (it was different 4 or 5 years ago), I really cannot give detailed answers on any questions, regardless if they are interesting for multiple people, or only for a single guy... At the end I think, that the community has to push the documentation forward without much help from my side. Everything else is additional effort at my side for a small number of people. It prevents me to continue with new stuff which makes myself and many other people happy. Best Regards, Thorsten.

This nice MIDIbox SEQ has been tinkered by MTE :) He wrote (in german)

Hallo Andreas, der Sache sollten wir nochmal nachgehen, evtl. befindet sich das System nun in einen unerlaubten (um nicht zu sagen "gefaehrlichen") zustand. Wenn der CRC Test schieflaeuft, bedeutet dies, dass der Upload von update_with_old_mios.hex aus irgendwelchen Gruenden nicht komplett war. Hat MIOS Studio einen Fehler angezeigt? Dann paste die Logmeldungen einfach mal ins Forum. Nur wenn die Checksumme korrekt ist, wird der neue Bootloader installiert. Wenn Du MIOS V1.9 und die Applikation ohne den neuen Bootloader aufspielst (was eigentlich nicht funktioniert, da Bloecke zwischen 0x7c00-0x7fff nicht angenommen werden), koennte es passieren, dass unvollstaendiger Code ausgefuehrt wird. Und im Worst Case wird dann auch noch alte Bootloader ueberschrieben, so dass gar nichts mehr funktioniert. Lade doch bitte nochmal das "update_with_old_mios.hex" File auf - wird immer noch ein ungueltiger CRC angezeigt? Gruss, Thorsten.

The button cycles through following filter type combinations: dw "L-- " dw "-B- " dw "LB- " dw "--H " dw "L-H " dw "-BH " dw "LBH " Best Regards, Thorsten.

Hi Trent, 1) there are different ways for disabling this "internal feedback". The easiest is the use of the mk_midio128_syx script, which creates a new configuration. So, just open the default midio128.ini file, search for these lines: ################################################################################ # Forward Input to Output # If Enabled: if an inputs gets an raising or falling edge, the appr. output # pin will be set to the same new logic level. The output pin # can be controlled via MIDI also # If Disabled: an output pin can only controlled via MIDI # Default: disabled ################################################################################ [FORWARD_INPUT_TO_OUTPUT] enabled [/code] and set the switch to "disabled" An alternative way is to change this in the firmware, and to build a new .hex file. Changes have to be made in main.asm: [code] ; Forward Input to Output ; If 0: if an inputs gets an raising or falling edge, the appr. output ; pin will be set to the same new logic level. The output pin ; can be controlled via MIDI also ; If 1: an output pin can only controlled via MIDI #define DEFAULT_FORWARD_IO 1 2) are you able to control the LEDs by sending Note messages with another tool. E.g., with MIDI-Ox? Great to hear, that the rest is working :) Best Regards, Thorsten.

I think, that the 22nF cap values have been choosen, since they are the best compromise for covering the whole LP/HP/BP frequency range. I will propably stuff two of my 8580 SID modules with 47nF caps in future, and integrate a switch into the firmware which does take this into account in 303 mode. Currently only the first quarter of the cutoff frequency value is used in 303 mode, but in the alternative version, the firmware could access the upper half (or 3/4 of the upper range) instead, which results into the best utilisation of the available filter resolution. Best Regards, Thorsten.

no, you haven't missed them - there are no MP3's yet - maybe somebody could add a nice documentation about the usage of different cap values into the Wiki? :) Best Regards, Thorsten.

Instead of adjustable caps, I just have mounted a pinhole header on my SID module which allows quick exchange: Best Regards, Thorsten.

What these buttons are doing does heavily depend on the host sequencer, because the MIDIbox LC itself is "stupid" - it sends a Note event when a button is pressed/released, and it sets/clears a LED when a Note event is received from the host. Same for the LCD (display messages are sent by the host) and for the motorfaders/encoders. So, you will find a detailed description of these functions in the manual of your sequencer. If not, then it propably doesn't support it, or assigns another (mostly useful) function to the button. Best Regards, Thorsten.

In diesem Fall kamen die Noten vom internen Sequencer, welcher per MIDI Clock mit Logic synchronisiert wurde Siehe auch http://www.ucapps.de/howto_sid_bassline.html Gruss, Thorsten.

P.S.: schau Dir mal dieses Video an, hier werden die Encoder/Endlosregler mehrmals bewegt ;-) http://www.midibox.org/videos/mbsid_bassline_session.avi Gruss, Thorsten.

if there is no commented or undocumented restriction: yes (it should, but who can guarantee this without testing... ;-)) yes, this shouldn't affect the behaviour. Here a video of a short SID session. It's far from a perfect live performance, especially because there was this tripod of my digicam before my face, I wasn't able to handle the interface like I'm normaly doing... :-/ -> http://www.midibox.org/videos/mbsid_bassline_session.avi (15 MB) Best Regards, Thorsten.

Hi Thomas, here are the detailed troubleshooting instructions: -> http://www.midibox.org/dokuwiki/doku.php?id=din_module Best Regards, Thorsten.

Here short 200k video about the SID buttons which (hopefully) says more than 1000 words... ;-) http://www.midibox.org/videos/mbsid_cs_sidbuttons.avi Best Regards, Thorsten.

If most people are thinking, that the 22 nF works better (for myself it doesn't really matter, I'm happy with both), I will change my own 8580 preset sounds accordingly. yes, I can consider this: * the information, which SID and caps have been used should be stored in the patch. SIDs: 0=6581, 1=6582, 2=8580, 3=FPGA; caps: 0=470pF, 1=1nF, 2=2.2nF, 3=4.7nF, 4=6.8nF, 5=10nF, 6=22nF, 7=47nF, 8=100nF[/code] Best Regards, Thorsten.

Thanks to the effort I put into MIOS and the bootloader, the applications itself are software compatible! :) So, just use the precompiled bootloader and MIOS versions for the PIC18F4620, select the IIC_MIDI interface in the PIC ID header, and it will work Best Regards, Thorsten.

Hallo, zu 1) weil bei Conrad das 100ter Tuetchen 10k Widerstaende 1.33 EUR kostet, und ein zusaetzliches 100ter Tuetchen 20k nochmals 1.33 EUR kosten wuerde? Weiss nicht. Vielleicht aber auch nur, weil es einfacher ist, passende 10k Widerstaende zu selektieren, als aufeinander abgestimmte 10k/20k Widerstaende Wenn die Widerstaende von der gleichen Charge kommen, ist die Wahrscheinlichkeit hoeher, dass ihre Werte identisch sind - da muss man dann auch eigentlich nicht mehr nachmessen. zu 2) nicht mein Gebiet, aber andere Freaks koennen sicherlich mehr zu dem Thema beitragen. :) Gruss, Thorsten.

you will see it when you are trying it out on your MBSID. Since software can be changed and uploaded very fast, I think that there is no real need to doublecheck this (I don't know this part of the firmware so well anymore, it's three years ago where I programmed this...) no, when you hold SID1, and press SID2 at the same time, you will select both and can edit both. The link button just only opens the MIDI gate to the slave SIDs (disabled by default to avoid feedback loops with your sequencer software, if MIDI loopback is enabled there as well) Yes, changes will be made to all selected OSCs and all selected SIDs. E.g., if you select all 4 SIDs, and all 3 OSCs, and change the portamento parameter, you will do this change on all 12 oscillators at the same time. This is a very important feature for polyphonic sounds, therefore I implemented this yes, modifying two ENVs at the same time hasn't been implemented For the LFOs it is not possible as well. Maybe I can add this possibility into MBSID V2 (such changes have to be done considered at the beginning, it's too difficult to do this later) Best Regards, Thorsten.

Congratulations to France for the great match yesterday against Brasilia! Hope to see you in the final :) Best Regards, Thorsten.

Yes, you should at least get random MIDI events when you touch your finger on these ungrounded pins. This is a very basic function, there is no reason why the analog pins shouldn't work (assumed that you haven't changed the firmware). Could it be, that you've destroyed the analog stages inside the PIC during some experiments? Best Regards, Thorsten.

MBSID is not a C application, therefore I've moved the article to the right section. In general you can get some useful tips in these articles, because there are users who did customizations before. Although these are no specific examples for your purposes, I think that they should give you enough input to understand, where changes have to be made... It would be great, if you could write a summary in the Wiki, because this is a frequently asked question, I spent the effort to explain this in the past, but I'm tired to do this again and again... http://www.midibox.org/forum/index.php?topic=6387.0 http://www.midibox.org/forum/index.php?topic=5039.0 http://www.midibox.org/forum/index.php?topic=5020.0 http://www.midibox.org/forum/index.php?topic=3655.0 http://www.midibox.org/forum/index.php?topic=5261.0 http://www.midibox.org/forum/index.php?topic=4198.0 http://www.midibox.org/forum/index.php?topic=4948.0 http://www.midibox.org/forum/index.php?topic=6674.0 http://www.midibox.org/forum/index.php?topic=7084.0 http://www.midibox.org/forum/index.php?topic=3925.0 http://www.midibox.org/forum/index.php?topic=6252.0 http://www.midibox.org/forum/index.php?topic=3642.0 http://www.midibox.org/forum/index.php?topic=1212.0 Best Regards, Thorsten.

Here the test results: 8580: - first impression was, that the sounds are more crispy with 6.8 nF caps - but this only depends on the filter envelope settings which are used. If the envelope depth is slightly increased when 22nF caps are stuffed, then you will get identical results - from the mathematical point of view, this behaviour makes sense. - I tried 100 nF caps, and the result is, that between 0..20 CutOff frequency (the "stepiness range") you won't hear any sound, and that within 21..127 the cutoff can be controlled with absolutely best resolution (-> no stepiness) - with 100 nF caps, it is not possible to set the cutoff frequency so high, that the filter has no effect... on the other hand: this is no problem if you want to play bass sounds. E.g., also the original TB303 doesn't allow to open the filter completely (if you want to take this old gear as reference... ;-)) 6582: - I don't really hear a big difference to the 8580, considered that e.g. on a filter sweep via envelope, the depth has to be adapted to get the same "crispiness" So: are 100 nF better for your purposes, or 47 nF, or 22 nF as a compromise (still filter stepiness in the low range, but filter can be completely opened) - or does it make sense to add a manual switch for different sets of caps? ;-) Best Regards, Thorsten.

Ja, dies ist sogar die empfohlene Loesung Gruss, Thorsten.

What happens, when you remove the 4051 and connect a pot input (e.g. AIN::J1:A0) directly with a Mux output (AIN::J5:A0) - if this doesn't behave like if you connect the pot directly to CORE::J5:A0, you know, that there is a problem with your PCB Best Regards, Thorsten.

The reason why the caps are not specified like in the original schematic is, that at the time where I created the MBHP_SID module (4 years ago) it was assumed that each SID needs different caps anyhow and the best specific values have to be found out by the user due to the variance between the revisions. Nowadays we know, that this mainly is true for the 6581, but not for the 6582 and 8580. Due to the fact, that at this time the 8580 filter was controlled with the same curve like the 6581, the 6.8nF value which can be found in the 6582 datasheet was more advantegous. After I changed the control curve based on the Razmo's great (!) suggestion (see his detailed description above), I never spent so much attention on testing different caps again. Ok, to end this thread I've just tested my 8580 with 22nF caps. As mentioned several times before by other people, the cutoff frequency goes deeper, this has the advantage, that in between the typical frequency range where the resonance plays a role when bass notes are played, there is less stepiness than with 6.8nF caps. I've tested some sounds which are using bandpass and highpass as well, and don't hear any restrictions in the sounds So - are 22nF caps really better, what are your oppinions? For the 6581 I still believe, that the 470pF caps (taken from the original C64 schematic) are better. For the 6582 I will test this now (thanks to Wilba for providing me two of these chips! :)) Best Regards, Thorsten.