TK.

Hi Gerald, I used the good old DOS batch language which is documented here: http://home.att.net/~gobruen/progs/dos_batch/dos_batch.html (I used it, because all Unix-style make.exe programs I found cannot handle properly with path variables - it causes even more issues with all windows versions) DOS batch should be compatible with all DOS/windows versions, but a potential problem is, that the PATH variables to sdcc and the gputils is not configured correctly. In WinXP this is done automatically during the installation. So far I remember in previous windows versions this has to be done in C:\AUTOEXEC.BAT Are you able to start "sdcc", "gpasm" and "gplink" from the command line? However, today I wrote some low-level AOUT functions for the C wrapper, it works very well and especially very fast (because they are assembly optimized ;-)) I've also prepared some small C programming examples which demonstrate the possibilities: forward/processing incoming MIDI events to AOUTs forward/processing AIN values to AOUTs generate waveforms at the AOUTs (AOUT = f(t)) transform incoming waveforms to new waveforms (AOUT = f(x)) set gate outputs depending on AIN levels hope that this gives enough inspirations - once I find the time to write some documentation, I will release it (maybe tomorrow if nothing else happens) Best Regards, Thorsten. P.S.: the programming effort to realize this was 2 hours so far ;-)

Von der Softwareseite her ist alles ganz einfach: in cv_map.inc findest Du den Kommentar "convert note to 12bit value". Hier wird der Notenwert einfach um 5 stellen nach links geshiftet. Stattdessen kann man den Wert auch aus einer Tabelle herauslesen (es gibt ja nur 128 verschiedene Moeglichkeiten), und den entspr. 12bit Wert direkt in die CV_AOUT_H und CV_AOUT_L Register uebertragen. Das sind vielleicht 10 Assemblerzeilen Problematisch wird es jedoch mit dem Pitchbender. Falls ein nichtlineares Verhalten akzeptabel ist, einfach den Code so belassen, ansonsten benoetigt man eine groessere Tabelle. Bei 2^12 waeren das 8k, das passt bei der MBCV noch problemlos ins Flash. Man koennte auch mehrere Tabellen in einen BankStick ablegen, dies waere sehr praktisch, um zwischen verschiedenen Mappings umzuschalten, ohne den PIC neu zu programmieren. Die Tabellen sollte man natuerlich vorberechnen (bspw. mit Perl, siehe das frqtab.pl Skript im MIDIbox FM Package) Von der Hardwareseite her weiss ich nicht, ob es die 12bit bringen. Die Referenzspannung des MAX525 betraegt 2.048V, 4.096V ist laut Datasheet nicht empfehlenswert, doch die Ausgangsspannung sollte sowieso gepuffert werden, somit empfielt sich ein nachgeschalteter OP mit 1:2 Spannungsverstaerkung. Bei 12bit Aufloesung folgt daraus eine Genauigkeit von 4.096V/2^12 = 1 mV reicht diese Genauigkeit? Gruss, Thorsten.

Great! :) Best Regards, Thorsten.

ok, if you want to use two cores anyhow, the solution is much simpler: just open mios_tables.inc in the AIN64DIN128DOUT128 application and replace 0xb0 (CC) by 0x90 (Note) Then add following line to USER_Init: MIOS_MIDI_MergerSet(MIOS_MIDI_MERGER_MBLINK_FP) to configure this core as a "forwarding point" or: MIOS_MIDI_MergerSet(MIOS_MIDI_MERGER_MBLINK_EP) to use it as an "endpoint" Best Regards, Thorsten. P.S.: don't forget to clamp all unused analog inputs to ground (for the DIN/DOUT core this means: the whole J5 port)

Hi Gerald, by using the MIOS C skeleton it shouldn't be that difficult to realize a quantizer, simple sequencer or whatever you want. In difference to assembly programs, sharing code with other users is much easier. So, how about a MIOS user library, a collection of some interesting functions and "program-modules", maintained by users and not by myself? Best Regards, Thorsten.

Hi Julien, if up to 8 buttons are enough, then you could use the j5_din application. It requires only one core module, the buttons have to be connected to port J5 - it can send any MIDI events you want (by default Note events) For more then 8 buttons (or additional LEDs), a DIN and DOUT module is required beside of the core, MIDIO128 is the recommented application for this case Best Regards, Thorsten.

thank you, Marcel! This sounds easy. For a common MIOS based application this means that in USER_MIDI_NotifyTx a check for MIDI clock (F8) has to be added (if it doesn't already exist). On an incoming MIDI clock, MIOS_DOUT_Set1 has to be called with the pin number which is used as sync output. Optionally a pre-divider can be added. In USER_SR_Service_Finish this pin has to be cleared (MIOS_DOUT_Set0) - and thats all. This will generate a pulse of 1 mS, with a jitter of +/- 0.5 mS. I think that such a jitter is acceptable, because it is only 1% at 140 BPM (I will integrate this feature into the next MBSEQ release) If less jitter is required, a free IO pin has to be used (but free IOs are rare). This IO pin can be set immediately once a F8 event has been received (zero jitter!), and it can be cleared by a timer. However, this requires some more programming effort, and the code will look different depending on the application where it is integrated (because of different pin usage and timer resources) For a standalone solution I would prefer Colin's circuit, it's the cheapest Best Regards, Thorsten.

Last time I saw this source code, it didn't find any SIDstation, nor general MIDI routines - are such features available in the meantime? Best Regards, Thorsten.

Hi, you could control the additional LEDs in cs_menu_leds.inc, example: CS_MENU_LED_Update clrf MIOS_PARAMETER1 ; clear LED by default movf CS_MENU, W xorlw CS_MENU_OSC skpnz setf MIOS_PARAMETER1 ; set LED if CS_MENU == CS_MENU_OSC movlw 8*(7-1) + 0 ; SR7, pin #0 call MIOS_DOUT_PinSet [/code] Best Regards, Thorsten.

I could give you a small C function which allows you to control all 128 LEDs, I just need to know which MIDI events should be assigned to the LEDs? Best Regards, Thorsten.

Hi Alex, do you know how to get a (free) datasheet for this chip? If you've luck, the internal functions and the SFR addresses are the same - if not, an adaption wouldn't be worth the effort Best Regards, Thorsten.

Hi Davo, I made some experiemts with a self-built oscillator some time ago (based on three inverters), but the results where not so good - sometimes the oscillator didn't start after power-on. If you are still interested, I can search for the schematic (I guess that I found it on a german website) However, for the MBSID the oscillator is not required, you can also clock the SIDs with the PWM output of the PIC - more infos can be found here: http://www.ucapps.de/mbhp_sid.html Best Regards, Thorsten.

Chriss added the code for the additional buttons and LEDs to the MBSID application, there are no changes in MIOS required. I guess that the question "are they really necessary?" is directed to Chriss (because I don't know anybody else who uses such an extension). If he doesn't read this posting, then just try to contact him via PM Best Regards, Thorsten.

Hi, it's very simple to implement this, but last time I asked in the forum for the specs, I havn't got a reply. So, maybe this time I've more luck? What is the required pulse width for a DIN-Sync signal? Best Regards, Thorsten.

Hi, I fear that it isn't possible to service the SHX8 module in parallel to all the other tasks which are running in the MBSEQ application, because the S&H outputs need to be refreshed very often. I would suggest the use of a second core which runs with the MB64 firmware and which handles the S&H stuff Best Regards, Thorsten.

Hi Dave, yes, thats possible with Meta Events (you can send anything you want...). The MB64 (and MB64E) source code contains an example in mb64_meta.inc (mb64e_meta.inc), there are users who already customized this for their synths, but I guess that there is no adaption for DW-8000, yet Best Regards, Thorsten.

Is there somebody who wants to create a webbased java application which calculates possible configurations? ;-) here some formulas: max number of available digital inputs: 128 max number of digital inputs which can be used to trigger button functions (e.g. MIDI events or Special Functions): 64 number of digital inputs which can be used for menu navigation: 4 number of digital inputs which are allocated for encoders: 2 * number of encoders (max. 64 encoders = 128 pins) max number of analog inputs: 64 number of 7-bit MIDI values which are stored within a bank, and which can be controlled via encoder or AINs: 128 number of 1-bit MIDI values which are stored within a bank, and which can be controlled via DINs: 64 max number of available digital outputs: 128 number of digital outputs which are controlled directly via button or via MIDI (same MIDI events like assigned to the 64 buttons): 64 max number of digital outputs which can be used for LEDrings: 32 for each group of 16 LEDrings, max: 64 LEDrings = 128 pins number of digital outputs which can be used as software-based MIDI Tx/Rx indicator: 2 pins anything missing? Best Regards, Thorsten.

Hi Matteo, it should work with MIOS v1.7, but I cannot guarantee this, since all of my own MIDIboxes are running with v1.8 in the meantime Best Regards, Thorsten. P.S.: thanks for the postcard! :-)

MBSEQ works with 96 ppqn Best Regards, Thorsten.

How is the quality of the LCDs from Voti? Best Regards, Thorsten.

Lower voltages cannot damage the SID, only higher voltages. But this scenario shouldn't happen so long the voltage regulator was between the power supply and the SID. Best Regards, Thorsten.

This is not a feasible setup - MIDI is the main bottleneck here, because the transfer of a single MIDI event (e.g. CC) takes ca. 1 mS. This already limits the max. transfer rate for the waveform of a single LFO a lot. For a sine wave I would say that at least 16 sample points are required for adequate results (we are not talking about the Nyquist theorems here), this limits the max. frequency to 62.5 Hz. Once you've more than one LFO, the results won't be much enjoyable anymore... I think that this obsoletes the other questions... ;-) Best Regards, Thorsten.

No thanks, I'm not interested. To give you an impression: the definition and implementation of the MIDIbox FM software took me ca. 6 months, the statement "can really easy adapt it to OPL4" can only come from somebody who never did something like this by himself. Best Regards, Thorsten.

Hallo, kleiner Tip: teste die DINs erstmal mit der MIDIO128 applikation - hier sendet jeder Pin (Button) ein MIDI Event Gruss, Thorsten.

I cannot spend the effort to write such a documentation, but I'm always open for distributions from other users. Today it's possibly better to write a user manual for the C wrapper, since it's easier to use, code snippets can be easier exchanged (e.g. in seperate .c files), and people are able to realize more complex applications without much knowledge about the internals (especially about assembly language) Best Regards, Thorsten.