seq~ phased to transport & the first event problem

Julien Bayle's icon

Hi there,
building a new sequencer based on a master JS script sending messages to a seq~ , I have found a workaround to be sure the first note is played everytime after the first play: offsetting the phasor feeding the seq.

The whole stuff is in the Max for Live context.

This workaround is ugly and a bit a non sense because that phasor is locked to transport in order to keep synced and I offset the whole stuff a bit.

any (light) tips?

many thanks

broc's icon

First I would try getting to the root of the problem, ie. why the first note is not always played.
Or is this a known issue/bug?

Julien Bayle's icon

I described my problem bad..

When I start the transport, the first note of my .. session (til I press stop, I mean) isn't play.
But the first note of the sequence itself is played everytime (except the first time .. thus)

Guillaume's icon

Hey Julien, I came across the same problem now, ten years later haha..

I found a nice work around I think.
It's a bit complicated to explain, and it's maybe not the best solution because we still read the seq~ with a tiny delay but take a look at the patch. Instead of using a phasor to drive the seq with a "continuous" signal, I use an audio counter. Then, instead of having a cycle that goes from 0 to 1, it goes from 1 to 1000 and I put the first event on 1 instead of 0.

Max Patch
Copy patch and select New From Clipboard in Max.

Please everyone, give us your opinion on this problem, that's really not normal that the first event with seq (if it start at 0) is not played the first time