Forums > MaxMSP

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

September 17, 2008 | 7:01 pm

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?


September 17, 2008 | 7:22 pm

The only way to to anything like this that comes to
mind would be to define what you’re describing as
"timing" as a series of snapshots in M which are
triggered via MIDI, and having Max provide the
aforementioned MIDI input.

But why not just take this as an opportunity to
write yourself a Max patch that does what M
does, or a patch that uses the specific functionality
you like about M?


September 17, 2008 | 7:38 pm

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


September 18, 2008 | 3:05 am

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 :)


September 18, 2008 | 5:29 am

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.


September 18, 2008 | 6:47 am

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.


September 18, 2008 | 7:56 am

An easy way to fake time signature changes is to use multiple named
transport with their own time signature. You can then send messages to
your timed objects to change the transport they are connected to on
the fly.

Best,
ej

On 18 sept. 08, at 07:29, David Zicarelli
wrote:

>
> 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.
>


September 19, 2008 | 4:13 pm

adam,

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


September 19, 2008 | 5:55 pm

Quote: m/organ wrote on Fri, 19 September 2008 09:13
—————————————————-
> adam,
>
> 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.


September 20, 2008 | 3:51 pm

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. . .


September 20, 2008 | 7:06 pm

Funny you should mention sections.

– Pasted Max Patch, click to expand. –

Viewing 11 posts - 1 through 11 (of 11 total)