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.

Works!

Thanks! I will be able to check this next Friday when I'm back home.

The reason why the sender id's are the same: In this TK's example on if_equal the id's are the same for each command. I assume this works because the conditions are mutually exclusive, so that only one of the events will be triggered at any one time. The same id for all senders works ok with one button, but not with one encoder, which leads me to think it's not the sender id that's the problem.

The following setup is the same as above, only for a button instead of an encoder (the encoder setup is commented out). The button if_equal setup works as expected, the encoder one doesn't, even though to me they seem the same. The encoder value changes and the label updates on the display, but no receiver is receiving; for some reason the if_equal condition doesn't trigger like it does for the equivalent (so it seems to me) button value condition. RESET_HW ENC n=1 sr=1 pins=0:1 type=detented3 ROUTER n= 1 src_port=IN1 src_chn=0 dst_port=OUT1 dst_chn=0 ROUTER n= 2 src_port=IN1 src_chn=0 dst_port=OUT3 dst_chn=0 ROUTER n= 3 src_port=IN1 src_chn=0 dst_port=OUT4 dst_chn=0 ROUTER n= 4 src_port=IN2 src_chn=0 dst_port=OUT3 dst_chn=0 ROUTER n= 5 src_port=IN2 src_chn=0 dst_port=OUT4 dst_chn=0 ROUTER n= 6 src_port=IN3 src_chn=0 dst_port=OUT3 dst_chn=0 ROUTER n= 7 src_port=IN3 src_chn=0 dst_port=OUT4 dst_chn=0 ROUTER n= 8 src_port=IN4 src_chn=0 dst_port=OUT3 dst_chn=0 ROUTER n= 9 src_port=IN4 src_chn=0 dst_port=OUT4 dst_chn=0 ROUTER n=10 src_port=SPI4 src_chn=0 dst_port=OUT1 dst_chn=0 ROUTER n=11 src_port=SPI4 src_chn=0 dst_port=OUT1 dst_chn=0 ROUTER n=12 src_port=SPI4 src_chn=0 dst_port=OUT1 dst_chn=0 ROUTER n=13 src_port=USB1 src_chn=0 dst_port=OUT1 dst_chn=0 ROUTER n=14 src_port=USB1 src_chn=0 dst_port=OUT2 dst_chn=0 ROUTER n=15 src_port=USB1 src_chn=0 dst_port=OUT3 dst_chn=0 ROUTER n=16 src_port=USB1 src_chn=0 dst_port=OUT4 dst_chn=0 MAP1 1 5 6 9 10 12 16 EVENT_BUTTON id=33 hw_id=33 range=map1 value=1 label="@(1:35:1)Ch: %02d@(1:34:2)^synth" button_mode=Toggle EVENT_ENC id=1 hw_id=1 range=1:16 value=1 label="@(1:35:1)Ch: %02d@(1:34:2)^synth" # receive on channel 1 on port 1 EVENT_RECEIVER id=1 fwd_id=SENDER:1 fwd_to_lcd=1 type=NoteOn chn=1 key=any lcd_pos=1:1:1 label="Receiver%3i: %e" ports=0000100000000000 # send on channel 6 on ports 3-4 EVENT_SENDER id=1 if_equal=Button:33:1 fwd_to_lcd=1 type=NoteOn chn=1 key=any lcd_pos=1:1:2 label="Sender%3i: %e" ports=0000001100000000 EVENT_SENDER id=1 if_equal=Button:33:5 fwd_to_lcd=1 type=NoteOn chn=5 key=any lcd_pos=1:1:2 label="Sender%3i: %e" ports=0000001100000000 EVENT_SENDER id=1 if_equal=Button:33:6 fwd_to_lcd=1 type=NoteOn chn=6 key=any lcd_pos=1:1:2 label="Sender%3i: %e" ports=0000001100000000 EVENT_SENDER id=1 if_equal=Button:33:9 fwd_to_lcd=1 type=NoteOn chn=9 key=any lcd_pos=1:1:2 label="Sender%3i: %e" ports=0000001100000000 EVENT_SENDER id=1 if_equal=Button:33:10 fwd_to_lcd=1 type=NoteOn chn=10 key=any lcd_pos=1:1:2 label="Sender%3i: %e" ports=0000001100000000 EVENT_SENDER id=1 if_equal=Button:33:12 fwd_to_lcd=1 type=NoteOn chn=12 key=any lcd_pos=1:1:2 label="Sender%3i: %e" ports=0000001100000000 EVENT_SENDER id=1 if_equal=Button:33:16 fwd_to_lcd=1 type=NoteOn chn=16 key=any lcd_pos=1:1:2 label="Sender%3i: %e" ports=0000001100000000 # EVENT_SENDER id=1 if_equal=Enc:1:1 fwd_to_lcd=1 type=NoteOn chn=1 key=any lcd_pos=1:1:2 label="Sender%3i: %e" ports=0000001100000000 # EVENT_SENDER id=1 if_equal=Enc:1:5 fwd_to_lcd=1 type=NoteOn chn=5 key=any lcd_pos=1:1:2 label="Sender%3i: %e" ports=0000001100000000 # EVENT_SENDER id=1 if_equal=Enc:1:6 fwd_to_lcd=1 type=NoteOn chn=6 key=any lcd_pos=1:1:2 label="Sender%3i: %e" ports=0000001100000000 # EVENT_SENDER id=1 if_equal=Enc:1:9 fwd_to_lcd=1 type=NoteOn chn=9 key=any lcd_pos=1:1:2 label="Sender%3i: %e" ports=0000001100000000 # EVENT_SENDER id=1 if_equal=Enc:1:10 fwd_to_lcd=1 type=NoteOn chn=10 key=any lcd_pos=1:1:2 label="Sender%3i: %e" ports=0000001100000000 # EVENT_SENDER id=1 if_equal=Enc:1:12 fwd_to_lcd=1 type=NoteOn chn=12 key=any lcd_pos=1:1:2 label="Sender%3i: %e" ports=0000001100000000 # EVENT_SENDER id=1 if_equal=Enc:1:16 fwd_to_lcd=1 type=NoteOn chn=16 key=any lcd_pos=1:1:2 label="Sender%3i: %e" ports=0000001100000000

Hi, I'm trying to use an encoder to select the outgoing midi channel by using receiver, sender and if_equal. I'm able to change the channel in a "static" way, regardless of the encoder value, but I'm unsuccessful in trying to use if_equal to control which sender gets activated. The following setup (with only one sender and router routings disabled) works if I remove the if_equal=Enc:1:1. If it's in, the receiver does work, but the sender won't send anything, no matter what the encoder value is. Am I thinking this the right way? RESET_HW ENC n=1 sr=1 pins=0:1 type=detented3 ROUTER n= 1 src_port=IN1 src_chn=0 dst_port=OUT1 dst_chn=0 ROUTER n= 2 src_port=IN1 src_chn=0 dst_port=OUT3 dst_chn=0 ROUTER n= 3 src_port=IN1 src_chn=0 dst_port=OUT4 dst_chn=0 ROUTER n= 4 src_port=IN2 src_chn=0 dst_port=OUT3 dst_chn=0 ROUTER n= 5 src_port=IN2 src_chn=0 dst_port=OUT4 dst_chn=0 ROUTER n= 6 src_port=IN3 src_chn=0 dst_port=OUT3 dst_chn=0 ROUTER n= 7 src_port=IN3 src_chn=0 dst_port=OUT4 dst_chn=0 ROUTER n= 8 src_port=IN4 src_chn=0 dst_port=OUT3 dst_chn=0 ROUTER n= 9 src_port=IN4 src_chn=0 dst_port=OUT4 dst_chn=0 ROUTER n=10 src_port=SPI4 src_chn=0 dst_port=OUT1 dst_chn=0 ROUTER n=11 src_port=SPI4 src_chn=0 dst_port=OUT1 dst_chn=0 ROUTER n=12 src_port=SPI4 src_chn=0 dst_port=OUT1 dst_chn=0 ROUTER n=13 src_port=USB1 src_chn=0 dst_port=OUT1 dst_chn=0 ROUTER n=14 src_port=USB1 src_chn=0 dst_port=OUT2 dst_chn=0 ROUTER n=15 src_port=USB1 src_chn=0 dst_port=OUT3 dst_chn=0 ROUTER n=16 src_port=USB1 src_chn=0 dst_port=OUT4 dst_chn=0 # select outgoing channel EVENT_ENC id=1 hw_id=1 value=1 range=1:16 label="@(1:35:1)Ch: %02d@(1:34:2)^synth" # receive on channel 1 on port 1 EVENT_RECEIVER id=1 fwd_id=SENDER:1 fwd_to_lcd=1 type=NoteOn chn=1 key=any lcd_pos=1:1:1 label="Receiver%3i: %e" ports=0000100000000000 # send on channel 6 on ports 3-4 EVENT_SENDER id=1 if_equal=Enc:1:1 fwd_to_lcd=1 type=NoteOn chn=6 key=any lcd_pos=1:1:2 label="Sender%3i: %e" ports=0000001100000000

First two giveaways (3 DINS + 1 DOUT) to me please!

Works!

Thanks, it's working now!

Hi, I have the following situation. I'm controlling the parameters of a DSI Tetra, whose patch dump uses a "packed data format" (shown here at the top of someone's JS decoding algorithm) which deals with two-byte values in a way that's not immediately comprehensible to me; and even if I took the time to understand it, it probably wouldn't be possible to syxdump_pos two separate bytes into the same event as one value. For this reason I'm picking out only one-byte values from the dump and using NRPN increment and decrement commands to change the two-byte values (mostly envelope amounts from -127 to 127). However, the interplay between the two doesn't work as expected. When I use the setup below and turn the first encoder (sending an absolute value), the first param value changes as expected. Now I turn the second encoder (sending an increment or decrement command), and the second param value changes as expected. But when I now turn the first encoder again, it keeps changing the second param on the synth, even though on the NG it would appear that it's the first param that's being changed. On the NG it's the first param's value that's changing, but it's sent to the second param (on the synth). If I keep alternating between the first and second encoders, only the second param's value will change. The only way to break out of this is to turn a third encoder, which now changes a third parameter, and this seems to break out of the loop. If I turn the first encoder, then the second, the the third, then the second, then the first again, it all works as expected. But alternating between an encoder that sends an absolute value and one that sends an increment/decrement command seems to get tangled somehow. Here's my test setup. RESET_HW ENC n=1 sr=1 pins=0:1 type=detented3 ENC n=2 sr=1 pins=2:3 type=detented3 ENC n=3 sr=1 pins=4:5 type=detented3 ## param 4. VCF release EVENT_ENC id=1 hw_id=1 label="@(1:1:1)Rel%B @(1:1:2) %03d " range=0:127 type=NRPN chn=12 nrpn="26" ## param 6. VCF env amount. RANGE 0-254 EVENT_ENC id=2 hw_id=2 label="@(1:6:1)Amt " enc_mode=Inc01_Dec7F if_equal=0x01 type=SysEx stream="0xbb 99 0 98 20 96 1" EVENT_ENC id=2 hw_id=2 label="@(1:6:1)Amt " enc_mode=Inc01_Dec7F if_equal=0x7f type=SysEx stream="0xbb 99 0 98 20 97 1" # param 7. VCF sustain EVENT_ENC id=3 hw_id=3 label="@(1:11:1)Sus%B @(1:11:2) %03d " range=0:127 type=NRPN chn=12 nrpn="25"

Hi, I had some unexpected behaviour with the label parameter, and here' some tests I did. I'm using two 2x40 LCDs (the tests use only one), and I would have thought that you can fill the screen(s) with text equally well with one entry, on the one hand, or several entries, on the other, by using the @(x:x:x) to place text wherever on the LCD(s), as long as it fits. However, this appear not to be so, and I'm not sure what the reasons are. The way around it is to write the text from several events with identical id's, and if this is among the recommended ways, I have no problem with it. But the NGC documentation does say that "Each EVENT_* element requires a unique ID in the configuration file!", so that's why I'm wondering. RESET_HW ENC n=1 sr=1 pins=0:1 type=detented3 ENC n=2 sr=1 pins=2:3 type=detented3 ENC n=3 sr=1 pins=4:5 type=detented3 ENC n=4 sr=1 pins=6:7 type=detented3 # works EVENT_ENC id=1 hw_id=1 label="@(1:1:1)This text is 32 characters long!" # doesn't work. hard fault! #EVENT_ENC id=2 hw_id=1 label="@(1:1:2)This @(1:6:2)text @(1:11:2)is @(1:14:2)32 @(1:17:2)characters @(1:28:2)long!" # doesn't work #EVENT_ENC id=2 hw_id=2 label="@(1:1:2)This @(1:6:2)text is 32 characters long!" # works #EVENT_ENC id=2 hw_id=2 lcd_pos=1:1:2 label="This @(1:6:2)text is 32 characters long!" # doesn't work #EVENT_ENC id=2 hw_id=2 lcd_pos=1:1:2 label="This @(1:6:2)text @(1:11:2)is 32 characters long!" # doesnt' work #EVENT_ENC id=2 hw_id=2 label="@(1:1:2)This text is@(1:13:2)32 characters long!" # doesn't work #EVENT_ENC id=2 hw_id=2 label="@(1:1:2)This text @(1:11:2)is 24 chrs!!!!" # works. identical to the one above, only one exclamation mark less #EVENT_ENC id=2 hw_id=2 label="@(1:1:2)This text @(1:11:2)is 23 chrs!!!" # doesn't work. text in three places #EVENT_ENC id=2 hw_id=2 label="@(1:1:2)This @(1:6:2)text @(1:11:2)is 23 chrs!!!" # works. text in three places, only shorter than above #EVENT_ENC id=2 hw_id=2 label="@(1:1:2)This @(1:6:2)text @(1:11:2)is 15" # works #EVENT_ENC id=2 hw_id=2 label="@(1:1:2)This @(1:6:2)text" #EVENT_ENC id=2 hw_id=2 label="@(1:11:2)is @(1:14:2)23 chrs!!!" # works #EVENT_ENC id=2 hw_id=2 label="@(1:1:2)This @(1:6:2)text" #EVENT_ENC id=2 hw_id=2 label="@(1:11:2)is @(1:14:2)23 @(1:17:2)chrs!!!"