TK.

Could you give an example, how this is realized on the Virus? E.g. a .mid file, or just a snapshot of a pianoroll editor, so that we can see when notes are played. Btw.: alternatively you could use one of the 4 WT sequencers to create your own arpeggio texture. Did you already consider this? Best Regards, Thorsten.

See my SwinSID review. Swinkels has released the source code, so that it can be ported to other derivatives. A fully stuffed MBSID V2 (with 4 PIC cores) can control 4 Atmega based SwinSIDs = 8 emulated SIDs = 24 SID voices. I'm already working on MBSID V3 which uses a STM32 derivative instead of PIC. With this microcontroller the number of SIDs isn't really limited anymore, it's only a question of memory consumption and update frequency. A STM32 can even emulate SIDs in parallel (see nILS' recent postings), so that no Atmega based "companion chip" is required. Best Regards, Thorsten.

Alright, please try RC35: o modulation source "KEY" now uses current frequency instead of key number to consider frequency sweeps correctly o bugfix for "jump to page" (empty page if current item position outside new page) o bugfix for knob page (min/max value modified Pa1 if multiple SIDs selected) [/code] Best Regards, Thorsten.

Then the problem seems to be located somewhere else. There is a trick which forces a reboot without power-cycling the core: tap a cable from ground to pin #1 of the PIC for a short moment - this will reset the core. It would be interesting, if this helps. Yes, for safety reasons I removed this hint, because the danger is too high that the upload fails if somebody tries this under "unstable" conditions (e.g. firmware overloaded, so that MIDI stream gets corrupted) Unlikely that this happened, but if you don't want to find out the exact reason for the failure, burning the bootloader makes sense... There is no reason why it doesn't make sense to upload v1.9g Best Regards, Thorsten.

Thanks - it's very likely that I can release an update today, but before I need some more help from your side: Ok, now I get it - (only) when multiple SID engines are selected, the Min parameter is copied to the Pa1 parameter as well. Yes, the Env/Misc/Assign selection behaves strange - thats probably related to the latest changes in RC34 (see ChangeLog) - improvable. Does this only happen in conjunction with this button function? Best Regards, Thorsten.

No, such MIDI events are not transmitted via CAN, and it would be too difficult to add this compared to a proper ensemble configuration done by the user - I will add this to the documentation. Has anybody else noticed the same? As always: I need step-by-step instructions. Best Regards, Thorsten.

To get some additional infomations: does MIOS Studio receive the initial upload request during startup with the master core? Best Regards, Thorsten.

Ob ein Geraet durch eine Masseschleife kaputt gehen kann oder nicht, haengt u.A. vom Netzteil ab. Die einfachste und sicherste Loesung waere in Deinem Fall, die Masseverbindung am MIDI Out des Core Modules zu trennen, und zwar direkt an der Leiterplatte (bzw. an der MIDI Buchse). So laeufst Du nicht Gefahr, dass das Core Modul abermals eine Ueberspannung abbekommt, wenn Du mal ein anderes (unmodifiziertes) MIDI Kabel anschliessen solltest. Alternativ koenntest Du ein besseres Netzteil verwenden - wie wird das Core Modul momentan versorgt? Gruss, Thorsten.

No, it isn't required to upload the sequencer application again (so long you are using MIOS V1.9g and the latest MBSEQ V3 release v3.4f) The DOUT registers won't be damaged if you connected them to J9 instead of J8 by fault. It's more likely an additional wiring or soldering error. Check especially the CORE:J8:DO->DOUT:J1:DO, CORE:J8:SC->DOUT:J1:SC and CORE:J8:RC->DOUT:J1:RC connections If you don't find the error visually, but own a multimeter, the srio_interconnection test helps you to measure the voltage levels: Best Regards, Thorsten.

So, you compiled MIOS by yourself and uploaded it to your core before uploading the application? If this modification hasn't caused an effect, then I assume an handling error (please describe more exactly what you did to clarify the issue). Since I assume an handling error, I attached a precompiled .hex file so that you can easily compare the results. Before continuing with speculations, could you please give me some feedback if the .hex file I gave you is working at your side. There are no other changes which are required, it's really straightforward. Best Regards, Thorsten.

I fixed the bug in the mbfm_interconnection_test and released a new one: In order to compare your scope snapshots, I would have to open my MBFM case... very timeconsuming :-/ However, it seems that they are looking good. Now it's time to check the audio output buffers (IC6) Just unplug IC3 and IC5, and tap an audio signal from a (known working) audio source to pin IC3:O4, IC3:O3, IC5:O4 and IC5:O3 (since you own a scope, I guess that I don't need to explain more details about the testing procedure) If audio is buffered correctly (1:1), then the remaining error must be located between the YAC chips and IC3/IC4 - I don't have the testing procedure for that (only trial&error&visual inspections) Best Regards, Thorsten.

I overworked the four existing interconnection tests for more comfortable usage, especially in conjunction with MIOS Studio. Instead of controlling the pins with the Modulation Wheel, they are now set with Note On events, which can be sent from the virtual keyboard. And a message about the current pin states is sent to the MIOS Terminal whenever a Note has been received to give you a clear hint about the voltage level you should read with a multimeter. Accordingly, no LCD is required for these checks anymore. Updated applications (can be downloaded here): srio_interconnection_test_v2: lcd_interconnection_test_v2: mbsid_interconnection_test_v2: mbfm_interconnection_test_v2: Best Regards, Thorsten.

Currently you are using the same handler for encoders/faders/buttons, since all three labels point to the same code: MB64E_META_Handler_Enc MB64E_META_Handler_Fader MB64E_META_Handler_Button ;; meta handler ;; ... return [/code] So long you only need a single variant for encoders, you could also write it below the MB64E_META_Handler_Enc label, and let the code below MB64E_META_Handler_Fader and MB64E_META_Handler_Button as it is. [code] MB64E_META_Handler_Enc ;; meta handler for encoders ;; ... return MB64E_META_Handler_Fader MB64E_META_Handler_Button ;; meta handler for faders/buttons ;; ... return I think this is the most simple solution (you asked for it) Best Regards, Thorsten.

Doppelpost:

Here the required modification: MIOS_SRIO_Loop btfsc MIOS_SRIO_PORT_DIN, MIOS_SRIO_PIN_DIN bsf IRQ_TMP5, 7 bsf MIOS_SRIO_LAT_DOUT, MIOS_SRIO_PIN_DOUT btfss INDF2, 7 bcf MIOS_SRIO_LAT_DOUT, MIOS_SRIO_PIN_DOUT btfss MIOS_SRIO_PORT_DIN, MIOS_SRIO_PIN_DIN bcf IRQ_TMP5, 7 bsf MIOS_SRIO_LAT_SCLK, MIOS_SRIO_PIN_SCLK nop btfsc MIOS_SRIO_PORT_DIN, MIOS_SRIO_PIN_DIN bsf IRQ_TMP5, 6 bcf MIOS_SRIO_LAT_SCLK, MIOS_SRIO_PIN_SCLK bsf MIOS_SRIO_LAT_DOUT, MIOS_SRIO_PIN_DOUT btfss INDF2, 6 bcf MIOS_SRIO_LAT_DOUT, MIOS_SRIO_PIN_DOUT btfss MIOS_SRIO_PORT_DIN, MIOS_SRIO_PIN_DIN bcf IRQ_TMP5, 6 bsf MIOS_SRIO_LAT_SCLK, MIOS_SRIO_PIN_SCLK nop btfsc MIOS_SRIO_PORT_DIN, MIOS_SRIO_PIN_DIN bsf IRQ_TMP5, 5 bcf MIOS_SRIO_LAT_SCLK, MIOS_SRIO_PIN_SCLK bsf MIOS_SRIO_LAT_DOUT, MIOS_SRIO_PIN_DOUT btfss INDF2, 5 bcf MIOS_SRIO_LAT_DOUT, MIOS_SRIO_PIN_DOUT btfss MIOS_SRIO_PORT_DIN, MIOS_SRIO_PIN_DIN bcf IRQ_TMP5, 5 bsf MIOS_SRIO_LAT_SCLK, MIOS_SRIO_PIN_SCLK nop btfsc MIOS_SRIO_PORT_DIN, MIOS_SRIO_PIN_DIN bsf IRQ_TMP5, 4 bcf MIOS_SRIO_LAT_SCLK, MIOS_SRIO_PIN_SCLK bsf MIOS_SRIO_LAT_DOUT, MIOS_SRIO_PIN_DOUT btfss INDF2, 4 bcf MIOS_SRIO_LAT_DOUT, MIOS_SRIO_PIN_DOUT btfss MIOS_SRIO_PORT_DIN, MIOS_SRIO_PIN_DIN bcf IRQ_TMP5, 4 bsf MIOS_SRIO_LAT_SCLK, MIOS_SRIO_PIN_SCLK nop btfsc MIOS_SRIO_PORT_DIN, MIOS_SRIO_PIN_DIN bsf IRQ_TMP5, 3 bcf MIOS_SRIO_LAT_SCLK, MIOS_SRIO_PIN_SCLK bsf MIOS_SRIO_LAT_DOUT, MIOS_SRIO_PIN_DOUT btfss INDF2, 3 bcf MIOS_SRIO_LAT_DOUT, MIOS_SRIO_PIN_DOUT btfss MIOS_SRIO_PORT_DIN, MIOS_SRIO_PIN_DIN bcf IRQ_TMP5, 3 bsf MIOS_SRIO_LAT_SCLK, MIOS_SRIO_PIN_SCLK nop btfsc MIOS_SRIO_PORT_DIN, MIOS_SRIO_PIN_DIN bsf IRQ_TMP5, 2 bcf MIOS_SRIO_LAT_SCLK, MIOS_SRIO_PIN_SCLK bsf MIOS_SRIO_LAT_DOUT, MIOS_SRIO_PIN_DOUT btfss INDF2, 2 bcf MIOS_SRIO_LAT_DOUT, MIOS_SRIO_PIN_DOUT btfss MIOS_SRIO_PORT_DIN, MIOS_SRIO_PIN_DIN bcf IRQ_TMP5, 2 bsf MIOS_SRIO_LAT_SCLK, MIOS_SRIO_PIN_SCLK nop btfsc MIOS_SRIO_PORT_DIN, MIOS_SRIO_PIN_DIN bsf IRQ_TMP5, 1 bcf MIOS_SRIO_LAT_SCLK, MIOS_SRIO_PIN_SCLK bsf MIOS_SRIO_LAT_DOUT, MIOS_SRIO_PIN_DOUT btfss INDF2, 1 bcf MIOS_SRIO_LAT_DOUT, MIOS_SRIO_PIN_DOUT btfss MIOS_SRIO_PORT_DIN, MIOS_SRIO_PIN_DIN bcf IRQ_TMP5, 1 bsf MIOS_SRIO_LAT_SCLK, MIOS_SRIO_PIN_SCLK nop btfsc MIOS_SRIO_PORT_DIN, MIOS_SRIO_PIN_DIN bsf IRQ_TMP5, 0 bcf MIOS_SRIO_LAT_SCLK, MIOS_SRIO_PIN_SCLK bsf MIOS_SRIO_LAT_DOUT, MIOS_SRIO_PIN_DOUT btfss INDF2, 0 bcf MIOS_SRIO_LAT_DOUT, MIOS_SRIO_PIN_DOUT btfss MIOS_SRIO_PORT_DIN, MIOS_SRIO_PIN_DIN bcf IRQ_TMP5, 0 bsf MIOS_SRIO_LAT_SCLK, MIOS_SRIO_PIN_SCLK nop [/code] and attached a precompiled .hex file Best Regards, Thorsten. mios_p18f452.hex

Fine :) And here the next ones: tomcody vcfool Simca Streusalz Dr_Nick Best Regards, Thorsten.

So, does it mean that you are able to control the pins with the virtual MIDI keyboard of MIOS Studio as well? This would be great - I will change the other test application as well if it works. Thats hard to determine. Thats strange - it seems that there is a short between the data pins which leads to higher power consumption. It's hard to say, if this is related to your soldering work, or if it's an internal short inside the OPL3 chip. The data pins are toggled with high frequency, you cannot measure the correct voltage w/o a scope. Therefore the test application supplies static voltages. With the interconnection test, do you always read 5V on the selected pin, and 0V on all other pins? This would help to exclude a short. Best Regards, Thorsten.

It's here: http://www.ucapps.de/mbhp/mbhp_doutx1.pdf Best Regards, Thorsten.

I recently programmed an AU by myself (to evaluate the possibility for a virtual MBSID), therefore I know the background details about latencies a bit better now :) Audio channels and MIDI events (to AUs) are streamed through buffer slices, the size is predefined by the host application. It's normaly 512 Words per slice, which results into ca. 6 mS delay at 44.1kHz sample frequency and two audio channels. If Reaper allows to change the buffer size (like Logic), then try it - but this will also increase the CPU load and the danger for buffer underruns. The buffer size is the same for all audio channels handled by the host. So, a second host (like AU Lab) which streams with smaller buffers will definitely solve the latency issue. Best Regards, Thorsten.

No, you would write: 9 = F0 01 00 @OnOnly [/code] Only three values can be defined, and the third value is not used by the meta handler example I gave you... To trigger the remaining MMC commands, use: [code] 10 = F0 02 00 @OnOnly 11 = F0 03 00 @OnOnly 12 = F0 04 00 @OnOnly 13 = F0 05 00 @OnOnly Best Regards, Thorsten.

Could you please do me a favor and check the most recent mbfm_interconnection_test_v1d release? -> http://www.ucapps.de/mios_download.html I added the code which allows to control the pins with a virtual MIDI keyboard w/o testing it... it was the fastest solution to solve this issue. Please let me know if it works. C : Pin J2_1:RS = 5V C#: Pin J2_1:A0 = 5V D : Pin J2_1:A1 = 5V D#: Pin J2_1:WR = 5V E : Pin J2_1:D0 = 5V F : Pin J2_1:D1 = 5V F#: Pin J2_2:D2 = 5V G : Pin J2_2:D3 = 5V G#: Pin J2_2:D4 = 5V A : Pin J2_2:D5 = 5V A#: Pin J2_2:D6 = 5V B : Pin J2_2:D7 = 5V (the octave doesn't matter) [/code] Best Regards, Thorsten.

Unfortunately Java doesn't allow to send common MIDI events in SysEx packages. :-( So, you have to find another solution, e.g. you could use MIDI-Ox (if you are using Windows) or MIDI-Pipe (if you are using MacOS) This remembers me, that I wanted to add an alternative control to this application (e.g. switching pins via MIDI keyboard) Best Regards, Thorsten.

But the last example was already your MMC handler - please let me know what was unclear here? I just have released a new midibox64e_v2_2d package (-> http://www.ucapps.de/mios_download.html), where you will find informations about the mk_syx Script under tools/mk_syx/README.txt, and the MMC handler example under meta_examples/3/mb64e_meta.inc Best Regards, Thorsten.

The preset patches are part of the release package (-> presets/ directory) - it's really hard to miss them ;) Best Regards, Thorsten.

You could use AU Lab to create a direct path from an Audio In to Out. This nice utility would even allow you to insert some Audio Unit based effects - basically it works like a Windows Mixer, but it is much more powerful - let's say it's a DAW replacement without recording/playback capabilities :) After the setup has been done, you could store the configuration in a .trak file, so that it can be recalled with a simple doubleclick on this file. The application comes with the Xcode package, which is located at the first installation DVD of MacOS (10.4, 10.5 and 10.6) After installation, you can start it under /Developer/Applications/Audio/AU Lab.app Best Regards, Thorsten.