midi thinning

lokki

giuliomoro yes i have one.

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

giuliomoro

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.

lokki

thanks, the link is dead though...

giuliomoro

fixed now

giuliomoro

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.

lokki

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

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

giuliomoro

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

lokki

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

giuliomoro

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

lokki

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.

lokki

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.

giuliomoro

lokki [pack $1 20]

the dollar sign in objects has a different meaning than in messages: it's the first argument to the patch (e.g.: when used as an abstraction [mypatch 123], then $1 in an object is replaced with 123). Ultimately the arguments to [pack] are the initial values, but (assuming they work in heavy) they will be replaced by the inputs. So you could use

(number input)
|  [loadbang]
|   |
|  [20(
|  |
[pack f f]
|
[line]

(number input)
|
[pack f 20] // check that this works in heavy
|
[line]

or even, in this specific case with [line]:

(number input)
|
[t  f b]
|  |
|  [20(
|  |
[line]

giuliomoro

lokki a good way to measure the efficiency of each of these would be to have like a few (somewhere between 10 and 100) of these per callback (use [bang~] to trigger them) and then measure the CPU usage. At the same time it would be good to use the scope trick above to check if any of these has "unreliable" non-constant CPU usage

lokki

ok. thanks. i replaced some more $1 messages with pack and the underruns reappear :-).
so there is some strange interaction...

i will probably have to measure as you wrote, since this patch is driving me crazy

lokki

just a quick update:

the suggested [pipe 0] messes up the midi messages from the quneo. they hang at the second last message. on "snapback" controllers (pressure, position) the last resetting message never makes it into the system. removing the [pipe 0] does the job. so i wonder why it would be necessary in the first place?

giuliomoro

lokki the suggested [pipe 0] messes up the midi messages from the quneo. they hang at the second last message. on "snapback"

I see how that would create issues if there are more than one [ctlin] messages being received by PD at the same logic time. It was just a lazy workaround I guess 🙂.

This is the non-lazy version of the above:

alt text

« Previous Page