timepoint bug

Oct 6, 2008 at 11:57pm

timepoint bug

It seems there is some strange behavior with timepoint when you try to:

1. Use a timepoint object to “loop” a transport by rewinding the transport to 0 everytime you hit a certain bar.beat.unit.
2. Use a separate timepoint object to try to detect that same bar.beat.unit that the transport is being rewinded on.

For example, you have a timepoint object that is banging at 2.1.0, and you use that bang to reset the transport to 1.1.0. Then, elsewhere in the patch you have another timepoint object that is banging at 2.1.0.

Expected behavior: the “remote” timepoint object should bang each time the transport reaches 2.1.0.

Actual behavior: the “remote” timepoint object actually only bangs every other time the transport reaches 2.1.0, resulting in only half the number of bangs compared to the timepoint object that is rewinding the transport.

See attached max5 patch to clarify.

Can anyone confirm that this is a bug?

I’m using Max 5.0.5, Mac OS X 10.4.11

#40190
Oct 7, 2008 at 3:26am

#141979
Oct 7, 2008 at 11:33pm

how does one go about submitting official bug reports nowadays?

#141980
Oct 8, 2008 at 3:21am

I think your bug report was quite good. The c74 team was away this
Monday/Tuesday, but if they don’t answer tomorrow, I suggest you send again
your e-mail to support @ cycling74.com

J-F

#141981
Oct 8, 2008 at 5:42am

On 7 oct. 08, at 01:57, Scott wrote:

> It seems there is some strange behavior with timepoint when you try
> to:
>
> 1. Use a timepoint object to “loop” a transport by rewinding the
> transport to 0 everytime you hit a certain bar.beat.unit.
> 2. Use a separate timepoint object to try to detect that same
> bar.beat.unit that the transport is being rewinded on.
>
> For example, you have a timepoint object that is banging at 2.1.0,
> and you use that bang to reset the transport to 1.1.0. Then,
> elsewhere in the patch you have another timepoint object that is
> banging at 2.1.0.
>
> Expected behavior: the “remote” timepoint object should bang each
> time the transport reaches 2.1.0.
>
> Actual behavior: the “remote” timepoint object actually only bangs
> every other time the transport reaches 2.1.0, resulting in only half
> the number of bangs compared to the timepoint object that is
> rewinding the transport.
>
> See attached max5 patch to clarify.
>
> Can anyone confirm that this is a bug?

This doesn’t sound like a bug to me, it all depends on the order of
which the timepoints will trigger. When you have multiple timepoints
with the same time location, the order of firing is unknown, and you
shouldn’t rely on it. I would suggest you use delay in that situation.
Hope that makes sense.

ej

– Pasted Max Patch, click to expand. –
#141982
Oct 8, 2008 at 2:53pm

I disagree. I believe it is a bug. There is an object that doesn’t work predictably in all cases. It doesn’t behave the way you would expect it to from looking at the documentation on it.

If it’s not a bug, then it’s a feature that is working correctly. Why would we need such a feature?

And it’s not that I’m trying to rely on the order of the firing of multiple timepoint objects with the same time location. I don’t really care what order they fire in, I just want them all to actually fire every time. If a timepoint object is supposed to trigger at time 1.3.0, then it should trigger no matter what.

I believe what you’re implying is that in some cases, the timepoint object that is rewinding the transport fires first, and thus rewinds the transport before the other timepoint object can trigger. In other cases, the “remote” timepoint object fires first, then the local one fires and rewinds the transport, and all is well. I believe that is a bug. If the transport reaches 1.3.0, then all [timepoint 1.3.0] objects should fire, regardless of whether or not one of them triggers a sequence of events that changes the transport time.

#141983
Oct 8, 2008 at 2:56pm

Quote: Emmanuel Jourdan wrote on Tue, 07 October 2008 22:42
—————————————————-
>
> This doesn’t sound like a bug to me, it all depends on the order of
> which the timepoints will trigger. When you have multiple timepoints
> with the same time location, the order of firing is unknown, and you
> shouldn’t rely on it. I would suggest you use delay in that situation.
> Hope that makes sense.
>

Hmmm… this does make sense, but…

It is perfectly acceptable that there is no guaranteed order that timepoints will fire. However, if the transport hits a certain time, all timepoints should fire no matter what else happens during that scheduler cycle. If a transport time is reached, but only some timepoints fire, that is very counterintuitive. It’s a “leaky encapsulation” – the transport system is no longer a black box that just works as expected. I’d go as far as to call it a bug.

Perhaps it’s not worth all the special-casing (and maybe a performance hit) to fix this problem. But this kind of situation is going to remain one of those gotchas that will cause confusion for a lot of people. I can see a lot of people wanting to build a transport loop control, and then independently from that use transports to schedule other various events. The fact that this system becomes non-deterministic without extra, non-obvious workarounds is very bad for the user.

So if this behavior is going to remain, I suggest at least add something about this kind of scenario to the help files. But I think it’s safe to say that those of us who use transport heavily would very much like to see this behavior corrected.

#141984
Oct 8, 2008 at 2:58pm

Quote: Adam Murray wrote on Wed, 08 October 2008 07:56
—————————————————-
> I can see a lot of people wanting to build a transport loop control, and then independently from that use transports to schedule other various events.

Whoops, I meant: “build a transport loop control [with timepoints], and then independently from that use [timepoints] to schedule other various events.”

Long story short, timepoints should always fire when that time occurs.

#141985
Oct 8, 2008 at 8:23pm

#141986
Oct 8, 2008 at 9:24pm

This is one of those frustrating situations in which a user is not doing things that we expected. I don’t think it is a bug, but I see how it can be viewed that way.

When the transport is changed as a result of a bang from a timepoint, the value of the current time is changed immediately.

This is what you want, because timing accuracy for a loop depends on the real-time equivalence between the old time and the new time. We could, when seeking the transport, wait until any other events at this same exact time were executed, whether temporary (from metro 4n objects) or permanent (from timepoints). That is not how the algorithm of the scheduler works now, and I have no plans to rewrite it at the current time. I might might consider changing it at some point in the future, as a feature request. I would need to determine whether it would introduce certain other problems.

Imagine a list of things to do at time X:

A. go shopping
B. pick up the kids from school
C. change time to Y

You could argue that we should use mind-reading tricks to sort these events so that C always happens last. But that is not how the system works. When C happens before B or A, the time is no longer X, and therefore, A and B are no longer applicable. Sorry kids, maybe you can walk home.

David Z.

#141987
Oct 8, 2008 at 11:52pm

David,

Perhaps I am just trying to do something the wrong way then. Here’s how I ran into this problem in the first place:

I have a patch that loops a transport, let’s say a 16 bar loop. While the loop is running, the user can choose to time certain events based on the transport position. For instance, they can mute that particular channel at the “next beat” or at the “next bar” or at the “next loop”.

So, if the user chooses to mute that channel at the next bar, then I get the current transport position, add a bar to it (and cut off the units to 0), and send it to a timepoint object to trigger at the next bar. No problems.

However, how about if they want to mute a channel at the “next loop”? In other words, when the transport gets set back to 1.1.0. Or, what happens if the transport is at bar 15 in a 16-bar loop, and the user chooses to mute that channel at the next bar? Then I’m going to end up with a timepoint object that is waiting for the loop point to happen, and maybe it’ll trigger and maybe it won’t.

Is there a better way to accomplish this that doesn’t use timepoint objects, or uses them in a different way?

Also, is there a particular reason that in my example patch, the timepoint object that is NOT rewinding the transport gets triggered exactly half as many times as the other timepoint object?

#141988
Oct 9, 2008 at 12:49am

If it’s not too much trouble, let’s have a look at your patch

You can send it to me privately if you would prefer.

-A

#141989
Oct 9, 2008 at 4:48pm

David Zicarelli schrieb:
> When C happens before B or A, the time is no longer X, and therefore,
> A and B are no longer applicable.

Out of a programmers point of view everything is sequential. But even
programmers got to the point and found solutions which is the human way
of thinking, We want that C, B and A happen at the same time. If all
timepoints are just a reference to a single event, then they could all
still recognize that it happened, or in other words, it had been reached…

> Sorry kids, maybe you can walk home.

Sorry Master, musicians tend to insist of not being programmers, as that
way of thinking doesn’t make musical sense. If we would just walk home,
the problem still remains…
I know programmers can switch to parallel thinking… ;-)
Emmanuels proposition to deferlow the reset unfortunately breaks the
tightness as you correctly pointed out. As all transports are actually
one, why can’t all timepoints who look for the same time be one?

The obvious workaround would be to use only a single timepoint and send
all infos to the places you need from that one like in the patch below…

But the same method could be put into the timepoint object, I expected
the timpoint to be nothing more than a receive object with a match for a
transport point. It would tell transport which points to send into the
world and all would receive the message and compare it to their stored
match -> bang…

– Pasted Max Patch, click to expand. –


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#141990
Oct 9, 2008 at 5:36pm

If you want to do something at the “next point in time” independent of transport position, you may want to think about using a delay object. delay, pipe, and metro wrap their intervals around loops. This is generally more flexible than using dynamically set timepoints (which, as has been noted, broke somewhat in 5.0.5 and will be fixed in the next update).

You’ll probably also want to mess with quantizing the delay.

David Z.

#141991
Oct 9, 2008 at 6:38pm

– Pasted Max Patch, click to expand. –
#141992
Oct 9, 2008 at 10:18pm

the only problem with delay is that it won’t work with a fluctuating tempo. The patch will have an option to gradually change the tempo over time as well..

I’ll take a look at the examples everyone posted and see if anything works.

Thanks

#141993
Oct 9, 2008 at 10:55pm

I think I can get it done with one of Andrew’s suggestions; it’s just not the first way I thought to do it, I guess. I still think it would be a lot cleaner if timepoint objects behaved the way I think they should, but I understand that there could be ramifications to modifying the scheduler code in this way.

The two ways I’m going to try to work around this problem are:

1. Use metro objects synced to the transport, and have them fire into gates or onebangs that open selectively when I need to know when the next beat/bar/loop happens. In my patch, this will result in a whole lot of metros firing bangs into closed gates. Not sure how that will affect performance yet.

2. Keep using timepoint objects, but instead of setting them to look for the actual loop point (i.e. 16.1.0), I’ll set them to look for one tick before the actual loop point, (15.4.479). While this is hacky, I’m really not concerned about one tick which, for most tempos, is 1 or 2 milliseconds or less. The only tricky part will be making it work when I’m in a time signature that’s not based on quarter notes, like 6/8 or something, in which case I’d have to trigger for 15.5.239 …. yikes

#141994
Oct 9, 2008 at 11:04pm

Also, Andrew, your solution using metro and onebang doesn’t allow for time signatures with an 8 or 16 in the denominator, like 6/8 or 5/16.

#141995
Oct 9, 2008 at 11:25pm

Another possibility for you is to roll your own bar counting mechanism.

Set your main transport with a bar length of a few zillion and create all the looping tempo changing timesig changing stuff yourself.

-A

– Pasted Max Patch, click to expand. –
#141996
Oct 9, 2008 at 11:49pm

>Also, Andrew, your solution using metro and onebang doesn’t allow for time signatures with an 8 or 16 in the denominator, like 6/8 or 5/16.

Now it does. I think this solves your tempo changing problem as well.

-

– Pasted Max Patch, click to expand. –
#141997

You must be logged in to reply to this topic.