jbartee

Hey guys. So I know it's been like a year, but I finally got around to doing some better video documentation. There's three new videos up on my youtube channel. Hopefully they'll generate some more traffic for ucapps.

I know this doesn't have anything to do with anything, but your avatar is killer. Boulder Dash is one of my all time favorite c64 games ever..

Hi Jordan, In order to use the LFO's they must first be assigned to a parameter using the modulation matrix. Similarly, the ARP must be turned on before it will do anything. These kinds of patch editing capabilities are not available via CC's. There are a few different ways to do this: Easy options: 1. Download the MidiBox Sid V2 SysEx Editor ( http://www.ucapps.de/midibox_sid_manual_ed.html ). This is a java based patch editor that allows you to create patches and upload them to your MBSID. 2. Build a minimal control surface. 1 encoder and a few buttons will give you complete access to all the editing functions. This is really what I'd recommend. Some more hardcore options: 3. Bust out the SysEx implementation chart ( http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fdoc%2Fmbsidv2_sysex_implementation.txt ) and use something like Max/MSP etc. to send your own SysEx strings for enabling and patching the stuff you want 4. Build a full control surface, because it's awesome and you'll be happy you did it when it's finally done. :smile: I'd say check out the SysEx editor for now, aim to a build a minimal control surface soon, and expand it to a full control surface later. As for option 3, there's no real reason to futz around with building your own SysEx front end unless there's some specific custom implementation you want to do.

Holy crap: I must have this.

I agree it would be best to integrate into mios studio, but sadly my knowledge of C++ is extremely noobish. I'm trying to learn more but I doubt I haz the skillz currently to pull this off with "real code." I've already started building the max implementation however, and if someone with more chops wanted to adapt the architecture, it would probably be pretty straightforward.

It occurs to me that what we really need is a calibration tool that will let you visually remove segments of an envelope, hear the resulting change in realtime on your mbsid, and then automatically determine precisely which regions should be omitted from the table. I think I can do this in max 5 by modulating cutoff using an nrpn, and then using a simple algorithim to convert from the current 14-bit step to the correct 12-bit step for use in the table. This way you could calibrate the filter in realtime, and only edit / upload the hex file once. If I get anywhere I'll post the patch here, as well as build a mac (and maybe windows if there's any interest) executable. I have a little time off in a couple days, so watch this space :smile:

No details missing! I posted "blind" before noticing that it had already made its way to the repository / official rc36 release.

Wow Thorsten, you're fast. Thank you once again for the awesomeness! Also lol @ NMFP. I wonder if you can walk me through the process here a little bit, since I'd rather not wait till the rc36 release to get this calibrated. The table can be compiled as a seperate hex file, or does the entire firmware need to be recompiled? EDIT: Oh, my bad, I just saw that RC36 is now available. Sweet.

Great news! I don't want to rain on the parade, but I'm still a little concerned because we don't know why attaching the LCD has spontaneously fixed the problem. If it works it works, I guess, but it would still be good to figure out what's going on. I wonder, when you removed the LCD originally, did you also remove the 1k pull up resistor on pin d3 of core j15 (shown here: http://ucapps.de/mbhp/mbhp_lcd_4bit_mios8.pdf ). Not having that resistor stuffed has been known to cause BOR style reset patterns similar to what (I think) was going on with your core. Anyway, the patch can be changed by sending a midi program change message. Most keyboard style midi controllers have this hard wired to generic + and - buttons. If you want to change a bank, send CC#0. Glad you got it working!

I'm just out the door to go to class, but tentatively I'd say it sounds like your core is constantly rebooting. My MB makes that popping sound immediately when I first turn it on. This would explain the delay also... every time the core resets, the SID modules and midi i/o must be reinitialized, during which time they will be inaccessible. You could confirm this by hooking your lcd back up (try without the backlight first) and see if you are getting the mios boot screen over and over again. Not 100% sure about this one, but start by checking behavior with the LCD. I wouldn't stick your other SID chip in just yet until we can figure out what's going on.

And here it is, commented in filter.cc in the latest resid source: "The function mapping FC to cutoff frequency has the shape of the tanh function, with a discontinuity at FCHI = 0x80. In contrast, the MOS8580 almost perfectly corresponds with the specification of a linear mapping from 30Hz to 12kHz."

Sigh. It's such a dilemma for me with 8580's. I vastly prefer the timbre of the 6581 filters... there's a certain warm distortion in the lower registers of the LP filter that just makes me incredibly happy, and it's the sound I remember from my old breadbox as a kid. But on the other hand the reduced bugginess of the 8580 is incredibly appealing. This latest discovery just makes it even worse - a beautiful filter that has a seriously messed up bug, or a functionally correct filter that sounds (to me) clinical and dry. Since it looks like this is the natural behavior of the 6581's (it's kind of hilarious that sidplay attempts to emulate it!) maybe it's not worth Thorsten's time and effort to build a workaround, especially since I seem to be the only one who's really noticed/cares about the issue. Unless TK is just feeling incredibly generous of course. :tongue: Otherwise I suppose I'll begin my quest for the 6581 "holy grail," since there are clearly some that fall on the good end of the bell curve with little to no jumps in the filter curve.