TK.

Very well said! Best Regards, Thorsten.

There is a high chance to rescue the installation. Does the PIC send an upload request after power-on? Then just upload the application via 1st level bootloader (you have to start the upload within 2 seconds after power-on) If this doesn't work, the corrupted MIDIO128 installation has probably affected a part of the MIOS range. In this case, re-install MIOS first (via 1st level bootloader), thereafter the application (as usual) Probably you have to press the "refresh" button of your browser to see the change Best Regards, Thorsten.

Btw: an application should never allocate this MIOS range (or in other words: -os_upload should never be required for an application .hex file) - but this identified a bug See also: http://www.midibox.org/forum/index.php/topic,10972.msg86415.html#msg86415 Best Regards, Thorsten.

Due to your other post, I found a nasty bug in the MBFM application! The encoder table wasn't located at the right address (0x0000 instead of 0x3280) The nasty thing: users who just updated the new firmware cannot regognize this bug (because the old encoder table won't be overwritten), and I haven't found it, because I'm using setup_mbfm_tk.hex instead of setup_mbfm_v1.hex Thats the reason, why you noticed this issue first (I'm sorry about that!) Please update to midibox_fm_v1_1c.zip Best Regards, Thorsten.

The script you are using is expired, thats the reason Please use this one: http://svnmios.midibox.org/trunk/bin/hex2syx.pl Best Regards, Thorsten.

If you notice this, I would spend some more time in thinking about the root cause, and give you some more individual troubleshooting tips. On the other hand: the upload issue should be solved first! It doesn't make much sense to analyse on symptoms which could be related to an incomplete firmware. Best Regards, Thorsten.

It seems that you assume, that features which can be easily realized in a "closed system" (like a VST host), could also be realized with an external device. Wrong! We always have jitter, regardless of the quality of your MIDI interface. Compensation is CPU intensive, error prone, and leads to compromisses. Just think about, why external MIDI clock synchronisation of a DAW is mostly not supported (anymore), or why experts don't recomment to use it... ...but you expect, that such a feature could be easily implemented into MBSEQ/MB808? Please run the MIDImon application, and tell me how accurate the BPMs are displayed. Does the value ever change during - let's say - 5 minutes? The advantage of a non-extrapolated based MIDI clock synchronisation is, that temporal delays or jitter (caused by DAW, OS or MIDI interface) only affect the external sequencer a single moment, and not over a long term of one second, or the whole song. Stable timings is what we really want - and thats what has been implemented in all MIDIbox sequencers With your proposal: yes, we would have a problem when delays are changing. With my proposal: no - let's say you set the negative clock delay to -100 mS in your DAW. It's a fixed delay, and you won't change it during the song(s) is/are running. For the instruments controlled by MB808, you will be able to change the positive delay on-the-fly before or after a drum sound is changed/triggered. By default you would set it to +100 mS, this results into 0 mS delay. Probably you would also store this default value into your patterns. If you want to play the drum 20 mS earlier, just use +80 mS for the individual drum instrument. I would propose to use the MBSID V2 firmware (see also the rsf Kobol demos). Tempo controlled envelopes (and LFOs) is one of many features of this firmware. You don't need to stuff a MBHP_SID module... ;) For MBSEQ it would be a nice feature as well, but it can never be so fast (and flexible) like already implemented in MBSID V2, and I don't really want to do all the work twice, if a more powerful solution already exists. Even transforming the envelopes to MIDI events would be possible (with some hacking), however the MIDI bandwidth would limit the possibilities. For CV, I would say, it's a perfect solution :) (Just to highlight it again: because the MBSID V2 firmware provides a much more powerful infrastructure - just think about the modulation capabilities!) Best Regards, Thorsten.

No, at the time the Init() hook is invoked, the pots haven't been scanned. I would add a request mechanism into Tick() which sends all pot values when a certain flag is set (e.g. POT_SNAPSHOT_REQ, similar handling like the DISPLAY_UPDATE_REQ you will find in many C based applications). This flag has to be set after a certain time (which depends on the number of pots). I guess, that with 30 mS you are at the save side. So, how to add a cheap delay mechanism without sacrificing the Timer() hook: use SR_Service_Prepare() or SR_Service_Finish(), these hooks are called each mS if number of SRIO is > 0 (I guess that you are using DIN/DOUT modules, so SRIO length is probably already initialized?) Then define a 8bit variable as counter, set it to 30 inside Init() Inside SR_Service_Prepare() (or _Finish() - doesn't really matter), check if the counter is already 0 if not, decrement it. Check again if it is 0 - yes: set the POT_SNAPSHOT_REQ flag Once the routine in Tick() is executed (this happens whenever nothing else is to do), it clears POT_SNAPSHOT_REQ (so that this mechanism won't be triggered again), sends the pot values - voila! Best Regards, Thorsten.

There are two issues with this display: the interface isn't properly docuemented, so that it is impossible to predict if it will work. Another issue (and I've mentioned it several times in this forum): the user interface has been designed for two 2x40 LCDs (2x80 characters). Just one of many examples, how deformed a typical configuration page would look like on a 8x24 screen: The original screen: Note especially, how nice the menu items are aligned to the GP buttons/LED/encoders, and imagine how you would have to find the right control elements with a 8x24 screen. Best Regards, Thorsten,

Have you ever tried to check the encoder A/B->DIN pin connections with the MIDIO128 application like descriped here? It would be interesting, if two individual note events are sent (good), and if note values are toggling when the encoder is not moved (bad). Best Regards, Thorsten.

I understand, why a delay is useful, and as mentioned above, a n x 1 mS delay can be added easily. But I still don't understand, why MB808 should provide a negative delay, if there are better methods for an exact and jitter-free compensation (master clock sent with negative delay by DAW, MB808 adds configurable, positive delays) - it doesn't matter how the delays are controlled. Stored in the patch: no problem. Changed via CC: no problem as well... You are speaking as if you would know a perfect solution to generate a stable, negative delay at the MIDI clock slave side. Please share your wisdom! What is the exact concept? Best Regards, Thorsten.

Maybe there is no contact between the RD# pin of YMF262 and +5V? The voice issue is probably related to a defective YAC512, or to bad solderings around this chip. Best Regards, Thorsten.

Yes, old link... but this solution isn't multi client capable. However, since so many people asked for a FT232 based solution in the past, and refered to documentation which exactly explains how it works, but nobody ever did the step to try it for MBHP, I will do the work for you... in ca. 1..2 weeks Best Regards, Thorsten.

No, I haven't tested it yet, because I paid for Mandolane, and don't know, how to ensure that it is uninstalled before testing an alternative driver. Napierzaza: how is it running on your Mac? Best Regards, Thorsten.

Yes, you can leave out the optocoupler part of the core module and the 220 Ohm resistors of the merger MIDI Out in this special case without danger so long both PICs are supplied by the same voltage source. The Tx output of the PIC used for the merger has to be connected to the Rx input of the second PIC An more clever method: you could easily re-use the optocoupler circuit of the core module for the merger circuit. Just break the track which is routed to the Rx pin. One side (the Rx pin of the core module) has to be directly connected to the Tx pin of the Merger circuit, and the other side (optocoupler part of the core module) can be directly connected to the Rx pin of the Merger circuit. It's like if you would "insert" the merger Tx/Rx pins between optocoupler and Rx pin of the core module. Best Regards, Thorsten.

Beside of Beethoven's approach, this project could be interesting for you as well (it's a dedicated application): http://www.midibox.org/forum/index.php/topic,11070.0.html Best Regards, Thorsten.

Crypto71 developed a special application to midify the buttons and drawbars of an old Dr. Böhm CnT/L organ. He wrote: Full View

Alkex built a MIDI controller into a Speak&Spell case! :) He wrote:

For completeness, here are the pictures of Sebo's MIDIboxes, which he has already introduced some time ago. Once the scripts are running again, they will be in the gallery as well (together with other missing pictures) MIDIbox SID (Sebo called it Mini64): http://www.midibox.org/forum/index.php/topic,7269.msg48375.html#msg48375 MIDIbox 64: http://www.midibox.org/forum/index.php/topic,9490.msg67973.html#msg67973 and finally a MIDIbox SID Sebo built for a friend (Bruno): http://www.midibox.org/forum/index.php/topic,10934.0.html

Napierzaza informed me, that an alternative software is available here: http://www.humatic.de/htools/mmj.htm In distance to Plumstone/Mandolane it's free! (I added this info to the Meeshka's initial article, so that people are immediately informed about this possibility) Best Regards, Thorsten.

ok, if this application sends Note events, the pull-up resistor is not correctly connected. Check it again Best Regards, Thorsten.

No, in such a case you don't need to reconfigure the software. But you should doublecheck, that R9 of the core module (10k pull-up resistor) is connected correctly to avoid randomly triggered button events (or functions). Do you notice the same with the ain64_din128_dout128_v2_0 application? Best Regards, Thorsten.

You selected the right .hex file, thats a good starting point! :) The issue looks similar like this one, but this time the LED lits. However, I think the reason is the same: visually check the circuitry around the optocoupler. TEST IN7 allows you to doublecheck, that the optocoupler itself isn't failing (e.g. because of a defect) Best Regards, Thorsten.

Are the events from B0 1D..B0 3F sent as well? Then it looks like the snapshot function. Could it be, that you accidently triggered it? (check the button) Best Regards, Thorsten.

This topic has been moved to MIDIbox of the Week. [iurl]http://www.midibox.org/forum/index.php?topic=11064.0[/iurl]