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

I need 2 AINSER64 and 1 AINSER8. I live in Ukraine

I'd like to buy an AINSER64 (maybe a couple of them) or AINSER8 boards or modules

Now it's interesting to know, how fast can LPC module scans one (or two) fully stuffed AINSER64 ? I've only found this info about old PIC based core: 12.8mS and more with Dynamic Priority handler ™ which scans the last two changed AIN pins more often than the others. For the project described above Dynamic Priority handler ™ would be useful for ~10 last changed AINSER pins (if scan rate is more then 0.2uS-0.5uS) in order to determine note velocity more precisely and send polyphonic aftertouch.

I forgot to mention: 3.3V is insufficient to feed BC's opamp. Feeding with 5V (taken from the core module) is a bad option because: 1. Output range is only 25% of 3.3V (CC values are 57 to 76 if mapped to 0..127), so much less resolution compared to floating ground 9V approach, that truncates unused lower half of the output. 2. It doesn't produce any changes if I suck the air in. But, I don't know why, I had no sporadic 127 values when powering with 5V from the core (I used 1.4k pot as a divider). May be the testing time span was to small so they didn't occur, I'm not sure. Cable of my BC-1 is very thin and obviously unshielded.

Hello guys! I'd like to share my experience of connecting Yamaha BC-1 breath controller to Core LPC (using MIDIbox NG application). First of all, I'm sorry but I didn't manage to obtain any AINSER module, so all test are done using onboard ADC. All 3 BC's are powered with 9V and output values in the upper half, but in a "mirrored" manner: higher voltage in rest and lower voltage when blown into. BTW, one can also suck the air in, then output value goes even higher, but doesn't reach 9v. BC-1 and BC-2 have a diode on their outputs (don't know about BC-3), so a pull-up resistor must be used (without it the output is "hanging": I get a random flow of CC values). There is a (not so good) option to power BC's with 5V, I saw this approach several times in the Web (e.g. for connecting to expression pedal input of a synth or to some commercial controller similar to sensorizer, e.g. Doepfer WE): I've found the following page on one forum (without a link to the source, but we may guess it's somehow related to some controller named MIDIBOARD): So after several experiments with different schemes and voltages, I settled on the above scheme. Doepfer WE manual recommends pull-up resistor from 1k to 4k7 (however, for 5V supply). Because above schematics outputs values more then 3.3V, I had to use a simple pot-based voltage divider instead of a pull-up resistor. I calibrated it and everything works fine... almost. Here was a good part. There is one annoying thing I still trying to get rid of: At first I used 47k pot as a divider. I've got a lot of 127 values in the flow. Even if I do nothing, they are flowing, like: 60, 127, 60, 127, 60, 127, etc. (60 is my value at rest if not adjusting pinrange etc, but simply setting output 0..127 mapped to 0-3.3V). I tried to increase the current by replacing my pot with 1.4k. It helped - now 127 values appeared ~ twice a minute. And finally I replaced my pot with 640 Ohm. Now I get 127 once a minute. So the problem is I cannot eliminate sporadic 127 values completely. And 640 Ohm divider I think is a waste of battery ;)

Update from TK is here

That's not the case, because I've noticed this feature with photo-transistor, then confirmed with POT. This feature is similar to dead band that I'd like to decrease a little. I seams to me that it works not only in zero neighborhood, but at any voltage. The only requirement - it has to be stable for some time. Then to be pushed to new value it has overcome +-4 threshold. BTW, mode is set to Direct.

Hello community! While experimenting with pots and other types of analogue inputs I've noticed a specific behavior: Let's say, some analogue input is mapped to certain controller with range from 0 to 127. If this input voltage is slowly rising from 0, MIDIbox NG does nothing and waits until this value is big enough to send at least 4. So, values from 1 to 3 are skipped. Fading works smoothly, i.e. values from 3 to 0 are sent. Then if I don't hesitate and rise the voltage again - rising goes smoothly (values 1 to 3 are sent), but if I wait a little and then repeat the procedure - values from 1 to 3 are skipped. Is this intended behavior of NG application? If so, could TK point me a place in code where it can be tweaked?

Thorsten, it would be great to connect computer (QWERTY) USB keyboard to MBHP_CORE_STM32F4 module. 1. It would give a quick (and dirty) start for beginners who are too lazy to solder a couple of DIN modules 2. There are a lot of keyboards for gamers with N-key rollover and latency up to 0.2ms (if polled more frequently then 1000 times per second :-) ). E.g. Bloody Lightstrike series from A4tech. So they can be used as kinda hex-keyboards, however without note velocity support. I used to play chromatic accordion and I find gaming keyboards pretty much applicable as a replacement.

PM sent