jjonas

Someone please lock this thread, it's just encouraging false hopes that something's going to happen.

The precompiled MIOS Studio available for Linux on this page works on my desktop computer but not my Thinkpad T400 (both computers are running Arch Linux). Attempting to run it on the laptop gives an "illegal command" error message. (I'm not too familiar with these things, but the desktop is AMD while the laptop is Intel, perhaps that makes a difference if the downloadable version was compiled on an AMD computer?) Anyway, I would like to attemp compiling it myself for the laptop, but I cannot locate the unpack_me.zip in the Github repository. The MIOS Studio page says, "The source code is available in the GIT Repository. It requires the Juce v2 release to compile; just unpack the files under tools/juce/unpack_me.zip", but there's no such file in the directory at the link. Where is it?

Hi, I haven't promoted my band's music on the forum before, but we have been grinding out a number of EPs since 2015 that feature the Midibox SID. Here's a link to our newest, published today: https://astrometrics.bandcamp.com/album/paradroid

The order number is 002188 (it was shipped on 12 January). Unfortunately I don't have a C64 available. I think the cable was correctly connected. But I can test it again, both with the cable and without it, and see if it makes a difference in my situation.

Hi Martin, thanks for your input into the discussion! My message was based on my direct (and relatively uninformed otherwise) experience, where putting an ARM2SID pair into my MB6582 SID synth (connected with the included cable, and replacing two 6581 SIDs which produced a stereo sound) resulted in a mono sound, while putting two "main" chips (taken from two ARM2SID pairs) into the same sockets (without the connecting cable) resulted in a stereo sound. I didn't change any settings in the chips, or in the synth. What could explain this? Do you think it can be explained by looking at the ARM2SID pair alone, or should the MBSID harware and firmware be considered as well?

I bought two pairs of ARM2SIDs, here's my experience. The first thing to say is: in my opinion one should not buy one ARM2SID for their MBSID for any reason. Buy two ARMSIDs instead. If it's true as dwestbury says a few messages above — and it would seem to be true — then the other chip in an ARM2SID pair is a dummy which makes no actual sound; instead the sound of the main chip is just doubled. Obviously that doesn't produce a stereo sound, only a louder mono sound. Maybe that's what a C64/128 user needs, but it's the wrong solution for an MBSID. Fortunately I could use the main ARMSID from each pair I bought to make one independent pair where each chip produces its own sound. And that sound is very good, I do recommend it (just check dwestbury's sound samples above). Unfortunately I effectively paid almost double the price for two ARMSIDs because I could use only half of what I bought (ARMSID = 28€ vs ARM2SID = 48€). But that's the nature of DIY sometimes :-) Hopefully this "research" will benefit someone else! As to the installation, it was a drop-in affair — no configuration needed on an actual Commodore 64/128 (which I don't have). Not sure whether it makes any difference, but I'm giving them 9VDC and that seems to work.

If it's possible to do a popular SID track (which I guess could be easily compared to something on YouTube), that would be great!

Have you had a look at the Beginner's Guide? Perhaps section 4. Entering notes (and subsection 4.1.4. Live recording) could be useful for your situation.

I didn't make any progress after the last message I wrote, unfortunately. I don't remember the details anymore, but based on what I wrote above — that sending 4000 bytes from the computer works ok, but sending a somewhat smaller number of bytes from the synth doesn't — I think I concluded that it's too much work for too unlikely gains. One of the reasons for this lack of faith is that the synth in question, DSI Tetra, has some problems, or at least some unpolished characteristics, with the combo mode. That's why I think it's possible that the syxdump problems might be because of the implementation of the synth, and that there's nothing I can do on the MBNG side. After all, a big test file dump from the computer to the MBNG works ok.

I uncommented all RECEIVERs and SENDERs except for one RECEIVER that receives the dump. My setup is such that the dump from the synth goes through a SEQv4 (v4+.095) before reaching the NG. If I bypass the SEQv4+ and put the dump directly into the NG, there doesn't seem to be dropped bytes, but if the dump goes through SEQv4+, some bytes (somewhere after the 1000 bytes mark) would seem to drop. The router on the relevant ports on the SEQv4+ is all channels in, all channels out (not sure if that affects sysex). Is it expected that routing the dump through the SEQv4+ could cause problems? The seq's info page shows CPU load 15% during the dump and no registered drops. UPDATE: I noticed today (13.2.) that even though I get the dump directly into the NG (and with only one receiver event) some bytes are jumping around between requests. So it might not have anything to do with SEQv4. I tried sending a 4000 byte test file from the computer to NG, that seemed to work ok, maybe I'll have to try different midi cables... UPDATE2: I tried 4 different midi cables, no difference. The next thing to try is to dump the data on the computer and diff the files to see if it's the synth that's sending inconsistent dumps.

I think what's limited to 8 characters is the label variable (like ^destpane), not the actual string that's displayed on the LCD. In your example above you have strings that are more than 8 characters ("VCO1 FREQ" has 9 characters), and in fact you're not limited to 8 characters with the "VCO1 FREQ" style texts you want to show on the LCD. The variable length in characters (^destpane) and the string length in characters ("VCO1 frequency") are not related, so you can have short variable names and long strings for them.

I ran into this a while ago. From the docs for NGL:

Hi, I trying to pick parameter values from a sysex dump that's over 1000 bytes long (a DSI Tetra combo edit buffer dump), is that too much for syxdump_pos? It's not possible to request a smaller slice. Requesting and receiving 439 bytes (normal mode edit buffer dump) seems to work ok, but with the <1000 dump I'm getting strange results at least from byte 137 onwards for some reason. Parameters values that should be in bytes one after the other are not; it appears as if some bytes are missing in between. For the moment I'd just like to determine whether or not it's a syxdump_pos limitation that might be causing the behaviour.

Not sure if this old thread is relevant anymore, but since it's pinned, I'll mention it here: I have three setups which take 41%, 44% and 95% of the available memory (64k) and contain 472, 569 and 1037 events respectively (as reported by MIOS Studio). I had to comment out some events in the last setup to make it fit (1066 events was a couple too much!). However, I don't require any changes, I didn't have to let go of anything important.

If you want to change the code to effect this, I cannot help, but the patch that comes up after power-on is saved with the emsemble.