[sharing is fun] basic sequencer


    Jun 14 2007 | 1:27 pm
    Hi,
    Seeing the recent fuzz about sequencers and timing accuracy on this forum; here is a very very simple sequencer made out of very very basic max objects.
    I guess it can be useful as an illustration of how a sequencer works.
    http://www.arttech.nl/basic-sequencer.zip
    Just enable Play.
    Furthermore: is there a timing problem with this sequencer?
    Cheers,
    Mattijs

    • Jun 14 2007 | 2:05 pm
      That's a nice model!
      Mind you, since you made it easy to load many duplicate events, you might try loading up multiple copies of all of them. If you give it 4 or 5 copies of each event, and let it play for a while, you'll probably see/hear what people are talking about. Every once in a while you get pronounced flamming between parts. The flams vary from just funky phasing, to outright flams. Which attack in the flam is the right one? Which one's on time?
      This is on a PPC G5 dual 1.8, os x 10.4.9, max 4.6.3. Maybe it's my machine, but I'm not exactly running a centris 660av anymore! ;-)
      J.
    • Jun 14 2007 | 2:15 pm
      Quote: jbm wrote on Thu, 14 June 2007 16:05
      ----------------------------------------------------
      > That's a nice model!
      Thanks
      >
      > Mind you, since you made it easy to load many duplicate events, you might try loading up multiple copies of all of them. If you give it 4 or 5 copies of each event, and let it play for a while, you'll probably see/hear what people are talking about. Every once in a while you get pronounced flamming between parts. The flams vary from just funky phasing, to outright flams. Which attack in the flam is the right one? Which one's on time?
      But wait, that has nothing to do with timing. That is about trying to play equal events multiple times at once. If you add two notes on top of each other in Logic you get the same effect.
      Let's for a moment assume you won't add two equal events on the same position.
      > This is on a PPC G5 dual 1.8, os x 10.4.9, max 4.6.3. Maybe it's my machine, but I'm not exactly running a centris 660av anymore! ;-)
      If you only enable Play after starting the patch (without adding any more events) there is no problem, right?
      Mattijs
    • Jun 14 2007 | 2:24 pm
      >
      >
      > But wait, that has nothing to do with timing. That is about trying to play equal events multiple times at once. If you add two notes on top of each other in Logic you get the same effect.
      >
      hehe... Sorry I had to be a pest. Mind you, I have to say that you don't get the same effect adding two or more notes on top of one another in Logic. If you did, they wouldn't have sold many copies. I only did this to show the fact that the timing problems that I think people generally complain about aren't really timing, per se, but are scheduling problems. That's where timing problems seem to come from, and Max seems to be really sensitive in this regard.
      > Let's for a moment assume you won't add two equal events on the same position.
      >
      Fair enough. But if we're running more than one track, chances are we'll have multiple events on the same position. What about a chord, for example? Or, heaven forbid, two chords. If you let it play for a while, you'll see what I mean. Sometimes you get a full-on flam. That is, I think, what gets people all wound-up about timing problems and the scheduler.
      As always, I'm open to being proven wrong...
      J.
    • Jun 14 2007 | 3:01 pm
      Mind that in this patch the events are loaded with a loadbang. Don't load them yourself. If I load the patch and do nothing but enable dsp and then press Play I get a very straight little beat loop and I don't experience timing/phasing/flamming problems in any form.
      So I'm curious what you might be meaning. Is there a chance you could record what you hear and post it on the forum?
      I'm so keen on this because I have the strong feeling we can make a strong statement towards this ongoing timing discussion by providing examples like the patch I posted.
      Mattijs
      Btw I just saw I forgot to connect the clear bang properly. I updated the link: http://www.arttech.nl/basic-sequencer.zip
      Quote: jbm wrote on Thu, 14 June 2007 16:24
      ----------------------------------------------------
      > >
      > > But wait, that has nothing to do with timing. That is about trying to play equal events multiple times at once. If you add two notes on top of each other in Logic you get the same effect.
      > >
      >
      > hehe... Sorry I had to be a pest. Mind you, I have to say that you don't get the same effect adding two or more notes on top of one another in Logic. If you did, they wouldn't have sold many copies. I only did this to show the fact that the timing problems that I think people generally complain about aren't really timing, per se, but are scheduling problems. That's where timing problems seem to come from, and Max seems to be really sensitive in this regard.
      >
      > > Let's for a moment assume you won't add two equal events on the same position.
      > >
      >
      > Fair enough. But if we're running more than one track, chances are we'll have multiple events on the same position. What about a chord, for example? Or, heaven forbid, two chords. If you let it play for a while, you'll see what I mean. Sometimes you get a full-on flam. That is, I think, what gets people all wound-up about timing problems and the scheduler.
      >
      > As always, I'm open to being proven wrong...
      >
      > J.
      >
      >
      >
      >
      ----------------------------------------------------
    • Jun 14 2007 | 3:28 pm
      On second thought I might have interpreted your post incorrectly. Did you mean you added the events multiple times on purpose?
      Quote: jbm wrote on Thu, 14 June 2007 16:24
      ----------------------------------------------------
      > > Let's for a moment assume you won't add two equal events on the same position.
      > >
      >
      > Fair enough. But if we're running more than one track, chances are we'll have multiple events on the same position. What about a chord, for example? Or, heaven forbid, two chords.
      Note, I was talking about two -equal- events on the same position. So chords and multiple tracks are no problem since these events are different, even though they might be triggered at the same time. In my example hihats are triggered simultaneously with bassdrums.
      > If you let it play for a while, you'll see what I mean. Sometimes you get a full-on flam. That is, I think, what gets people all wound-up about timing problems and the scheduler.
      Ok, I believe you're taking two steps at a time here where you shouldn't.
      So
      1) there are flams after you added the events to the sequencer multiple times -> This is expected behaviour since in that case two or more bassdrums will be sequenced to be triggered at the same time.
      2) people get wound-up about timing problems and the scheduler. -> I don't think the flams have anything to do with timing or the scheduler, as mentioned above. The reason -I- think people get wound-up about timing and scheduler problems is because they don't understand how those systems work. Which we can't expect them to because there is no proper documentation about this for non-software-engineers. This patch is meant as an illustration how to use max correctly in case you want to build a sequencer.
      Mattijs
      >
      > As always, I'm open to being proven wrong...
      >
      > J.
      >
      >
      >
      >
      ----------------------------------------------------
    • Jun 14 2007 | 3:39 pm
      Quote: Mattijs wrote on Thu, 14 June 2007 16:28
      ----------------------------------------------------
      > On second thought I might have interpreted your post incorrectly. Did you mean you added the events multiple times on purpose?
      >
      Well, I added them accidentally at first, then started messing around with that. I realize it may not have been exactly "fair" to do that, as the patch is clearly not made with that sort of polyphony in mind... But I thought it was interesting, and symptomatic of the sorts of problems people talk about, that it did start phasing and flamming. I mean, it's common practice to define a chord, in midi, as a series of pitches sent at (essentially) the same time.
      Anyway, yes, for the most part, I deliberately loaded multiple events. gulp... I realize that the flamming problems may have been more related to the little sampler's monophonic design, than to any problems with timing.
      J.
    • Jun 14 2007 | 3:48 pm
      Either way, I ran it for about 2 minutes with only single events loaded. It didn't flam, but it did drop a number of events altogether. I recorded the output with an sfrecord~. Maybe I can post it on my site and send you a link.
      I'm going to make a version of this using 4 instances of your basic patch, with one start toggle, just to see if the flamming still occurs.
      J.
    • Jun 14 2007 | 4:03 pm
      Quote: jbm wrote on Thu, 14 June 2007 17:39
      ----------------------------------------------------
      > Quote: Mattijs wrote on Thu, 14 June 2007 16:28
      > ----------------------------------------------------
      > > On second thought I might have interpreted your post incorrectly. Did you mean you added the events multiple times on purpose?
      > >
      >
      > Well, I added them accidentally at first, then started messing around with that. I realize it may not have been exactly "fair" to do that, as the patch is clearly not made with that sort of polyphony in mind...
      Ok, that explains the miscommunication.
      > But I thought it was interesting, and symptomatic of the sorts of problems people talk about, that it did start phasing and flamming.
      Perhaps, but for the moment let's try to seperate the ambiguity about timing and sequencing from other possible problems people may have.
      > I mean, it's common practice to define a chord, in midi, as a series of pitches sent at (essentially) the same time.
      Yes, but again, even though a chord may consist of multiple events defined at the same time, these are not -equal- events. A chord is built with events that differ in pitch.
      In my example events are indeed played at the same time: hihats, snares and bassdrums. They are played by a deliberately simple monophonic drum sampler. As you said, it requires a polyphonic engine to play a chord, but there is no restriction to playing a chord as far as the sequencer is concerned.
      >
      > Anyway, yes, for the most part, I deliberately loaded multiple events. gulp... I realize that the flamming problems may have been more related to the little sampler's monophonic design, than to any problems with timing.
      Thanks a lot for confirming. This is important because in fact I am hoping to refer to this patch from now on whenever someone starts another topic about perceived inherent timing flaws in Max.
      Any additions are of course welcome. This includes changes to the interface that could lower the risk of possible user mistakes such as adding multiple copies of events ;)
      Best,
      Mattijs
    • Jun 14 2007 | 4:04 pm
      Okay, so what I just did was to pull out the sampler, and give it a changeable argument, just to specify independent buffers. I made a patcher with 4 instances of your sequencer, with arguments for the buffers. The all start on the same toggle. The outputs feed into a stereo sfrecord~. I put two of the instances into the left channel and two into the right, so any timing problems would be really obvious. Basically, it does okay. When playback timing is really locked, the output is mono, dead centre. When it wavers the stereo channels really "pop" out. As I say, it didn't do too badly, but it's not stellar. And we're really not talking about sample-accuracy here. They flam, which means they're many ms apart.
      J.
      sequencer
      sampler
      test patcher
    • Jun 14 2007 | 4:07 pm
      oh, and btw, it's kind of a cool effect when they do start to wander! ;-)
    • Jun 14 2007 | 4:15 pm
      Quote: jbm wrote on Thu, 14 June 2007 17:48
      ----------------------------------------------------
      > Either way, I ran it for about 2 minutes with only single events loaded. It didn't flam, but it did drop a number of events altogether.
      You are right about that. When I minimize/unlock patches and switch programs sometimes it happens that events are dropped. I am curious what that could be.
      > I recorded the output with an sfrecord~. Maybe I can post it on my site and send you a link.
      I think I already experienced what you mean. I'll look into the patch some more to see how this can be explained.
      >
      > I'm going to make a version of this using 4 instances of your basic patch, with one start toggle, just to see if the flamming still occurs.
      Ok, let me know what your results are.
      Mattijs
    • Jun 14 2007 | 4:17 pm
      Ah, thanks. I'll check out your patch, I hope in a few more hours.
      Mattijs
      Quote: jbm wrote on Thu, 14 June 2007 18:04
      ----------------------------------------------------
      > Okay, so what I just did was to pull out the sampler, and give it a changeable argument, just to specify independent buffers. I made a patcher with 4 instances of your sequencer, with arguments for the buffers. The all start on the same toggle. The outputs feed into a stereo sfrecord~. I put two of the instances into the left channel and two into the right, so any timing problems would be really obvious. Basically, it does okay. When playback timing is really locked, the output is mono, dead centre. When it wavers the stereo channels really "pop" out. As I say, it didn't do too badly, but it's not stellar. And we're really not talking about sample-accuracy here. They flam, which means they're many ms apart.
      >
    • Jun 14 2007 | 4:20 pm
      Well personally I prefer a system to work flawlessly. If I want a cool effect I will program it myself. ;)
      Quote: jbm wrote on Thu, 14 June 2007 18:07
      ----------------------------------------------------
      > oh, and btw, it's kind of a cool effect when they do start to wander! ;-)
      >
      ----------------------------------------------------
    • Jun 14 2007 | 4:45 pm
      Quote: Mattijs wrote on Thu, 14 June 2007 17:20
      ----------------------------------------------------
      > Well personally I prefer a system to work flawlessly. If I want a cool effect I will program it myself. ;)
      >
      ...indeed.
      It would be nice to get to the bottom of this, as this exchange has really exemplified some of my joys and frustrations with Max.
      Joy: being able to make simple, elegant, and functional music machines, like your little sequencer object.
      Frustration: that such nice, clean objects as yours can have problems scaling to larger environments, when used as abstractions.
      cheers,
      J.
    • Jun 14 2007 | 6:37 pm
      Quote: jbm wrote on Thu, 14 June 2007 18:04
      ----------------------------------------------------
      > Okay, so what I just did was to pull out the sampler, and give it a changeable argument, just to specify independent buffers. I made a patcher with 4 instances of your sequencer, with arguments for the buffers. The all start on the same toggle. The outputs feed into a stereo sfrecord~. I put two of the instances into the left channel and two into the right, so any timing problems would be really obvious. Basically, it does okay. When playback timing is really locked, the output is mono, dead centre. When it wavers the stereo channels really "pop" out. As I say, it didn't do too badly, but it's not stellar. And we're really not talking about sample-accuracy here. They flam, which means they're many ms apart.
      >
      I tested your patch. Here is a recording of what happens when I play the sequence (overdrive enabled) and then start opening applications, browsing to heavy flash websites, etc, on a Powerbook G4 1.25.
      As far as I can hear there is indeed some stereo/phasing-ish effect, but I can hear no flamming. So I'd say that there may be an error of 1 or 2 ms (in the range of phasing), but not around 30 ms (in the range of flamming).
      And then there are the moments that everything halts for a short moment, which I assume happens when the cpu is overloaded and can't be used by max for a short moment. Note that no events are dropped in such a case and no cumulative error occurs (something a lot of people complain about when using metro and counter).
      Based on these results I'd say everything works as expected.
      An interesting find regarding the dropping out of events: on the powerbook this problem doesn't occur! A few hours ago I was on a MacPro Quadcore where the dropouts occurred approximately once in a minute.
      Could this have something to do with multiple cores (i.e. the dsp thread running on a separate processor)? Would you have the oppurtunity to do a test on a single-core computer?
      Mattijs
    • Jun 14 2007 | 7:13 pm
      cool patch, and i didnt expect it to be built that way!
      i have to admit the thought never crossed my mind to use cpuclock and the time divisions as float for events.
      but then again i'm not a software engineer... i tend to go for signal based clocks as i find them more reliable, especially past 1/32 divisions - which isn't that fast when doing intricate rhythms.
      to illustrate the grudge i have with metro (or event scheduler?), see patch below. it doesnt seem to matter if i have overdrive on / off with metro. BTW, this is also on a dual core MBP.
      sometimes i feel Max timing goes through a Logic humanise effect!
      j
    • Jun 14 2007 | 7:38 pm
      Quote: Mattijs wrote on Thu, 14 June 2007 19:37
      ----------------------------------------------------
      > Quote: jbm wrote on Thu, 14 June 2007 18:04
      > ----------------------------------------------------
      > > Okay, so what I just did was to pull out the sampler, and give it a changeable argument, just to specify independent buffers. I made a patcher with 4 instances of your sequencer, with arguments for the buffers. The all start on the same toggle. The outputs feed into a stereo sfrecord~. I put two of the instances into the left channel and two into the right, so any timing problems would be really obvious. Basically, it does okay. When playback timing is really locked, the output is mono, dead centre. When it wavers the stereo channels really "pop" out. As I say, it didn't do too badly, but it's not stellar. And we're really not talking about sample-accuracy here. They flam, which means they're many ms apart.
      > >
      >
      > I tested your patch. Here is a recording of what happens when I play the sequence (overdrive enabled) and then start opening applications, browsing to heavy flash websites, etc, on a Powerbook G4 1.25.
      >
      > http://www.arttech.nl/basic-sequencer-recording.aif
      >
      > As far as I can hear there is indeed some stereo/phasing-ish effect, but I can hear no flamming. So I'd say that there may be an error of 1 or 2 ms (in the range of phasing), but not around 30 ms (in the range of flamming).
      >
      > And then there are the moments that everything halts for a short moment, which I assume happens when the cpu is overloaded and can't be used by max for a short moment. Note that no events are dropped in such a case and no cumulative error occurs (something a lot of people complain about when using metro and counter).
      >
      > Based on these results I'd say everything works as expected.
      >
      > An interesting find regarding the dropping out of events: on the powerbook this problem doesn't occur! A few hours ago I was on a MacPro Quadcore where the dropouts occurred approximately once in a minute.
      >
      > Could this have something to do with multiple cores (i.e. the dsp thread running on a separate processor)? Would you have the oppurtunity to do a test on a single-core computer?
      >
      > Mattijs
      ----------------------------------------------------
      This is actually very interesting, and a little disconcerting. I can't post my recording right now, but I'll post it tomorrow. My playback had pronounced flamming, which went in phases - and I would guess, coincidentally, that it happened around every minute. It would flam for 2 or 3 bars, then go back to normal for around a minute, then start flamming again. My machine is dual G5 - though not dual-core. What machine was your recording made on? I'm now *very* curious about this... I can try disabling one of my CPUs tomorrow in the CHUD tools as well, just to see if the periodic flamming goes away. I'll report back at some point tomorrow, and post my recording as well.
      cheers,
      J.
    • Jun 14 2007 | 7:50 pm
      Quote: justin wrote on Thu, 14 June 2007 21:13
      ----------------------------------------------------
      > cool patch, and i didnt expect it to be built that way!
      Thanks justin! For the record, I assume seq~ works exactly this way, the difference is that this allows for a look inside and can be educative in that aspect.
      >
      > i have to admit the thought never crossed my mind to use cpuclock and the time divisions as float for events.
      >
      > but then again i'm not a software engineer... i tend to go for signal based clocks as i find them more reliable, especially past 1/32 divisions - which isn't that fast when doing intricate rhythms.
      >
      > to illustrate the grudge i have with metro (or event scheduler?), see patch below. it doesnt seem to matter if i have overdrive on / off with metro. BTW, this is also on a dual core MBP.
      >
      > sometimes i feel Max timing goes through a Logic humanise effect!
      I tested your patch and recorded a few seconds of audio at a subdivision of 32. On a powerbook G4. In the middle of the recording I switch from the metro output to the phasor output. I don't hear a difference.
      Maybe you could also post a recording so that we can compare..
      Cheers,
      Mattijs
      btw: a tip: you might have named the number boxes of the bpm and subdivision. Sending a loadmess with a functional value is also a pro.. One could be less tempted to try your patch if one had to guess what those number boxes are for. ;)
    • Jun 14 2007 | 7:57 pm
      Getting something rather strange when I try to download the patch (updated
      link) - it starts to download as 'basic-sequencer.zip', then changes into an
      XL file called " staff_rota_wb_11.06.07_with_no_end_times.xls" !
      Subsequent attempts to download it result in exactly the same behaviour,
      with the original being overwritten, instead of the usual Safari behaviour
      of adding a '1' to the file name...
      However, I can say that when I downloaded the original patch at work and
      ran it, the timing was not good (Intel iMac 2GHz); no flamming, but obvious
      timing glitches. Unfortunately I can't try it again here at home, for the
      reason above,
      Cheers
      Roger
      On 14/6/07 16:01, "Mattijs Kneppers" wrote:
      >
      > Mind that in this patch the events are loaded with a loadbang. Don't load them
      > yourself. If I load the patch and do nothing but enable dsp and then press
      > Play I get a very straight little beat loop and I don't experience
      > timing/phasing/flamming problems in any form.
      >
      > So I'm curious what you might be meaning. Is there a chance you could record
      > what you hear and post it on the forum?
      >
      > I'm so keen on this because I have the strong feeling we can make a strong
      > statement towards this ongoing timing discussion by providing examples like
      > the patch I posted.
      >
      > Mattijs
      >
      > Btw I just saw I forgot to connect the clear bang properly. I updated the
      > link: http://www.arttech.nl/basic-sequencer.zip
      >
      > Quote: jbm wrote on Thu, 14 June 2007 16:24
      > ----------------------------------------------------
      >>>
      >>> But wait, that has nothing to do with timing. That is about trying to play
      >>> equal events multiple times at once. If you add two notes on top of each
      >>> other in Logic you get the same effect.
      >>>
      >>
      >> hehe... Sorry I had to be a pest. Mind you, I have to say that you don't get
      >> the same effect adding two or more notes on top of one another in Logic. If
      >> you did, they wouldn't have sold many copies. I only did this to show the
      >> fact that the timing problems that I think people generally complain about
      >> aren't really timing, per se, but are scheduling problems. That's where
      >> timing problems seem to come from, and Max seems to be really sensitive in
      >> this regard.
      >>
      >>> Let's for a moment assume you won't add two equal events on the same
      >>> position.
      >>>
      >>
      >> Fair enough. But if we're running more than one track, chances are we'll have
      >> multiple events on the same position. What about a chord, for example? Or,
      >> heaven forbid, two chords. If you let it play for a while, you'll see what I
      >> mean. Sometimes you get a full-on flam. That is, I think, what gets people
      >> all wound-up about timing problems and the scheduler.
      >>
      >> As always, I'm open to being proven wrong...
      >>
      >> J.
      >>
      >>
      >>
      >>
      > ----------------------------------------------------
      >
      >
      > --
      > SmadSteck - http://www.smadsteck.nl
      > Hard- and software for interactive audiovisual sampling
    • Jun 14 2007 | 8:00 pm
      That seems pretty weird indeed. My recordings were done on a powerbook G4 1.25 GHz (1 processor) with MaxMSP 4.6.2 with overdrive on and default dsp settings (I/O vector size 512, signal vector size 64, scheduler in audio interrupt off)
      My guess was there could be a relation between the dropping out of events and multiple cores. But not between multiple cores and periodic flamming..
      Mattijs
      Quote: jbm wrote on Thu, 14 June 2007 21:38
      ----------------------------------------------------
      > This is actually very interesting, and a little disconcerting. I can't post my recording right now, but I'll post it tomorrow. My playback had pronounced flamming, which went in phases - and I would guess, coincidentally, that it happened around every minute. It would flam for 2 or 3 bars, then go back to normal for around a minute, then start flamming again. My machine is dual G5 - though not dual-core. What machine was your recording made on? I'm now *very* curious about this... I can try disabling one of my CPUs tomorrow in the CHUD tools as well, just to see if the periodic flamming goes away. I'll report back at some point tomorrow, and post my recording as well.
      >
      > cheers,
      >
      > J.
      >
      ----------------------------------------------------
    • Jun 14 2007 | 8:06 pm
      Here is the zip as attachment.
      Mattijs
      Quote: roger.carruthers wrote on Thu, 14 June 2007 21:57
      ----------------------------------------------------
      > Getting something rather strange when I try to download the patch (updated
      > link) - it starts to download as 'basic-sequencer.zip', then changes into an
      > XL file called " staff_rota_wb_11.06.07_with_no_end_times.xls" !
      > Subsequent attempts to download it result in exactly the same behaviour,
      > with the original being overwritten, instead of the usual Safari behaviour
      > of adding a '1' to the file name...
      > However, I can say that when I downloaded the original patch at work and
      > ran it, the timing was not good (Intel iMac 2GHz); no flamming, but obvious
      > timing glitches.
      The question is: did this timing glitches occur without your cpu being busy with other stuff? When the cpu is at 100% it is quite normal that timing glitches will occur.
      > Unfortunately I can't try it again here at home, for the
      > reason above,
      > Cheers
      > Roger
      >
      >
      >
    • Jun 14 2007 | 8:10 pm
      Scrub that: /everything/ I tried to download with Safari after that came out
      as the mystery XL file until I quit & reopened Safari! Bizarre...
      Now I have several copies of the patch and the timing sounds pretty sweet -
      which is strange as my machine here is the same spec as the other one I
      tried it on, and afaicr, the DSP settings are the same. Computers, eh?
      Cheers
      Roger
    • Jun 14 2007 | 8:14 pm
      > I tested your patch and recorded a few seconds of audio at a subdivision of 32. On a powerbook G4. In the middle of the recording I switch from the metro output to the phasor output. I don't hear a difference.
      >
      > http://www.arttech.nl/justin-recording.aif
      >
      > Maybe you could also post a recording so that we can compare..
      yeah will do it tomorrow.
      > btw: a tip: you might have named the number boxes of the bpm and subdivision. Sending a loadmess with a functional value is also a pro.. One could be less tempted to try your patch if one had to guess what those number boxes are for. ;)
      didnt have much time for the labelling / init process!
      but this is an interesting subject for me, as i have had numerous problems getting solid timing in the past... excuse my enthusiasm to dive straight in there!
      how did it go at 1/64?
      j
    • Jun 14 2007 | 8:37 pm
      I did 64 and 128 and now I see what you were talking about.
      The recording is here:
      What you hear is: 64 metro, 64 phasor, 128 phasor, 128 metro.
      Does that mean that with default dsp settings and performance options, event-based timing is 'useful' until you reach approximately 120 bpm with 64 subdivisions? Guess so..
      Mattijs
      Quote: justin wrote on Thu, 14 June 2007 22:14
      ----------------------------------------------------
      >
      > > I tested your patch and recorded a few seconds of audio at a subdivision of 32. On a powerbook G4. In the middle of the recording I switch from the metro output to the phasor output. I don't hear a difference.
      > >
      > > http://www.arttech.nl/justin-recording.aif
      > >
      > > Maybe you could also post a recording so that we can compare..
      >
      > yeah will do it tomorrow.
      >
      > > btw: a tip: you might have named the number boxes of the bpm and subdivision. Sending a loadmess with a functional value is also a pro.. One could be less tempted to try your patch if one had to guess what those number boxes are for. ;)
      >
      > didnt have much time for the labelling / init process!
      > but this is an interesting subject for me, as i have had numerous problems getting solid timing in the past... excuse my enthusiasm to dive straight in there!
      >
      > how did it go at 1/64?
      >
      > j
      ----------------------------------------------------
    • Jun 14 2007 | 8:40 pm
      Quote: roger.carruthers wrote on Thu, 14 June 2007 22:10
      ----------------------------------------------------
      > Scrub that: /everything/ I tried to download with Safari after that came out
      > as the mystery XL file until I quit & reopened Safari! Bizarre...
      > Now I have several copies of the patch and the timing sounds pretty sweet -
      ah, cool.
      > which is strange as my machine here is the same spec as the other one I
      > tried it on, and afaicr, the DSP settings are the same. Computers, eh?
      in fact it might be very interesting to find out what was going on..
      > Cheers
      > Roger
      >
      >
      >
      >
      >
      ----------------------------------------------------
    • Jun 14 2007 | 9:19 pm
      Allright, one last thing for tonight. A patch to compare seq~ with the sequencer I originally posted.
      I haven't tested it enough to really conclude anything, but perhaps on the setups where the strange flams occur this might make a difference.
      Best,
      Mattijs
    • Jun 15 2007 | 6:57 am
      >
      > As far as I can hear there is indeed some stereo/phasing-ish effect, but I can hear no flamming. So I'd say that there may be an error of 1 or 2 ms (in the range of phasing), but not around 30 ms (in the range of flamming).
      >
      Okay, so here's my run with my original 4-instance patcher from last night:
      Around a minute into it you'll hear the stereo image clearly break-up (well beyond simple phasing), and pronounced flamming occurs on some events. I'll try it a little later with a single processor, just to see what happens. After about 10 seconds of this, it goes back to normal. In fact, the changing of stereo width suggests that it gradually moves back into sync.
      I will also give your latest version a try, though this patch clearly demonstrates the difficulties I've had with the scheduler. It's a simple patch, and shouldn't need a re-write...
      I'm also *very* curious as to whether anyone else has experienced the flamming that is apparent in my output? If not, I'll obviously have to consider the possibility that this is somehow isolated to my system (though I'm not sure how). If anybody has a solid theory as to how this might be happening, and whether it could be isolated to an individual system, **please** let me know.
      J.
    • Jun 15 2007 | 7:25 am
      Okay, here's the output from a 4-instance patcher built on the seq~ version of basic-sequencer. As you can tell, it's not really better, though the timing errors seem smaller - more phasing, but fewer distinct flams. In fact, the other version seems to remain stable for a longer period, in exchange for more pronounced errors when it wanders off.
      I also tried disabling my second processor. This actually did improve matters, but it still wasn't anything like perfect. Actually, it seemed to shorten the time between errors. The errors also seemed less pronounced... But they were still there. I can post if anyone wants to hear it. So, I'd say dual processors exaggerate the problem, but aren't the sole cause.
      I can't emphasize enough that if anyone (at c74, in particular) thinks this problem indicates a system- or even hardware-related issue in my case, *please* let me know. This exact kind of issue has been driving me mad for years. If my G5 is just flaking out, I'll gladly take it out in the pasture and shoot it, if it means the end of these frustrations. IMHO, this shouldn't be happening with such a simple patch.
      J.
    • Jun 15 2007 | 7:49 am
      damn! I just realized I forgot to toggle over to the seq~ version on that last recording. grrrr...
      So, I'm playing from the seq~ version now, and it is actually much better. It phases occasionally, with no really clear pattern. But it doesn't obviously flam the way the other one does. Sorry for the false post.
      Nevertheless, there is clearly a problem with the original, non-seq~ version. And since most of my programming is event-based composition stuff, I'd be interested to know whether anyone at c74 has any thoughts on this. I'm still also interested to know whether anyone else has the flamming problem when running the vanilla Max object version. I would *love* to have a more stable scheduler in Max 5. Any chance?
      J.
    • Jun 15 2007 | 8:22 am
      Quote: jbm wrote on Fri, 15 June 2007 08:57
      ----------------------------------------------------
      > >
      > > As far as I can hear there is indeed some stereo/phasing-ish effect, but I can hear no flamming. So I'd say that there may be an error of 1 or 2 ms (in the range of phasing), but not around 30 ms (in the range of flamming).
      > >
      >
      > Okay, so here's my run with my original 4-instance patcher from last night:
      >
      > http://rubato-music.com/Media/mp3/flam.mp3
      >
      > Around a minute into it you'll hear the stereo image clearly break-up (well beyond simple phasing), and pronounced flamming occurs on some events. I'll try it a little later with a single processor, just to see what happens. After about 10 seconds of this, it goes back to normal. In fact, the changing of stereo width suggests that it gradually moves back into sync.
      I clearly hear the flamming in your recording. On both of the computers I tested this on (powerbook G4 and Mac Pro quad) this never happened.
      >
      > I will also give your latest version a try, though this patch clearly demonstrates the difficulties I've had with the scheduler. It's a simple patch, and shouldn't need a re-write...
      True. I can't explain why this occurs on your computer and not on mine.
      BUT theoretically it is possible to have flamming because you used 4 different metro's in this patch. I believe you should rewrite the patch a little so that all 4 sequencers are driven by the same metro. If flamming still occurs in that situation, something pretty weird is going on.
      > I'm also *very* curious as to whether anyone else has experienced the flamming that is apparent in my output? If not, I'll obviously have to consider the possibility that this is somehow isolated to my system (though I'm not sure how).
      > If anybody has a solid theory as to how this might be happening, and whether it could be isolated to an individual system, **please** let me know.
      I'm curious what your findings are with one metro instead of 4.
      Mattijs
    • Jun 15 2007 | 9:02 am
      >
      > BUT theoretically it is possible to have flamming because you used 4 different metro's in this patch. I believe you should rewrite the patch a little so that all 4 sequencers are driven by the same metro. If flamming still occurs in that situation, something pretty weird is going on.
      >
      >
      > I'm curious what your findings are with one metro instead of 4.
      >
      > Mattijs
      ----------------------------------------------------
      Right. That's a good point. I would certainly never use multiple metros in a real-world patch. I'll make the adjustments and get back to you. Mind you, there's no absolutely transparent, Documentation-supported reason why 4 metros should be a huge problem. Is there?
      Nevertheless, I understand it would be bad formy, so I'll trim it down to a single metro and try again.
      J.
    • Jun 15 2007 | 9:46 am
      Well, that did tighten it up a lot:
      Around 40 seconds to 1:00 you'll hear phasing and some slap-back delay types of "effects". So, it is a lot better, but...
      I'm curious, though, how the multiple-metro version compares to a patch which, for example, uses multiple delay or pipe objects? I mean, over the years I've learned to avoid both those objects like the plague, but it's always bothered my that this should be necessary. In some cases, after all, a basic event delay is exactly what's needed - not to fix some logical design flaw, but because you literally want a delay. As an example, a little over a year ago I was writing a patch that delayed all midi input by 1 second, in order to perform some musical analysis and insert variations into the playback. The variations handled short notes in a specific way, and I therefor needed duration information in the analysis - hence the 1 second delay. I eventually gave up the patch, because it just wouldn't run reliably. The last versions were okay, but not really usable in day-to-day work. I never found a logical reason. Perhaps the errors demonstrated over the past 24 hours point to some possible causes...(?)
      This begs the question: since even these minor phasing problems suggest that events are not arriving at their scheduled times, how are we to know precisely what these timing fluctuations will do to the performance of our patches? I mean, I realize I'm being highly speculative... But I don't think I'm too far off-base in being a little concerned. Am I?
      J.
    • Jun 15 2007 | 9:54 am
      Quote: jbm wrote on Fri, 15 June 2007 11:02
      ----------------------------------------------------
      >
      > >
      > > BUT theoretically it is possible to have flamming because you used 4 different metro's in this patch. I believe you should rewrite the patch a little so that all 4 sequencers are driven by the same metro. If flamming still occurs in that situation, something pretty weird is going on.
      > >
      > >
      > > I'm curious what your findings are with one metro instead of 4.
      > >
      > > Mattijs
      > ----------------------------------------------------
      >
      > Right. That's a good point. I would certainly never use multiple metros in a real-world patch. I'll make the adjustments and get back to you. Mind you, there's no absolutely transparent, Documentation-supported reason why 4 metros should be a huge problem. Is there?
      These issues are not documented at all for non-programmers (and in fact for programmers there is only this one article in the in-depth section of the website), so documentation-supported, no.
      But with my software engineering-backed understanding of the scheduler system -flamming- shouldn't occur, even though timing glitches could. As I see it (and please correct me if I'm wrong, anyone, cycling?) a metro adds the appropriate amount (hopefully only zero or one) of timed events to the scheduler, every time the metro's thread gets out of wait. The scheduler handles all events equally. So if the scheduler for some reason (a cpu spike somewhere else) fails to get attended for a long time, -all- events should be delayed, not only a few of them.
      Mattijs
      >
      > Nevertheless, I understand it would be bad formy, so I'll trim it down to a single metro and try again.
      >
      > J.
      ----------------------------------------------------
    • Jun 15 2007 | 11:42 am
      here are recordings from the comparison patch and from my (not v.well labelled ) patch (which compares metro with signal clock).
      these were done on a 2.16 MBP running maxmsp 4.63 + jitter 1.63.
      the dsp settings are: in built core audio sound card / i/o vector size=512 / signal vector size=512
      using the seq~ comparison patch, i modified the patch to have two sets of samplers run by Mattijs seq~ and the standard seq~. the left channel is Mattijs, and the right is seq~. the recording is almost 9mins long, and my observations are:
      - the standard seq~ seems to always miss the first bass drum hit, whereas mattijs seq~ doesnt.
      - i did get dropouts occasionally, altho i cant hear them in this recording. maybe because i merged the two in a stereo file...
      - the timing seems to be "ok", but over the 9mins you can hear the stereo image start to spread - and at the end i would say it's not far off short flams.
      this recording was done using my patch running at intervals of 1/32, 1/64, 1/128. i alternate between metro and signal clock for each timing division. on my machine, i can hear a slight difference at 1/32. and a big difference as the divisions increase.
      > Does that mean that with default dsp settings and performance options, event-based timing is 'useful' until you reach approximately 120 bpm with 64 subdivisions? Guess so..
      i think you are being a bit generous with "useful", i'd say it's closer to "useless". ;)
      what happens if you go over 120 bpm and still want 1/64? IMO, it should at least be steady at 1/64 up to 240bpm.
      anyway, i'd like to conclude with a vague recollection of reaktor which i understand has an event scheduler that runs up to 400 hz.
      whether or not this is actually true i dunno, havent tested it? currently the max event scheduler does seem a bit lame if it starts flaking out at 32hz...
      j
      also here is an updated and better labelled version of the patch:
      Quote: Mattijs wrote on Thu, 14 June 2007 21:37
      ----------------------------------------------------
      > I did 64 and 128 and now I see what you were talking about.
      >
      > The recording is here:
      >
      > http://www.arttech.nl/justin-recording-64-128.aif
      >
      > What you hear is: 64 metro, 64 phasor, 128 phasor, 128 metro.
      >
      > Does that mean that with default dsp settings and performance options, event-based timing is 'useful' until you reach approximately 120 bpm with 64 subdivisions? Guess so..
      >
      > Mattijs
    • Jun 15 2007 | 12:33 pm
      Quote: justin wrote on Fri, 15 June 2007 13:42
      ----------------------------------------------------
      > here are recordings from the comparison patch and from my (not v.well labelled ) patch (which compares metro with signal clock).
      > these were done on a 2.16 MBP running maxmsp 4.63 + jitter 1.63.
      > the dsp settings are: in built core audio sound card / i/o vector size=512 / signal vector size=512
      There is something I could have thought of earlier. Events can't be added to the dsp in-between the I/O vector.
      Try setting the I/O vector size to 32 (signal vector size will also change to 32). The 64th subdivision now sounds perfect for me.
      >
      > - the timing seems to be "ok", but over the 9mins you can hear the stereo image start to spread - and at the end i would say it's not far off short flams.
      This is an entirely new issue. Now I am very curious which one of the two is not timed right, my sequencer or seq~.. If you look at the way my sequencer is programmed you see that events are played according to cpu time. I'd say there is absolutely no way that this could result in an accumulative error. In that case something must be wrong with seq~ that results in a long term accumulative timing error (!!).
      Mattijs
    • Jun 15 2007 | 1:09 pm
      Quote: Mattijs wrote on Fri, 15 June 2007 13:33
      ----------------------------------------------------
      > Quote: justin wrote on Fri, 15 June 2007 13:42
      > ----------------------------------------------------
      > > here are recordings from the comparison patch and from my (not v.well labelled ) patch (which compares metro with signal clock).
      > > these were done on a 2.16 MBP running maxmsp 4.63 + jitter 1.63.
      > > the dsp settings are: in built core audio sound card / i/o vector size=512 / signal vector size=512
      >
      > There is something I could have thought of earlier. Events can't be added to the dsp in-between the I/O vector.
      >
      > Try setting the I/O vector size to 32 (signal vector size will also change to 32). The 64th subdivision now sounds perfect for me.
      i will try this in a bit.
      > > - the timing seems to be "ok", but over the 9mins you can hear the stereo image start to spread - and at the end i would say it's not far off short flams.
      >
      > This is an entirely new issue. Now I am very curious which one of the two is not timed right, my sequencer or seq~.. If you look at the way my sequencer is programmed you see that events are played according to cpu time. I'd say there is absolutely no way that this could result in an accumulative error. In that case something must be wrong with seq~ that results in a long term accumulative timing error (!!).
      >
      > Mattijs
      ----------------------------------------------------
      yes, i thought this wasnt necessarily going to be a fair test, because of the "different" approach - even if they are similar in their programming techniques.
      btw, is there any way to get the bpm to change smoothly in your patch? as they are with phasor~ and seq~
      j
    • Jun 15 2007 | 1:27 pm
      Quote: justin wrote on Fri, 15 June 2007 15:09
      ----------------------------------------------------
      > > This is an entirely new issue. Now I am very curious which one of the two is not timed right, my sequencer or seq~.. If you look at the way my sequencer is programmed you see that events are played according to cpu time. I'd say there is absolutely no way that this could result in an accumulative error. In that case something must be wrong with seq~ that results in a long term accumulative timing error (!!).
      > >
      > > Mattijs
      > ----------------------------------------------------
      >
      > yes, i thought this wasnt necessarily going to be a fair test, because of the "different" approach - even if they are similar in their programming techniques.
      Well, fair or not, there is obviously an accumulative error in one of the both approaches. So one of them is wrong. And I dearly hope it is mine, otherwise we've been wrong with seq~ all this time. But I can't see how there could possibly be an accumulative error in my example, seeing that it is strictly related to cputime.
      >
      > btw, is there any way to get the bpm to change smoothly in your patch? as they are with phasor~ and seq~
      Yeah, for simplicity I left that out. I'll look into it.
      Mattijs
    • Jun 15 2007 | 2:37 pm
      Quote: Mattijs wrote on Fri, 15 June 2007 15:27
      ----------------------------------------------------
      > > btw, is there any way to get the bpm to change smoothly in your patch? as they are with phasor~ and seq~
      >
      > Yeah, for simplicity I left that out. I'll look into it.
      >
      Here it is:
      But as I said, the addition doesn't make the patch easier to understand. ;) Although after you have the first one figured out this one should be do-able.
      Cheers,
      Mattijs
    • Jun 15 2007 | 4:57 pm
      ok, with an io vector size at 32 the metro timing is a lot better. at 120bpm it's steady at 1/64, and better at 1/128 although you can here a slight pitch difference between both methods.
      as i said before i would expect the timing to be steady up to 1/64 @ 240bpm - so almost there! i am assuming this would be a good specification to work to as it would cover most ppl sequencing needs.
      on a slightly different but related topic, if i were to run an event scheduler with the dsp vector size at 32 - i assume that any dsp further down the line would need to run at the same setting. my main concern being the added cpu load of a smaller vector size... perhaps there is some optimisation that could be achieved with poly~'s ability to load dsp chains at different vector sizes.
      BTW, nice improvement with the smooth bpm in v2. i was also considering to make a better gui to input the sequences, but i think i would need to have a velocity value to make it more useful... will have a look at it and see if i can come up with something.
      cheers,
      j
      Quote: Mattijs wrote on Fri, 15 June 2007 13:33
      ----------------------------------------------------
      > There is something I could have thought of earlier. Events can't be added to the dsp in-between the I/O vector.
      >
      > Try setting the I/O vector size to 32 (signal vector size will also change to 32). The 64th subdivision now sounds perfect for me.
    • Jun 15 2007 | 5:40 pm
      Quote: justin wrote on Fri, 15 June 2007 18:57
      ----------------------------------------------------
      > ok, with an io vector size at 32 the metro timing is a lot better. at 120bpm it's steady at 1/64, and better at 1/128 although you can here a slight pitch difference between both methods.
      >
      > as i said before i would expect the timing to be steady up to 1/64 @ 240bpm - so almost there! i am assuming this would be a good specification to work to as it would cover most ppl sequencing needs.
      Good news. So here we are, we figured this one out (others still remain), but no one else knows. It would really be a good idea to make an article 'Timing for dummies' which discusses all the different situations / potential problems and how to deal with them.
      >
      > on a slightly different but related topic, if i were to run an event scheduler with the dsp vector size at 32 - i assume that any dsp further down the line would need to run at the same setting. my main concern being the added cpu load of a smaller vector size... perhaps there is some optimisation that could be achieved with poly~'s ability to load dsp chains at different vector sizes.
      >
      > BTW, nice improvement with the smooth bpm in v2. i was also considering to make a better gui to input the sequences, but i think i would need to have a velocity value to make it more useful... will have a look at it and see if i can come up with something.
      Thanks. I'm curious about which kind of UI you would come up with. Btw you can add any list as an event. It will output the list without the float so feel free to add '0.25 bd 0.6' and it will output 'bd 0.6' at 1/4 of the bar.
      But, once again, all this functionality is also supported by seq~. Although there remains this puzzling issue with an accumulating time error that gets noticable after about 5 minutes. Thinking a bit more about this, it would mean that phasor~ is not 100% time-accurate. Could it be a rounding error of some sorts?
      Mattijs
    • Jun 15 2007 | 6:20 pm
      Quote: Mattijs wrote on Fri, 15 June 2007 18:40
      ----------------------------------------------------
      > Good news. So here we are, we figured this one out (others still remain), but no one else knows. It would really be a good idea to make an article 'Timing for dummies' which discusses all the different situations / potential problems and how to deal with them.
      agreed - an article on timing issues would be very beneficial.
      > I'm curious about which kind of UI you would come up with. Btw you can add any list as an event. It will output the list without the float so feel free to add '0.25 bd 0.6' and it will output 'bd 0.6' at 1/4 of the bar.
      i'll probably just start with a multislider and take it from there. will also require some modification to the samplers. thanks for info about the list events.
      > But, once again, all this functionality is also supported by seq~. Although there remains this puzzling issue with an accumulating time error that gets noticable after about 5 minutes. Thinking a bit more about this, it would mean that phasor~ is not 100% time-accurate. Could it be a rounding error of some sorts?
      >
      > Mattijs
      ----------------------------------------------------
      not sure what to say about the accumulative time error. i wonder if jmb's test with 4 instances of your sequencer patch demonstrates the same problem - i'm guessing no. in which case, you should stick to using one or the other but not a combination of both. although it would be good to know where the problem stems from...
    • Jun 15 2007 | 6:34 pm
      >
      > not sure what to say about the accumulative time error. i wonder if jmb's test with 4 instances of your sequencer patch demonstrates the same problem - i'm guessing no. in which case, you should stick to using one or the other but not a combination of both. although it would be good to know where the problem stems from...
      ----------------------------------------------------
      No kidding. I'd say, for myself, knowing where the problem stems from is far more important than devising new and convoluted workarounds. It's all well and fine to have specific solutions for sequencer-like patches, but what appears to be a general flakiness in timing is a genuine problem. It shouldn't be necessary to re-invent the wheel for each new timing-critical patch we write...
      J.
    • Aug 06 2007 | 11:31 am
      I've been trying to make a UI for this Mattij's sequencer patch, but i've run into a few problems...
      the most annoying at the moment is a double entry (in coll) of the last step in the sequence, despite the fact that the max window only shows one message being sent.
      other than that, i'm still working on a way to send multiple multislider sequences to the same coll object, currently it only controls the bassdrum sampler.
      any help / comments appreciated.
      j
    • Aug 06 2007 | 1:42 pm
      Hi justin,
      I added some stuff that I think solves the problems you describe:
      Quote: justin wrote on Mon, 06 August 2007 13:31
      ----------------------------------------------------
      > I've been trying to make a UI for this Mattij's sequencer patch, but i've run into a few problems...
      >
      > the most annoying at the moment is a double entry (in coll) of the last step in the sequence, despite the fact that the max window only shows one message being sent.
      >
      > other than that, i'm still working on a way to send multiple multislider sequences to the same coll object, currently it only controls the bassdrum sampler.
      >
      > any help / comments appreciated.
      >
      > j
      >
      >
    • Aug 06 2007 | 4:29 pm
      nice one :)
      that solves all the problems i outlined in my previous post, and looks somewhat neater and leaner than my attempt!
      next i want to incorporate another feature for trapping a section of the sequence within a certain ramp range (eg. play only 0.5 to 0.75) as a potential tool to build drum breaks live... will see where it takes me!
      another (not too important) observation i made was when i'm changing the sequence in the multislider UI, the patch seems to behave better when overdrive is on. otherwise i get the odd spurious drum hit...
      thanks,
      j