howto get feedback from panel:sendMidiMessageNow()

Home Forums General Using Ctrlr howto get feedback from panel:sendMidiMessageNow()

Tagged: 

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #72169
    Mr.ToR
    Participant
      • Topics: 7
      • Replies: 51
      • Total: 58

      Does anyone know of a trick or method to receive a feedback from panel:sendMidiMessageNow(CtrlrMidiMessage(midiMessage))
      I need to do the following:

      result = panel:sendMidiMessageNow(CtrlrMidiMessage(HexString))
      continue = false
      repeat
      if result then
      doSomething()
      continue = true
      end
      until continue

      #72170
      Mr.ToR
      Participant
        • Topics: 7
        • Replies: 51
        • Total: 58

        The problem is that if you issue a couple of panel:sendMidiMessageNow() calls, Ctrlr sends all of them at the same time. You can see this in the midi monitor. There should be an adjustable delay between them. This causes synth to not understand what’s coming in.

        I really hope Atom would implement a delay between midi sends feature.

        I’m on Mac.
        Version = 5.3.198, Build date = Tue Mar 15 15:53:07 PDT 2016, Branch = Nightly, Juce = 4.0.2, libusb = 1.0.19, liblo = 0.28,

        #72171
        Mr.ToR
        Participant
          • Topics: 7
          • Replies: 51
          • Total: 58

          ok, apparently there is a property called “panelMidiGlobalDelay” which puts a delay between each midi send. This solves my problems but I have to check if it creates any other performance issues.

          #72178
          human fly
          Participant
            • Topics: 124
            • Replies: 1070
            • Total: 1194
            • ★★★★

            timers.
            Possemo has shown me a great panel with loads of methods in it,
            for the matrix1000, seems to be Atom’s work. the matrix1000 has
            delicate sysex timing issues, as i understand it, so there are
            timers on various events to create delays while data is passing
            or writing.

            have you noticed that getRestoreState pauses MIDI?
            i’ve seen the ‘pauseMIDI’ script elsewhere as well.
            both used for letting midi pass one way only until
            transfer complete, to avoid 2way/midithru looping.

            i would VERY MUCH like to understand all about this.

            eg: what is that little script header intended to
            stop indexing issues as startup with getRestoreState,
            getProgramState – what’s that all about then? that
            seems to get included in many methods, rather than
            just a panelIsLoaded method.

            #72184
            Mr.ToR
            Participant
              • Topics: 7
              • Replies: 51
              • Total: 58

              ok, apparent this actually would create latencies on the modulators as well.
              So if you’re sending multiple messages for a program and need to have a little delay between each message, your synth might require a small delay between each message. so the solution is to use this parameter programatically and keep it normally at 0ms to avoid latency on the modulators.

              this is how I use it.

              panel:setPropertyInt(“panelMidiGlobalDelay”,20) — Set MIDI delay to 20ms
              panel:setPropertyString(“panelMidiPauseIn”,”1″) — disable MIDI input
              for s=1, 5, 1 do panel:sendMidiMessageNow(CtrlrMidiMessage(MidiMsg[s])) MidiMsg[s] = “” end — send 5 Midi messages
              timer:setCallback (9, TimerCallback) timer:startTimer(9, 1000) — enable MIDI input
              panel:setPropertyInt(“panelMidiGlobalDelay”,0) — Set MIDI delay back to 0ms

              #72186
              goodweather
              Participant
                • Topics: 45
                • Replies: 550
                • Total: 595
                • ★★★

                You can also look at my Pro2 panel.
                Look at Timers method (timers 3 and 4) and corresponding bank receive / bank send in the BankProceed_OnChange method under Programs library methods.
                Ctrlr was indeed sending too fast for the Pro2 to load. Therefore I introduced a 150ms timer.

                timer:setCallback (3, timerCallback)
                timer:startTimer(3, 150)

                This means that the code in timer 3 is executed every 150ms.
                In timer 3 you need to foresee a way to stop the timer at a certain moment.

                Good luck!

                #72187
                Mr.ToR
                Participant
                  • Topics: 7
                  • Replies: 51
                  • Total: 58

                  Hi goodweather,

                  Thnx for your post.
                  Actually, initially I was using timers but I had issues when a program was loaded from the library and when multiple non-midi-sending-modulators were updating at the same time; sendMidi sometimes sent very close messages even when I used timers, so to fix that I had to even include an additional initial delay as well to wait for modulators to finish updating, and then sending multiple messages with delays in between them, that worked, but that initial delay changes from system to system depending on cpu power and also it took a lot of milliseconds 🙂 timer method made additional processing and additional code etc, so now with this method I don’t have to care about any timing, different systems or timers etc and I can send multiple messages as quick as I want, not slower, not faster.
                  now with setting the global delay programmatically, it works flawlessly 🙂
                  I found this method to be very clean and working very nicely.
                  I highly recommend it.

                  Thnx a lot.

                Viewing 7 posts - 1 through 7 (of 7 total)
                • The forum ‘Using Ctrlr’ is closed to new topics and replies.
                There is currently 0 users and 38 guests online
                No users are currently active
                Forum Statistics
                Threads: 2,495, Posts: 17,374, Members: 77,605
                Most users ever online was 12 on January 22, 2019 3:47 pm
                Ctrlr