TK.

Yes - since some days there are also C usage examples for GLCDs! :) Unfortunately they are based on the new project structure, which isn't documented yet. Basically, you would use a "MIOS base" package, which includes the drivers, include files, and even some graphical fonts - and your application itself would only contain a small set of files anymore. So, here is the C example: http://svnmios.midibox.org/trunk/apps/examples/lcd7/ks0108/c/ And here the graphic font package: http://svnmios.midibox.org/trunk/modules/glcd_font/ You won't be able to compile the code with the old approach that is currently documented on my website. Therefore I created a temporal package for you, which should give you a good starting point (instead of the global "mios base" structure, it uses a local file structure) -> http://www.ucapps.de/tmp/ks0108_c_example.zip In addition, you need to install the "posix_bin" directory as described here Best Regards, Thorsten.

Hallo, bei der MBSID V1 ist es normal, dass am Anfang SysEx Dumps and die Slaves gesendet werden - damit muss man leben. ;) Controller senden: ist die CC Funktion aktiviert? Dafuer gibt es eine eigene Taste (und LED) Gruss, Thorsten.

no, you can defined button numbers from 0 to 127 - hm, maybe the button function is overruled by an encoder entry? How does your encoder table look like? Best Regards, Thorsten.

Hi Keith, the usage of Meta Events isn't the right approach here, for your plans it's better to write a dedicated application based on the C wrapper. Many people already did this in the past, some of them introduced their project in the forum (unfortunately there is no complete list of projects, so you need to use the search function) Best Regards, Thorsten.

no - for more inputs you need something like the MIDI Router project Best Regards, Thorsten.

-> http://www.midibox.org/forum/index.php/topic,11115.0.html Best Regards, Thorsten.

Since the MIDImerger project is still quite popular, I created a new variant which is based on the PIC16F88. Not only that this chip is smaller and cheaper - it's especially possible to use it without external crystal with a sufficient accuracy :) -> http://www.ucapps.de/midimerger.html Best Regards, Thorsten.

I found the error: in mb64_lcd.inc, search for BRA_IFCLR MB64_CFG0, MB64_CFG0_SNAP, ACCESS, MB64_LCD_PrnVBar_Normal and replace it by BRA_IFCLR MB64_CFG0, MB64_CFG0_SNAP, BANKED, MB64_LCD_PrnVBar_Normal The change is already commited to the repository, and a new precompiled version will be released soon Best Regards, Thorsten.

Man koennte die MIOS interne merge Funktion einschalten, um eingehende MIDI Events weiterzuleiten (erfordert modifikation im Source Code), doch fuer Deinen Anwendungsfall ist das nicht empfehlenswert, denn der Clock wuerde dann mit einem Delay von mindestens 1 mS + Jitter weitergeleitet, ausserdem wuerde es auch die internen MBSID Timings zusaetzlich belasten (bspw. wenn soviele MIDI Events quasi gleichzeitig eintreffen, dass die In/Out Buffer nicht mehr ausreichen - in diesem Fall bleibt die Sound Engine solange stehen, bis die Buffer wieder frei sind) Geschickter waere es, der MBSID einen MIDI Thru Port zu spendieren. Man muss hierfuer kein komplettes MBHP_LTC Modul aufbauen, es reichen schon ein 74HC00 + DIN Buchse + zwei 220 Ohm Widerstaende auf Lochraster. So koenntest Du den MIDI Clock von Deinem Sequencer direkt an den Gameboy weiterleiten. Gruss, Thorsten.

Swinkels is currently very busy @work, therefore the documentation (schematics, etc...) hasn't been updated yet on his website, and the latest firmware isn't available as well. I recomment you to inform him about your interest, this can be very motivating :) In addition, somebody could support him by creating (and testing) a PCB layout for the stereo option? (I don't find the time for this, I built SwinSID on a veroboard...) Additional wiring

Both is strange. LCD: you considered the 4bit interface (D0-D3 should not be connected)? LCD interconnection test done? Strange Sound: it's interesting that the waveform and volume (or ADSR setting?) changes while you are playing different notes. It could either be a powering problem, connection problem or firmware upload problem - hard to diagnose via remote, but let's start with the power problem: does it also sound so strange when the LCD (and especially the backlight) is *not* connected? Best Regards, Thorsten,.

It definitely was the wrong topic (just consider, that other people should still be able to find informations about this issue some months later) Sounds like a bug, I will check this soon Best Regards, Thorsten.

Thats what I explained three times, please read my answers again. In difference to your explanation, I'm using the common wording which you can also find in your DAW documentation. Illusory I'm not interested in a cooperation with you - too different interests, and too time consuming ;) However, the most clever way would be to integrate the sequencer engine completely into the VSTi, and to communicate with external devices with the given interfaces (MIDI, USB, doesn't matter... it only depends on your programming skills) Best Regards, Thorsten.

Yes, especially when you are programming in Whitespace Best Regards, Thorsten.

http://www.midibox.org/dokuwiki/midibox_speakjet Best Regards, Thorsten.

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.