Strategies of using multicore MB SID without control surface

[skunks]

I’ve recently built quad-SID setup without control surface (2 core modules + 4 SID modules) to use warm and dirty sound of old 6581 SIDs.

Could you please suggest some strategies for working with multi core MB SID setup without a control surface? I know some of you guys build such machines - they can be seen in gallery and here is a project by Flexinoodle's and nILS in wiki http://wiki.midibox.org/doku.php?id=fnp-sid

So, I faced several challenges I have not overcome yet:

 

CTRL panel vs MBSIDV2_Editor_v0_5

HawkEye suggested using virtual machine with Windows XP in order to run fully functional MBSIDV2_Editor_v0_5 in modern MacOS-es (editor and library (with ensembles also!) manager in one program, wavetable editing capability etc). Maybe that’s the only "perfect" option, however now I’m trying hard to avoid it, so here we go. (BTW, in virtual WinXP scenario, do I need to pass MIDI stream through MIDI Yoke as described here? http://www.ucapps.de/jsynthlib.html) 

1.     I’ve tried to run MBSIDV2_Editor_v0_5 in my old MacOS 10.5.8 with mmj. I’m not sure mmj works correctly in my case. So, program failed on start up:

java -jar MBSIDV2_Editor_v0_5.jar

Exception in thread "main" java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/libmmj.jnilib:

at java.lang.ClassLoader$NativeLibrary.load(Native Method)              

at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1822)              

at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1715)              

at java.lang.Runtime.loadLibrary0(Runtime.java:822)              

at java.lang.System.loadLibrary(System.java:993)              

at de.humatic.mmj.MidiSystem.loadLibrary(MidiSystem.java:79)              

at de.humatic.mmj.MidiSystem.getDevices(MidiSystem.java:287)              

at de.humatic.mmj.spi.CoreMidiProvider.getDeviceInfo(CoreMidiProvider.java:38)              

at javax.sound.midi.MidiSystem.getMidiDeviceInfo(MidiSystem.java:173)              

at org.midibox.midi.MidiDeviceManager.rescanDevices(MidiDeviceManager.java:102)              

at org.midibox.midi.MidiDeviceManager.<init>(MidiDeviceManager.java:47)              

at org.midibox.apps.sidv2editor.SIDV2Editor.<init>(SIDV2Editor.java:44)              

at SIDV2Editor.<init>(SIDV2Editor.java:29)              

at SIDV2Editor.main(SIDV2Editor.java:91)              

 

2      Storing Ensembles and Patches created with CTRLR

I’m aware that Ctrl cannot send patches to EEPROM/BankStick. I have to transfer buffer to memory via Sysex Librarian in MIOS Studio or “F0 00 00 7E 4B <device-number> 0C 18 <type> F7” command. But how to store Ensemble?  Is “F0 00 00 7E 4B <device-number> 0C 18 <type> F7” the only way? Sysex Librarian doesn’t work with Ensembles.

However, I couldn't even edit Ensemble successfully in CTRLR, as I described in CTRLR based editor topic

 

Bank change via MIDI trouble.

This trouble is not related only to machines without control panel, however it is felt much more painful if there is no panel.

If I store all my patches in the first bank and do not use CC#0 to switch the bank – only Program Change message, there is no trouble. I can freely switch patches for master (midi channel = 1) and slave (midi channel = 2) cores.

Trouble starts, when I use CC#0 (Bank MSB message) before Program Change message. Bank switching for master core works fine. But for slave core it works fine only sometimes for the first time. Most of the time it switches to Patch#A002 somehow instead of particular patch from the second bank I want it to. Failure is guaranteed if CC#0 and Program Change messages is sent again to master core.

 

The problem is recreated in this song. Play it twice to disclose the bug:

 "strange behaviour of slave core bank selection in Logic 5.LSO"

 

This song is in Logic 5 on PC format. But it behaves the same in newer Logic for MacOS. I’ve checked it in Renoise also (however, in Renoise bank number should be multiplied by 128, because it contains both MSB and LSB). My old trusty MB6582 behaves the same of course.