@lacuna said:

click bang [o] (GUI always on block-boundary) > [spigot] opens > [bang~] bangs > [spigot] closes > [vline~] starts (still on same block-boundary).

Yes, this is how I was hoping it would work, but it's not always the case that [bang~] bangs after the spigot is open within the same control block. It appears to bang afterward if there is a direct bang from a GUI element, but bangs before if the bang came from a delay. (Edit: I'm going to start a new topic on this, I don't see why this should be true)
bang~ runs last.pd
bang~ runs first.pd
If it runs before, then we are really waiting until it bangs at the end of the next audio block. (BTW, you can modify the number of blocks of delay and see the numbers change as you'd expect)

You use [rpole~ 1] as sample-counter, right? But [snapshot~] only snapshots on block-boundaries.

Yes, but all I'm concluding from that is that the message is available in the control block before the audio block that contains its actual time. The fact that so many Pd objects ignore the fractional block of time remaining suggests to me that it could be possible to truncate that fractional block of time in the message in order to make objects like vline~ start at the beginning of the audio block, like sig~.

So is it correct that you want to move the start of vline~ 'backward' ? To the start of the block?

Your diagram annotation is correct, but "want" is a strong word . Let's just say I'm curious if it's possible. Right now, I'm delaying things like [sig~] to match [vline~] by inserting [vline~] just before them. I could have used any of our 3 quantizers to align the first [vline~] ramp with the block following the block that contains the fractional block timed message, but then I would have had to also delay my [sig~] processing a block as @seb-harmonik-ar confirmed.

The last two slides in that PP deck you linked to shows what I mean. Objects like [vline~] implement the ideal, but I'm wondering how to make it behave more like the last slide. See how the message's timing is labeled "t0+16"? Wouldn't it be possible just to zero out the "16" part?

@ddw_music said:

[spigot] blocks messages if its right inlet is 0.
One of the ctlin outlets gives you the channel number (I forget which one). It's not leftmost, which means it will be processed earlier than the controller value.
Channel number --> [== 6] will produce 1 if it's 6, and 0 otherwise.
So if you plug that into the right inlet of spigot, then you have an on-off switch based on channel number.

thanks! that helped! so two spigots like in the picture below, and it seems to work like a charm, no issues.

Then you can pack the value and array index into a 2-item list, pass this through spigot, and it's ready to plug directly into tabwrite (because tabwrite accepts a list of "value index").

hmmm.
so [pack f f] and then slam that into tabwrite?

thanks, this also seems to work!
interesting stuff for sure. i've never really gotten comfortable with using [pack] anywhere, there might be multiple ways of doing it properly

@esaruoho said:

so while the [- 41] definitely would assist, the required logic is to discard anything 41-56 that isn't coming from channel 6.
if that can be easily solved, that'd be pretty hot!

[spigot] blocks messages if its right inlet is 0.

One of the ctlin outlets gives you the channel number (I forget which one). It's not leftmost, which means it will be processed earlier than the controller value.

Channel number --> [== 6] will produce 1 if it's 6, and 0 otherwise.

So if you plug that into the right inlet of spigot, then you have an on-off switch based on channel number.

Then you can pack the value and array index into a 2-item list, pass this through spigot, and it's ready to plug directly into tabwrite (because tabwrite accepts a list of "value index").

hjh

A "one-shot spigot" is a basic piece of patching vocabulary which should be taught as basic, but which (AFAICS) is not.

... prints only one time.

But the problem in your patch comes from whatever is feeding [s gate]... this isn't shown so I don't know.

hjh

@WEIRD1 As you want floats and bangs (and maybe symbols and lists one day?) to pass through unchanged...... maybe build your "router" with a bunch of [spigot] objects ..... 3 per inlet and each connected to one of the 3 outlets.
Then a counter that rotates 1, 2, 3 as it is banged (by your bang [inlet] ) and its output sent to the control inlets of the spigots via [== 1] [== 2] [== 3] for the first inlet and [== 3] [== 1] [== 2] for the second..... etc..... I think.......
When the counter output is 2....... for example.... [== 2] will output 1 and open the spigot...... whereas [== 1] and [== 3] will output 0 and close their spigots.
You will have built a rotating multi-gate in vanilla........
All vanilla.....Started for you but untested..... so please check it...... bof.zip
(( Just noticed that you should also change the initial [spigot] arguments for each inlet so that they route correctly on creation.))

When you have finished it save it and use it in your patches as an abstraction (you will have created your first)..... by "putting" [bof] in a patch. You should probably save it with a name that makes more sense though.
You could even make a [bof-help] file so that it will be understood later.

BUT!!! change the send/receive names first..... to [s $0-control] and [s $0-out1]....etc.... or when you use the abstraction more than once the instances will be receiving each others messages....... https://forum.pdpatchrepo.info/topic/9774/pure-data-noob/4

A lot to absorb.... but worth it....!
David.

How about this

[comport] <- I guess you're reading values from a serial bus
|
| [r spigot]
| /
[spigot 1]
|
[t f b b]
|    |  |
[0\ [0( [del 100]
     |   |
     |   [1(
     |  /
     [s spigot]

This will receive the first value, close [spigot], and re-open it after 100ms. You can experiment with the argument to [del] to get an optimal result.

@dfkettle The spigot and related logic means it does not send a [dirty 1( for every change, just when needed, more efficient. In your way if you slide one of those sliders from top to bottom you send [dirty 1( 127 times, which could cause issues and lag things if the processor is nearing its limits. So first change closes the spigot and no more messages sent until you open the save panel, then the spigot is opened back up until the next message goes through and closes it/sends [dirty 1(.

@whale-av Thanks a lot!
By printing the messages I could see that the [vline~] received the same message twice. Once when I pressed the key, and then again when I released it. No idea why it worked before, I'm guessing my BSP is a little buggy.
Anyways, solved it with a [spigot] and now it works like a charm.
Thanks again!

@whale-av said:

You have a lot of zeros flying in from the [*] at the same time as the data and that is the problem.
A couple of spigots will solve it..... buggy.pd
Just changed.... I had the spigot defaults the wrong way around.
David.

oh wow.. you are a hero!
i learned something today... spigot, interesting object!

@Jona said:

i think select or route can solve your problem, but perhaps select makes more sense in your case:

edit: i think i misunderstood the problem

ooh, this looks fine. a bit less messy than my sequencing hack!

thanks ,

@Transcend Yes, [phasor~] just scans through the indexes at a desired speed and over a desired range, and [tabread4~] returns the sample values of those indexes at the audio rate.
[phasor~] actually sends a ramp..... 0 to 1, fall instantly to 0 and another ramp...... so a sawtooth 0 to 1 at the frequency that is sent to its left inlet. So to get it to play all the indexes its output needs to be multiplied by the total samples.
The frequency needs to be set that the time for each ramp is the same as the normal time length of the sample....... for playback at normal speed. Changing the frequency will speed up or slow down playback, and inverting the ramp (horizontally) will play backwards.
[mess] uses some math which changes as random numbers arrive........
The [*~ 1] will change the start point and the speed at the same time. They could be separated using a [+~] as well, but I kept it reasonably simple. The speed changes the frequency, but does no stretching (to maintain the time length of what is played) so higher pitch will be shorter, lower pitch longer.
The Grain slider changes the rate at which random numbers arrive, and [random] spews any number between zero and the size of the array..... a value that it gets from [soundfiler].
The [phasor~] gets its frequency from dividing the samplerate (I assumed 44100) by the number of samples, so that if nothing was messed up it would simply play the file at the correct speed from beginning to end repeatedly.
The [spigot] allows the same random numbers to change the frequency of [phasor~] as well.
You can reset that by closing the spigot and clicking the [44100( message. The clicking of the message could be automated by a bang when the spigot is turned off like this........ mess.pd
David.