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.

I'm running recommended Ctrlr_ac6a3185.exe on Windows (it is now available from archive.org only). Selection SID1 - SID4 does not work correctly. Only SID1 selection produces expected results. E.g., I activate ENS tab. I can receive and modify patch # etc. for first core. When I switch cores (SID2-SID4), information seams to be received correctly, but when I modify any knob (e.g. patch#), it does not get stored to ENS buffer. The only condition under which it get stored, as I noticed, is when that particular SID core I've selected in CTRLR is selected on control surface also. From time to time I notice messages like "SIDx not available (No MBNet Response)" on LCD. Sometimes they last for a second, sometimes they stay. MIOS studio reports a continuous flow of messages F0 00 00 7E 40 00 0F 00 F7 from MIDI IN, when CTRLR is active.

I suspected it is so :-) I also looked through a soviet electronic accordion Estradin schematic. It has 12 tone generators heavily stuffed with logic elements.

I don't quite understand the theory behind this. Maybe someone could advice me an article or explain briefly. Why most of analog oscillators are very sensitive to temperature and tuning them is a real challenge while SID is not?

I used Arctic Silver Adhesive previously. It worked fine, but it is very strong glue, so once glued, heatsinks will be coupled with SIDs forever. I think it's a disadvantage, if one day you wish to sell your SIDs (at least a pictures of them could be taken before gluing). Using semi-permanent akasa tape seams to be a better idea. Maybe it is not as much thermically conductive, but many people run SIDs without heatsinks at all and do not care.

You can buy this not so expensive thing http://www.ebay.com/itm/182178120435?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT And split it into 4 peaces, if you have a dremel tool or something.

jaytee, you seem to be right. During my experiments I've discovered that chaining SIDs is more interesting that any of above mentioned applications of AUDIO IN. Also, balancing output impedances of SID and audio interface is not the challenge I'd like to accept. I have to disconnect matrix and other leds (not possible for people who soldered base board to control surface directly) in order to have external audio in passing through SID filter without loud hum caused by LEDs switching (mine are bright, maybe that's the case). Wiring (or cross-wiring) SIDs' outputs to inputs does not produce that much hum (however, it can also be reduced by disconnecting LEDs and matrix. It helps even if audio inputs are grounded). Maybe I should compile some special .hex file that does not light any LEDs for song bouncing?

So, I tried my idea with 10k resistor on SID's output also. I must admit that output from my audio interface comes from SID very attenuated, especially when it passes through filter (EXT IN is on). Feedback on SID doesn't sound that good (self-oscillating) with that extra 10k resistor also.

MIOS does not check for full transition cycle completion, it reacts on each edge regardless if there was a full turn or not. However the question remains. Meanwhile I'm trying to find manual mode for each encoder. But I suspect I'll have to replace some of them anyway :-( Or maybe set all to MIOS_ENC_MODE_NON_DETENTED and reduce their speed.

Thank you, guys. It's strange for me to think something wrong is with the quality of my Alphas. Maybe something with electronics? Yesterday I noticed one strange thing: I set DEFAULT_TESTMODE_ENC_SPEED to 1 and uploaded the application. So I started to experiment with NORMAL speed mode. Mode of all encoders was set to MIOS_ENC_MODE_DETENTED4 (0xa5), that means that the same edges triggers DEC and INC (according to diagram found in mios.h) I took a piece of wire, pressed one end to encoder's ground leg and started touching encoder's D0 leg with the other end. Touching and releasing, several times. Note, that I touched only D0 leg and did not touch D1 leg at all. And I've got a sequence of values like: 5,6,5,6,5,6,7,6,7,6,7,8,9,10,9,10,9,10,11,10,11,10, ... Increasing when I touch end decreasing when I release the wire is no surprise - that's exactly how MIOS_ENC_MODE_DETENTED4 should behave. What surprised me is that numbers started to drift in one direction, and sometimes in other direction. I thought that could be because of speed acceleration in random direction cause by bouncing contacts, but NORMAL speed test mode does not imply any acceleration. Is it intended to be? This drifting is strange, because for every INC (touch with wire) we have DEC (release). Even if some bouncing e.g. DEC is skipped, there should be no INC because no change was registered. Could anyone please explain, why it is so

jaytee, that's great your Bourns encoders work good. Have you removed detents? So, you never-ever have noticed them jumping back, right?

I'd like to experiment with SID filter supplied by my audio interface output to SID's audio input. I'd like feedback pot to remain because it gives extended possibilities bringing SID filter resonating capabilities to another level :-) So, I thought I could connect my audio interface output to the middle pin of the pot (the wiper) through 10k resistor in series. Like passive mixer schematics, but no additional resistor on SIDs output, because here no-fi managed to connect output buffers of 4 SIDs without any resistors at all. Is it a good idea, or, when feedback pot is fully clockwise I have a chance to burn my SIDs? I hope the only thing I can possibly burn - is the transistor, isn't it it's main purpose to protect SID's output?

Theoretically you are right, in newer MIOS8 versions we can select any combination of pulses that MIOS should react to. However, my menu (still detented) encoder works flawlessly IN ALL MODES comparing to other non-detented encoders, especially some of them. Non-detented encoders have to be set to MIOS_ENC_MODE_NON_DETENTED in order to work more or less evenly. This was my strange experience. Of course, in some modes detented menu encoder works with some multiplier (like 2x, 4x), but anyway without unpredictable jumping back and forth. Exactly these modes give me ability to adjust value precisely with non-detented encoders (though it jumps sometimes). It feels like detent gives kinda "guaranty" that full sequence between two detention points will be completed correctly (without bouncing?), and if it is removed and encoder gets an ability to stop somewhere in-between (increasing it's resolution though) - staying in these "in-between areas" can produce some bouncing. Just a feeling. Hawkeye, why did you recommend: "If you changed the angle of the metal tongue while flattening the dent with your caliper, push back the metal tongue to an angle as it had before" This tongue (which we flattened) does not have any electrical contact with any of 3 legs, as far as I understood detention is it's only purpose. Or may be I should have done that for some reason unclear for me yet :-/

Yep, but I wouldn't call it "stepping" in a standard way, because of the nature of described bug - it has audible consequences only when it occurs (i.e. value jumps). What about Alpha - they have to be good encoders, HawkEye recommended them here

Hello guys! Finally I reached my hands to try to fix jumping behavior of non-detented encoders on my MB-6582. Wilba says that only one (menu) encoder has to be left detented in his CS construction guide. I'm curious then why ALL 15 encoders are assigned as MIOS_ENC_MODE_DETENTED3 in setup_mb6582.asm by default ? Were MIOS_ENC_MODE_DETENTED* modes designed only for detented encoders? As for my non-detented ALPHA encoders MIOS_ENC_MODE_NON_DETENTED works best. However, not perfect (it's more noticeable on large range values like cutoff): even if I move encoder very slowly, sometimes value gets rapidly advanced by ~10 (jumps a little forward). And sometimes even it jump backward, but not so often at least (like MIOS_ENC_MODE_DETENTED3 mode does). By "forward" I mean sporadic acceleration, and by "backward" I mean direction opposite to direction in which I turn the knob. So, I've checked all the modes and MIOS_ENC_MODE_NON_DETENTED seems to be the most close to perfect. I've tried also another encoder. It is almost like my ALPHA, however without "ALPHA" logo on it's bottom and contacts are white instead of yellow. Metal tongue inside is also white, not yellow. I've made it non-detented also. I must admit, this encoder does not jump backwards in MIOS_ENC_MODE_DETENTED3 mode. Almost :-) It jumped to ~30 (of 256 range) back only once. I slowly moved it back and forth during 10 minutes - the feel is very symmetrical and uniform compared to original ALPHA, however, not as smooth and still a little "clicky" (may be I didn't remove detent perfectly). So, if I want to set a precise value - it feels a little rough and non linear compared to original ALPHA, but in large scope (when I turn encoder faster) - it works in polite and predicted manner. Please, let me know what do you think