TK.

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.

Just to ensure that we have the same understanding ;) Not for the touch sensor, but as a good shield against noise (which would result into jitter). A perfect ground connection to the case is important, the connections via M3 screws are not sufficient. If you want to save money, it's a good choice. The motorfader project was created before BCF2000 came to the market, today I probably wouldn't do the effort anymore. We opened a BCF2000 case long time ago in doc's lab - the construction is impressively compact, faders and motors are directly soldered on a PCB. It was too hard (and dangerous) to find a way to control the faders directly with the core module. We haven't measured voltages, but it can be assumed that they are either 0-5V or 0-3.3V Yes, thats possible softwarewise, but the idea to connect the VCA CV directly to the MF wiper wasn't so bad, I think that this will already work, so that no AOUT module is required. I would need a frontpanel for my 16x16 BLM - I will write you a separate PM :) Best Regards, Thorsten.

Whenever a meta event is assigned to a button, pot or encoder, the meta handler will be called and here it's totally in your hand how the event should be processed. To improve the understanding, just let's try different code snippets. 1) send a constant SysEx stream - replace the code in mb64e_meta.inc by: MB64E_META_Handler_Enc MB64E_META_Handler_Fader MB64E_META_Handler_Button movlw 0xf0 call MIOS_MIDI_TxBufferPut movlw 0x01 call MIOS_MIDI_TxBufferPut movlw 0x02 call MIOS_MIDI_TxBufferPut movlw 0x03 call MIOS_MIDI_TxBufferPut movlw 0xf7 call MIOS_MIDI_TxBufferPut return [/code] Note that all Labels are assigned to the same code, so that encoders/faders and buttons can access the same meta events. Now assign "F0 00" to a button, e.g. with the mk_syx.pl script (I prefer this one), or with serge's SysEx editor (don't know if it still works, it hasn't been maintained since years, and I'm a Mac user...) The button should send this SysEx string. Depending on the button mode (OnOff/Toggle/OnOnly) it will be sent only on pressed, or on pressed/depressed button. I would recomment OnOnly mode here, so that the event will only be sent when the button is pressed, and not when it has been depressed Next step: as you can read in the comments: [code] ;; -------------------------------------------------------------------------- ;; This function is called by MB64E_midi.inc when a meta event (Fx xx) has ;; been assigned to a enc or button ;; You can use this handler to enhance the firmware by your own MIDI events. ;; Here you are able to send more than one MIDI event (i.E. two Note On ;; Events to control Cakewalk via MIDI remote with one button), or a ;; SysEx/NRPN string to your synthesizer, or just to toggle PIC pins ;; in order to switch relays... ;; IN: ;; on enc events (entry point: MB64E_META_Handler_Enc): ;; o Enc number in MB64E_CURRENT_ENC (BANKED access required!) ;; o first MIDI byte in MIDI_EVNT0 (no BANKED access required) ;; o second MIDI byte in MIDI_EVNT1 (no BANKED access required) ;; o enc value in MIDI_EVNT_VALUE (no BANKED access required) ;; ;; on button events (entry point: MB64E_META_Handler_Button): ;; o Enc number in MB64E_CURRENT_BUTTON (BANKED access required!) ;; o first MIDI byte in MIDI_EVNT0 (no BANKED access required) ;; o second MIDI byte in MIDI_EVNT1 (no BANKED access required) ;; o button value in MIDI_EVNT_VALUE (no BANKED access required) ;; -------------------------------------------------------------------------- Parts of the MIDI event (Fx xx, marked with x) are available in variables, which you can use to build your SysEx stream. E.g., with: MB64E_META_Handler_Enc MB64E_META_Handler_Fader MB64E_META_Handler_Button movlw 0xf0 call MIOS_MIDI_TxBufferPut movf MIDI_EVNT1, W call MIOS_MIDI_TxBufferPut movlw 0xf7 call MIOS_MIDI_TxBufferPut return [/code] The SysEx stream will contain the second byte of the MIDI event. E.g., with Meta Event "F0 11" this routine will now send "F0 11 F7" And with Meta Event "F0 22" this routine will send "F0 22 F7" Now try: [code] MB64E_META_Handler_Enc MB64E_META_Handler_Fader MB64E_META_Handler_Button ;; send F0 7F 00 06 xx F7 movlw 0xf0 call MIOS_MIDI_TxBufferPut movlw 0x7f call MIOS_MIDI_TxBufferPut movlw 0x00 call MIOS_MIDI_TxBufferPut movlw 0x06 call MIOS_MIDI_TxBufferPut movf MIDI_EVNT1, W call MIOS_MIDI_TxBufferPut movlw 0xf7 call MIOS_MIDI_TxBufferPut return and try Meta event "F0 01", "F0 02", "F0 03", "F0 04", "F0 05" with button mode "OnOnly" Success? Best Regards, Thorsten.

It would be required to overwork MIOS from scratch, e.g. because of overlapping memory ranges and missing support for multiple MIDI ports, resp. MIDI handling which fits with USB requirements (packet based transfers). All this has been solved with MIOS32, I don't plan to do the same for old PIC derivatives (especially because it would never work so perfectly like with STM32) However, if you have advanced programming skills, you could use the MBHP_USB_PIC firmware as basis and add AIN/DIN/DOUT/LCD drivers there - it's possible, but it will be some effort and it won't be compatible to the common MIOS8 architecture. If you are asking me: it isn't worth the effort, since with MIOS32 a better solution is already available. It's available here: http://www.avishowtech.com/mbhp/buy.html Best Regards, Thorsten.

yes, and you can apply different filter settings/modulations to the left/right filter by selecting the L/R channel via SHIFT->GP button 1 and changing the parameters in FIL and MOD page. Best Regards, Thorsten.

There wasn't a change in the application itself... however, I updated the ChangeLog: http://www.ucapps.de/mido128_changelog.html Best Regards, Thorsten.

Yes, it will work when you swap the two motor pins and the Ground/+5V terminal of the fader. Take care: the metal case of the fader still has to be connected to ground, and not to +5V! Best Regards, Thorsten.

ucapps.de is my website, as you can see at the bottom of each page. The .zip file got the wrong version number (v1.1d is the right one), I will change the filename, and also fix the documentation. Best Regards, Thorsten.

Shipped today: zygis simonfloris Best Regards, Thorsten.

In Germany we call this "Schwanzvergleich" - it's better not to translate this term. ;) Don't get me wrong, Propeller is a nice SoC and it was obvious that sooner or later somebody will implement a SID emulation for this chip. It would be interesting, how long you worked on this project, and if you feel that there are enough resources free (not performance, but also memory wise) to enhance it in future. Or would you prefer to add a second uC to control the emulated SIDs? Best Regards, Thorsten.

What is the 8th Propeller core doing - USB? Best Regards, Thorsten.