rheslip

Forum Replies Created

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • in reply to: handing bitmapped MIDI parameters #118656
    rheslip
    Participant
      • Topics: 1
      • Replies: 8
      • Total: 9

      I finally got bitmaps working using global variables. Each of the six XFM2 operators has 7 buttons that are mapped to the bits in global variables 1 to 6. OP1 bits are stored in k1, OP2 bits in k2 etc. Each button has an expression in the property panel which toggles its bit in the global e.g. to set bit 1 in k1:

      setGlobal (1, setBit (global.k1, 1, modulatorValue))

      Each button has a name of the form “p1bit1” which means parameter 1 bit 1 (sysex parameter 1 in the XFM2 happens to be operator 1). When I receive a sysex patch dump from the synth I sync the state of the OP buttons using this ugly code:

      if paramnumber == 1 then
      op1=midiParam — save OP bits to update globals
      mod = panel:getModulatorByName(“p1bit0”)
      if mod ~= nil then
      if bit.band(midiParam,1) == 1 then
      mod:setModulatorValue(1, false, false, false)
      else mod:setModulatorValue(0, false, false, false)
      end
      end

      mod = panel:getModulatorByName(“p1bit1”)
      if mod ~= nil then
      if bit.band(midiParam,2) == 2 then
      mod:setModulatorValue(1, false, false, false)
      else mod:setModulatorValue(0, false, false, false)
      end
      end

      etc etc for each bit of each bitmapped parameter. Not elegant code but the elegant approach didn’t work. After all that I sync the globals to the parameter value which was saved above:

      panel:setProperty(“panelGlobalVariables”,Unit..”:”..op1..”:”..op2..”:”..op3..”:”..op4..”:”..op5..”:”..op6, false)

      “Unit” is a variable I keep in sync with global k0. Its used in sysex messages to address the XFM2 unit number.

      Other things I had to do:
      – go back to stable release 5.3.201 – I had all kinds of strange LUA behavior with later versions
      – had to recreate the entire UI using “copy with children” to cut and paste subpanels from an older version of the panel to the newly created one. I did this because the panels I had created with later versions of CTRLR would not work correctly under 5.3.201
      – CTRLR bug in copy/paste resulted in a whole pile of duplicated modulators which I had to find and delete using the modulator list. They generally show up as modulators with the same name in a phantom componentGroupName that is invisible. Quite tedious.
      – I’m still using numbers as modulator names which is “illegal” in Lua but it works. It makes finding the modulator by its sysex parameter number quite simple. That helps a lot because the XFM2 has over 450 parameters…

      It took about ten times longer than it should have but now I have a panel for the XFM2 that is working quite well. Still have to implement file load/save and a few other things but when I’m happy with it I’ll post it on the panel page.

      Thanks a lot for the suggestions and many thanks to the authors of the DX7 panel for sharing their work. The XFM2 panel is based on their UI and code.

      Rich

      in reply to: handing bitmapped MIDI parameters #118626
      rheslip
      Participant
        • Topics: 1
        • Replies: 8
        • Total: 9

        Excellent suggestion! The current implementation creates the name on the fly from the loop variables which is slower but less code. If I was to unroll the loops that would work very well which I may yet do. There are about a dozen bitmapped parameters so unrolling the nested loops is not too bad and it might miraculously fix my problem.

        So the XFM2 panel works for you under Win 10 5.3.201 – very interesting. I developed it on my old Win 7 desktop which has been showing signs of instability lately. I need to upgrade the machine anyway, this is more motivation. I could be chasing OS related problems.

        Thanks a lot for your help dnaldoog!

        Rich

        in reply to: handing bitmapped MIDI parameters #118619
        rheslip
        Participant
          • Topics: 1
          • Replies: 8
          • Total: 9

          Thanks for the suggestions!

          I have tried changing the button names so they start with alpha characters op1bit0 etc but it still didn’t work. I will try the other forms of setModulatorValue() and I’ll clean up the names too.

          FYI: the creator of the XFM2 Rene Ceballos has just released an alpha of a new FPGA synth that runs on the same $100 hardware. Its a subtractive synth with 32 voice polyphony, 4 osc per voice, 3 env gens, 2 lfos, stereo audio and the same wonderful FX chain as the XFM2. I have been playing with it and it sounds pretty good. He reused a lot of the XFM2 blocks so I should be able to create a CTRLR panel for this one fairly easily.

          XVA1 Virtual Analog FPGA synth

          You can bet I will be using the stable release of CTRLR to develop that editor!
          Rich

          in reply to: handing bitmapped MIDI parameters #118612
          rheslip
          Participant
            • Topics: 1
            • Replies: 8
            • Total: 9

            I’ll try dropbox links:

            XFM2 Operator page (image)
            XFM2 Global controls and effects page (image)
            panel file

            I don’t want to post the panel on the CTRLR panel page yet because its not feature complete and it has this annoying bug with the OP buttons. The OP buttons work correctly for editing the XFM2 – there are 64 possible algorithms times 6 ops. What does not work correctly is setting the buttons when I pull a patch from the XFM2. It works correctly if there is only 1 OP button set, but shifts them if more than one is set. Its very strange.

            I am setting the button values to either 0 or 1. I’m not using bit.band() anymore because the results were incorrect – more evidence that something is really messed up. I have a couple of lines of LUA that extracts the least significant bit of the bitmap using mod arithmetic and I shift right using division.

            If I install 5.3.201 I can load other panels OK but when I load the XFM2 panel the whole CTRLR UI changes – text gets larger, the panel tabs have a large X beside them. It doesn’t crash CTRLR but the XFM2 panel doesn’t work either.

            I would start over with 5.3.201 but creating those panels took a LOT of time. I have probably made a mess of this thing anyway.

            in reply to: handing bitmapped MIDI parameters #118597
            rheslip
            Participant
              • Topics: 1
              • Replies: 8
              • Total: 9

              This is what the XFM2 panel looks like at this point. Not pretty but it works – except for the OP buttons which update incorrectly when I sync the panel to the synth.

              XFM2 Operator control page

              XFM2 global controls and effects

              in reply to: handing bitmapped MIDI parameters #118596
              rheslip
              Participant
                • Topics: 1
                • Replies: 8
                • Total: 9

                The XFM2 sounds amazing. Its quite an easy build and its cheap. I found a few odd things but 99% of it works as advertised. A DX7 on steroids!

                I based my XFM2 panel on the DX7 panel by Sjoerd Bijleveld, Torsten Tittmann and Pascal Collberg. Used most of the same UI elements and some of the Lua code.

                I brute forced the MIDI message suppression with a flag and a timer. I didn’t realize you could do it with built in methods. CTRLR is cool but it seems you have to read a lot of source code to find these things out.

                I did a lot of cutting and pasting on this panel because there are six identical groups of operator controls. I noticed its easy to “lose” UI elements if you are not careful dragging them into position. I think this may be my problem – I’m guessing there are phantom UI buttons that are overwriting the ones I think I’m updating. I noticed the button text which should read “ON” or “OFF” is greyed out on one button after I refresh the UI. If I manually toggle it goes back to normal. I found and removed a couple of duplicated UI elements by searching the XML but when I update the UI those buttons are still not updating properly.

                I really wish I had started with v5.3.201. Now I find I can’t go back – CTRLR goes a little wonky when I load this panel with v5.3.201. All the evidence suggests the later versions I’ve tried are unstable. I REALLY do not want to start over! If somebody knows how to downgrade from later releases I would like to do that.

                Thanks for the suggestions!

                in reply to: handing bitmapped MIDI parameters #118592
                rheslip
                Participant
                  • Topics: 1
                  • Replies: 8
                  • Total: 9

                  Thanks for the tip on setting globals. That should work. In the meantime I went back to the code that uses a LUA array to store the bitmaps because it ~ALMOST~ works. If I use globals I have to go back and change ~400 UI properties which I would like to avoid.

                  in reply to: handing bitmapped MIDI parameters #118591
                  rheslip
                  Participant
                    • Topics: 1
                    • Replies: 8
                    • Total: 9

                    I fixed the race condition by using a timer to disable MIDI output while the UI is updating.

                    This is the loop I’m using to update the UI buttons for each bitmapped parameter. Each button has a name of the form “1bit1” which means it is sysex parameter 1 bit 1.

                    for j=0,7 do — set the modulators from the bitmap
                    local bitval=bit.band(midiParam, 1)
                    name = string.format(“%dbit%d”, paramnumber,j) — find the modulator for this bit
                    mod = panel:getModulatorByName(name)
                    if mod ~= nil then
                    mod:setModulatorValue(bitval, false, false, false)
                    end
                    midiParam=midiParam/2 — bit shift right
                    end

                    I spent a lot of time trying different things yesterday and concluded that LUA is not behaving correctly. eg bit.band (0xff,0x1) results in 0xff, if then else clauses not working, code that used to work no longer works etc. Just tried installing CTRLR 6.04 and it crashes when I run the problematic LUA code. The code was developed with 5.4.52 win64.

                    Maybe my panel is corrupted? I suspect I have duplicated modulators from cutting and pasting. Any ideas on how to clean up the XML?

                    Thanks

                  Viewing 8 posts - 1 through 8 (of 8 total)
                  Ctrlr