lokki i "preprocess" all cc messages like this to route them per channel and cc number easily, maybe heavy/pd does not like the message $ or something...

When you say this:

lokki just sending the messages to heavy without even connecting anything in heavy/PD leads to dropouts

what does the patch look like? Just [ctlin] without anything connected to it? Can you try with deleting [ctlin] altogether?

        giuliomoro what does the patch look like? Just [ctlin] without anything connected to it? Can you try with deleting [ctlin] altogether?

        no it was with [ctlin] and my preprocessing, but without anything connected to the route objects. will try to delete the ctlin on my big patch and see what it does.

        in the meantime i created a much smaller test patch which is much lighter on cpu and the results are as follows:

        block size 16, no underruns. cpu at 22%
        block size 8, no underruns. cpu at 30%
        block size 4, underruns. cpu at 44-48%

        so it seems that anytime i get close to 50 % usage the underruns with midi input start to happen. (i know that with a block size 4 there is even less time for other processes)

        if i delete the [ctlin] from my test patch, i get no more underruns even at 4 blocks.
        if i leave [ctlin] in there but disconnect it from everything else still no underruns.
        if i connect it to the pack object and disconnect everything after, no underruns
        ...only when i attach back the midi controls to the corresponding endpoints the underruns happen again.
        which indicates that it is indeed a "problem" in heavy/pd (or my patch) and not before. my test patch is very simple though:

        alt text

        will now test with my actual patch...

          ok the actual patch with no [ctlin] object has almost no underruns, but still some. the CPU indicator shows 55%.

          the patch with a [ctlin] in it, but not connected to anything has much more underruns. so this is different to the test patch before, but CPU usage is also higher.

          i still wonder if i do something in my patch (not midi related) that spikes the CPU, and i don't see it. and as soon as some midi messages come in it pushes it over the border.

          yeah, I believe something is 'spiking' which is holding up all processing hence why the midi message arrive in a single burst.

          (I really would not expect to ever see more than 1 message in that queue, given the regularity its called)

          but hard to know whats the spike is, could be heavy, could be the patch, could even be something related to IO over USB.

          now I don't think its USB IO as I do quite heavy usb IO with the soundplane, and its ok. however, I dont use midi (and so alsa) , and I don't use heavy. (*)

          as for the tests.
          I think if you have ctlin contained in your patch, but not connected - then I think heavy is doing all its work (in terms of distribution) .. so if its not underruning then, id say there a spike in your patch perhaps as a result of midi messages coming in. at least that would be my initial working assumption....

          you could try to 'replicate' this by removing the midi io entirely and creating an lfo or sequence (or similar) which 'emulates' what you'd expect from your controller then
          - if it underruns you know its something in the patch (unrelated to midi)
          - if it doesnt underrun (and its a fair emulation 😉 ) then it points back to midi.

          note : I must admit I've also been really careful how I put together my apps though, in particular I do as much processing as possible OFF the audio thread.
          if I take your example above, all the processing of your CC messages would be done in an aux thread. (eg. route /127, motf) - unfortunately thats not possible with PD (esp heavy)

            thetechnobear so if its not underruning then, id say there a spike in your patch perhaps as a result of midi messages coming in. at least that would be my initial working assumption....

            i have a feeling that the [line~] object does not translate well in heavy. i have quite a few of them in my patch (basically all midi input is smoothed that way) and i will try to replace them with a [sig~]-->[lop~ 30] combo.

            yeah, let the spike hunt begin!

              a month later

              thetechnobear - if it underruns you know its something in the patch (unrelated to midi)
              - if it doesnt underrun (and its a fair emulation 😉 ) then it points back to midi.

              ok, a bit late but i just ran some tests...

              if i substitute the midi-in part with a [metro 5] connected to a counter (0-127) and feed that to the point where the CC was connected i get no underruns at all, so it is really the midi which is causing the trouble. i even left all the midi-in in place, and as soon as i start to press the PADs on the quneo the underruns start to appear again.

              i think a [metro 5] is quite a fair emulation, no?

              this is driving me a bit nuts, since i cannot use the rest of the CPU (i am at about 55% with block size 16 now) without getting very frequent underruns when using midi input.

              BTW. replacing the [line~] objects did not help either, it all points back to midi.

                  giuliomoro That would be done as:

                  int msgs = 0;
                  int maxMsgs = 5;
                  while(msgs++ < maxMsgs && (num = midi[port]->getParser()->numAvailableMessages()) > 0)
                  {
                  ...
                  }

                  Make a note about the earlier points about increased latency of this approach.

                  @giuliomoro
                  i just tried this as well. values as low as 2 for maxMsgs still produce underruns, only a value of 1 makes them disappear completely.

                    ok, i now pushed the patch a little further (by integrating some more fx stuff) and now it even underruns with the maxMsgs at 1.

                    if i don't input any midi it still fine though. (midi objects are in place, i just don't touch the pads)

                    is there a way to see if my patch has some spikes in cpu usage even without midi? (and that one midi message causes the underrun)

                    can i try another lower level fix to throttle midi data?

                      lokki is there a way to see if my patch has some spikes in cpu usage even without midi? (and that one midi message causes the underrun)

                      do you have a good scope?

                      EDIT: digital scope that can do some basic stats (average, min, max of the duration of a pulse).

                          giuliomoro yes i have one.

                          EDIT: at least i think it can do those operations, i never used them :-)

                            You could toggle a GPIO before and after the heavy callback. Use this example as a starting point. Basically, besides the code in setup(), you'll need:

                            gpio.write(1);
// code you want to test goes in here
// ...
// ...
gpio.write(0);

                            So you could start from:

                            gpio.write(1);
hv_processInline(gHeavyContext, gHvInputBuffers, gHvOutputBuffers, context->audioFrames);
gpio.write(0);

                            and then see if you can spot some inconsistencies there. If that is not the case, move gpio.write(1) earlier, possible to the top of render(), but I think it is most likely that the bottleneck will be hv_processInline().

                            Then connect the scope to the GPIO in use and see if you see irregularities in the length of the callback.

                            thanks, the link is dead though...

                            lokki if i substitute the midi-in part with a [metro 5] connected to a counter (0-127) and feed that to the point where the CC was connected i get no underruns at all, so it is really the midi which is causing the trouble. i even left all the midi-in in place, and as soon as i start to press the PADs on the quneo the underruns start to appear again.

                            could you do something like

                            [metro 5]
|
[t b b]
|  /
|/ 
[whatev]

                            ?

                            This way you are actually sending two messages during the same callback, and it would be equivalent to having two messages coming in during the same render().

                            Are you sure your [metro] behaves exactly the same as [ctlin]? Maybe the latter involves some swap/pack/route that the former doesn't?

                            Also, you may want to add --high-performance-mode to the command line options. This will increase the amount of CPU available for audio.

                                giuliomoro --high-performance-mode only increases the underruns...

                                presumably because the midi comes in in even larger junks...

                                  that's possible, and an interesting reason not to have it on automatically :/

                                  ha! you were on the right track.

                                  alt text

                                  i used this "fake" midi input and i am finally able to reproduce the underruns. this sends 3 messages at once to my midi parsing patch. hmm, still don't know what the issue is really. i use [route] to parse the midi, is that a known problem? are there any better ways to get individual cc messages from a ctlin object then to use pack and route like so?:

                                  alt text

                                  I don't know of any specific bottleneck in heavy, but I wouldn't be surprised if it had something to do with $ substitution. What about one of the two options below?

                                  EDIT: Removed the preview of the patch, as it was causing troubles, as outlined below in > giuliomoro

                                    hey giulio, that is great! it works much better with the [pipe 0] solution, almost no underruns anymore.
                                    why the [pipe 0], btw?

                                    i will try to substitute some $1 messages in my patch then...

                                    no, [ctlin 10 1] does not work in heavy, that was why i used the solution i did.

                                    so. i have quite some $ substitutions going on. what would be your advice for something like this:

                                    (number input)
|
[$1 20(
|
[line] or [line~]
|

                                    do i use [pack 0 20] ? since [pack $1 20] has the same substitutions as the messages i guess.