Forums > MaxMSP

[sharing is fun] basic sequencer

June 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



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


June 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



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


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


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



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



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


June 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



jbm
June 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

#N comlet loadbang;
#P inlet 221 35 15 0;
#P outlet 49 376 15 0;
#P inlet 156 27 15 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 2;
#P comment 297 129 116 196617 Just enable DSP and press Play.;
#P window linecount 1;
#P comment 224 67 96 196617 Add these events;
#P newex 30 273 87 196617 samplePlayer $1;
#P button 30 132 15 0;
#P comment 47 132 74 196617 Clear sequence;
#N vpatcher 40 104 501 568;
#P window setfont "Sans Serif" 9.;
#P newex 239 69 40 196617 t clear;
#P newex 86 216 21 196617 t 0;
#P newex 86 197 40 196617 change;
#P newex 86 178 27 196617 / 1.;
#P newex 134 216 31 196617 % 1.;
#P newex 88 371 36 196617 zl reg;
#P newex 50 370 27 196617 i;
#P newex 50 216 27 196617 t i i;
#P newex 50 390 27 196617 + 1;
#P newex 134 197 35 196617 * 0.5;
#P newex 134 178 46 196617 / 1000.;
#P newex 134 159 27 196617 – 0.;
#P newex 50 197 27 196617 i;
#P newex 50 349 41 196617 sel 1 0;
#P newex 50 329 27 196617 &&;
#P newex 50 110 30 196617 t b b;
#P newex 50 269 44 196617 zl nth 1;
#P newex 50 289 29 196617 t f f;
#P newex 84 309 27 196617 < 0.;
#P newex 50 69 40 196617 t i i 0;
#P newex 189 140 48 196617 cpuclock;
#P newex 189 120 32 196617 sel 1;
#P newex 50 90 49 196617 metro 2.;
#P newex 50 309 33 196617 >= 0.;
#N coll events 1;
#P newobj 50 249 68 196617 coll events 1;
#P newex 134 140 48 196617 cpuclock;
#P newex 170 69 40 196617 / 240.;
#N comlet (bool) play;
#P inlet 50 49 15 0;
#N comlet (bang) clear;
#P inlet 239 49 15 0;
#N comlet (float , bars) loop length;
#P inlet 103 49 15 0;
#N comlet (list) event to add;
#P inlet 300 49 15 0;
#N comlet (int , bpm) tempo;
#P inlet 170 49 15 0;
#P outlet 88 393 15 0;
#P message 300 131 53 196617 renumber;
#P message 315 111 52 196617 sort -1 0;
#P newex 330 90 84 196617 prepend insert 1;
#P newex 300 69 40 196617 t b b l;
#P connect 9 0 17 0;
#P connect 17 0 14 0;
#P connect 14 0 21 0;
#P fasten 28 0 24 0 55 410 38 410 38 193 55 193;
#P connect 21 0 24 0;
#P connect 24 0 29 0;
#P fasten 36 0 12 0 244 246 55 246;
#P connect 29 0 12 0;
#P fasten 1 0 12 0 335 246 55 246;
#P fasten 2 0 12 0 320 246 55 246;
#P fasten 3 0 12 0 305 246 55 246;
#P connect 12 0 20 0;
#P connect 20 0 19 0;
#P connect 19 0 13 0;
#P connect 13 0 22 0;
#P connect 22 0 23 0;
#P connect 23 0 30 0;
#P connect 30 0 28 0;
#P connect 17 2 24 1;
#P connect 35 0 24 1;
#P connect 18 0 22 1;
#P connect 29 1 30 1;
#P connect 19 1 18 0;
#P connect 27 0 33 0;
#P connect 33 0 34 0;
#P connect 34 0 35 0;
#P connect 23 0 31 0;
#P connect 31 0 4 0;
#P connect 32 0 18 1;
#P connect 7 0 33 1;
#P connect 20 1 31 1;
#P connect 21 1 11 0;
#P connect 11 0 25 0;
#P connect 25 0 26 0;
#P connect 26 0 27 0;
#P connect 27 0 32 0;
#P connect 16 0 25 1;
#P connect 7 0 32 1;
#P connect 10 0 27 1;
#P connect 5 0 10 0;
#P connect 17 1 15 0;
#P connect 15 0 16 0;
#P connect 8 0 36 0;
#P connect 6 0 0 0;
#P connect 0 0 3 0;
#P connect 0 1 2 0;
#P connect 0 2 1 0;
#P pop;
#P newobj 30 160 66 196617 p sequencer;
#B color 5;
#P hidden newex 135 108 60 196617 loadmess 1;
#P flonum 30 108 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 67 108 64 196617 Bars to loop;
#P message 207 185 56 196617 0.5625 sd;
#P button 98 227 15 0;
#P button 64 227 15 0;
#P button 30 227 15 0;
#P button 207 67 15 0;
#P hidden newex 100 84 72 196617 loadmess 136;
#P hidden newex 183 350 18 196617 t l;
#P message 207 203 44 196617 0.75 sd;
#P message 207 167 44 196617 0.25 sd;
#P message 207 352 50 196617 0.875 hh;
#P message 207 334 44 196617 0.75 hh;
#P message 207 316 50 196617 0.625 hh;
#P message 207 298 38 196617 0.5 hh;
#P message 207 280 50 196617 0.375 hh;
#P message 207 262 44 196617 0.25 hh;
#P message 207 244 50 196617 0.125 hh;
#P message 207 226 32 196617 0. hh;
#P message 207 142 44 196617 0.75 bd;
#P message 207 124 38 196617 0.5 bd;
#P message 207 106 44 196617 0.25 bd;
#P message 207 88 32 196617 0. bd;
#P newex 30 206 112 196617 route bd sd hh;
#P toggle 30 59 15 0;
#P comment 46 59 29 196617 Play;
#P number 30 84 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 67 84 28 196617 Bpm;
#P window linecount 5;
#P comment 297 174 116 196617 Note: The events to the left are loaded with a loadbang. Make sure you don’t add multiple copies of these events.;
#P hidden connect 22 0 17 0;
#P hidden connect 22 0 16 0;
#P hidden connect 22 0 15 0;
#P hidden connect 22 0 14 0;
#P hidden connect 22 0 13 0;
#P hidden connect 22 0 12 0;
#P hidden connect 22 0 11 0;
#P hidden connect 22 0 10 0;
#P hidden connect 22 0 19 0;
#P hidden connect 22 0 26 0;
#P hidden connect 22 0 18 0;
#P hidden connect 22 0 9 0;
#P hidden connect 22 0 8 0;
#P hidden connect 22 0 7 0;
#P hidden connect 22 0 6 0;
#P connect 38 0 22 0;
#P hidden connect 26 0 20 0;
#P hidden connect 7 0 20 0;
#P hidden connect 8 0 20 0;
#P hidden connect 9 0 20 0;
#P hidden connect 18 0 20 0;
#P hidden connect 19 0 20 0;
#P hidden connect 10 0 20 0;
#P hidden connect 11 0 20 0;
#P hidden connect 12 0 20 0;
#P hidden connect 13 0 20 0;
#P hidden connect 14 0 20 0;
#P hidden connect 15 0 20 0;
#P hidden connect 16 0 20 0;
#P hidden connect 17 0 20 0;
#P hidden connect 6 0 20 0;
#P connect 25 0 33 2;
#P connect 5 2 25 0;
#P hidden connect 20 0 30 4;
#P hidden connect 32 0 30 3;
#P connect 24 0 33 1;
#P connect 5 1 24 0;
#P hidden fasten 2 0 30 2 35 154 63 154;
#P connect 33 0 37 0;
#P hidden fasten 28 0 30 1 35 154 49 154;
#P connect 23 0 33 0;
#P connect 5 0 23 0;
#P connect 30 0 5 0;
#P hidden connect 4 0 30 0;
#P hidden connect 29 0 28 0;
#P hidden connect 21 0 2 0;
#P connect 36 0 4 0;
#P window clipboard copycount 39;

sampler

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 199 130 145 196617 loadmess replace 808hh01.aif;
#P newex 21 130 32 196617 t 0 1;
#P newex 73 130 29 196617 sig~;
#P newex 73 149 91 196617 groove~ $1_hihat;
#P newex 21 90 32 196617 t 0 1;
#P newex 73 90 29 196617 sig~;
#P newex 73 109 117 196617 groove~ $1_snaredrum;
#P newex 21 50 32 196617 t 0 1;
#P newex 73 50 29 196617 sig~;
#P newex 73 69 112 196617 groove~ $1_bassdrum;
#P newex 199 90 145 196617 loadmess replace 808sd01.aif;
#P newex 199 50 145 196617 loadmess replace 808bd01.aif;
#P newex 199 69 109 196617 buffer~ $1_bassdrum;
#P newex 199 109 114 196617 buffer~ $1_snaredrum;
#P newex 199 149 88 196617 buffer~ $1_hihat;
#P inlet 21 30 15 0;
#P inlet 38 30 15 0;
#P inlet 55 30 15 0;
#P outlet 73 174 15 0;
#P connect 18 0 4 0;
#P connect 8 0 5 0;
#P connect 7 0 6 0;
#P connect 15 0 0 0;
#P connect 12 0 0 0;
#P connect 9 0 0 0;
#P connect 17 0 15 0;
#P connect 16 0 15 0;
#P connect 17 1 16 0;
#P connect 14 0 12 0;
#P connect 13 0 12 0;
#P connect 14 1 13 0;
#P connect 11 0 9 0;
#P connect 10 0 9 0;
#P connect 11 1 10 0;
#P connect 1 0 17 0;
#P connect 2 0 14 0;
#P connect 3 0 11 0;
#P window clipboard copycount 19;

test patcher

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 523 71 48 196617 loadbang;
#P user ezdac~ 119 225 163 258 0;
#P message 360 208 30 196617 open;
#P newex 208 238 64 196617 sfrecord~ 2;
#P newex 402 100 92 196617 basic-sequencer 4;
#P newex 304 100 92 196617 basic-sequencer 3;
#P newex 208 100 92 196617 basic-sequencer 2;
#P toggle 495 38 15 0;
#P newex 94 100 92 196617 basic-sequencer 1;
#P fasten 8 0 0 1 528 94 181 94;
#P fasten 8 0 2 1 528 94 295 94;
#P fasten 8 0 3 1 528 94 391 94;
#P fasten 8 0 4 1 528 94 489 94;
#P fasten 1 0 0 0 500 77 99 77;
#P fasten 1 0 2 0 500 77 213 77;
#P fasten 1 0 5 0 500 146 213 146;
#P fasten 1 0 3 0 500 77 309 77;
#P fasten 1 0 4 0 500 77 407 77;
#P connect 4 0 5 1;
#P connect 3 0 7 1;
#P connect 3 0 5 1;
#P connect 2 0 5 0;
#P connect 0 0 7 0;
#P connect 0 0 5 0;
#P fasten 6 0 5 0 365 230 213 230;
#P connect 4 0 7 1;
#P connect 2 0 7 0;
#P window clipboard copycount 9;



jbm
June 14, 2007 | 4:07 pm

oh, and btw, it’s kind of a cool effect when they do start to wander! ;-)


June 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


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


June 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! ;-)
>
—————————————————-



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


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

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


June 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

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 465 177 100 196617 reset phase / speed;
#P newex 368 345 33 196617 < ~ 0.;
#P user scope~ 369 382 499 512 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135 135 135 0;
#P newex 368 326 38 196617 delta~;
#P comment 147 52 100 196617 start / stop;
#P window linecount 2;
#P comment 13 364 100 196617 compare metro / phasor;
#P window linecount 1;
#P newex 404 201 30 196617 t b b;
#P newex 533 233 27 196617 0;
#P user scope~ 237 382 367 512 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135 135 135 0;
#P newex 115 385 27 196617 + 1;
#P toggle 115 364 15 0;
#P newex 115 407 71 196617 selector~ 2 1;
#P newex 404 272 27 196617 0.;
#P newex 404 177 60 196617 sel 1;
#N vpatcher 494 44 841 398;
#P outlet 42 182 15 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 107 109 29 196617 t b f;
#P inlet 107 85 15 0;
#P newex 42 151 29 196617 * 4.;
#P window linecount 0;
#P newex 42 96 40 196617 / 240.;
#P inlet 42 53 15 0;
#P connect 0 0 1 0;
#P connect 4 0 2 0;
#P connect 1 0 2 0;
#P connect 2 0 5 0;
#P connect 4 1 2 1;
#P connect 3 0 4 0;
#P pop;
#P newobj 368 135 55 196617 p bpmtohz;
#P flonum 368 234 62 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 432 234 100 196617 interval in hz;
#P newex 368 303 46 196617 phasor~;
#P comment 280 91 292 196617 from 1/32 timing has a strange shuffle like effect with metro.;
#P flonum 208 234 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P user ezdac~ 115 475 159 508 0;
#P newex 145 300 37 196617 click~;
#P number 244 91 35 9 4 0 1 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 196 91 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 145 93 15 0;
#N vpatcher 20 74 620 474;
#P window setfont "Sans Serif" 9.;
#P newex 44 128 31 196617 120.;
#P comment 65 190 55 196617 ms – float;
#P comment 209 69 42 196617 divider;
#N comlet ms interval – float;
#P outlet 44 190 20 0;
#N comlet divider – float;
#P inlet 191 69 17 0;
#N comlet bpm – float;
#P inlet 44 69 17 0;
#P newex 191 91 29 196617 t b f;
#P newex 44 149 176 196617 expr ((60000./$f1) *4.) * (1./$f2);
#P comment 62 70 26 196617 bpm;
#P connect 3 0 8 0;
#P fasten 2 0 8 0 196 118 49 118;
#P connect 8 0 1 0;
#P connect 1 0 5 0;
#P connect 4 0 2 0;
#P connect 2 1 1 1;
#P pop;
#P newobj 196 135 58 196617 p bpmtoms;
#P newex 145 177 61 196617 metro 125.;
#P comment 245 234 100 196617 interval in ms;
#P connect 17 0 18 0;
#P connect 18 0 16 0;
#P connect 16 0 7 0;
#P connect 3 0 1 0;
#P connect 1 0 6 0;
#P connect 6 0 16 1;
#P connect 16 0 7 1;
#P fasten 26 0 16 2 373 372 180 372;
#P connect 4 0 2 0;
#P connect 2 0 1 1;
#P fasten 2 0 8 0 201 163 213 163;
#P fasten 6 0 19 0 150 348 242 348;
#P connect 5 0 2 1;
#P fasten 4 0 13 0 201 120 373 120;
#P fasten 21 0 12 0 409 226 373 226;
#P connect 13 0 12 0;
#P connect 12 0 10 0;
#P fasten 20 0 10 0 538 299 373 299;
#P fasten 10 0 24 0 373 321 373 321;
#P connect 24 0 26 0;
#P connect 26 0 25 0;
#P hidden fasten 3 0 14 0 150 158 409 158;
#P connect 14 0 21 0;
#P fasten 21 1 15 0 429 266 409 266;
#P connect 15 0 10 1;
#P fasten 5 0 13 1 249 120 418 120;
#P fasten 14 1 20 0 459 213 538 213;
#P window clipboard copycount 28;



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


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

http://www.arttech.nl/justin-recording.aif

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


June 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


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


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


June 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


June 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


June 14, 2007 | 8:37 pm

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

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


June 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
>
>
>
>
>
—————————————————-


June 14, 2007 | 9:19 pm

Allright, one last thing for tonight. A patch to compare seq~ with the sequencer I originally posted.

http://www.arttech.nl/basic-sequencer-seq~-compare.zip

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



jbm
June 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:

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



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

http://www.rubato-music.com/Media/mp3/flam2-seq~.mp3

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.



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


June 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



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



jbm
June 15, 2007 | 9:46 am

Well, that did tighten it up a lot:

http://www.rubato-music.com/Media/mp3/flams2.mp3

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.


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


June 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

1. http://www.weirdcore.tv/j3zA/timingtest.mp3

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.

2. http://www.weirdcore.tv/j3zA/timingtest2.mp3

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:

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 244 68 28 196617 div;
#P newex 387 171 29 196617 t b f;
#P flonum 424 247 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 368 215 48 196617 * 1.;
#P toggle 267 532 15 0;
#P message 238 532 30 196617 open;
#P user number~ 193 603 248 618 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 193 583 55 196617 sfrecord~;
#P comment 196 68 28 196617 bpm;
#P newex 314 57 76 196617 unpack 120 16;
#P newex 314 38 48 196617 loadbang;
#P comment 594 268 100 196617 reset phase;
#P newex 368 345 33 196617 < ~ 0.;
#P user scope~ 369 382 499 512 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135 135 135 0;
#P newex 368 326 38 196617 delta~;
#P comment 44 93 100 196617 start / stop >>;
#P window linecount 2;
#P comment 13 364 100 196617 compare metro / phasor;
#P user scope~ 237 382 367 512 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135 135 135 0;
#P window linecount 1;
#P newex 115 385 27 196617 + 1;
#P toggle 115 364 15 0;
#P newex 115 407 71 196617 selector~ 2 1;
#P newex 565 268 27 196617 0.;
#P newex 565 211 60 196617 sel 1;
#N vpatcher 494 44 841 398;
#P outlet 42 182 15 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 107 109 29 196617 t b f;
#P inlet 107 85 15 0;
#P newex 42 151 29 196617 * 4.;
#P window linecount 0;
#P newex 42 96 40 196617 / 240.;
#P inlet 42 53 15 0;
#P connect 0 0 1 0;
#P connect 1 0 2 0;
#P connect 4 0 2 0;
#P connect 2 0 5 0;
#P connect 4 1 2 1;
#P connect 3 0 4 0;
#P pop;
#P newobj 387 135 55 196617 p bpmtohz;
#P comment 461 247 100 196617 interval in hz;
#P newex 368 303 46 196617 phasor~;
#P comment 280 91 292 196617 from 1/32 timing has a strange shuffle like effect with metro.;
#P flonum 208 247 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P user ezdac~ 115 475 159 508 0;
#P newex 145 300 37 196617 click~;
#P number 244 91 35 9 4 0 1 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 196 91 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 145 93 15 0;
#N vpatcher 20 74 620 474;
#P window setfont "Sans Serif" 9.;
#P newex 44 128 31 196617 120.;
#P comment 65 190 55 196617 ms – float;
#P comment 209 69 42 196617 divider;
#N comlet ms interval – float;
#P outlet 44 190 20 0;
#N comlet divider – float;
#P inlet 191 69 17 0;
#N comlet bpm – float;
#P inlet 44 69 17 0;
#P newex 191 91 29 196617 t b f;
#P newex 44 149 176 196617 expr ((60000./$f1) *4.) * (1./$f2);
#P comment 62 70 26 196617 bpm;
#P fasten 2 0 8 0 196 118 49 118;
#P connect 3 0 8 0;
#P connect 8 0 1 0;
#P connect 1 0 5 0;
#P connect 4 0 2 0;
#P connect 2 1 1 1;
#P pop;
#P newobj 196 135 58 196617 p bpmtoms;
#P newex 145 177 61 196617 metro 125.;
#P comment 245 247 100 196617 interval in ms;
#P connect 16 0 17 0;
#P connect 17 0 15 0;
#P connect 15 0 7 0;
#P connect 3 0 1 0;
#P connect 1 0 6 0;
#P connect 6 0 15 1;
#P fasten 15 0 7 1 120 449 154 449;
#P fasten 23 0 15 2 373 372 180 372;
#P fasten 15 0 28 0 120 438 198 438;
#P fasten 31 0 28 0 272 569 198 569;
#P fasten 30 0 28 0 243 569 198 569;
#P connect 28 0 29 0;
#P fasten 26 0 4 0 319 82 201 82;
#P connect 4 0 2 0;
#P connect 2 0 1 1;
#P fasten 2 0 8 0 201 163 213 163;
#P fasten 6 0 18 0 150 348 242 348;
#P fasten 26 1 5 0 385 82 249 82;
#P connect 5 0 2 1;
#P connect 25 0 26 0;
#P fasten 3 0 32 0 150 161 373 161;
#P connect 34 0 32 0;
#P connect 32 0 10 0;
#P fasten 10 0 21 0 373 321 373 321;
#P connect 21 0 23 0;
#P connect 23 0 22 0;
#P fasten 4 0 12 0 201 120 392 120;
#P connect 12 0 34 0;
#P fasten 14 0 10 1 570 294 409 294;
#P connect 34 1 32 1;
#P fasten 12 0 33 0 392 168 429 168;
#P fasten 5 0 12 1 249 120 437 120;
#P fasten 3 0 13 0 150 161 570 161;
#P connect 13 0 14 0;
#P window clipboard copycount 36;

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


June 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


June 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


June 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


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

http://www.arttech.nl/basic-sequencer-v2.zip

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


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


June 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


June 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…



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


August 6, 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

#P window setfont "Sans Serif" 9.;
#P window linecount 2;
#P comment 528 356 194 196617 bug: if a velocity value is inserted on the last step , it gets 2 entries in coll???;
#P window linecount 1;
#P comment 285 217 331 196617 1. insert some velocity values below , you dont need to press clear;
#P button 196 77 15 0;
#N vpatcher 10 59 610 459;
#P inlet 64 24 15 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 5;
#P comment 162 189 116 196617 Note: The events to the left are loaded with a loadbang. Make sure you don’t add multiple copies of these events.;
#P outlet 40 359 15 0;
#P window linecount 1;
#P comment 81 45 96 196617 Add these events;
#P message 64 163 56 196617 0.5625 sd;
#P button 64 45 15 0;
#P hidden newex 40 328 18 196617 t l;
#P message 64 181 44 196617 0.75 sd;
#P message 64 145 44 196617 0.25 sd;
#P message 64 330 50 196617 0.875 hh;
#P message 64 312 44 196617 0.75 hh;
#P message 64 294 50 196617 0.625 hh;
#P message 64 276 38 196617 0.5 hh;
#P message 64 258 50 196617 0.375 hh;
#P message 64 240 44 196617 0.25 hh;
#P message 64 222 50 196617 0.125 hh;
#P message 64 204 32 196617 0. hh;
#P message 64 120 44 196617 0.75 bd;
#P message 64 102 38 196617 0.5 bd;
#P message 64 84 44 196617 0.25 bd;
#P message 64 66 32 196617 0. bd;
#P hidden connect 0 0 14 0;
#P hidden connect 11 0 14 0;
#P hidden connect 10 0 14 0;
#P hidden connect 9 0 14 0;
#P hidden connect 8 0 14 0;
#P hidden connect 7 0 14 0;
#P hidden connect 6 0 14 0;
#P hidden connect 5 0 14 0;
#P hidden connect 4 0 14 0;
#P hidden connect 13 0 14 0;
#P hidden connect 12 0 14 0;
#P hidden connect 3 0 14 0;
#P hidden connect 2 0 14 0;
#P hidden connect 1 0 14 0;
#P hidden connect 16 0 14 0;
#P connect 14 0 18 0;
#P connect 20 0 15 0;
#P hidden connect 15 0 0 0;
#P hidden connect 15 0 1 0;
#P hidden connect 15 0 2 0;
#P hidden connect 15 0 3 0;
#P hidden connect 15 0 12 0;
#P hidden connect 15 0 16 0;
#P hidden connect 15 0 13 0;
#P hidden connect 15 0 4 0;
#P hidden connect 15 0 5 0;
#P hidden connect 15 0 6 0;
#P hidden connect 15 0 7 0;
#P hidden connect 15 0 8 0;
#P hidden connect 15 0 9 0;
#P hidden connect 15 0 10 0;
#P hidden connect 15 0 11 0;
#P pop;
#P newobj 196 108 57 196617 p test_seq;
#P newex 254 108 49 196617 r seq_bd;
#N vpatcher 850 94 1346 642;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 46 166 34 196617 defer;
#P comment 175 75 56 196617 send clear;
#P newex 154 331 27 196617 t b i;
#P newex 132 308 32 196617 sel 0;
#P newex 63 308 62 196617 prepend set;
#N comlet seq size;
#P inlet 353 57 15 0;
#P newex 353 115 37 196617 int 16;
#P newex 63 254 27 196617 – 1;
#P newex 63 406 49 196617 s seq_bd;
#P newex 16 91 243 196617 t b l clear;
#P newex 46 187 27 196617 t b i;
#P newex 63 289 45 196617 / 16.;
#P newex 63 375 118 196617 pack 0. bd 127;
#P newex 16 146 40 196617 uzi 16;
#P newex 132 254 35 196617 zl nth;
#P window linecount 0;
#P newex 16 63 62 196617 mousefilter;
#N comlet seq list;
#P inlet 16 33 15 0;
#P comment 280 326 100 196617 remove 0 velocity from sequence;
#P connect 1 0 2 0;
#P connect 2 0 8 0;
#P connect 8 0 4 0;
#P fasten 11 0 4 1 358 139 51 139;
#P connect 4 2 17 0;
#P connect 17 0 7 0;
#P connect 7 1 10 0;
#P connect 10 0 6 0;
#P connect 6 0 13 0;
#P connect 15 0 5 0;
#P connect 13 0 5 0;
#P connect 5 0 9 0;
#P fasten 8 2 9 0 253 401 68 401;
#P fasten 11 0 6 1 358 280 103 280;
#P connect 7 0 3 0;
#P connect 8 1 3 0;
#P connect 3 0 14 0;
#P connect 14 1 15 0;
#P connect 7 1 3 1;
#P connect 15 1 5 2;
#P connect 12 0 11 0;
#P pop;
#P newobj 285 345 88 196617 p multislid_parse;
#N vpatcher 10 59 280 364;
#N comlet position UI;
#P outlet 22 89 15 0;
#N comlet seq UI;
#P outlet 106 89 15 0;
#P window setfont "Sans Serif" 9.;
#P message 22 64 83 196617 setminmax 0 $1;
#P message 106 64 43 196617 size $1;
#P inlet 22 37 15 0;
#P connect 0 0 2 0;
#P connect 2 0 4 0;
#P fasten 0 0 1 0 27 58 111 58;
#P connect 1 0 3 0;
#P pop;
#P hidden newobj 285 236 36 196617 p size;
#P user multiSlider 285 256 256 10 0. 16. 1 2664 15 0 0 2 0 0 0;
#M frgb 0 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P noclick;
#P user umenu 542 256 25 196647 1 64 272 1;
#X setrgb 0 0 0 255 255 255 255 255 255 221 221 221 170 170 170 119 119 119 187 187 187;
#X add 16;
#X add 32;
#P user multiSlider 285 267 256 64 0. 127. 16 2921 15 0 0 2 4 0 0;
#M frgb 150 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 0 0 0;
#M rgb5 75 0 0;
#M rgb6 0 0 0;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P comment 31 343 143 196617 2. enable DSP and press Play.;
#P newex 237 32 48 196617 loadbang;
#N vpatcher 40 104 429 340;
#P window setfont "Sans Serif" 9.;
#P newex 173 130 145 196617 loadmess replace 808hh01.aif;
#P window linecount 1;
#P newex 21 130 32 196617 t 0 1;
#P newex 73 130 29 196617 sig~;
#P window linecount 0;
#P newex 73 149 72 196617 groove~ hihat;
#P window linecount 1;
#P newex 21 90 32 196617 t 0 1;
#P newex 73 90 29 196617 sig~;
#P window linecount 0;
#P newex 73 109 98 196617 groove~ snaredrum;
#P newex 21 50 32 196617 t 0 1;
#P newex 73 50 29 196617 sig~;
#P newex 73 69 93 196617 groove~ bassdrum;
#P newex 173 90 145 196617 loadmess replace 808sd01.aif;
#P newex 173 50 145 196617 loadmess replace 808bd01.aif;
#P newex 173 69 90 196617 buffer~ bassdrum;
#P newex 173 109 95 196617 buffer~ snaredrum;
#P newex 173 149 69 196617 buffer~ hihat;
#P inlet 21 30 15 0;
#P inlet 38 30 15 0;
#P inlet 55 30 15 0;
#P outlet 73 174 15 0;
#P connect 3 0 11 0;
#P connect 2 0 14 0;
#P connect 1 0 17 0;
#P connect 11 1 10 0;
#P connect 11 0 9 0;
#P connect 10 0 9 0;
#P connect 14 1 13 0;
#P connect 14 0 12 0;
#P connect 13 0 12 0;
#P connect 17 1 16 0;
#P connect 17 0 15 0;
#P connect 16 0 15 0;
#P connect 9 0 0 0;
#P connect 12 0 0 0;
#P connect 15 0 0 0;
#P connect 7 0 6 0;
#P connect 8 0 5 0;
#P connect 18 0 4 0;
#P pop;
#P newobj 30 273 79 196617 p samplePlayer;
#P button 30 132 15 0;
#P comment 47 132 74 196617 Clear sequence;
#N vpatcher 154 94 686 691;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 415 254 32 196617 print;
#P newex 342 115 60 196617 route clear;
#P newex 172 498 44 196617 zl nth 1;
#P newex 161 257 27 196617 f 1.;
#P newex 117 317 32 196617 sel 1;
#P newex 117 277 27 196617 t f f;
#P newex 117 297 27 196617 < 0.;
#P newex 117 237 27 196617 + 0.;
#P newex 147 237 27 196617 f;
#P newex 217 115 29 196617 t f b;
#P newex 286 154 40 196617 t clear;
#P newex 117 337 31 196617 t 0 b;
#P newex 117 257 31 196617 % 1.;
#P newex 135 526 36 196617 zl reg;
#P newex 97 525 27 196617 i;
#P newex 97 379 27 196617 t i i;
#P newex 97 545 27 196617 + 1;
#P newex 117 217 35 196617 * 0.5;
#P newex 117 197 46 196617 / 1000.;
#P newex 117 177 27 196617 – 0.;
#P newex 97 360 27 196617 i;
#P newex 97 504 41 196617 sel 1 0;
#P newex 97 484 27 196617 &&;
#P newex 97 137 30 196617 t b b;
#P newex 97 424 44 196617 zl nth 1;
#P newex 97 444 29 196617 t f f;
#P newex 131 464 27 196617 < 0.;
#P newex 97 96 40 196617 t i i 0;
#P newex 168 157 48 196617 cpuclock;
#P newex 168 137 32 196617 sel 1;
#P newex 97 117 46 196617 metro 2;
#P newex 97 464 33 196617 >= 0.;
#N coll events 1;
#P newobj 97 404 68 196617 coll events 1;
#P newex 117 157 48 196617 cpuclock;
#P newex 217 96 40 196617 / 240.;
#N comlet (bool) play;
#P inlet 97 76 15 0;
#N comlet (bang) clear;
#P inlet 286 76 15 0;
#N comlet (float , bars) loop length;
#P inlet 178 76 15 0;
#N comlet (list) event to add;
#P inlet 347 76 15 0;
#N comlet (int , bpm) tempo;
#P inlet 217 76 15 0;
#P outlet 135 548 15 0;
#P message 347 215 53 196617 renumber;
#P message 362 195 52 196617 sort -1 0;
#P newex 377 174 84 196617 prepend insert 1;
#P newex 347 154 40 196617 t b b l;
#P window linecount 3;
#P comment 217 500 114 196617 * amended to remove velocity value , until sampler is modified;
#P connect 10 0 18 0;
#P connect 18 0 15 0;
#P connect 15 0 22 0;
#P fasten 29 0 25 0 102 565 85 565 85 356 102 356;
#P connect 22 0 25 0;
#P connect 25 0 30 0;
#P fasten 3 0 13 0 367 401 102 401;
#P fasten 35 0 13 0 291 401 102 401;
#P connect 30 0 13 0;
#P fasten 4 0 13 0 352 401 102 401;
#P fasten 2 0 13 0 382 401 102 401;
#P connect 13 0 21 0;
#P connect 21 0 20 0;
#P connect 20 0 14 0;
#P connect 14 0 23 0;
#P connect 23 0 24 0;
#P connect 24 0 31 0;
#P connect 31 0 29 0;
#P connect 34 0 25 1;
#P connect 19 0 23 1;
#P connect 30 1 31 1;
#P connect 22 1 12 0;
#P connect 12 0 26 0;
#P connect 26 0 27 0;
#P connect 27 0 28 0;
#P connect 28 0 38 0;
#P connect 38 0 33 0;
#P connect 33 0 40 0;
#P connect 40 1 39 0;
#P connect 39 0 41 0;
#P connect 41 0 34 0;
#P connect 20 1 19 0;
#P connect 17 0 26 1;
#P connect 37 0 38 1;
#P connect 40 0 39 1;
#P connect 24 0 32 0;
#P connect 32 0 5 0;
#P connect 42 0 33 1;
#P connect 36 0 28 1;
#P connect 36 1 37 0;
#P connect 18 2 37 0;
#P connect 33 0 19 1;
#P connect 34 1 42 0;
#P connect 43 0 32 1;
#P connect 33 0 37 1;
#P connect 18 1 16 0;
#P connect 36 1 17 0;
#P connect 16 0 17 0;
#P connect 21 1 43 0;
#P connect 8 0 42 1;
#P connect 6 0 11 0;
#P connect 11 0 36 0;
#P connect 9 0 35 0;
#P connect 44 0 35 0;
#P connect 7 0 44 0;
#P connect 44 1 1 0;
#P connect 1 0 4 0;
#P connect 1 1 3 0;
#P connect 1 2 2 0;
#P connect 4 0 45 0;
#P connect 3 0 45 0;
#P connect 2 0 45 0;
#P connect 35 0 45 0;
#P pop;
#P newobj 30 160 66 196617 p sequencer;
#B color 5;
#P hidden newex 135 108 60 196617 loadmess 1;
#P flonum 30 108 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 67 108 64 196617 Bars to loop;
#P user ezdac~ 30 297 74 330 0;
#P button 98 227 15 0;
#P button 64 227 15 0;
#P button 30 227 15 0;
#P hidden newex 100 84 72 196617 loadmess 136;
#P newex 30 206 112 196617 route bd sd hh;
#P toggle 30 59 15 0;
#P comment 46 59 29 196617 Play;
#P number 30 84 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 67 84 28 196617 Bpm;
#P hidden fasten 20 1 22 0 562 232 290 232;
#P hidden fasten 20 1 23 1 562 344 368 344;
#P connect 19 0 23 0;
#P hidden fasten 22 1 19 0 316 262 290 262;
#P hidden fasten 22 0 21 0 290 255 290 255;
#P connect 26 0 25 0;
#P connect 8 0 16 2;
#P connect 4 2 8 0;
#P hidden fasten 25 0 13 4 201 154 91 154;
#P hidden fasten 24 0 13 4 259 157 91 157;
#P hidden connect 15 0 13 3;
#P connect 16 0 9 0;
#P connect 16 0 9 1;
#P connect 7 0 16 1;
#P connect 4 1 7 0;
#P hidden fasten 1 0 13 2 35 154 63 154;
#P hidden fasten 11 0 13 1 35 154 49 154;
#P connect 6 0 16 0;
#P connect 4 0 6 0;
#P connect 13 0 4 0;
#P hidden connect 3 0 13 0;
#P hidden connect 12 0 11 0;
#P hidden connect 5 0 1 0;
#P window clipboard copycount 29;


August 6, 2007 | 1:42 pm

Hi justin,

I added some stuff that I think solves the problems you describe:

#N vpatcher 30 89 460 415;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 40 255 65 196617 s eventsColl;
#P newex 109 60 60 196617 route clear;
#P newex 40 81 40 196617 t clear;
#N comlet (bang) clear all;
#P inlet 40 41 15 0;
#N comlet (list) event to add;
#P inlet 109 41 15 0;
#P message 240 161 53 196617 renumber;
#P message 255 141 52 196617 sort -1 0;
#P newex 270 120 84 196617 prepend insert 1;
#P newex 240 100 40 196617 t b b l;
#P newex 109 141 20 196617 t b;
#P newex 109 181 82 196617 prepend remove;
#P newex 109 161 27 196617 i;
#P newex 109 121 36 196617 zl sub;
#P window linecount 0;
#P newex 109 81 46 196617 t dump l;
#P newex 109 101 89 196617 grab 2 eventsColl;
#P connect 11 0 12 0;
#P fasten 4 0 14 0 114 237 45 237;
#P fasten 7 0 14 0 275 237 45 237;
#P fasten 9 0 14 0 245 237 45 237;
#P fasten 8 0 14 0 260 237 45 237;
#P fasten 12 0 14 0 45 187 45 187;
#P connect 10 0 13 0;
#P connect 13 0 1 0;
#P connect 1 0 0 0;
#P connect 0 0 2 0;
#P connect 2 0 5 0;
#P connect 5 0 3 0;
#P connect 3 0 4 0;
#P connect 0 1 3 1;
#P connect 1 1 2 1;
#P connect 13 1 6 0;
#P connect 6 0 9 0;
#P connect 6 1 8 0;
#P connect 6 2 7 0;
#P pop;
#P newobj 207 114 76 196617 p editSequence;
#P comment 375 159 21 196617 BD;
#P comment 402 229 331 196617 1. insert some velocity values below , you dont need to press clear;
#N vpatcher 518 67 824 385;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 34 204 29 196617 gate;
#P newex 34 184 27 196617 != 0;
#P newex 34 224 76 196617 pack 0. sd 127;
#P newex 132 224 69 196617 pack clear sd;
#P newex 53 124 58 196617 unpack 0 0;
#P newex 53 104 52 196617 listfunnel;
#P comment 207 224 56 196617 send clear;
#N comlet seq size;
#P inlet 207 46 15 0;
#P newex 207 97 37 196617 int 16;
#P newex 34 250 35 196617 s edit;
#P newex 53 84 27 196617 t l b;
#P newex 53 163 45 196617 / 16.;
#P window linecount 0;
#P newex 53 64 62 196617 mousefilter;
#N comlet seq list;
#P inlet 53 46 15 0;
#P comment 66 184 100 196617 remove 0 velocity from sequence;
#P connect 10 1 13 0;
#P connect 13 0 14 0;
#P connect 14 0 12 0;
#P connect 12 0 5 0;
#P fasten 11 0 5 0 137 246 39 246;
#P connect 1 0 2 0;
#P connect 2 0 4 0;
#P connect 4 0 9 0;
#P connect 9 0 10 0;
#P connect 10 0 3 0;
#P connect 3 0 14 1;
#P fasten 6 0 3 1 212 159 93 159;
#P connect 10 1 12 2;
#P connect 4 1 11 0;
#P connect 7 0 6 0;
#P pop;
#P newobj 402 357 88 196617 p multislid_parse;
#N vpatcher 10 59 280 364;
#N comlet position UI;
#P outlet 22 89 15 0;
#N comlet seq UI;
#P outlet 106 89 15 0;
#P window setfont "Sans Serif" 9.;
#P message 22 64 83 196617 setminmax 0 $1;
#P message 106 64 43 196617 size $1;
#P inlet 22 37 15 0;
#P connect 0 0 2 0;
#P connect 2 0 4 0;
#P fasten 0 0 1 0 27 58 111 58;
#P connect 1 0 3 0;
#P pop;
#P hidden newobj 402 248 36 196617 p size;
#P user multiSlider 402 268 256 10 0. 32. 1 2664 15 0 0 2 0 0 0;
#M frgb 0 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P noclick;
#P user umenu 659 268 25 196647 1 64 284 1;
#X setrgb 0 0 0 255 255 255 255 255 255 221 221 221 170 170 170 119 119 119 187 187 187;
#X add 16;
#X add 32;
#P user multiSlider 402 279 256 64 0. 127. 32 2921 15 0 0 2 4 0 0;
#M frgb 150 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 0 0 0;
#M rgb5 75 0 0;
#M rgb6 0 0 0;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P comment 402 57 331 196617 1. insert some velocity values below , you dont need to press clear;
#P button 273 57 15 0;
#N vpatcher 10 59 336 464;
#P inlet 64 24 15 0;
#P outlet 40 359 15 0;
#P window setfont "Sans Serif" 9.;
#P comment 81 45 96 196617 Add these events;
#P message 64 163 77 196617 0.5625 sd 127;
#P button 64 45 15 0;
#P hidden newex 40 328 18 196617 t l;
#P message 64 181 65 196617 0.75 sd 127;
#P message 64 145 65 196617 0.25 sd 127;
#P message 64 330 71 196617 0.875 hh 127;
#P message 64 312 65 196617 0.75 hh 127;
#P message 64 294 71 196617 0.625 hh 127;
#P message 64 276 59 196617 0.5 hh 127;
#P message 64 258 71 196617 0.375 hh 127;
#P message 64 240 65 196617 0.25 hh 127;
#P message 64 222 71 196617 0.125 hh 127;
#P message 64 204 53 196617 0. hh 127;
#P message 64 120 65 196617 0.75 bd 127;
#P message 64 102 59 196617 0.5 bd 127;
#P message 64 84 65 196617 0.25 bd 127;
#P message 64 66 53 196617 0. bd 127;
#P hidden connect 0 0 14 0;
#P hidden connect 11 0 14 0;
#P hidden connect 10 0 14 0;
#P hidden connect 9 0 14 0;
#P hidden connect 8 0 14 0;
#P hidden connect 7 0 14 0;
#P hidden connect 6 0 14 0;
#P hidden connect 5 0 14 0;
#P hidden connect 4 0 14 0;
#P hidden connect 13 0 14 0;
#P hidden connect 12 0 14 0;
#P hidden connect 3 0 14 0;
#P hidden connect 2 0 14 0;
#P hidden connect 1 0 14 0;
#P hidden connect 16 0 14 0;
#P connect 14 0 18 0;
#P connect 19 0 15 0;
#P hidden connect 15 0 0 0;
#P hidden connect 15 0 1 0;
#P hidden connect 15 0 2 0;
#P hidden connect 15 0 3 0;
#P hidden connect 15 0 12 0;
#P hidden connect 15 0 16 0;
#P hidden connect 15 0 13 0;
#P hidden connect 15 0 4 0;
#P hidden connect 15 0 5 0;
#P hidden connect 15 0 6 0;
#P hidden connect 15 0 7 0;
#P hidden connect 15 0 8 0;
#P hidden connect 15 0 9 0;
#P hidden connect 15 0 10 0;
#P hidden connect 15 0 11 0;
#P pop;
#P newobj 273 76 57 196617 p test_seq;
#P newex 285 114 35 196617 r edit;
#N vpatcher 518 67 824 385;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 34 204 29 196617 gate;
#P newex 34 184 27 196617 != 0;
#P newex 34 224 76 196617 pack 0. bd 127;
#P newex 132 224 69 196617 pack clear bd;
#P newex 53 124 58 196617 unpack 0 0;
#P newex 53 104 52 196617 listfunnel;
#P comment 207 224 56 196617 send clear;
#N comlet seq size;
#P inlet 207 46 15 0;
#P newex 207 97 37 196617 int 16;
#P newex 34 250 35 196617 s edit;
#P newex 53 84 27 196617 t l b;
#P newex 53 163 45 196617 / 16.;
#P window linecount 0;
#P newex 53 64 62 196617 mousefilter;
#N comlet seq list;
#P inlet 53 46 15 0;
#P comment 66 184 100 196617 remove 0 velocity from sequence;
#P connect 10 1 13 0;
#P connect 13 0 14 0;
#P connect 14 0 12 0;
#P connect 12 0 5 0;
#P fasten 11 0 5 0 137 246 39 246;
#P connect 1 0 2 0;
#P connect 2 0 4 0;
#P connect 4 0 9 0;
#P connect 9 0 10 0;
#P connect 10 0 3 0;
#P connect 3 0 14 1;
#P fasten 6 0 3 1 212 159 93 159;
#P connect 10 1 12 2;
#P connect 4 1 11 0;
#P connect 7 0 6 0;
#P pop;
#P newobj 402 185 88 196617 p multislid_parse;
#N vpatcher 10 59 280 364;
#N comlet position UI;
#P outlet 22 89 15 0;
#N comlet seq UI;
#P outlet 106 89 15 0;
#P window setfont "Sans Serif" 9.;
#P message 22 64 83 196617 setminmax 0 $1;
#P message 106 64 43 196617 size $1;
#P inlet 22 37 15 0;
#P connect 0 0 2 0;
#P connect 2 0 4 0;
#P fasten 0 0 1 0 27 58 111 58;
#P connect 1 0 3 0;
#P pop;
#P hidden newobj 402 76 36 196617 p size;
#P user multiSlider 402 96 256 10 0. 16. 1 2664 15 0 0 2 0 0 0;
#M frgb 0 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P noclick;
#P user umenu 659 96 25 196647 1 64 112 1;
#X setrgb 0 0 0 255 255 255 255 255 255 221 221 221 170 170 170 119 119 119 187 187 187;
#X add 16;
#X add 32;
#P user multiSlider 402 107 256 64 0. 127. 16 2921 15 0 0 2 4 0 0;
#M frgb 150 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 0 0 0;
#M rgb5 75 0 0;
#M rgb6 0 0 0;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#N vpatcher 40 104 630 470;
#P window setfont "Sans Serif" 9.;
#P newex 306 242 35 196617 *~ 1.;
#P newex 284 162 27 196617 t b i;
#P newex 331 183 40 196617 / 127.;
#P newex 284 183 32 196617 t 0 1;
#P newex 174 242 35 196617 *~ 1.;
#P newex 152 162 27 196617 t b i;
#P newex 199 183 40 196617 / 127.;
#P newex 152 183 32 196617 t 0 1;
#P newex 21 162 27 196617 t b i;
#P newex 68 183 40 196617 / 127.;
#P window linecount 1;
#P newex 43 241 35 196617 *~ 1.;
#P window linecount 0;
#P newex 403 112 145 196617 loadmess replace 808hh01.aif;
#P window linecount 1;
#P newex 306 203 29 196617 sig~;
#P window linecount 0;
#P newex 306 222 72 196617 groove~ hihat;
#P window linecount 1;
#P newex 174 203 29 196617 sig~;
#P window linecount 0;
#P newex 174 222 98 196617 groove~ snaredrum;
#P newex 21 183 32 196617 t 0 1;
#P newex 43 203 29 196617 sig~;
#P newex 43 222 93 196617 groove~ bassdrum;
#P newex 403 73 145 196617 loadmess replace 808sd01.aif;
#P newex 403 34 145 196617 loadmess replace 808bd01.aif;
#P newex 403 53 90 196617 buffer~ bassdrum;
#P newex 403 92 95 196617 buffer~ snaredrum;
#P newex 403 131 69 196617 buffer~ hihat;
#P inlet 21 30 15 0;
#P inlet 38 30 15 0;
#P inlet 55 30 15 0;
#P outlet 43 303 15 0;
#P connect 3 0 19 0;
#P connect 19 0 11 0;
#P connect 11 1 10 0;
#P connect 11 0 9 0;
#P connect 10 0 9 0;
#P connect 9 0 17 0;
#P fasten 23 0 0 0 179 279 48 279;
#P connect 17 0 0 0;
#P fasten 27 0 0 0 311 279 48 279;
#P connect 19 1 18 0;
#P connect 18 0 17 1;
#P connect 2 0 22 0;
#P connect 22 0 20 0;
#P connect 20 1 13 0;
#P connect 20 0 12 0;
#P connect 13 0 12 0;
#P connect 12 0 23 0;
#P connect 22 1 21 0;
#P connect 21 0 23 1;
#P connect 1 0 26 0;
#P connect 26 0 24 0;
#P connect 24 1 15 0;
#P connect 24 0 14 0;
#P connect 15 0 14 0;
#P connect 14 0 27 0;
#P connect 26 1 25 0;
#P connect 25 0 27 1;
#P connect 7 0 6 0;
#P connect 8 0 5 0;
#P connect 16 0 4 0;
#P pop;
#P newobj 26 227 79 196617 p samplePlayer;
#P button 207 39 15 0;
#P comment 224 39 74 196617 Clear sequence;
#N vpatcher 1342 48 1614 619;
#P window setfont "Sans Serif" 9.;
#P newex 109 366 65 196617 r eventsColl;
#P newex 103 219 27 196617 f 1.;
#P newex 59 279 32 196617 sel 1;
#P newex 59 239 27 196617 t f f;
#P newex 59 259 27 196617 < 0.;
#P newex 59 199 27 196617 + 0.;
#P newex 89 199 27 196617 f;
#P newex 159 77 29 196617 t f b;
#P newex 59 299 31 196617 t 0 b;
#P newex 59 219 31 196617 % 1.;
#P newex 77 488 36 196617 zl reg;
#P newex 39 487 27 196617 i;
#P newex 39 341 27 196617 t i i;
#P newex 39 507 27 196617 + 1;
#P newex 59 179 35 196617 * 0.5;
#P newex 59 159 46 196617 / 1000.;
#P newex 59 139 27 196617 – 0.;
#P newex 39 322 27 196617 i;
#P newex 39 466 41 196617 sel 1 0;
#P newex 39 446 27 196617 &&;
#P newex 39 99 30 196617 t b b;
#P newex 39 386 44 196617 zl nth 1;
#P newex 39 406 29 196617 t f f;
#P newex 73 426 27 196617 < 0.;
#P newex 39 58 40 196617 t i i 0;
#P newex 110 119 48 196617 cpuclock;
#P newex 110 99 32 196617 sel 1;
#P newex 39 79 46 196617 metro 2;
#P newex 39 426 33 196617 >= 0.;
#N coll events 1;
#P newobj 39 366 68 196617 coll events 1;
#P newex 59 119 48 196617 cpuclock;
#P newex 159 58 40 196617 / 240.;
#N comlet (bool) play;
#P inlet 39 38 15 0;
#N comlet (float , bars) loop length;
#P inlet 120 38 15 0;
#N comlet (int , bpm) tempo;
#P inlet 159 38 15 0;
#P outlet 77 510 15 0;
#P connect 3 0 11 0;
#P connect 11 0 8 0;
#P connect 8 0 15 0;
#P fasten 22 0 18 0 44 527 27 527 27 318 44 318;
#P connect 15 0 18 0;
#P connect 18 0 23 0;
#P connect 35 0 6 0;
#P connect 23 0 6 0;
#P connect 6 0 14 0;
#P connect 14 0 13 0;
#P connect 13 0 7 0;
#P connect 7 0 16 0;
#P connect 16 0 17 0;
#P connect 17 0 24 0;
#P connect 24 0 22 0;
#P connect 27 0 18 1;
#P connect 12 0 16 1;
#P connect 23 1 24 1;
#P connect 15 1 5 0;
#P connect 5 0 19 0;
#P connect 19 0 20 0;
#P connect 20 0 21 0;
#P connect 21 0 30 0;
#P connect 30 0 26 0;
#P connect 26 0 32 0;
#P connect 32 1 31 0;
#P connect 31 0 33 0;
#P connect 33 0 27 0;
#P connect 13 1 12 0;
#P connect 10 0 19 1;
#P connect 29 0 30 1;
#P connect 32 0 31 1;
#P connect 17 0 25 0;
#P connect 25 0 0 0;
#P connect 34 0 26 1;
#P connect 28 0 21 1;
#P connect 28 1 29 0;
#P connect 11 2 29 0;
#P connect 26 0 12 1;
#P connect 27 1 34 0;
#P connect 14 1 25 1;
#P connect 26 0 29 1;
#P connect 11 1 9 0;
#P connect 28 1 10 0;
#P connect 9 0 10 0;
#P connect 2 0 34 1;
#P connect 1 0 4 0;
#P connect 4 0 28 0;
#P pop;
#P newobj 26 114 66 196617 p sequencer;
#P hidden newex 131 88 60 196617 loadmess 1;
#P flonum 26 88 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 63 88 64 196617 Bars to loop;
#P user ezdac~ 26 251 70 284 0;
#P button 110 181 15 0;
#P button 76 181 15 0;
#P button 42 181 15 0;
#P hidden newex 96 64 72 196617 loadmess 136;
#P newex 26 160 112 196617 route bd sd hh;
#P toggle 26 39 15 0;
#P comment 42 39 29 196617 Play;
#P number 26 64 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 63 64 28 196617 Bpm;
#P comment 376 329 21 196617 SD;
#P hidden fasten 28 1 30 0 679 244 407 244;
#P hidden fasten 28 1 31 1 679 356 485 356;
#P hidden fasten 19 1 21 0 679 72 407 72;
#P hidden fasten 19 1 22 1 679 184 485 184;
#P connect 27 0 31 0;
#P hidden fasten 30 1 27 0 433 274 407 274;
#P hidden fasten 30 0 29 0 407 267 407 267;
#P connect 18 0 22 0;
#P hidden fasten 21 1 18 0 433 102 407 102;
#P hidden fasten 21 0 20 0 407 95 407 95;
#P connect 23 0 34 1;
#P connect 24 0 34 1;
#P connect 25 0 24 0;
#P hidden connect 16 0 34 0;
#P connect 5 2 9 0;
#P connect 5 2 17 2;
#P hidden fasten 2 0 14 2 31 108 87 108;
#P connect 5 1 17 1;
#P connect 5 1 8 0;
#P connect 17 0 10 0;
#P connect 17 0 10 1;
#P hidden fasten 12 0 14 1 31 108 59 108;
#P connect 5 0 17 0;
#P connect 5 0 7 0;
#P connect 14 0 5 0;
#P hidden connect 4 0 14 0;
#P hidden connect 13 0 12 0;
#P hidden connect 6 0 2 0;

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


August 6, 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


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