@solipp
re-positioning the count unit helped in that case to a later stage. [moses] is on my learning list. so the change did its job as you mentioned. great!! I managed to build a synced pd patch to my DAW banging out bars and 16th notes. It needs some minor fixes, but runs as intended in a first version now. Thank you very much for your great and quick help, patience and time to everybody !!

@solipp
the [change] make no difference between value "-0" and "0", indicating negative decimal numbers. So if I want to send a bang with a comparator [>= o] the [change] really happens on 1, which is one beat late then.
Negative number are send by the [abl_link~] after a reset of beat_time, which guarantees the next bar by a preroll with negative numbers

Glad about help!!

Thank you!

Thank you to all!
Here´s the thing. I am experimenting on how to get rid of the multiple bangs running through the beat section. I just need one bang representing the beat...Truncating the decimal points with [int] does not really work, as bangs are sent through it. As the very fast ticks are printed, I am not sure if the [delay] method works here safely to cut out the bang stream, but let through the first bang intended by the [% 4]...

Dear Forum,

EDITED

I tried a bit on [playhead] in plugdata in a plugin and ableton link [abl-link~] in standalone mode.

The difference is that both objects work either in the DAW or only outside the DAW. What is a good approach to start out time aligning pd to every spot of the DAW (or vice versa), IF possible at all?

In some videos I sometimes see a 64 element [hradio] representing 16th of a section, I guess, that are switched once finished. Besides I am thinking about a continuous counter marking bar numbers to trigger any patch kind of [% 4] a 4/4 time signature. But I am not too experienced here and understanding larger sequencer setups.

What is good?

Thank you very much!!

@Balwyn said:

@Moothart This may work for you
the first bang closes the spigot stopping anymore bangs, anything else opens the spigot

This is a good thing at another place in my patch for just letting through one initial bang only. (hoping to get your aproach correctly...)
I have to experiment with it.
The question here is filtering out double bangs (so to speak on top of each other) if they happen occasionally, but opening it to bangs that are not close together like a beat´s time interval or so.

THANK YOU!!

@whale-av

Great advice! It is an occasional doubled bang for now at least.
Appreciating your quick help !!

@FFW
Great! Thank you very much. I can change the delay time to let quicker or slower bang tempos pass, when I get your patch right.

Dear Forum,

I had it once, but can´t remember how to replicate it...It occurs that two bangs fall together on one beat.
How can I filter out the doubling, so that I can send only one bang for further processing, which would be sufficient. There was a chance to do it with a delay or kind of that....

THX!!

@oid said:

@Moothart In this case it does not matter if it is the left or the right inlet and it would work the same. The general convention when something is patched as I did is that the connection does not cross inlets/outlets and is connected to the first it comes to since anything else would be ambiguous. Vast majority of those who patch like this, follow this convention.

Going to the right inlet it loads 0 into the float, than the [until] is banged sending [get 0 1( to [list store], the [until] then bangs until the [list store] gets an out of bounds get which sends a bang out of its right outlet to the left inlet of [until] which stops the [until]. Going to the left inlet the [f ] immediately outputs a zero which sends the [get 0 1( message to [list store], adds 1 to it and sends 1 to the right inlet of [f ], the [until] then starts and sends 1 out giving us [get 1 1(. Only difference between the two is that the [until] will bang one time less if you send [0( to the left inlet than it would if you send it to the right.

Good hint! THX

Is there a chance to see the change of the value in the moment, when the line passes a number of the [2 5 6 7 10]? I hope I get it right here in rebuilding the latest patch.
Maybe there is a chance to build in a number box representing the actual number for so long, until the next number from [line] is passed, being represented in that number box then. The result would be showing adjacent numbers from 2 5 6 7 10, each occuring for a specific amount of time depending on the line object passing that numbers one after another...