TK.

Such effect can happen when there is a problem with the MIDI connections to the PC, the PC MIDI Interface or the MIDI driver - e.g., I can reproduce this with a 10 m USB cable enhancement (out-of-spec) to a MIDIsport 2x2 interface - code uploads are not reliable in this case, and MIOS Studio shows errors - this is correct, problem is not MIOS or MIOS Studio here, but the unsteady transfers to the core. So, did MIOS Studio report an error during the upload? However, as Sebo has mentioned, you can revive the core by uploading the application via 1st level bootloader (MIOS itself propably doesn't need to be uploaded again) Best Regards, Thorsten.

Just to ensure (I'm not sure if there is a misunderstanding of the circuit, or something else...): which voltage do you measure at J1 of the core module? Best Regards, Thorsten.

Changing the CC value there means, that you would also have to adapt the assignment in the SysEx table... I think it's easier just to send an additional CC from the appr. button handler in cs_menu_buttons.inc Best Regards, Thorsten.

Hallo Andreas, yep - kann man auch auschalten. Entweder in main.asm, oder per Tastendruck. Die Details stehen im ChangeLog Nein, MIOS Studio kann keine IDs aendern. Du koenntest im Notfall die ID mit der change_id Applikation abaendern, oder vor dem Brennen die ID im .hex File patchen - dabei muss die Checksumme angepasst werden. Hierfuer habe ich irgendwo ein paar Beispiele gepostet, doch ich kann sie gerade nicht finden... :-/ Gruss, Thorsten.

Can you send me your .ini and .syx file? I will try this out on my own box - but propably I won't find the time before this weekend (too much other things to do in parallel...) Best Regards, Thorsten.

You can be sure, that I don't understand this as critism! :) But I know, that it isn't done with putting just an additional comment to a line of code (how big is your screen?), it is still useless for people who don't know the whole programming concept, who don't know how to read assembly code, and which programming rules I'm using in my code. Let's go back to the CS_SID_VOICEx_FINETUNE example: as you can see in this line: ;; Function name parameter menu offset cursor pos CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_FINETUNE, CS_MENU_OSC, 0x09, 0x0a [/code] (do you see, how many comments I would already have to add to this single line?) it's a parameter number. And these numbers are defined in app_defines.h - where you can find the hint: [code] ;; offsets to registers (we are using the same like for the presets (sid_presets.inc), ;; so that SID_SYSEX_TABLE can be reused so, you are addressing registers with these parameter numbers, registers which hold the sound parameters. The same parameters are also part of a patch, and which are stored in a SysEx structure. For a newbie this might lead to following questions: - what is a parameter? - what is the difference between a register and a parameter? - what is a SysEx structure - what is finetune? - what does the VOICEx mean here? - what is a voice? - what is the difference between a voice and an oscillator, if any? - and what the heck is the purpose of all the other constants and function names in this single line: ;; Function name parameter menu offset cursor pos CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_FINETUNE, CS_MENU_OSC, 0x09, 0x0a [/code] So, hope you see the desaster. "adding some more comments" is no real solution. I think that it would more help, if somebody would describe in his own words, how he did the modifications, where he found the informations, etc... It could also be required to describe, how a synthesizer is working, what for example "finetune" means...? Finding out all the details might take some weeks, regardless if I'm giving even more hints or not. There is definitely no 1-2-3 way for CS modifications, and I hope that - in distance to others - you are writing down all your findings in the Wiki MIOS is a text adventure... Best Regards, Thorsten.

nein, Du kannst ihn nicht komplett ersetzen. Man kann lediglich CCs intern generieren. Probiere es erstmal mit den Encodern aus, MIOS bietet eine Accelerator Funktion! Diese ist uebrigens nicht fuer das "Datawheel" (also dem zum Menu gehoerigen Encoder) aktiviert, weil man hier eher feine Einstellungen vornimmt. Die restlichen Encoder beschleunigen automatisch. Bedeutet: langsames drehen - langsamer sweep. Schnelles drehen (eine Handdrehung), sweep ueber den gesamten Wertebereich - man gewoehnt sich dran. ja, wenn Du den Programmcode in die Applikation (MIDIbox SID) einbaust, der die Poti-Werte weiterverarbeitet Es gibt weder 9 Eingaenge (sondern 8 ), nocih eine Bruecke. Vielleicht hast Du dieses Dokument uebersehen: http://www.ucapps.de/mbhp/auaimbctg.pdf Vielleicht kann auch jemand anderes nochmal ein paar Anfaengertips geben (habe gerade wenig Zeit...) Gruss, Thorsten.

Hallo Andreas, die Power LED sollte immer leuchten, VPP und VDD LED leuchten zufaellig - entweder sind sie an oder aus - solange der Druckerport noch nicht initialisiert wurde. Das passiert erst, wenn P18 gestartet wurde - beim Programmstart sollten beide LEDs ausgehen. Miss doch einfach mal direkt am LPT Port, wenn Du die einzelnen Pins von der P18 aus unter Hardware->Options umschaltest. Die Pinbelegung befindet sich im MBHP Burner Schaltplan. Gruss, Thorsten.

Hi, MK_SET_OBJ clears the object list and creates a new one. MK_ADD_OBJ adds objects to the current list. It's just a preparation for an unimplemented feature, which would allow to build multiple .hex files with different objects with a single "make" run. Best Regards, Thorsten.

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.