David Clements

Am i going mad? Why is this patch creating more than one bang for each timepoint? It's doubling most, but not all, and sometimes tripling for me.

Please can someone check that it's behaving the same way for you?

Yes, i can use [change] to fix it. But i'd like to understand why it's happening..

print

number

outlet

message

timepoint

Hi.
Am i going mad? Why is this patch creating more than one bang for each timepoint? It's doubling most, but not all, and sometimes tripling for me.
Please can someone check that it's behaving the same way for you?
And if so, can anyone explain why?
Yes, i can use [change] to fix it. But i'd like to understand why it's happening..

Hi.
Am i going mad? Why is this patch creating more than one bang for each timepoint? It's doubling most, but not all, and sometimes triplin

timepoint-multiple-bangs

It worked correctly for me - single bang per timepoint. Is your global transport set up for 4 beats to the bar?

Also, is there a reason you've used so many timepoints - otherwise, you could achieve the same result with a single metro and a counter.

Also, is there a reason you've used so many timepoints - otherwise, you could achieve the same result with a single metro and  a counter.

How strange. Yes the global transport is set up right. At least i think so... images attached

Yes, it needs to be driven from the transport, i just pasted a very small part of a much larger patch. 

Thanks for checking that for me... I'll explore further.

Screenshot 2021-10-26 at 17.54.32.png

Screenshot 2021-10-26 at 17.54.41.png

Thanks Nick.
How strange. Yes the global transport is set up right. At least i think so... images attached
Yes, it needs to be driven from the transport, i just pasted a very small part of a much larger patch. 
Thanks for checking that for me... I'll explore further. 

Screenshot 2021-10-26 at 18.03.09.png

timepoint is very dangerous because you have no easy control over order.

What else do you suggest for syncing from transport? 

I guess i could get the bars/beats and write a patch to convert that to 64 numbers?

What else do you suggest for syncing from transport? 
I guess i could get the bars/beats and write a patch to convert that to 64 numbers?

something like metro or clocker, where you have all desired positions in one stream.

Any thoughts on how to get swung 8notes (320 ticks) to add to that count? So...

1 = 1. 1. 0
2 = 1. 1. 320
3 = 1. 2. 0
4 = 1. 2. 320 etc.

Screen shot 2021-10-30 at 9.54.48 AM.png

You need rawticks output, divide by 160 (8nt = 160 ticks, note length you are after)

and then add first and last note in the triplet per beat.

You need rawticks output, divide by 160 (8nt = 160 ticks, note length you are after)
and then add first and last note in the triplet per beat.


Here is my patch from above, also counting the swung eighths. Basically its just multiplying the current value by two, and adding the transport units divided by 320. As this is done in integer division, it will be 0 before 320 ticks, and 1 after it;

Can i ask a couple of questions about it, just to understand better, so i can incorporate into my patch...

1, What does the "transport state" outlet actually do? It seems to just send 1's with every tick. What is it? And why does it need to control a gate when it only ever sends "1"?

2, So when you do @clocksource internal, what is that telling the transport? Presumably just saying that max controls the clock, doesn't it do that automatically? My main transport is already governing tempo, this one will be slaved to it so i can remove the tempo controls you added, but should i make my main transport "@clocksource internal"?

3, The start/stop/pause stuff is already being governed elsewhere, so i don't think i need that, but unsure about the trigger which is resetting a few object when it gets zero. I hooked this patch up to a makenote quickly and controlled it from my transport, (i.e not using your toggle and not sending zeros to that trigger) and it seemed to make no difference except maybe it's creating a flam when the transport loops back to bar1?

An easier way to understand what i'm saying - if you open the pasted patch below, and use the toggle i've created to switch it on/off, instead of your toggle, can you forsee a problem that the trigger is not recieving zeros? I think it might be double-generating the first note on "1", sounds like a flam.

4, i'm still using one timepoint - to loop the track back to bar1. When it gets to the variable loop point *See pic. Can you think of a better way to have a variable set the loop point without using [timepoint].

Screenshot 2021-10-30 at 16.17.58.png

Also, last question, not just related to your patch, but i problem i've been having since i stopped using [timpoint] to create the beats - when i rewind (send zero to transport), it plays the first note on my patch as if it's playing bar1beat1, and then because of [change] the 1st note doesn't sound when i do press play. Is there a way to set the transport position without output? I tried "set", doesn't work. 

My solution has been to 'rewind' to -1 which still sends a note, but allows the first beat to play properly. That works, but it's ugly, and becomes difficult when i'm locating transport to particular bars other than just rewind.

1, What does the "transport state" outlet actually do? It seems to just send 1's with every tick. What is it? And why does it need to control a gate when it only ever sends "1"? 

2, So when you do @clocksource internal, what is that telling the transport? Presumably just saying that max controls the clock, doesn't it do that automatically? My main transport is already governing tempo, this one will be slaved to it so i can remove the tempo controls you added, but should i make my main transport "@clocksource internal"? 

3,  The start/stop/pause stuff is already being governed elsewhere, so i don't think i need that, but unsure about the trigger which is resetting a few object when it gets zero. I hooked this patch up to a makenote quickly and controlled it from my transport, (i.e not using your toggle and not sending zeros to that trigger) and it seemed to make no difference except maybe it's creating a flam when the transport loops back to bar1?

An easier way to understand what i'm saying - if you open the pasted patch below, and use the toggle i've created to switch it on/off, instead of your toggle, can you forsee a problem that the trigger is not recieving zeros? I think it might be double-generating the first note on "1", sounds like a flam. 

4, i'm still using one timepoint -  to loop the track back to bar1. When it gets to the variable loop point *See pic. Can you think of a better way to have a variable set the loop point without using [timepoint]. 

Also, last question, not just related to your patch, but i problem i've been having since i stopped using [timpoint] to create the beats - when i rewind (send zero to transport), it plays the first note on my patch as if it's playing bar1beat1, and then because of [change] the 1st note doesn't sound when i do press play. Is there a way to set the transport position without output? I tried "set", doesn't work. 
My solution has been to 'rewind' to -1 which still sends a note, but allows the first beat to play properly. That works, but it's ugly, and becomes difficult when i'm locating transport to particular bars other than just rewind. 

swing.... basically by putting an LFO on the clock speed... or you implement a delay for every number... and the delay times are bound to the number...

Your problem with retriggering of stuff when reset is usual

problem with counters, when one expects them to do something on "first"

beat, but same happens if one resets transport to beginning.

Transport state is NOT only sending "1" but also zero when stoped.

That said, I never use transport, and if I have to group notes by ticks,

That's why expression using transport's bar, beat, ticks

as in Holme's patch would fail, if one changes form 4/4 to 6/8

If you use that patch I posted it will not produce any flams and 1st beat will allways

Next question about loopin certain amount of bars or beats.

Transport is NOT a thing to loop, not for me anyway.

You can use modulo set to as many beats you want

Your problem with retriggering of stuff when reset is usual
problem with counters, when one expects them to do something on "first"
beat, but same happens if one resets transport to beginning.
Transport state is NOT only sending "1" but also zero when stoped.
That said, I never use transport, and if I have to group notes by ticks,
then I use absolute tick count, ignoring any time signature.

That's why expression using transport's bar, beat, ticks
as in Holme's patch would fail, if one changes form 4/4 to 6/8
while running.
----
If you use that patch I posted it will not produce any flams and 1st  beat will allways
make a note.
Next question about loopin certain amount of bars or beats.
Transport is NOT a thing to loop, not for me anyway.
You can use modulo set to as many beats you want
and loop the count.

Not sure how to quote reply on this forum, but thanks Nick. I'm sure Source is right about time sigs, but as i'm currently only in 4/4 (so far...), this might work nicely for me as a simple solution.

I see what you mean, so best to have the transport just running endlessly and modulo the bars or count to avoid sending it back to 0 on loops. That might solve my flam. I didn't think it was coming from your patch, but from the loop being created by the [timepoint], or me not using the trigger in your patch, so i'll experiment on that as suggested and should fix it.

 not getting a zero from that transport state. But i do get one from other transports in the patch. Maybe a max bug.

Screenshot 2021-10-30 at 17.30.52.png

I'd happily dump transports entirely from this patch, but not totally sure i understand what you're suggesting as a replacement. I'm only using transport for stop/start/goto/tempo controls, which then triggers a count (as you know). So if that could be replaced by something else that'd be cool.

Haven't checked out the "dirty patch" XD yet, but will do tonight.

Thanks again Source.
I see what you mean, so best to have the transport just running endlessly and modulo the bars or count to avoid sending it back to 0 on loops. That might solve my flam. I didn't think it was coming from your patch, but from the loop being created by the [timepoint], or me not using the trigger in your patch, so i'll experiment on that as suggested and should fix it. 

Weirdly, i'm definitely not getting a zero from that transport state. But i do get one from other transports in the patch. Maybe a max bug.


I'd happily dump transports entirely from this patch, but not totally sure i understand what you're suggesting as a replacement. I'm only using transport for stop/start/goto/tempo controls, which then triggers a count (as you know). So if that could be replaced by something else that'd be cool.

Haven't checked out the "dirty patch" XD yet, but will do tonight. 

Update, i get a zero, if i use the toggle directly on that transport. I don't get a zero if it's not that particular transport that was stopped. Strangely this isn't true of other transports which send a zero regardless of which one was stopped. Perhaps this is something to do with the clocksource argument?

Tried to make a version of [timepoint] that will follow a modulo of the bar count rather than actual transport position (so i don't have to loop transport - which is also inconsistent & creates flams).

Made something, but doesn't work. I dunno if the ticks are going past too fast for [zl compare] to pick up or what? But it's not working.

If i'm not looping transport, i need an alternative to [timepoint] because [timepoint] will expect a bang on e.g 33, when it's actually coming at 1 because of the modulo.

In the patch below, you should be able to choose one of the three timepositions on the right, and have them bang their position when the timeposition happens, but it works only occasionally for me.

If i'm not looping transport, i need an alternative to [timepoint] because [timepoint] will expect a bang on e.g 33, when it's actually coming at 1 because of the modulo. 

In the patch below, you should be able to choose one of the three timepositions on the right, and have them bang their position when the timeposition happens, but it works only occasionally for me. 

It is not allways easy to give ideal answer, in first place

in not knowing what exactly is the goal of the project.

If really all you need is to run swing eight notes ,

count and loop them, than you can get away with only few objects.

run tempo or metro set to eight notes, trigger counter set to

loop for wished amount of numbers, delay every 2nd number by swing amount using pipe.

It is not allways easy to give ideal answer, in first place
in not knowing what exactly is the goal of the project.
If really all you need is to run swing eight notes ,
count and loop them, than you can get away with only few objects.
no transport at all.
For example :
run tempo or metro set to eight notes, trigger counter set to
loop for wished amount of numbers, delay every 2nd number by swing amount using pipe.



If you want to get 1 1 0 from transport you must stop the metro.

And then start/stop metro and transport using toggle.

In the patch you posted transport will never output 1 1 0

Here is a patch with transport which has own name as well as metro so that no different

As you dont use raw ticks really, ticks in beat have been connected instead.

and better collection into list using pack and following

If you want to get 1 1 0 from transport you must stop the metro.
and remove @active 1 attribute.
I hope you understand why.
And then start/stop  metro and transport using toggle.
-------
In the patch you posted transport will never output 1 1 0

Here is a patch with transport which has own name as well as metro so that no different
transpost disturbes it.
Proper reset when stoped.
As you dont use raw ticks really, ticks in beat have been connected instead.
and better collection into list using pack and following
zl objects to avoid repetitions.
Everything has it's reason.

Here is patch that does what you tried,
and another option using match object


Hi David, with specific reference to your patch above not working as expected, its seems due to a typo in the metro, which should be [metro 

interval 1 ticks @active 1] (note the @ before "interval"). As it was, the metro was running at the default interval of 5ms, which around 5 times longer than a tick at 160 bps, so [% 480] was only ever reporting 0 by luck or patience!

I hope that clears up that specific question, but more generally to this thread, I can only agree with what Source Audio is saying.

Hi David, with specific reference to your patch above not working as expected, its seems due to a typo in the metro, which should be [metro @interval 1 ticks @active 1] (note the @ before "interval"). As it was, the metro was running at the default interval of 5ms, which around 5 times longer than a tick at 160 bps, so [% 480] was only ever reporting 0 by luck or patience!

Thanks everyone, this forum really is invaluable.

Doh, yes, i missed the @. Thankyou Nick and Source.

It's tricky coz the patch is really big (at least it's by far the biggest i've ever worked on) and requires external stuff, so i can only paste bits - i understand it must seem a bit confused, and appreciate your patience and help. 

One part of it only requires swung 8ths which is what i was initially asking about, but other parts (following the same overall time) need timepositions down to the tick. The former part I have working really solidly now, no longer needing to loop transport or use timepoints. The latter - which is basically a straight replacement for timepoint, but using a modulo on bars so it doesn't get confused by the transport not looping, should now work too with the typo fixed and using some of Source's additions for stability in last posted patch.

So basically, i think i'm good now - thanks for that. But one last thing, to answer Source "i hope you know why" in reference to the "active 1". No, the truth is i don't know. I'm reasonably down with all the transport attributes, but i don't get that one. I've looked on the reference and the help file, but neither mention it specifically. I assume it relates to the clocksource, but i can't find info on how. It would be useful to know if it affects a situation like mine where i'm running several transport objects together.

Finally, i totally see the rationale for working with raw ticks, and it's something i ought to get clearer about how to do effectively and use in my patches, but yes, for the moment i'm ok with 480 ticks just to get moving on this patch which i've been working on since May! Maybe i'll update later.

It's tricky coz the patch is really big (at least it's by far the biggest i've ever worked on) and requires external stuff, so i can only paste bits - i understand it must seem a bit confused, and appreciate your patience and help. 
One part of it only requires swung 8ths which is what i was initially asking about, but other parts (following the same overall time) need timepositions down to the tick.  The former part I have working really solidly now, no longer needing to loop transport or use timepoints. The latter - which is basically a straight replacement for timepoint, but using a modulo on bars so it doesn't get confused by the transport not looping, should now work too with the typo fixed and using some of Source's additions for stability in last posted patch.

So basically, i think i'm good now - thanks for that. But one last thing, to answer Source "i hope you know why" in reference to the "active 1". No, the truth is i don't know. I'm reasonably down with all the transport attributes, but i don't get that one. I've looked on the reference and the help file, but neither mention it specifically. I assume it relates to the clocksource, but i can't find info on how. It would be useful to know if it affects a situation like mine where i'm running several transport objects together.  

Finally, i totally see the rationale for working with raw ticks, and it's something i ought to get clearer about how to do effectively and use in my patches, but yes, for the moment i'm ok with 480 ticks just to get moving on this patch which i've been working on since May! Maybe i'll update later. 

metro with @active 1 runs as soon as transport starts,

any transport, if one did not bind it to some named transport.

That can cause unwanted bangs coming out.

I prefer a trigger with clearly organised order of execution,

so that one can stop the metro and transport,

or any other order needed to avoid flams and double or

If you really need to use transport I would use named

and isolated one , and also metro for it.

And a single one, if all has to run in sync.

You can grab all outlets and treat them separately for different

metro with @active 1 runs as soon as transport starts,
any transport, if one did not bind it to some named transport.
That can cause unwanted bangs coming out.
I prefer a trigger with clearly organised order of execution,
so that one can stop the metro and transport,
then reset transport to set ticks
or any other order needed to avoid flams and double or
unwanted triggers.
------
If you really need to use transport I would use named
and isolated one , and also metro for it.
And a single one, if all has to run in sync.
You can grab all outlets and treat them separately for different
divisions and outputs.


So you're saying that only a single instance of [transport] should be used, and then use [s] and [r] to send that to different parts of the patch?

As for naming it, I'm only using one (un)named transport, just multiple instances of it, so it's only annoying when i open a help patch and it changes the tempo or something, but yeah, i can do that too.

TBH, i still don't really understand what you mean about not using [transport] at all. Do you just count ticks off a metro? Surely that still needs a [transport] to think in terms of ticks or beats etc? How do you generate musical time without a transport?

Thanks Source. 
V informative.
So you're saying that only a single instance of [transport] should be used, and then use [s] and [r] to send that to different parts of the patch? 

As for naming it, I'm only using one (un)named transport, just multiple instances of it,  so it's only annoying when i open a help patch and it changes the tempo or something, but yeah, i can do that too. 

TBH, i still don't really understand what you mean about not using [transport] at all. Do you just count ticks off a metro? Surely that still needs a [transport] to think in terms of ticks or beats etc?  How do you generate musical time without a transport? 

I don't know your main patch, and so can' really make exact suggestions.

I just opened once one patch you posted and mentioned loads of

Making bars/beats/subdivisions out of metro - counter stream is a trivial task.

If one needs full tick resolution, then 1 tick metro.

If one knows that for example smallest time division would be 16th note,

than I'd rather use metro set to 16th note interval.

then run dividers modulo to whatever divisions and counts.

coll object is a perfect one to use instead.

you either store absolute time in ticks as indexes,

one needs to use symbol as index, so either

When bar counter reaches any stored index, coll will output data in that line,

could be cues, or note values , anything.

coll can embed stored stuff in the patcher, or load file from disk,

One would need to calculate bar-beats-units to ticks.

Stupid thing with bar beat counter is that elapsed time count is 

in reality 0 0 0 for the very beginning, so that when one calculates

ticks in for example 7/8 , position 6 3 0 it

would mean elapsed 5 bars, 2 beats and 0 ticks.

shit - it does not work without transport ! for any tempo and timesig conversions

would output 2400 if one inputs 1 1 0 in 4/4 bar.

Screen shot 2021-11-01 at 9.22.19 AM.png

And all that is reason I really refuse all that transport - translate stuff

and prefer to make calculations using standard objects.

In Max 6 I remember sending timesig messages to both transport and translate

in same patch made transport go nuts, really shity.

Back to number of transports in the patch,

I would prefer to have only one, and to send output to all needed destinations.

One can use bar beat or raw ticks output at same time,

and divide, loop or whatever localy at destination points if needed.

I don't know your main patch, and so can' really make exact suggestions.
I just opened once one patch you posted and mentioned loads of
timepoint objects in a sub patcher.
I would never do it so.
------
Making bars/beats/subdivisions out of metro - counter stream is a trivial task.
If one needs full tick resolution, then 1 tick metro.
If one knows that for example smallest time division would be 16th note,
than I'd rather use metro set to 16th note interval.
Simple, isn't it ?
then run dividers modulo to whatever divisions and counts.
-----
Now back to timepoint.
coll object is a perfect one to use instead.
you either store absolute time in ticks as indexes,
or bar/beat/ticks as symbol.
Depends a bit on what you really need.

coll example
1.1.0, 1;
1.3.240, 2;
3.1.320, 3;
etc
one needs to use symbol as index, so either
1.1.0 or "1 1 0"
When bar counter reaches any stored index, coll will output data in that line,
could be cues, or note values , anything.
coll can embed stored stuff in the patcher, or load file from disk,
to recall different sequences etc.
------
Option using absolute time in ticks
0, 1;
1920, 2;
2760, 3;
etc
One would need to calculate bar-beats-units to ticks.

Stupid thing with bar beat counter is that elapsed time count is 
in reality 0 0 0 for the very beginning, so that when one calculates
ticks in for example 7/8 , position 6 3 0 it
would mean elapsed 5 bars, 2 beats and 0 ticks.
Evan that translate object linked to transport
shit - it does not work without transport ! for any tempo and timesig conversions
would output 2400 if one inputs 1 1 0 in 4/4 bar.


And all that is reason I really refuse all that transport - translate stuff
and prefer to make calculations using standard objects.
In Max 6 I remember sending timesig messages to both transport and translate
in same patch made transport go nuts, really shity.
never used that stuff again.
------
Back to number of transports in the patch,
I would prefer to have only one, and to send output to all needed destinations.
One can use bar beat or raw ticks output at same time,
and divide, loop or whatever localy at destination points if needed.
here is one example patch


timepoint multiple bangs