how easy is it to sync M with the transport in max5

Sep 17, 2008 at 7:01pm

how easy is it to sync M with the transport in max5

If I’m algorithmically modulating time signatures in max (like a bar of 4/4 then a bar of 7/8 then a bar of 26/16) on the transport, can M deal with it?

#39807
Sep 17, 2008 at 7:38pm

so that’s like break-beats with midi patterns rather than drum samples?

#140397
Sep 18, 2008 at 3:05am

Quote: m/organ wrote on Wed, 17 September 2008 12:01
—————————————————-
> If I’m algorithmically modulating time signatures in max (like a bar of 4/4 then a bar of 7/8 then a bar of 26/16) on the transport

Sorry, this is getting a bit off topic, but I am interested in modulating time signatures too. And I find it overly limiting that I must be at time 0 to change the time signature. Otherwise the transport says “time signature cannot be changed unless time is at the beginning”.

I suspect this might be an attempt to prevent unpredictable behavior. I know in Logic, you can switch the ultrabeat sequencer from say 4/4 to 12/8, but if you do that in the middle of a piece when the sequencer is on step 0, it might jump to the middle of the sequence. I bet the reason is it’s programmed to calculate:
beat within measure = total beat count % beats per measure
So if you switch beats per measure, beat with the measure may suddenly jump to a completely different value.

Honestly, I’d rather have that behavior than be forced to only change time signatures at time 0. And I believe there are ways to compensate for the jump: queue up a timesig change for the next downbeat and store an offset value for properly calculating measures & beats from the current underlying time value. I’ll figure out a way to deal with it if Max doesn’t handle it for me.

Anyway, I hope this limitation will be removed one day. Consider it a feature request :)

#140398
Sep 18, 2008 at 5:29am

The reason time signatures can’t currently be changed at times other than 0 is that there are multiple interpretations of how to treat the past and the future after such a change, and I didn’t feel comfortable with making a commitment to any particular one at a time when I was trying to fix a lot of bugs in a huge release. Once I made such a commitment, it would be very difficult to change.

As an example, consider a change to 3/8 at tick 480 (after one measure of 4/4). What happens if you seek back to time 0?

a) you could take the “score” interpretation and say the time signature is back to 4/4. This means you have to store when all time signatures happened

b) you could say that the time signature remains what it is until it is changed, since someone could explicitly make another time signature change to 4/4 at time 0

To continue with this example, let’s say you implement something that can randomly decide to seek over the time signature change…or not. This means that any absolute bar/beat/unit time references will refer to different times depending on whether the time signature change happened.

Metrical scheduling in Max is not a “score” but some people who would like to think of their music in terms of a succession of time signature might be tempted to think it is. Others will see it more how I interpret it, which is as a sort of programmable state machine.

Sooner rather than later we will decide on a strategy, however. In the meantime, one thing that can be done is to write scores in bar/beat/unit values and use computations to convert these values to ticks before passing them to timing objects based on an evolving time signature value that reflects your aesthetic preferences.

David Z.

#140399
Sep 18, 2008 at 6:47am

Thanks for the informative explanation, David. It’s an interesting problem.

One of the best things about Max is it doesn’t lock you into particular interpretations about how music is supposed to work. I could certainly see myself wanting either interpretation of time signature changes depending on the situation. It will be awesome if you find a way to enable both interpretations. Not sure if that’s possible though, and there’s the usual problem of introducing too many options and overly complicating the interface.

Regardless, I’m looking forward to working with whatever strategy you decide on.

#140400
Sep 19, 2008 at 4:13pm

this might’ve been mentioned, but
you could hook a count object to a bang that happens at the beginning of each measure.

#140402
Sep 19, 2008 at 5:55pm

Quote: m/organ wrote on Fri, 19 September 2008 09:13
—————————————————-
>
> this might’ve been mentioned, but
> you could hook a count object to a bang that happens at the beginning of each measure.
>

I’m not sure how that would help me with the way I’ve been doing things…

How are you managing your time signature modulations and keeping track of time?

Lately I’ve been putting my events in a [coll] with the format:
bars.beats.ticks, pitch velocity duration (other parameters…);
And I use transport-synced [metro], [when], and [translate] to drive the coll. I like this approach because it provides some interesting opportunities to hook in some logic between [translate] and [coll] to mess with the time and play the events out of order, backwards, faster, slower, filter out beats, etc.

#140403
Sep 20, 2008 at 3:51pm

I’ve ditched it currently(haven’t actually gotten it to work flawlessly), but was storing “sections” in pattr.
the preset info includes time signature/tempo along with a duration in bars, the next section to trigger and so on. the transport resets at the changes. . .

#140404

You must be logged in to reply to this topic.