Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


jjonas last won the day on January 30

jjonas had the most liked content!

Community Reputation

48 Excellent

About jjonas

  • Rank
    MIDIbox Tweaker

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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.
  3. 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
  4. 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 ARM
  5. 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!
  6. 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.
  7. 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
  8. 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? Th
  9. 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.
  10. I ran into this a while ago. From the docs for NGL:
  11. 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 li
  12. 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.
  13. 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.
  14. Thanks! I will be able to check this next Friday when I'm back home.
  • Create New...