I have a very simple spigot mechanism in place. To the right inlet an [==] object is connected. It sends out a 1 when it receives a 3, and otherwise a 0. To the left input of the spigot is connected a number box that receives input every time the [==] is triggered. The problem is that the spigot refuses to work correctly when the patch is running. It keeps letting numbers through when [==] is outputting a 0. The only thing I can think of that might be the problem is that [==] and the number box are receiving their inputs at different times, so that the spigot is sometimes open for a number when it should be closed. However, I went to fairly ridiculous lengths to ensure that the two inputs are arriving at the same moment, even though it shouldn't have been necessary. And yes, the number box was connected to the spigot after [==]. I checked multiple times. So what on earth is the problem?

@nineofkings [onebang] can be easily implemented as a vanilla abstraction. In fact there's [once] (I think from iemlib library) which is a vanilla abstraction. You can use a [spigot 1] to let the bang through, and then close that [spigot]. You can use a right inlet in the abstraction to open the [spigot], hence reset the abstraction.

I had the same problem, I used spigots:

i can confirm getting strange results from the two test patches @weightless made.

These are some results from pipezero2.pd without any changes:
spigot: 10.294
pipe: 10.313
spigot: 10.315
pipe: 10.334
spigot: 10.302
pipe: 10.322
spigot: 5.187
pipe: 5.206
spigot: 10.294
pipe: 10.314
spigot: 10.3
pipe: 10.32

Notice the about 5 ms results in the middle. Similar results appear now and then in the list. i had similar results with the manual test patch. i also tested with zexy/time and got similar results.

This is Pd 0.47.1 on linux.

@cuinjune here is a simpler version: getdollarzero.zip

Also be careful if want to close a spigot but it's a float going through the spigot. It will overwrite [0] and the spigot will stay open. Better to use a message [0( will always close the spigot.

@Fauveboy Here is a simpler version, the -1 isn't actually needed: expr-trigger-test.pd

The first button who meets the condition sets the toggle to 1 and closes the spigot. The current number is stored in the [==]. Only this button can open the spigot again: If and only if the incoming number equals the stored one and the second condition is true (1 x 1 = 1), the spigot is opened. The [change] protects against redundancy.

Hi,

Maybe I am missing something, but the timer in this patch seems to work well. I tried sending messages with values 0 and 127 to it (after sending a 125 to open the [spigot], of course), and the timer shows no problems here. It shows to me the time elapsed since the first 127 value arrived and not the time since the patch was loaded. Can you please explain better what issue you are having?

Also, some comments on your patch:

• using [expr if($f1 > 1250, 1, 0)] is a bit of an overkill since it is identical to [> 1250], and also using [expr if($f1 == 125, 125, 0)] to open the spigot is identical to using [expr if($f1 == 125, 1, 0)] (since the spigot opens whenever the value in the right inlet is different than 0) which in turn is identical to [== 125]

• I personally would use a [pack f f] above the [stripnote] and send the note number + velocity as a single list to it, since when using the right inlet you must make sure that the velocity arrives always first and this can be easily forgotten in a more complex patch

Cheers,
Gilberto

@dzees Like this.......
spigotted.zip
.....but if you give the incoming messages a tag....... making each one a list like 1 0.345 and 2 woof7 etc. (by using [prepend] then you can just use [route 1 2 3.........] ....... look inside [spigotted] for clues.....
You can even use recognisable symbols to tag the incoming messages...... like dog 0.345..... cat woof7 and then [route dog cat] ......... so basically the message arriving tells the [route] object to which output it should be sent........
David.

@nicnut Ah, so instead of Gate 5, you would have to use... four Spigots, right?

Of course, if everyone's using Vanilla now and there's no Vanilla Gate object, that might be the only way to do it. I'll upload another .zip of this with Spigots soon.

EDIT: No, it would be five Spigots, right? I was thinking of doing it with [moses], which would also be possible... then you'd need four.

it's a recursive thing: I'll walk through part of an example:
say the list has 5 elements.
The list comes in, and goes into the open spigot.

so at this point the [t a a a a] is sending a list of 5 elements. the following is what happens to the right [list-split] at this moment:
the first 2 elements of the list are sent back to the upper trigger, and go back into the spigot, where they are split again into lists of length 1. element 1 goes back into the upper trigger and out of the outlet, and then the second does as well.

All of this happens before the list of 5 elements is even sent to the left [list split], because of the trigger. A similar thing occurs:
the last 3 elements of the 5-element list are sent to the upper trigger and into the open spigot, and then the first element of that is split off and sent out the outlet. Then the last 2 elements are sent through the spigot and split, and are sent out in order.

The crucial thing to understand is the recursive nature; it has to do with the depth-first message passing in pd.
The first half of the list is split off before the second half, and sent to be split in half again before the second half of the original list is even processed. So it goes the first half of the first half of the first half, etc. until the first element is sent to the outlet. Then it goes back up the "stack" to the second halves of the lists that it missed in doing the first half every time (this happens because of the triggers). So after the first element is sent, the second element is sent. After that, elements 3 and 4 (in a list since they weren't even processed to be split yet) are split and sent out in order. then elements 5-8, which are still in a list, are sent back and processed in the same manner.

Hopefully that's somewhat clear..

(rambling extra stuff:)
From a "computer science" perspective, you could say that you process the first half and put the second half on a "stack" , and then go into the first half, split it in half, put the second half on the "stack", etc. And then after the 1st element is put out, repeat that process for each thing on the top of the stack until you end up with 1 element:

in "pseudocode" (with a datatype "list" and an assumed stack):

function splitlist (list inlist) {
         list firsthalf;
         list secondhalf;
         if length(inlist) == 1 then {
                     output(inlist); -- pass the element
                     if stack exists then {
                            secondhalf = popstack(); -- get the next thing on the stack
                            splitlist(secondhalf); -- call the function recursively
                     }
        } else {
                   firsthalf, secondhalf = split(inlist); -- split the list, pass to variables
                   pushstack(second half); --- push the second half onto the stack
                   splitlist(firsthalf); -- call the function recursively
         }
}

I think that in reality most of this is taken care of in the computer's call stack, though not completely sure on how the memory for the lists is dealt with