TK.

Just to be sure: did you already test the encoder and DINX4 module connections? Details can be found here: http://www.midibox.org/dokuwiki/doku.php?id=din_module Best Regards, Thorsten.

Yes, thats it! Please: add this description to the Wiki (http://www.midibox.org/dokuwiki/doku.php?id=mios_details_ain_deadband) so that it won't get lost, it's really good and could be enhanced later if required. Best Regards, Thorsten.

Controlling CutOff and Resonance with analog pots is not natively supported by the firmware, has anybody written a GOOD documented extension in the meantime? I don't think that an AIN module is required, so long not more than 8 pots are connected to the core. 300 mA sounds a little bit weak if the LCD has a backlight, a 500 mA PSU would do better. Best Regards, Thorsten.

This is the intention of the Wiki - instead of buring the informations in the forum, they should be collected there. But this is a long process, and it especially relies on the contribution of the users. The target is, to have ucapps.de as some kind of "reference manual", which describes things in a compact and exact form, and the Wiki as "user manual", which describes things more detailed for non technical experts. Therefore I asked you for help (please read my posting again) You are now going to understand the Deadband feature, so once you know how it is working, why not writing down a report at http://www.midibox.org/dokuwiki/doku.php?id=mios_details_ain_deadband, so that next time it will be easier for other people to get into this topic? Best Regards, Thorsten.

You have replaced the 1.2k by a 100 Ohm resistor? This cannot work, and this is propably the reason for the failure... if the MIDIbox is directly connected to a gameport, you can also left out 1.2k, or (better) you can replace it by a 10k or higher in order to avoid that the MIDIbox will receive random (and invalid) MIDI events when it is not connected to your PC Best Regards, Thorsten.

You can only mute a group of 3 voices Drum mode is a real tinkering solution, my target was to bring this into the firmware with as less code changes as possible (I don't use it by myself, it was requested by hallucinogen), and with no panel changes... Best Regards, Thorsten.

Short hint: if you want to control more gates and low resolution CV outs, all you need to change is the MIDI_EVNT_Send_Fx function in midi_evnt.inc Best Regards, Thorsten.

The upload request already notifies a reset. If multiple requests are sent, then due to a watchdog timer reset - this reset happens on a timeout (e.g. no SysEx code received, or MIOS not uploaded). It doesn't make much sense to add more variations here, it wouldn't give you any useful information, it would only increase the complexity. So far I know, the "Received unexpected Upload Request" message can only happen in two cases: 1) the core doesn't receive a SysEx block with command 02 (Write), therefore a watchdog reset will happen 2) you are sending the code with a different device ID number - your core has device ID 00 (therefore I asked for the MIDI In dump, it shows me the number), is the same number selected in the upload window? I don't know other cases for such a behaviour Best Regards, Thorsten.

SysEx messages can be sent with MIDIbox64 and MIDIbox64E by using "Meta Events", but this requires that you are doing (simple) enhancements in the application. An programming example for SysEx can be found in mb64_meta.inc/mb64e_meta.inc within the source code packages In addition it makes sense to run the applications in patch mode, some infos can be found here http://www.midibox.org/dokuwiki/doku.php?id=midibox64_e_patchmode Best Regards, Thorsten.

yes, you are right, MBSEQ neither supports the AOUT_LC module, nor more than 4 triggers when the normal AOUT module is used. I just have added this request to the MBSEQ V3 wishlist Supporting more than 4 gates will require some programming effort at my side, since gates are currently handled channel based, and not note based. If somebody wants to implement it by himself: the changes have to be made in midi_evnt.inc, MIDI_EVNT_Send_Fx function Best Regards, Thorsten.

With this new build: http://www.ucapps.de/mios/midibox_sid_v1_7303b_rc6.zip the constant time glide feature (E2P flag) can be used in combination with the arpeggiator Note that since only one envelope is used for this feature (in MBSID V1, will be improved in MBSID V2), only the arpeggiator of voice 1 resets the envelope in order to avoid multiple triggers Best Regards, Thorsten.

What is the output of the MIDI In window? Best Regards, Thorsten.

this doesn't make much sense once the function uses subfunctions. Why not using the search function over the source code? (Windows: "search" button, Unix: "grep") Best Regards, Thorsten.

Just don't ignore the hints of the others, and spend some time to read the relevant postings in the forum. I've explained the purpose of a deadband several times in the forum, I've also written some more details at the http://www.ucapps.de/mbhp_mf.html page (search for deadband), I drew diagrams, I demonstrated the behaviour with pseudo code, and not at least I released the source code which contains some helpful comments. This is my distribution, now it's your term - you could be the man who takes care that other people don't have to spend the same work in searching for all these scattered informations. I've created a Wiki page where you can start explaining the AIN deadband function with your own words: http://www.midibox.org/dokuwiki/doku.php?id=mios_details_ain_deadband Hope that you understand this motivation. Best Regards, Thorsten.

Would you help me to write a GOOD documentation? Best Regards, Thorsten.

Hi Jaicen, if you have programming skills: yes of course, it's just an alternative user interface Without programming skills the only possibility is to ask somebody who did this before. Have you already seen Alkex's MIDIbox SID? -> http://www.midibox.org/forum/index.php?topic=6553.0 it doesn't fit with all your requirements, but maybe it will give you a good starting point. Best Regards, Thorsten.

You could improve the readability of a sequence by using constants (#define) for each note value. Unfortunately # (for major) is not allowed in a macro name, but "m" should do the same: #define NOTE_____ 0 #define NOTE_Cm0 1 #define NOTE_D_0 2 #define NOTE_Dm0 3 ... #define NOTE_C_4 48 #define NOTE_Cm4 49 #define NOTE_D_4 50 ... [/code] Now you can program sequences in this way: [code] const char pattern[] = { NOTE_C_4, NOTE_C_5, NOTE_C_4, NOTE_C_5, ... }; As you can see, I've already prepared a NOTE____ for an empty step. This is a simple solution, because it's very unlikely that somebody wants to play C_0 Alternatively, you could define an empty note as 0x80 ... in fact, 0x80 and 0xff can be easily used for extensions, such as chords, arpeggio definitions (entry number in the sorted list of held keys), or other control words Back to the implementation: the #define's should be put into a seperate include file You could also think about the integration of your sequencer routines into a seperate .c file - than earlier, than better. Just do it in a similar way like it has been done for the MCLOCK_* routines. Create a seq.c and seq.h file, and announce the new .c file in MAKEFILE.spec Best Regards, Thorsten.

MIOS V1.9 aufladen, und die Speicherbegrenzung in main.asm entfernen (Zeile 611, wie im Error File nachzulesen ist) Gruss, Thorsten.

To 1) yes, in this case you can use my default setup (main.asm/main.hex), because I'm also using a single 24LC512 For the case that you haven't found this page yet: http://www.ucapps.de/midibox_seq_options.html It explains all the options Best Regards, Thorsten.

You can connect the R/G/B pin to three different DOUT pins and drive them directly (easiest solution), or you can time multiplex the pins in order to save DOUT shift registers - but in this case, the LEDs won't be so bright anymore. Best Regards, Thorsten.

Hi Wilba, what I meant was, that it's already possible realize mono/poly unisono sounds by assigning the SIDs to the same MIDI channel, and that internal polyphony is also possible (with up to 3 voices, since 2 SIDs are not supported by MBSID V1). "Distributed" polyphony (if more than the internally accessible voices have to be used) is not possible with MBSID V1, since it requires the same note queue concept like used by MIDIbox FM, with a slight change: external voices of the slaves have to be accessed via MIDI (no problem...) And a general note (before you guys are starting again to beg for an MBSID V1 update): if the plans for V2 wouldn't exist, I would try to tinker this into V1, but doing extensions in this organically grown up firmware is always a pain, therefore I prefer to implement this into a firmware which is built up from scratch... Best Regards, Thorsten.

The filter will be handled in the same way like for MBSID-D: you can control it from all voices, the modulation values will be properly merged. This allows to use the filter properly so long only voice controls it, and it allows to make some fancy modulation effects once more than one voice is assigned to the filter... :) In general I see the requirement for following modes (I'm trying to reduce this to the most important variants): - single voice polyphony handled by a single PIC/one or two SIDs (up to 6 notes) - distributed single voice polyphony handled by multiple PICs (up to 24 notes) - distributed multi voice polyphony (lead subsystem - with stereo effecs) handled by multiple PICs Note that combinations of these modes are possible of course. E.g., using 4 or 2*2 leads assigned to the same channel for unisono sounds. Or using two PICs using multi subsystem with the first option (no note extension for > 6 notes), but assigned to the same MIDI channel for 2-voice or unisono polyphony... Or like above, but four PICs, each controls 2 SIDs, each PIC listens to a different MIDI channel for a nice instrumentation Working with the MIDI Channel and internal/distributed polyphony will open enough possibilities - the two first options are already available in MBSID V1, the third option can be easily implemented into MBSID V2 :) Best Regards, Thorsten.

I don't find the number 5000 (0x1388) so interesting, let's go for 8192 (0x2000) ;-) Thanks for all donations! I will let you know, which special thing I've purchased from the money! Best Regards, Thorsten.

Hi Thomas, so far I remember, a single motorfader normaly takes ca. 200 mA when driven with PWM, this is what I saw on the ampere meter last time I measured the current drain. Yes, 700 mA is too much, maybe it's the maximum value when a fader is stopped by hand, but the weak TC4427 will do some saturation here (therefore the reduced max current has an advantage - it saves your PSU). Which voltage do you read before and after a TC4427 when a fader is moved? And are you able to measure the current? This afternoon I had the idea to make a small video to demonstrate, how to test the motorfaders with the MIDIbox MF application. It should also give an impression about the fader speed. The result can be downloaded from this location: http://www.midibox.org/videos/mf_test.avi (11 MB) Sorry for the "Denglish" ;-) (I've noticed some wrong words during the playback, but now it's too dark to record a new video, next time I should prepare a script...) Best Regards, Thorsten.

Great that you finally solved this! Now we especially know, how the bootloader reacts on a bad supply voltage. Shum, could you please test the upload of the application with MIOS Studio? I just only want to know, if it works reliable on your computer Best Regards, Thorsten.