JobeC

Hi, As you may have noticed, I too have some work in progress for MB Sid patch editor (SidPEC in SourceForge). The problem is that I got a bit too ambitious and the system is just growing. Currently the implemented stuff can read and write both MB Sid and SidStation patch bank SysEx files and model their contents as classes/objects. When I find enough time, the implementation will undergo more testing and making the function interfaces more robust. I don't know if you could (or should) utilize the classes in your implementation (or is it even possible to use GPL stuff and Steinbergs VST stuff in same code), but still it is an alternative. (And the evil idea here is that VSTi could offer both GUI and a real MIDI interface ;) ) But if these two projects could be merged, it'd might be fruitful. -- Jouni

Finally I managed to get the system into a state, in which I can make an alpha file release. At this stage, there are classes that model patch banks, individual patches etc on both SidStation and on MB Sid. I tried to make them so that someone could make a patch editor using those classes, so they contain a bit too much stuff for only this conversion routine. There is also a simple conversion program implemented, that reads a SidStation patch bank and then prints the contents and/or tries to convert it to MB Sid format. The actual conversion is still _very_ crude, but at least it is a start. The release contains sources and binaries for linux and win. http://sourceforge.net/project/showfiles.php?group_id=116852 Have fun! Â :) -- Â Jouni

I thought that the most recent code should be also available for people, and as a result it can be found from now on at http://sourceforge.net/projects/sidpec/. The current state is not too high, but it's a start. The time will show if actually something useful (or working) will be reached. :) -- Jouni

That's just what it is supposed to do (for now at least). Â :) It just reads the patch file and displays the contents, no conversion takes place. The conversion itself is not so direct, since the inner functionality of MBSid and SidStation differ a bit. As the program displays quite much information when run, I recommend that you direct the output to a file and inspect that afterwards. I.e sspr_cmd patch.syx > file.txt I can try to implement some kind of a crude automatic conversion (and a GUI), but I won't promise anything. (Edit 22.7.) Some kind of a conversion routine is now almost done. As I expected, there is a lot of differences between MBSid and SidStation, so the conversion result is probably quite poor. The structure of a "normal" patch is about clear to me, but the wavetable is somewhat unclear. I.e. I didn't find any good reference on how the patch has been constructed, so WT conversion is not done. (I'll publish the new sources and binaries after I've implemented also the WT conversion and tested the routine.) -- Â Jouni

As I had some spare time and interest, I ported the ssPatchReader to win platform. The slightly modified sources (that will compile on both win and linux) and resulting win binary is available at http://sammal.ton.tut.fi/~paulus/sspr/ (if the server has not crashed).

Evening folks, I spent few moments reminding myself of C++ programming and created a simple patch reader that reads SidStation patch SysExs and displays the information. Unfortunately I have no idea whether of not the extracted data is correct. (Sorry, no perl nor python here :) ) The utility source code files are available at http://sammal.ton.tut.fi/~paulus/ssPatchReader_0.1.tar.gz. I have compiled them only in linux, so any other OS a big question mark. I guess it should port quite nicely. Please, do send comments and feel free to develope the code further. And if you create any cool new sounds with the help of this utility, please do share them with other SidBoxers. And a small question for TK: is the patch SysEx format of SidBox available in anywhere else than within the source code of the JSynth? -- JobeC

Hmm.. Of course it possibly couldn't be so simple. :) Seems that the register indices are a bit messed. The regs 4, 11 and 18 are skipped and they are inserted to the <mask4> and <msb4>. As far as I could decode the data, there may be two consecutive writes to these 3 registers in one data packet. I wonder is this correct... I updated the .txt file and there is now a table which should tell the correct location of bits for each register. I clarified the lsb/msb thing a bit, too. There is still some oddities at least in the filter register values. I'm working on that . And the 100% sure thing... I'm not 100% sure about anything in the spec. :D That's why it'd be nice to get some feedback if it works or not.

This is what I managed to find out about the protocol (got some info from Elektron) and it seems to be consistent with the SysEx's that ASID and Sidplay/w send. http://sammal.ton.tut.fi/~paulus/asid_protocol.txt I don't have the needed MIOS programming experience to implement it (at least at this point), so I'll just provide this info. The protocol seems quite simple, so maybe it could be implemented as an additional feature to the normal SidBox? E.g. menu item "Play .sid" and then the system would go to a state where it would just play the data received from computer. Or recognize the "start playing" SysEx-command and enter the playback mode. Or some other scheme, these just came to my mind. :)

When you are uploading the MIOS with Midi-Ox, the core should return status messages after every packet. The messages contain a status code and the check sum of the previous packet, see http://www.ucapps.de/mios_bootstrap.html. The correct check sums can be calculated e.g with the hex2syx script. If the core returns correct sums and 0F status, it should write the MIOS correctly.

You could try selecting a patch from the library in JSynth and choosing "Play" from the pull down menu. Then it should play that sound once. There should be some life in the connector. I guess the heating is normal behaviour. At least 6581 seems to get unbelievably hot, but the 8580 stays a bit cooler.

Ok. Thanks.

I was just wondering will it cause any problems if I connect LTC (without the MAX232) and (a) slave core(s) at the same time in a multi-SID setup? I mean, since they all use the J11 of the master core. My reasoning says, that it'll work since the LTC is a passive module in this setup, just replicating the data to outputs. But because I tend to blow up electronics, I thought, it may be better to ask what do the wise men think about this matter. ;)

-- Edit -- Eehh.. Nevermind. I guess inspection done visually and with multimeter is not accurate enough. The problem was solved by resoldering the connector on the SID-module. :)

Last night I built a second SID module, and as could be expected it didn't get up and running as easily as the first one. When I power it up, the LCD displays the MIOS information and then just P 1 C 1 1--- <empty> I have a BankStick connected to the core and there should be patches available. If I remove the cable to the J2 of SID, the LCD displays "Loading From BankStick". The only sound I get from the module is just random noise. The SID-IC has been tested with another module and it is working, so are the other ICs. The IC voltages are ok. The module is almost identical to the previous one (except different caps and regulator, because of 6581 -> 8580 change, and BC547 -> BC546). I haven't found any shorts by eye or multimeter, yet. Any ideas what might be wrong?

I got all the other parts already from a cheaper dealer, but the encoders seem to be somewhat rare to the local shops here. So, when needing just one encoder, there is no use in ordering them e.g. from Sweden. Luckily, I got one local dealer to order the encoder from RS Electronic when they order some other stuff from there. Hopefully it'll be ok. (Extending my one-SID -box to dual-SID with the minimal control surface.) :)

Yet another encoder choise question. It seems that the production of the Alps EC16B24 (http://international1.farnell.com/Search/level_5.jhtml?PRODID=89285&SKUID=87224) encoders has ended. At least I was told so by Farnell. So, the question is now what to use instead? They offered to me EC11B15 (http://international1.farnell.com/Search/level_5.jhtml?PRODID=89283&SKUID=87222) which is twice the price (almost 10e each) and has some switch in it. Maybe some encoders by Bourns? http://international1.farnell.com/Search/level_5.jhtml?PRODID=4803&SKUID=2742 which is about the same price or http://international1.farnell.com/Search/level_5.jhtml?PRODID=62469&SKUID=60408 which looks like an el cheapo model? Or if someone knows a better option from Finland?

I use the Opera browser and installed the Java Runtime that came with it. And the JSynth works with it (on a Win2000). But not fully. E.g when trying to edit a patch with it while the SID is connected, the JSynth just freezes. BTW, check that you have the Java Runtime in your path. Or run a command prompt and try to run the .bat "manually" from it and see what it says.