When I first try to feed a number into a series of calculations, I receive nothing on the output end. When I try a second time to feed a number into a series of calculations, I once again get nothing. The third time I try it, I finally get results, and they're derived from the first number I entered instead of the one I just directed Puredata to use for its calculations. I needed that number when I asked for it, not after asking for it three times, much less after asking for a different number altogether.

None of the objects I'm using to perform these calculations should have any kind of memory or delayed release mechanism (I'm basically just using a series of [/], [+ ], etc. objects--the results should be coming out through the other end immediately, and there is nowhere an object that should be capable of storing old numbers). The only exception is the [expr] boxes I use to input the numbers Puredata is to operate on. These are not the problem unless they have some kind of phantom memory. Something in Puredata evidently has a phantom memory.

This is an extremely irritating issue that renders it impossible to operate in real-time. Is there some way to unclog Puredata's arteries?

Hi Polaris, do you think you could upload your patch here, or at least share the schematics you are using? It's a bit difficult to diagnose what is wrong just by reading your message above.

Take care,
Gilberto

The setup is pretty simple. Right now I'm getting the problem with four objects:

[ number box] [number box]
| |
[ - ]
|
[number box]

The number box repeatedly tells me what A minus B used to be instead of what it is right now.

The top number boxes are getting their inputs from a [list split 1] object.

I solved the problem in this case by inserting a [pipe] object between the number box connected to the hot inlet of [ - ] and its input. This tells me that [list split] is probably not releasing its output all at once, as it should be. In the past I had some calculations that were getting screwed up because data was not arriving at certain points in a synchronized fashion. I was told this was because MIDI data is transferred across MIDI channels piece-by-piece instead of all at once, but right now I'm thinking that the problem is in the way Puredata operates. It might be necessary for me to start making liberal use of [pipe] objects, which, unfortunately, will probably create some lag in Puredata's processing.

I have yet to check whether the [pipe] method will solve the other problem spots similar to the one above.

Hi Polaris,

Thanks for the update. Your problem is very strange, on my machine I created the following patch and it works flawlessly:

[<A> <B>(
|
[list split 1]
|    ________|
|   |
[ - ]
|
[number box]

When I substitute <A> and <B> for any two numbers, the result is always correct. I tried to see if the output of [list split] was having some buggy behaviour influenced by the order of creation of the patch chords, but it always works as expected.

But you also mentioned that you are using MIDI in this patch and that you suspect this may be influencing your problem. So are you creating those lists using MIDI data? If so, how exactly? It seems to me that your problem may not be with your algorithm above (so nothing to do with how [list split] works), but actually with the way the MIDI data is arriving in your patch.

If using [pipe] or [delay] solves your problem, then I guess you can go for it, but just be aware that it is not only lag that this type of solution introduces: more than once I had some badly constructed patches that were fixed by adding a bunch of [pipe] objects, and it was always difficult to modify it later without breaking everything (e.g. some of the [pipe] objects had to delay things less than other ones, and to keep track of this in a large patch was a nightmare).

Best,
Gilberto

You might want to try it without the [list split] object. Many of the vanilla PD objects will take a list of arguments given to the first inlet and distribute them across the remaining inlets. For example:

[3 2(
|
[- ]
|
[> -1]  <-number box

Another thing to try is using the [unpack] object instead of the [list split] object.

Thanks for the advice, everyone.

When I mentioned the MIDI data issue, I was talking about a different patch. The patch I'm currently working on does not receive MIDI data--everything it generates is made from scratch in Puredata--so that wouldn't be related to the problem in this case.

The strange thing about my using [pipe] to fix the problem is that I'm not assigning the object a delay time. So either no delay is occurring or the delay is extremely brief.

Cutting the [list split] object is unlikely to address the deeper issue, since this problem occurs in many cases where there is no [list split] object. The only reasonable explanation I can think of is that these objects are releasing their output in a sequence instead of all at once and this is causing the numbers that arrive at the hot inlets to be paired up with the wrong numbers.

Hi Polaris, that's a really odd problem you are having, particularly if something as simple as this below isn't working for you:

[ number box] [number box]
|  ___________|
[-]
|
[number box]

I used to have some problems like this when I started working with Pd, but it turned out that I was creating patches in the wrong way (messing hot and cold inlets, messing packing and unpacking, not using triggers, etc.). But what you describe above seems to be way to basic to be included in these types of mistake - there is no way of messing this little schematic you wrote before, and if it isn't working for you then the problem is really not with the patch itself.

Probably your problem is beyond what I can help you with, but I guess that you have higher chances of finding a solution if you share your OS information, Pd version and maybe some more samples here - but that's just a suggestion.

Best,
Gilberto

Hi, I just wanted to echo what gsagostinho said: based on your description it sounds like an order of operations issue, although it also sounds like you've investigated that possibility thoroughly. I'm just posting to say that if the cold inlet were receiving it's input after the hot inlet, adding a pipe object without arguments before the hot inlet would fix it because it would delay the input by 0, creating a callback and not immediately executing the hot inlet (and letting the cold inlet go first).

I also wanted to address this:

None of the objects I'm using to perform these calculations should have any kind of memory or delayed release mechanism (I'm basically just using a series of [/], [+ ], etc. objects--the results should be coming out through the other end immediately, and there is nowhere an object that should be capable of storing old numbers).

[+ ] and [/ ] do store their last values (on both inlets) by design,
I feel like the the example you gave is part of a larger patch? if so uploading the whole patch here could help find the issue

As far as I know, [+ ] and [/ ] store both of their last inputs rather than the last solution they came up with, so that shouldn't be a problem unless the hot inlet is receiving its number before the cold inlet.

It should be mentioned that the middle inlet of the [list split] empties itself into the hot inlet of the math object. Apparently [list split]'s output is released in sequence from left to right, so that by the time it releases the rightmost number, the math object has already been banged. Essentially, it's ignoring the order of operations I specified by connecting the cold inlet first. I'm not sure if this is abnormal behavior or not, but it's frustrating and pointlessly limiting. I strongly suspect that other problem spots are variations on this. I have some subpatches with multiple inlets receiving numbers, and it seems likely that these numbers, which arrive simultaneously, are trickling through the subpatch's inlets one by one, in order from left to right, and in so doing not only ignoring the order in which I connected them to subsequent objects but rendering their motions non-simultaneous.

@gsagostinho: The example you gave works for me. I think the problem only happens when the numbers are arriving from the same source (apparently the use of multiple [inlet]s makes all of the them function as if they're sticking out from the end of one object).

Hi Polaris,

You write:

As far as I know, [+ ] and [/ ] store both of their last inputs rather than the last solution

That is not correct. Try this: create an object [+] and send numbers to its two inlets, but do not connect its outlet to anything yet. Now after you send those numbers, connect the outlet of [+] into a number box. This number box is obviously still at 0, but now if you bang the hot inlet of [+], the previous result will be send to the number box: that is, the result was stored there all the time.

Essentially, it's ignoring the order of operations I specified by connecting the cold inlet first.

The order of connections only influences the order in which data flows if and only if all the connections come from the same outlet of a single object - is that the case? Also, it is normally considered to be bad style of patching to rely on this: if the order in which data arrives from a same outlet is important for the logic of the patch, then by all means use a trigger! It will save you much more time to add a simple [t f f] once in a while then troubleshoot a large patch with problems.

I think the problem only happens when the numbers are arriving from the same source (apparently the use of multiple [inlet]s makes all of the them function as if they're sticking out from the end of one object)

Your phrase above is not very clear to me. Could you please give me a concrete example (schematics or patch) of data arriving from a same source and confusing the order of the operation?

It is starting to look like your problem has something to do with some of the basic concepts of patching in Pure Data. It would be really good if you uploaded here one of your problematic patches, because that would be the easiest (and fastest) way to diagnose what is wrong. I strongly suspect now that your problem is actually easy to solve, but we are all missing the solution by writing too much and patching too few

Take care,
Gilberto