Who would have thought!

All kidding aside, I've made a patch that can tell which chord is most likely to come up, to be used in my jam-machine.

It looks at incoming notes and tries to recognize a repeating pattern in it.
When it does, it outputs the chord that was next in the last repetition.

It's functioning, but causes dropouts, even though the CPU-usage is below 2%.
The part that is at fault is a nested until loop.

I thought that 'until' spits out the next bang as soon as the "depth first" branch is completed, but no sooner.
Is this true?
If so, a until (even a nested one) couldn't cause a dropout as long as it doesn't tax the CPU too much, right?

I'm at a loss here. If someone could please have a look, the troublesome part is in MIDIchordImpro.pd->ChordProgresionChecker->Compare

Thank a lot!!!

Bart

PS: the patch is in alpha state, so don't expect too much of it. Also, some sub-patches are messy, though I've cleaned up the one that is giving me grief.

http://www.pdpatchrepo.info/hurleur/MidiChordImpro.zip

Roman Haefeli made this abstraction (attached).
According to him: "[nbuntil] works similar to the regular [until], but unlike the original,
it breaks Pd's principle of "depth first". It measures how much time
each iteration requires and delays the next iteration by this time. By
employing [nbuntil], many kinds of tasks can be performed without
causing drop-outs, that would otherwise block Pd for a certain amount of
time."
There is a help patch included which demonstrates its performance.
Didn't try your patch cause there were some objects that Pd couldn't create..never the less, I thought that this abstraction will be helpful.

http://www.pdpatchrepo.info/hurleur/nbuntil.zip

Oooh, thanks for posting this! I tried making something similar a year or so ago and failed miserably.

alexandros: Thank you for the quick reply! That helped a lot, but didn't solve it completely.

I would like to understand why this mostly works and until mostly gives xruns. Then I can hopefully change the algorithm so is just works.
I've read the thread on the mailing-list about nbuntil, but that didn't help much, since I'm not entirely clear on how the normal until works.
It seems my assumption that -until spits out bangs as fast as the underlying branch can bear, but no faster- is false.
Could someone point me to an explanation? 'until' is kinda hard to google on...

For those interested, here's the thread about nbuntil : http://markmail.org/message/binb3mv7ys657g5n#query:+page:1+mid:wk5t6kapa7dg3g2o+state:results

Maybe if I read it again in the morning it wil make more sense...

Maelstorm: For a moment I was glowing with pride, then I realized you where talking about nbuntil...

If you're using [nbuntil] you're basically just hoping the calculations get done in time for whatever deadlines you have in your patch design-- otherwise it will break determinism (which is way worse than dropouts which at least explicitly signal to your ear that there's a problem) unless you're extremely careful with how you use it. (And [nbuntil] has _no_ idea what these deadlines are-- how could it?) If you encapsulate it inside an abstraction, or multiple abstractions you're almost guaranteed to break Pd's determinism.

If you're interested in some weird, subtle Cage-style indeterminism where you don't even realize that's what you're composing, then replace all your [until] objects with [nbuntil]. If you're not then realize that you REALLY don't want to break determinism in your patches. If you're interested in making patches that you can maintain and understand, only use [nbuntil] for initialization tasks or in places where it doesn't connect with complex object chains.

The only place I've ever wanted this kind of behavior is with a threaded [soundfiler], and that should just be an internal/external object coded in c. The number of cases where the user needs to break determinism is certainly not so vast that a general-purpose tool like [nbuntil] is required.