(First of all, I am french, so there may be grammatical mistakes)

Hello ! I'm new to this forum and a complete beginner with pure data. I'm studying sound engineering, and our professor taught us the very fondementals of Pd, and ask us to make a patch that involves music, so I tried to create an auto-composition I.A. Basically, it's just a loop where the previous chord determines the next one with probabilities, nothing too fancy. On the left of the patch, we have the creation of the sound with the fundamental, the big web on the right is the determination of the next chord, and on the top, I'm currently trying to implement a way to choose when the next chord will play on a beat, using the interface on the bottom left.

So what I was thinking to do was to "block" the loop with a very long pipe, so what was considered the next chord had to wait for the current chord to finish playing. To know when to finish playing, I wanted to have Pd check every column of the tab, and if the value is above the line, send a "flush" to the pipe, releasing the next chord and block the one that comes next.

Unfortunaly, if I connect the flush to the pipe, Pd crash, and my computer doesn't appreciate at all.

Am I missing something ? I am creating some sort of larsen when I connect the pipe ?

Thanks for the help !

@bocanegra
if the patching is causing a stack overflow (havent tried it either) you could in both cases solve that using a gate.

flush works for me as expected, the error must be elsewhere in the patch.

@Obineg said:

flush works for me as expected, the error must be elsewhere in the patch.

Now try feeding [pipe]'s output back into it's input and see what happens when you flush it (or set the delay to zero)

@whale-av OP's patch is not using any lists for the chord selection loop. Replacing [pipe] with [float] for scheduling the feedback is all he needs to do

Thanks everyone for your replies, my patch works now !

...Except that my console still send me a "stack overflow" error every time the chord changes :^/

But the patch works anyway, so should I worry about it ?

@Déléo For the "gate" to work properly the [receive praccord] should be connected to the right inlet of the [f ] object. Connecting it to the left inlet creates a loop similar to before (stack overflow) and no actual gating is going on...

Right, it's a general principle of Pd/Max-style programming:

• It's always safe to send a value back to a prior object's COLD inlet.
• If you're sending back to a prior object's HOT inlet, this is potentially dangerous. You must make sure there's an exit condition (some branch that does not feed the value back).

IMO "send back to hot" is probably a mistake, unless a [delay] is involved.

hjh

@bocanegra
[quote]Now try feeding [pipe]'s output back into it's input[/quote]

sure, but that is not releated to the flush command - IMHO this is not a bug of the pipe object.
the flush command cant "close the input" before it sends the buffered content out the outlet, or the order at the two inputs would be not ideal.
and if you do, you get a stack overflow because pipe outputs at scheduler.

connecting objects to themselves is a special case, and i am not suprised it does not work with any form of "delay 0."

@Obineg said:

connecting objects to themselves is a special case, and i am not suprised it does not work with any form of "delay 0."

Agreed here. "Feed back to hot" always needs to be handled with care, at best. (BTW is there a standard name for this data flow pattern? Has anyone systematically analyzed data flow patterns and risks/benefits of each? This is a 30+ year old programming technology...)

In this case I think "handle with care" could be to use a [spigot] to block "flush"ed messages from feeding back into [pipe]:

sure, but that is not releated to the flush command - IMHO this is not a bug of the pipe object.

But, as I think about this more, this looks like a case of the classic bug of "modifying a collection while iterating over it."

If I have a list of four numbers and I "do" something over it, my initial expectation is that the loop would run four times.

If some (or all) of the iterations add something to the tail of the list, then there are two possible ways to design it:

• Remember the initial collection to loop over, and use this as the source while modifying a separate copy of the collection.
• Or, use the same identical collection as the source and target.

In the second case, the number of iterations is not guaranteed to match the size of the source. We can even do this in Pd:

... where you think you did everything correctly (there's an end condition = [list store]'s right outlet), but this never stops because the end of the list keeps moving further into the distance.

This may be OK sometimes, but it may also just be a mistake. I'd argue here that you expect "flush" to output no more than the number of items that were in the queue at the time of receiving the message. If [pipe]'s backend simply does the same thing as the naïve loop illustrated above, isn't that faulty behavior?

EDIT: Quick glance at the source code shows that pipe is using a unidirectional linked list for the queue, and the stop condition for "flush" is "is there a remaining node?" which is precisely the naïve approach I'm pointing out. So I'd say, yeah, bug (though the fix might involve a second iteration, which the devs might not want to do).

hjh

21-1205-pipe-feedback-01.pd

Of course, the objection to "flush only what was in the queue at the time of flushing" is: if you put things into the queue during the flush process, then the queue wouldn't be empty at the end, which also breaks a reasonable user expectation.

So then it's still up to the user to block the feedback during flush, only without a hang.

Avoiding a hang may still be worth it; I might log an issue for this later, when I have some time.

hjh