(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 !

It's hard to tell from the screenshot, but it looks like whatever the pipe spews out gets sent straight back into it (after some processing) like this (simplified):

This works because the pipe has a set delay time in your case. But the moment you give the pipe a 'flush' message it starts unloading everything in cue, which includes what it causes the chord send to feed back into it's "send this" input, with zero delay, effectively causing an infinite loop = stack overflow = computer stuck with no other remedy but a hard reboot.

I can't pretend to know the intricate workings of your system or what exactly you are trying to achieve well enough to offer a viable solution though.

Rereading your post- I guess what you want is a scheduled message for your chord picker? Since your "chord" is just a number (float), you can use the [f ] object like this:

Some recommended reading about scheduling: https://forum.pdpatchrepo.info/topic/13320/welcome-to-the-forum

@bocanegra Ok, I see ! I thought that the flush would not apply for a period of time, and just work as a bang, so that would explai the stack overflow. Thank you !

I'll try to use the [f] object. Does it work as a gate for the number ? When a bang hit the [f] the number is released ?

@Déléo Yes, the right inlets of objects hold floats or lists or symbols until the left inlet is banged or a float arrives on the left inlet of [*] or [/] or [+] for example and then the calculation is done according to the value stored on the right inlet.
Beware of the order of operations........... https://forum.pdpatchrepo.info/topic/13320/welcome-to-the-forum
David.

@Déléo said:

@bocanegra Ok, I see ! I thought that the flush would not apply for a period of time, and just work as a bang, so that would explai the stack overflow. Thank you !

Flush doesn't apply "over a period of time". It does work as a discrete "bang", but once [pipe] receives it, PD will calculate the entire signal path from [pipe] to [send praccord] through [receive praccord] and back into pipe before doing anything else, and thus [pipe]'s list of messages to flush will be perpetually full. Read the thread both @whale-av and I have linked you up with to get a better idea of how PD computes stuff.

i believe what you want to do is set pipe´s delay time to 0 and then back to another value. this also should emtpy its buffer.

besides that, your "web" with the transition states would be better placed in an object like [text] or [coll]. including the random value, that is.

@Obineg said:

i believe what you want to do is set pipe´s delay time to 0 and then back to another value. this also should emtpy its buffer.

I'm pretty sure that would result in the same infinite loop but I'm not gonna test it to verify

@Obineg Setting delay to 0 will not flush the buffer. Inputs are delayed by the time that is set when they arrive..... so as it says at the top of the help file they are then sorted automatically.
If you send in [1 10000, 2 0, 8 6000( then you get 2 immediately and then 8 after 6secs and 1 after 10secs.
That is probably why the [flush( method was thought necessary.

@Déléo Actually [list-fifo] from the list-abs library is probably what you need.
It bangs "EOL end of list" when the list has been emptied and bangs to its left inlet (on the beat) will output (pop) elements of the list in the order they were pushed in...... "first in first out".
Just send in the chords as lists and pop them with a bang from the tempo.
It is an abstraction that should simplify your patch....... no tables or arrays.
I have included [list-lifo] in case you want to play the list backwards.......
fifo.zip
David.

David.

@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