TK.

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.

I think, that using the Lead subsystem is not the best solution for poly sounds, since you need to adjust each oscillator to the same values for best results (like on MBSID V1). Therefore the Multi mode is better for polyphony, and this is actually how MIDIbox FM is working (I will use the same voice assignment algorithms, they are working great). exactly! :) Best Regards, Thorsten.

Hi Dan, you will find my answer here: http://www.midibox.org/dokuwiki/doku.php?id=midibox64e Best Regards, Thorsten.

this was Axel's decition, I guess it matched better with his panel layout So far I remember (I'm using a graphical display where such problems don't exist...) the status messages allocate 8 characters for all 8 visible tracks. You could cut out some of them by changing LC_CLCD_Print_RSM in lc_clcd.inc (search for the comment "print 8 chars"). However, this doesn't make much sense, especially when each button has a LED - you could also remove it completely Best Regards, Thorsten.

Don't do this, this will worsen the handling. When you are pushing an encoder, it can happen from time to time that you are rotating it unintentionally. This is suboptimal especially in live situations - e.g. when you want to mute/unmute a note or select a new patch, an unintended tweak on the encoder could change the note/CC value at the same time. Same is true for the select button Just use the original button arrangement, it works perfectly Best Regards, Thorsten.

An important hint: next time use ribbon cable to connect your modules, it's much easier to solder and less error prone (the cable doesn't break so easy). Some time ago a friend brought me his MIDIbox SID because it didn't work stable - the first thing what I did was to desolder all these thick cables, and I replaced them by the flexible ribbon cables. Thereafter it worked perfectly without failure. See also the addendum of the soldering guide: http://www.ucapps.de/mbhp_core.html Best Regards, Thorsten.

I've moved the chat about webshop strategies to this location: [iurl=http://www.midibox.org/forum/index.php?topic=6934.0]http://www.midibox.org/forum/index.php?topic=6934.0[/iurl]

I can see the pictures with Firefox 1.5.0.3 under Linux However, I will upload them to the MIDIbox server soon Best Regards, Thorsten.

Great progress! :) Best Regards, Thorsten.

Hi Marcus, this was a typing error at my webpage, J7:D0 is ment of course, like it can be seen in the schematic Best Regards, Thorsten.

I think that with the MIDIbox Plus it's likely that this happens, because buttons are handled with a very low priority. It requires different programming strategies in order to overcome this. Today with MIOS this isn't a problem anymore, since buttons are scanned interrupt driven with an update period of 1 mS (by default) Best Regards, Thorsten.

Hi Thomas, it shouldn't make a difference, if one or more faders are moved in parallel, the movement from 0 to max should always take the same time. One/Two seconds sound very long! As you can see here: http://www.ucapps.de/mbhp/mf/final/rsaon11m9.gif, the fader should reach the target position within ca. 200..400 uS (0.2..0.4 seconds) It's not normal that the TC4427 gets hot. Maybe the protection diodes are connected at the wrong way? This would also explain, why the faders are so extremely slow, and why they get even slower when they are moved in parallel. Best Regards, Thorsten.

So long you don't want to use the arpeggiator or transpose function, a keyboard is not required. Just activate some Notes and CCs in one or more tracks, and your sound module will start to play. Encoders with push buttons: I don't use the integrated buttons, and there is also no dedicated function in the firmware for these buttons. You could use them to activate the FAST function when an encoder button is pushed Best Regards, Thorsten.

Das Toggeln von Parameterwerten ist ziemlich trivial: erstelle eine Variable, die den Toggle-Status enthaelt, und aendere den Wert nur dann, wenn die entspr. Taste gedrueckt wurde. Die Variable kann auch von mehreren Tastern modifiziert werden... ich denke, wenn Du einfach mal in diese Richtung weiterprogrammierst, kommst Du schon sehr schnell dahinter Gruss, Thorsten.

Hi Shum, I guess that you are still not using the most recent hex2syx.pl script, which is part of the mios_v1_9_src package, and located in the tools/ directory (I wrote you about this some days ago, but I never got an answer, if you really tried it). The old script doesn't know about the changed memory ranges. So, with the new script you will be able to convert the .hex when you add the "-os_upload" AC: I don't want to make the usage of this script too much public, since it is too difficult to handle (as you can see...) and the unidirectional upload without checking the error codes is too dangerous. It's better to have a flawless working MIOS Studio. So, if this tool (or Java) is the reason why the code upload doesn't work at Shum's PC(s), then we should find out, why But before making such hypotheses, it would be an important input from Shum's side, if the upload is working with MIDI-Ox Shum: here a direct link to the source package: http://www.ucapps.de/mios/mios_v1_9_src.zip you can find hex2syx.pl in the tools/ directory Best Regards, Thorsten.

no, just use Meta events - these are special parameters which don't send a common MIDI event, but jump to selfwritten functions which are located in mb64_meta.inc/mb64e_meta.inc Just have a look into these files, they already contain examples. You could also use the search function of this forum to find even more examples. For an increment function you need a variable as a counter, and you need a table which maps the counter to the CC/Note value which should be sent out Best Regards, Thorsten.

After exactly (!) four years, the time had come to update the official layouts of the MBHP_CORE and MBHP_SID module based on the requirements, which came up during this period, and based on the progress of SmashTV's improved board versions, which I've taken as inspiration (a 1:1 copy was not possible due to the different dimensions and the double-layer design) Especially for people who are going to build a MIDIbox SID with the old board design I'm sure that it won't be so easy like before to determine the right wiring between the core and the SID module, since most interconnection diagrams are now refering to the new pinnings. But this situation should be settled sooner or later once the next generation starts with the new "perfect layouts" - which doesn't include all these interim workarounds anymore. For your convenience, I've created two special pages which contain the docs to the old boards: -> http://www.ucapps.de/mbhp_core_old.html -> http://www.ucapps.de/mbhp_sid_old.html The new docs can now be found under: -> http://www.ucapps.de/mbhp_core.html -> http://www.ucapps.de/mbhp_sid.html (if you've visited these pages in the last days, you propably have to push the "refresh" button of your webbrowser) In addition, the final MBHP_IIC_MIDI layout has been released: -> http://www.ucapps.de/mbhp_iic_midi.html Thanks goes to SmashTV, who has created the MBHP_IIC_MIDI layout, and to Mike, who has supplied me with free prototypes! :) Best Regards, Thorsten.

I must say, that I'm also not sure. I just tried a 1k pot and it worked, therefore I never spent much thoughts on the theoretically best value. Best Regards, Thorsten.

Ok, so now you know that it is not the PIC, and now you can just try the other tests at this page like suggested five mails ago Best Regards, Thorsten.