Was there anything fixed with this in beta 13? I’m still using beta 12 and am experiencing some weirdness. I’m checking for a change in some values every 5 seconds, if there is a change then I’m trying to send the information to a php script that adds the values to a database. The first time the script runs it works, but after that every time the values change, instead of sending the new values it sends the old values. The weird part is that the “Value” input on the HTTP node shows the new values (it is a spread of 3 values, created via a Cons (String) node). If I disconnect the cons (string) node from the HTTP “Value” inlet and reconnect it, then it updates the values and becomes stuck on those values.
I’ll try to think of a way to make an example, but if this rings any bells let me know because I’ve been messing with it for a few days and it seems like I’m either doing something wrong (maybe you can’t use a spread into the “Value” inlet of the HTTP post node?) or something is wrong with the node.
Ok, I’ve set this up closer to the way I’m doing it and I’m definitely seeing the same issue. When I open it, I receive the correct value on the first refresh. After that, the refreshing seems to not work according to the Network Receiver. If I connect the cons output to the value input, it updates the numbers once again, but then gets stuck on them.
well the way you set it up is definitely the way you shouldn´t do it. the refresh pin is a pin which should be banged. if you connect it to the lfo the way you did, it is constantly set to “1”( for approximately half of the time of the period of the lfo,in this case 2,5 seconds). So the HTTP-Node refreshes all the time during this 2,5 secs (once every vvvv-frame).
But every time you refresh and a previous attempt of sending the values isn´t finished (the server has not yet responded), this foregoing attempt is cancelt and a new one is started.
Since a server most likely isn´t able to answer a request in such a short time frame , all your attemps of sending the values are cancelt and therefore never reach the server.
Yes, that makes perfect sense, however it was just a stupid mistake on my part. I meant to have it being banged from the change node (which is how I have it in my real patch). I’m still getting the same behavior with refresh attached to the change node. Is it working for you? are the numbers being updated in the HTTP receiver value output?
Ok, I think I’ve finally cracked it to the extent that I’m able to. It seems like having text being the first slice seems to mess something up, because simply re-arranging the cons so that the text slice is last seems to make it work. Check out this example.
Same here it seems that the content is only updated when the leftmost pin was triggered.
What’s strange is that when you connect the “buggy” one the http receiver node ondata output pin bang 1 at each cycle. So it receive something but not update it.
Ah, I bet you’re right about the leftmost pin updating, it probably has nothing to do with the text and “number” changing (because they are both really just strings). The node must check for a change in the first slice of the spread, and only update if it detects one.
mmh this is a bug, the node checks only the first slice for a change. If nothing changes in the first slice, the content that the node sends won´t be updated and it always sends the same. That´s why something is received but nothing changes in the output of http(network receiver).
will be fixed for the next release. meanwhile always change the first slice, if you have constant values “put them into other slices”.
Since I am timing my samples with the LFO I’ve just grabbed the LFO cycles output and added it as the first slice dummy value in my requests. I can’t guarantee that any of the numbers will always change when others do, so I think it is a decent solution for now.
