midi thinning

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