Forums > MaxMSP

midi sequencer

July 8, 2013 | 3:15 am


i have a problem with seq, look into my patch and add an event with add msg at position 0 as you can see in the max window seq read the event and the flush (who is banged at the end of the loop) arrived after

how to synchronize that?

thank you

  1. test-seq4.maxpat
July 8, 2013 | 1:55 pm


July 8, 2013 | 4:46 pm

huhu :)

July 8, 2013 | 11:54 pm

what’s your problem, man??????

July 9, 2013 | 1:30 am

ok, i try to explain again,
in this patch i use a seq and add an event at position 0,
and i make a flush at the end of the loop, so when i play the sequence i must have first the event noteon 60 100 and when the sequence reaches the end the flush generates the noteoff 60 0.
In fact, the flush generates the noteoff just after the noteon
perhaps it’s normal but i want to know how to resynchronize that

thank you

July 9, 2013 | 1:41 am

the behaviour of your current patch seems indeed a bit inconsistent. Not sure what you try to do, but maybe this is a valid approach ?


— Pasted Max Patch, click to expand. —


July 9, 2013 | 1:45 am

the behaviour of the [seq~] object, in fact, seems unreliable… sometimes it outputs twice its content, sometimes once… though i do’nt know that obejct well, but it does seem odd.

July 9, 2013 | 2:28 am

yes my patch is just an illustration of my problem and you’re right i have a lot of problem with this object but tell me what are you using for midi sequencing?

thank you

July 9, 2013 | 3:03 am

hem… i usually do it outside Max… but when i do it inside, i rather use [seq] (the non-signal version – i did not know of the signal one, it seems pretty recent) and if i was going to do a big project with midi sequencing i’d look at graphical things, like [detonate], or the bach library ( or thigns like the [note~] external ( or the rs.delos (, not free), but i’d say [seq~] seems cool… if only it was consistant… you could also try to use [techno~] if you need signal-driven sequencing, it’s cool, albeit maybe less than seq~.

July 9, 2013 | 3:07 am

maybe its worth reporting a bug to cycling regarding seq~’s output inconsistant repetition.

July 9, 2013 | 4:12 am

yes you’re right, it’s incredible that max haven’t a reliable midi sequencer, another problem is if you make an add 0 0. like i do in my patch the event is not played every time

July 9, 2013 | 6:34 am

Regarding the original patch, I think there is a timing conflict between the note playing at time 0 and the edge detector banging at time 0. Apparently the detector bang is sent just after the note and thus triggers an immediate note off. I’ve checked that a small delay of the note (eg. start time 0.1) avoids this timing problem but not sure about a general solution. In my experience synchronization with phasor~ is inherently problematic.

July 9, 2013 | 6:59 am

thank you
can you tell me if you use midi sequencing and what are you using for that?

July 9, 2013 | 7:42 am

Yes, I’m using [seq] with start/stop synchronization from transport.

July 9, 2013 | 8:26 am

ok, i try that it’s working not bad, are you making live recording?

July 9, 2013 | 9:34 am

Yes, recording and playback works perfectly for me.

July 9, 2013 | 10:52 am

are you making a flush at the end of the loop for eliminate the handle note?
do you quantize the note when you record?

July 9, 2013 | 11:33 am

No quantization and no flush at recording.
But I’m recording only linear sequences, ie. there is no loop.

July 10, 2013 | 1:07 am

hi Vichug,

have you a patch that can reproduce output seq~’s inconsistant repetition i’m going to report the differents problems to cycling.

thank you

July 10, 2013 | 2:31 am

Hey Zarby,
I just used the patch, and a print at the output of seq~.


— Pasted Max Patch, click to expand. —


Notably, this happens only when using the "global transport" patcher in the extras, and only when said patcher is opened : if you open this, activate it, then the inconsistency is there ; but if you then close the "global transport" patcher (without desactivating) your example continues to run, and this time, there is no inconsistancy. So, i’m not sure anymore who is the culprit : it might very well be the "global transport" patcher, the [transport] object, the [phasor~] behavior when synced with unit timing system, or the unit timing system itself…

July 10, 2013 | 3:35 am

i don’t understand this sentence "only when said pather is opened"

i try it but i don’t have this problem but i have another problem :
sometime the event in 0. is not played
of course you are in overdrive but have you in audio interrupt : on?
i modifiy the patch to add other events :


— Pasted Max Patch, click to expand. —


July 10, 2013 | 5:06 am

Just had a closer look at the phasor~ helpfile. There is a subpatch ‘using phasor~ with a metro’ comparing both synchronization methods on different stereo channels. I’ve connected a live.gain~ to observe the output channels and noticed that sometimes the very first beat from phaser~ is missing at transport start. This confirms my experience of unreliable phaser~ synchronization and may be related to your problems with seq~.

July 10, 2013 | 7:22 am
July 10, 2013 | 7:23 am

there’s a typo, i meant "only when said patcher is opened" – in the context, "said patcher" refering to "global transport".

July 10, 2013 | 7:35 am

ok, thank you

i am waiting for support response,
but i think that the seq~ object must be rethink in the manner of the groove~ object for example with a start and end of the loop, with synchronization output….

July 10, 2013 | 8:04 am

i believe asking for a looping function is asked a bit too much from seq, as "end of the file" or "last event" is not exactly an information you will find in midi files – not talking of data recorded live into seq.

for building a midi sequencer you might want to look into the detonate object first … before telling the support that you dont like seq, that is.

detonate is a bit weird at first, because you must use an external counter in conjunction with detonates delta time output, but when you get used to it you will find out that it is the perfect logic for a midi player object.
a working example of this kind of implementation should be somewhere in the detonate help file.


July 10, 2013 | 11:34 am

Asking for a midi sequencer with looping function makes perfect sense to me. There is no reason why midi and audio should be handled differently in this regard. A good example are clips in Ableton Live where both midi and audio clips have exactly the same looping functions.

As for [detonate], I don’t see much benefit over [seq] unless you want dynamic tempo changes.

July 10, 2013 | 7:06 pm

one of detonates benefits over seq is that you can build a looping function with it.
the only thing worth criticizing about seq is its misleading name. it should be called player.

and i really dont think that a programming language deserves a full featured "sequencer" with looping, overdubbing and quantisation.
the comparison between ableton live 9.0 and a max external from 1992 seems inappropiate. (but maybe thats just me, i also dont use groove~ or omx~ or nodes.)

July 11, 2013 | 12:43 am

i’m perfectly ok with Broc, i don’t understand why audio object evoluates and get benefit of time format, looping fonction etc… and not midi (external from 1992) it’s time to have a modern and reliable midi sequencer!!!

July 11, 2013 | 10:16 am

then build one – maxmsp would be the right tool for it. :)

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

Forums > MaxMSP