midi sequencer

    Jul 08 2013 | 10: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 laurent

    • Jul 08 2013 | 8:55 pm
    • Jul 08 2013 | 11:46 pm
      huhu :)
    • Jul 09 2013 | 6:54 am
      what's your problem, man??????
    • Jul 09 2013 | 8: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 laurent
    • Jul 09 2013 | 8: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 ?
    • Jul 09 2013 | 8: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.
    • Jul 09 2013 | 9: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 laurent
    • Jul 09 2013 | 10: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 (http://www.bachproject.net/home) or thigns like the [note~] external (http://www.noteformax.net/data/index.php/en/) or the rs.delos (https://cycling74.com/forums/announce-rs-delos-a-maxmsp-timeline-external-released/, 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~.
    • Jul 09 2013 | 10:07 am
      maybe its worth reporting a bug to cycling regarding seq~'s output inconsistant repetition.
    • Jul 09 2013 | 11: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
    • Jul 09 2013 | 1:34 pm
      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.
    • Jul 09 2013 | 1:59 pm
      thank you can you tell me if you use midi sequencing and what are you using for that?
    • Jul 09 2013 | 2:42 pm
      Yes, I'm using [seq] with start/stop synchronization from transport.
    • Jul 09 2013 | 3:26 pm
      ok, i try that it's working not bad, are you making live recording?
    • Jul 09 2013 | 4:34 pm
      Yes, recording and playback works perfectly for me.
    • Jul 09 2013 | 5:52 pm
      are you making a flush at the end of the loop for eliminate the handle note? do you quantize the note when you record?
    • Jul 09 2013 | 6:33 pm
      No quantization and no flush at recording. But I'm recording only linear sequences, ie. there is no loop.
    • Jul 10 2013 | 8: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 laurent
    • Jul 10 2013 | 9:31 am
      Hey Zarby, I just used the patch, and a print at the output of seq~.
      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...
    • Jul 10 2013 | 10: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 :
    • Jul 10 2013 | 12:06 pm
      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~.
    • Jul 10 2013 | 2:22 pm
    • Jul 10 2013 | 2:23 pm
      there's a typo, i meant "only when said patcher is opened" - in the context, "said patcher" refering to "global transport".
    • Jul 10 2013 | 2:35 pm
      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....
    • Jul 10 2013 | 3:04 pm
      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.
    • Jul 10 2013 | 6:34 pm
      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.
    • Jul 11 2013 | 2:06 am
      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.)
    • Jul 11 2013 | 7: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!!!
    • Jul 11 2013 | 5:16 pm
      then build one - maxmsp would be the right tool for it. :)